Методы структурного анализа и проектирования ПО. Тема 2

1. Методы структурного анализа и проектирования ПО

1

2.

Структурный анализ — один из формализованных
методов анализа требований и проектирования ПО
(автор Том Де Марко).
Основная задача – описание:
а) функциональной структуры системы;
б) последовательности выполняемых действий;
в) передачи информации между функциональными
процессами;
г) отношений между данными.
Модели структурного анализа и проектирования:
1. Функциональная модель SADT (Structured Analysis and
Design Technique);
2. DFD (Data Flow Diagrams) – диаграммы потоков
данных;
3. Модель IDEF3;
2

3.

DFD
(Data
Flow
Diagrams)
–
иерархия
функциональных процессов, связанных потоками
данных.
Метод SADT (IDEF0) – совокупность правил и
процедур, предназначенных для построения
функциональной модели объекта какой-либо
предметной области (производимые действия и
связи между ними).
Модель IDEF3 – предназначена для моделирования
последовательности выполняемых действий и
взаимозависимости между ними, основа модели –
сценарий процесса.
3

4.

Модель DFD
Для изображения диаграмм потоков данных (DFD) традиционно
используют два вида нотаций: нотации Йордана и Гейна-Сарсона
4

5.

В основе модели лежат понятия внешней сущности,
процесса, хранилища (накопителя) данных и потока
данных.
Внешняя сущность - материальный объект или
физическое лицо, выступающие в качестве источников или
приемников информации, например, заказчики, персонал,
поставщики, клиенты, банк и т. п.
Процесс - преобразование входных потоков данных в
выходные в соответствии с определенным алгоритмом.
Каждый процесс в системе имеет свой номер и связан с
исполнителем,
который
осуществляет
данное
преобразование.
На верхних уровнях иерархии, когда процессы еще не
определены, вместо понятия «процесс» используют
понятия «система» и «подсистема», которые обозначают
соответственно систему в целом или ее функционально
законченную часть.
5

6.

Хранилище данных - абстрактное устройство для
хранения информации. Тип устройства и способы
помещения, извлечения и хранения для такого
устройства не детализируют. Физически это может
быть база данных, файл, таблица в оперативной
памяти, картотека на бумаге и т. п.
Поток данных — процесс передачи некоторой
информации от источника к приемнику.
Физически процесс передачи информации может
происходить по кабелям под управлением программы
или программной системы или вручную при участии
устройств или людей вне проектируемой системы.
6

7.

Пример потока данных (нотация
Гейна-Сарсона)
Над линией потока, направление которого
обозначают стрелкой, указывают, какая конкретно
информация в данном случае передается
7

8.

Построение иерархии диаграмм потоков данных
начинают с диаграммы особого вида - контекстной
диаграммы, которая определяет наиболее общий
вид системы.
На
такой
диаграмме
показывают,
как
разрабатываемая система будет взаимодействовать
с приемниками и источниками информации без
указания исполнителей, т. е. описывают интерфейс
между системой и внешним миром.
8

9. Методология структурного моделирования SADT

Методология SADT (Structured Analysis and Design
Technique) была создана и опробована на практике в
период с 1969 по 1973 гг. Автором методологии SADT
является Дуглас Росс.
Предназначения для моделирования систем на основе
принципов структурного анализа.
Методология
предлагает графический язык проектирования систем, в
котором сочетаются декомпозиция и иерархическое
упорядочение и для обозначения составляющих системы
используется графическая конструкция, называемая SAблок.
9

10. Предпосылки создания SADT

Возрастание сложности проектируемых систем.
Необходимость формализации процесса разработки при создании
крупномасштабных систем.
Процесс разработки систем был формально разбит на этапы:
1.
Анализ –определение того, что система будет делать
2.
Проектирование – определение подсистем и их взаимодействие
3.
Реализация – разработка подсистем по отдельности
4.
Обьединение – сборка подсистем в целое
5.
Тестирование – проверка работы системы
6.
Установка – введение системы в действие
7.
Функционирование – использование системы
Данная последовательность этапов разработки стала традиционной
10

11. Проблемы традиционного подхода

• Неучастие пользователя в процессе разработки.
• Сложности и отсутствие согласования результатов этапов
разработки.
• Сложности в качественной и количественной оценке
процесса разработки.
• Трудности в выявлении ошибок, допущенных на ранних
этапах разработки системы.
• Неполнота функциональных спецификаций.
• Отсутствие согласованности между спецификациями и
результатами проектирования.
11

12. Результат применения традиционного подхода

• Выявление необходимости совершенствования методов
анализа как ключа к созданию систем, эффективных по
стоимости, производительности и надежности.
• Поиск методологии, применение которой способно было бы
преодолеть выявленные недостаки традиционного подхода.
• Появление и совершенствование методологии структурного
анализа SADT.
12

13. Преимущества SADT

Легко отражает такие системные характеристики как управление,
обратная связь и исполнители,так как возникла на базе проектирования
систем общего вида в отличие от структурных методов, «выросших» из
проектирования программного обеспечения.
Имеет развитые процедуры поддержки коллективной работы.
Применяется на ранних стадиях создания системы, что позволяет
избежать наиболее дорогостоящих ошибок.
Успешно сочетается с другими структурными методами.
Разработка и широкое успешное использование ее графического
языка превратило SADT в методологию, способную значительно
повысить качество продуктов, создаваемых на ранних этапах
проектов.
13

14. Сущность структурного подхода

Система декомпозируется (разбивается) на
функциональные подсистемы до нужной
степени детализации.
Базовые принципы:
• принцип «разделяй и властвуй».
• принцип иерархического упорядочивания
14

15. Использование SADT

Методология SADT может использоваться для
моделирования широкого круга систем и определения
требований и функций, а затем для разработки системы,
которая удовлетворяет этим требованиям и реализует эти
функции. Для уже существующих систем SADT может быть
использована для анализа функций, выполняемых системой, а
также для указания механизмов, посредством которых они
осуществляются.
15

16.

Методология SADT может быть направлена как для описания
функций, выполняемых системой, так и на описание объектов,
составляющих систему.
В первом случае методология SADT
представляет собой
совокупность методов, правил и процедур, предназначенных для
построения функциональной модели объекта какой-либо предметной
области. Функциональная модель SADT отображает функциональную
структуру объекта, т.е. производимые им действия и связи между этими
действиями.
Во-втором случае методология SADT представляет собой
совокупность методов, правил и процедур, предназначенных для
описания обьектов, входящих в систему, их свойств и взаимосвязей
между ними
16

17. Методологии SADT

• IDEF0 (Icam Definition) модели и соответствующие
функциональные диаграммы.
• DFD (Data Flow Diagrams) диаграммы потоков
данных.
• ERD (Entity-Relationship Diagrams) диаграммы
"сущность-связь«.
17

18. Методология функционального моделирования IDEF0

Методология функционального моделирования
IDEF0 (Icam DEFinition) была разработана на
основе SADT и являлась основной частью
программы ICAM (Интеграция компьютерных и
промышленных технологий), проводимой по
инициативе ВВС США.
18

19. Принципы функционального моделирования. Основные понятия.

• Система – совокупность взаимодействующих компонент и взаимосвязей
между ними.
• Моделирование – процесс создания точного описания системы.
• SADTмодель – полное, точное и адекватное описание системы, имеющее
конкретное назначение, которое называется целью модели. SADTмодель
может быть сосредоточена либо на функциях системы (функциональная
модель), либо на ее обьектах (модель данных).
• Цель модели – получение ответов на некоторую совокупность вопросов
относительно системы. Список вопросов сводится к одной-двум фразам,
которые и формулируют цель.
19

20.

• Субьект моделирования – сама система.
• Границы системы - точно определяют, что является и что не является
субьектом моделирования, что входит в систему и что лежит за ее
пределами. SADT-модель всегда имеет единственный субьект.
• Точка зрения – позиция, с которой наблюдается система и создается ее
модель. Это позиция человека или обьекта, в которую нужно встать, чтобы
увидеть систему в действии.
В процессе моделирования субьект определяет, что включить в модель, а
что исключить из нее. Точка зрения диктует выбор нужной информации о
субьекте и форму ее подачи. Цель становится критерием окончания
моделирования.
20

21. Концепции IDEF0

IDEF0-Модель отображает систему в виде иерархии диаграмм.
Каждая диаграмма содержит блоки и дуги.
Диаграмма в виде блока отображает функцию. Блоки имеют
доминирование;
Интерфейсы входа/выхода представляются дугами, входящими в
блок и выходящими из него;
Интерфейсные дуги показывают взаимодействие блоков друг с
другом;
Интерфейсные дуги выражают "ограничения", определяющие,
когда и каким образом функции выполняются и управляются.
21

22. Правила IDEF0

• Диаграмма, лежащая на вершине иерархии, называется контекстной.
На этой диаграмме вся система представляется в виде единого
функционального блока.
• Следующей в иерархии является диаграмма декомпозиции контекстной
диаграммы. На ней функциональный блок контекстной диаграммы
декомпозируется на составляющие его функциональные блоки. Каждый
из этих блоков может иметь свою диаграмму декомпозиции.
• Количество блоков на каждом уровне декомпозиции ограничено (может
быть от 3 до 6);
• Диаграммы связаны по номерам блоков;
• Метки и наименования уникальны;
• Входы и управления разделены по роли данных;
• Исключено влияние организационной структуры на функциональную
модель.
22

23. Состав функциональной модели IDEF0

Функциональная модель состоит из диаграмм, фрагментов текстов и
глоссария, имеющих ссылки друг на друга.
Диаграммы - главные компоненты модели, все функции системы и
интерфейсы на них представлены как блоки и дуги.
Место соединения дуги с блоком определяет тип интерфейса.
Управляющая информация входит в блок сверху,информация, которая
подвергается обработке, - слева, результаты выхода - справа стороны.
Механизм (человек или автоматизированная система), который
осуществляет операцию, входит в блок снизу.
23

24. Функциональный блок и интерфейсные дуги

24

25. Иерархия диаграмм

На вершине иерархии находится диаграмма, на которой
система представляется в виде единого блока и дуг,
изображающих интерфейсы с функциями вне системы.
Контекстная диаграмма.
Уровнем ниже находится диаграмма, на которой блок,
представляющий систему в целом, детализируется с
помощью
нескольких
блоков,
соединенных
интерфейсными дугами. Эти блоки представляют
основные подфункции исходной функции.
25

26. Правила декомпозиции функциональных блоков

• Каждая функция может быть декомпозирована на
подфункции;
• Подфункция может содержать только те элементы, которые
входят в исходную функцию;
• Родительский блок и его интерфейсы обеспечивают контекст.
Из модели нельзя выбросить какие-либо элементы или
добавить их;
• Дуги, входящие в блок и выходящие из него на диаграмме
верхнего уровня, являются точно теми же самыми, что и
дуги, входящие в диаграмму нижнего уровня и выходящие из
нее.
26

27. Структура IDEF0-модели. Декомпозиция диаграмм

Структура
IDEF0модели.
Декомпозици
я диаграмм
27

28.

• Каждый блок на диаграмме имеет свой номер.
• Для того, чтобы указать положение любой диаграммы или
блока в иерархии, используются номера диаграмм. Например,
А21 является диаграммой, которая детализирует блок 1 на
диаграмме А2. Аналогично, А2 детализирует блок 2 на
диаграмме А0, которая является самой верхней диаграммой
модели.
28

29. Иерархия диаграмм

29

30. Что отражает модель IDEF3?

В общем случае, процесс – это упорядоченная
последовательность действий.
Следовательно, процессная модель IDEF3
позволяет:
• Отразить последовательность процессов
• Показать логику взаимодействия элементов
системы.
Цель IDEF3 - дать возможность аналитикам описать
ситуацию, когда процессы выполняются в
определенной последовательности, а также
объекты, участвующие совместно в одном
процессе.

31. Основные компоненты IDEF3-модели

Основные компоненты IDEF3модели
Основными элементами IDEF3-модели являются:
1) единицы работ;
2) связи;
3) перекрестки;
4) объекты ссылок.

32. Единицы работ

AT:
AUTHOR: as u
PROJECT: 123
DATE: 18.03.2009
REV: 18.03.2009
Единицы работ
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
CONTEXT:
TOP
• Единица работ (UOW, Unit of Work) является
центральным компонентом модели.
Номер работы
является
уникальным,
присваивается при
ее создании и не
меняется никогда
Им я работы
1.1
Словосочетание с
отглагольным
существительным,
изображающим
действие
(выполнение,
изготовление,…)
Или
Инфинитив глагола
(изготовить
продукцию)

33. Связи

• Связи показывают взаимоотношения работ.
• Связи однонаправлены и могут быть направлены
куда угодно
• Обычно диаграммы рисуют таким образом, чтобы
связи были направлены слева направо
• Различают 3 типа связей:
• Старшая стрелка
• Стрелка отношений
• Поток объектов.

34. Связь «старшая стрелка»

AUTH OR: as u
PROJECT: 123
DATE:
REV:
18.03.2009
18.03.2009
WOR KING
DR AFT
REC OMMEN DED
PUBLICATION
READER
DATE
• Связь типа «временное предшествование» - Precedence
NOTES: 1 2 3 4 5 6 7 8 9 10
• Соединяет единицы работ
• Показывает, что работа-источник должна быть закончена
прежде, чем начнется работа-цель
Принятие
рекомендаций
рецензента
Внесение
исправлений
1.1
1.2
1.1
1.1´ 1.2
1.2´
CONTEXT
TO

35. Стрелка отношений

TH OR: as u
ROJECT: 123
DATE:
REV:
18.03.2009
18.03.2009
WOR KING
DR AFT
REC OMMEN DED
PUBLICATION
READER
• Связь типа нечеткое отношение - Relational
OTES: 1 2 3 4 5 6 7 8 9 10
• Изображается в виде пунктирной линии,
используется для изображения связи между
единицами работ, а также между единицами
работ и объектами ссылок
Принятие
рекомендаций
рецензента
Внесение
исправлений
1.1
1.2
1.1
1.2
1.1´ 1.2´
DATE
CON

36. Поток объектов

HOR: as u
JECT: 123
ES: 1
DATE:
REV:
18.03.2009
18.03.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
• Стрелка, изображающая поток объектов - Object Flow
2 3 4 5 6 7 8 9 10
• Применяется для описания того факта, что объект
используется в двух и более единицах работ,
например, когда объект порождается в одной работе и
используется в другой
Получение
счета
на оплату услуг
1.1
Оплата
1.2
C

37. Перекрестки (соединения)

• Используются для отображения логики взаимодействия
стрелок при их слиянии или разветвлении, для
отображения множества событий, которые могут или
должны быть завершены перед началом следующей
работы.
• Различают перекрестки для слияния и разветвления
стрелок.
• Перекрестки не могут быть одновременно использованы
для слияния и разветвления стрелок.
• Все перекрестки на диаграммах нумеруются, каждый
номер имеет префикс J.
• В отличие от других методологий (IDEF0, DFD) стрелки
могут сливаться или разветвляться только через
перекрестки.

38. Типы перекрестков

Обозначение
Наименов
ание
Смысл в случае
слияния стрелок
Смысл в случае
разветвления стрелок
Асинхрон- Все предшествующие Все последующие
ное «И»
процессы должны
процессы должны быть
быть завершены
Синхронное «И»
запущены
Все предшествующие Все последующие
процессы должны
процессы запускаются
быть завершены
одновременно
одновременно
Асинхрон- Один или несколько
ное
предшествующих
процессов должны
«ИЛИ»
быть завершены
Один или несколько
следующих процессов
должны быть запущены

39. Типы перекрестков

Обозна- Наименов
ание
чение
Смысл в случае
слияния стрелок
Синхронн Один или несколько
ое «ИЛИ» предшествующих
процессов должны
быть завершены
Эксклюзи
вное
(исключа
ющее)
«ИЛИ»
Смысл в случае
разветвления стрелок
Один или несколько
следующих процессов
должны быть
запущены
одновременно
одновременно
Только один
предшествующий
процесс должен
Только один
следующий процесс
быть завершен
запускается

40. Правила создания перекрестков

:
Правила создания перекрестков
1. Каждому перекрестку
для слияния должен
DATE: 18.03.2009
WORKING
READER
предшествовать перекресток
для разветвления.
REV:
18.03.2009
DRAFT
RECOMMENDED
2.
Перекресток
для
слияния
«И»
не
может
следовать за
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
перекрестком для разветвления типа синхронного или
асинхронного «ИЛИ»
AUTHOR: asu
PROJECT: 123
2.1.6
O
2.1.5
&
J1
J2
2.1.7
2.1.8
DAT

41. Правила создания перекрестков

AUTHOR: asu
PROJECT: 123
DATE:
REV:
18.03.2009
18.03.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
3. Перекресток для слияния «И» не может следовать
NOTES: 1за
2 3перекрестком
4 5 6 7 8 9 10
типа исключительного «ИЛИ»
2.1.6
X
2.1.5
&
J1
J2
2.1.7
2.1.8
DAT

42. Правила создания перекрестков

AT:
AUTHOR: asu
PROJECT: 123
DATE:
REV:
18.03.2009
18.03.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Правила создания перекрестков
NOTES: 1 2 3 4 5 6 7 8 9 10
READER
4. Перекресток для слияния типа исключительного «ИЛИ» не
может следовать за перекрестком для разветвления типа
«И»
2.1.6
&
2.1.5
X
J1
J2
2.1.8
2.1.7
5. Перекресток, имеющий одну стрелку на одной стороне,
должен иметь более одной стрелки на другой.
DATE

43. Примеры

UT HOR: asu
ROJECT : р
DAT E: 18 .03.200 9
REV: 18 .03.200 9
WO RKING
READER
DAT E
CON
DRAFT
RECOM MENDED
Примеры
OTES: 1 2 3 4 5 6 7 8 9 10
PUBLICAT ION
1
Включен ие
по жар ной
си гна лизации
1.1 .3
Обн аружени е
по жар а
1.1 .2
Набо р
но ме ра
01
O
J1
1.1 .4
Самосто яте льн ое
тушени е
по жар а
1.1 .5
За пис ь
в жур нале
де журс тв
O
J2
1.1 .6

44. Примеры

RECOM MENDED
1
PUBLI CAT ION
Примеры
Оплата
на личн ыми
1.1 .7
X
X
J4
J3
Безналичная
оп лата
1.1 .8

45. Примеры

RECOMMENDED
PUBLICATION
1
Примеры
Выстрел
из стартового
пистолета
1.1.3
Начало
состязания
1.1.2
Запуск
секундомера
&
J1
1.1.4
J2
Начало
забега
1.1.5
&

46. Комбинации перекрестков

PROJECT: 1
REV: 18.03.2009
DRAFT
RECOMMENDED
PUBLICATION
NOTES: 1 2 3 4 5 6 7 8 9 10
Комбинации перекрестков
• Перекрестки могут комбинироваться для создания
сложных соединений
1.1.3
&
1.1.2
J3
J2
X
&
1.1.4
J1
X
J4
1.1.5
1.1.6

47. Объект ссылок

• выражает идею, концепцию данных, которые
нельзя связать со стрелкой, перекрестком, работой
03.2009
WORKING
READER
DATE CONTEXT:
используется
при
построении
диаграммы
для
03.2009
DRAFT
привлечения
внимания пользователя к каким-либо
RECOMMENDED
важным
аспектам модели
PUBLICATION
1.1
Тип / Имя объекта
ссылок

48. Объект ссылок

• Официальная спецификация IDEF3 различает 3
стиля объектов ссылок – безусловные
(unconditional), синхронные (synchronous),
асинхронные (asynchronous).
• BPWin поддерживает только безусловные
объекты ссылок.

49. Типы объектов ссылок

Тип
объекта
ссылок
Назначение
1. Object
Используется для описания того, что в действии
принимает участие какой-либо заслуживающий
отдельного внимания объект
2. Ссылка
Используется для реализации цикличности
выполнения действий. Этот объект также может
относиться к перекрестку
GOTO
3. Единица Используется для многократного отображения на
действий
диаграмме одного и того же действия, но без цикла
UOB (Unit of
Behavior)

50. Типы объектов ссылок

Тип объекта
ссылок
Назначение
4. Заметка
(Note)
Используется для документирования какой-либо
важной информации общего характера,
относящейся к изображаемому на диаграммах.
Служит альтернативой методу помещения
текстовых заметок непосредственно на диаграммах
5. Уточнение
Elaboration
(ELAB)
Для уточнения или более подробного описания
изображаемого на диаграмме. Обычно
используется для детального описания
разветвления или слияния стрелок на перекрестках

51. Декомпозиция работ в IDEF3

• В IDEF3 декомпозиция используется для
детализации работ.
• Методология IDEF3 позволяет декомпозировать
работу многократно, т.е. работа может иметь
множество дочерних работ.
• Это позволяет в одной модели описать
альтернативные потоки.
• Возможность множественной декомпозиции
предъявляет дополнительные требования к
нумерации работ

52. Нумерация работ в IDEF3

X
Нумерация1.1.2
работ в IDEF3
J2
1.1
J1
• Номер работы состоит из номера родительской
работы, версии декомпозиции и собственного
номера работы на текущей диаграмме
1.1
Номер родительской
работы
Версия
декомпозиции
1.1.7
Собственный номер
единицы работ

53. Структура множественной декомпозиции работ

USED AT:
AUTHOR: Øèëèíà Ì.À.
DATE: 18.03.2009
WORKING
PROJECT: ï
REV: 18.03.2009
DRAFT
READER
DATE CONTE
Структура множественной декомпозиции
работ
RECOMMENDED
AUTHOR: 1
NOTES: 1 2 3 4 5 6 7 8 9 10
PROJECT: 1
PUBLICATION
DATE: 19.03.2009
WORKING
REV:
DRAFT
19.03.2009
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
Первая
декомпозиция
работы 1.2
PUBLICATION
1.1
1.2
2.1.4
2.1.5
Вторая
декомпозиция
работы 1.2
2.2.7
NODE:
1.3
2.1.6
2.2.8
TITLE:
2.2.9
Context
NUMBER:
2.1
READE

54. Пример построения модели IDEF3

• Рассмотрим на примере построения динамической модели
процесса «Выполнение курсовой работы»
• Начнем с построения контекстной диаграммы
Выполнение
курсовой работы
1.1

55. Пример построения модели IDEF3

Выполним декомпозицию контекстной диаграммы:
Выполнение
разделов к/р
Получение
задания
1.1.2
Подбор
литературы
1.1.3
1.1.4
&
&
J1
J2
Посещение
консультаций
Оформление
пояснит.
записки
1.1.6
1.1.5
OBJECT/
Преподаватель
Защита
1.1.7
Примечание: Обратите внимание на нумерацию единиц работ. Родительской является
работа с собственным номером 1. Она декомпозируется первый раз, следовательно,
версия декомпозиции = 1, далее следует собственный номер единицы работ в рамках
модели (2-7).

56. Пример построения модели IDEF3

Выполним декомпозицию UOW №4 – «Выполнение разделов к/р»
ELAB/ Если есть ошибки в
расчетах – внесение
исправлений
Выполнение
расчетов
4.1.9
Написание
теор.части
4.1.8
Оформление
Х
J6
&
&
J3
J4
Построение
графиков
4.1.10
Х
J5
4.1.11

57. Пример построения модели IDEF3

• Продекомпозируем повторно контекстную диаграмму (в виде сценария IDEF3
для выполнения курсовой работы по «Информатике и программированию»)
Построение
блок-схемы
1.2.13
Получение
задания
1.2.12
&
&
J7
Написание
программы
Математическое
моделирование
J8
1.2.15
1.2.14
GOTO/ При обнаружении
ошибок при тестировании
возврат к 1.2.15
Тестирование и
отладка
1.2.16
Оформление
поясн. записки
1.2.17