СТРУКТУРНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

СТРУКТУРНЫЙ ПОДХОД
К ПРОЕКТИРОВАНИЮ
ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
ПРОБЛЕМА СЛОЖНОСТИ
БОЛЬШИХ СИСТЕМ
Основные понятия
Программная инженерия
(software engineering)
определяется как


совокупность инженерных методов и
средств создания ПО
дисциплина, изучающая применение
строгого системного количественного (т.е.
инженерного) подхода к разработке,
эксплуатации и сопровождению ПО
Основные понятия

При проектированию сложной
программной системы ее необходимо
разделять (декомпозировать) на
небольшие подсистемы, каждую из
которых можно разрабатывать
независимо от других.
Основные понятия
Правила декомпозиции:
 Количество связей между
отдельными подсистемами должно
быть минимальным;
 Связность отдельных частей
внутри каждой подсистемы должна
быть максимальной.
Основные понятия
Требования к структуре
 каждая подсистема должна
инкапсулировать свое
содержимое (скрывать его от
других подсистем);
 каждая подсистема должна иметь
четко определенный интерфейс
с другими подсистемами.
CASE (Computer Aided
Software Engineering)

CASE– технология представляет собой
совокупность методов проектирования
ПО, а также набор инструментальных
средств, позволяющих в наглядной
форме моделировать предметную
область, анализировать эту модель на
всех стадиях разработки и
сопровождения ПО и разрабатывать
приложения в соответствии с
информационными потребностями
пользователя
Бизнес–модель

Бизнес–модель –
структурированное графическое
описание сети процессов и
операций, связанных с данными,
документами, организационными
единицами и прочими объектами,
отражающими существующую или
предполагаемую деятельность
предприятия.
Моделирование бизнеспроцессов
Основные подходы к
проектированию ПО


Функционально-модульный или
структурный. В его основу положен принцип
функциональней декомпозиции, при которой
структура системы описывается в терминах
иерархии ее функций и передачи информации
между отдельными функциональными
элементами.
Объектно-ориентированный подход
использует объектную декомпозицию. При этом
структура системы описывается в терминах
объектов и связей между ними, а поведение
системы описывается в терминах обмена
сообщениями между объектами.
Методологии моделирования бизнеспроцессов (Business Process Modeling)
UML
Flow Chart
IDEF0
Модель бизнеспроцесса
IDEF3
DFD
Блок-схемы
ARIS
Методологии моделирования
бизнес-процессов
• Блок-схема
(Block-Diagram)
• Диаграмма
последовательности
(Flow Chart)
• Диаграмма потоков
(Data Flow Diagram)
11
Методологии моделирования
бизнес-процессов
• IDEFO (Функциональное
моделирование)
• Сетевой график
(Activity Network
Diagram)
• Диаграмма процесса
принятия решения
(Process Decision Program
Chart)
Методологии моделирования бизнес-процессов
(нотация eEPS)
Методология Rational Rose
СТРУКТУРНЫЙ ПОДХОД
К ПРОЕКТИРОВАНИЮ
ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
МЕТОД
ФУНКЦИОНАЛЬНОГО
МОДЕЛИРОВАНИЯ SADT
Общие принципы
структурного подхода:
принцип "разделяй и властвуй;
 принцип иерархического
упорядочения;
 принцип абстрагирования;
 принцип непротиворечивости ;
 принцип структурирования
данных.

Декомпозиция процесса
Модели, описывающие
функциональную структуру системы




:
DFD(Data Flow Diagrams) - диаграммы
потоков данных;
SADT(Structured Analysis and Design
technique —метод структурного анализа
и проектирования,) - модели и
соответствующие функциональные
диаграммы;
STD (State Transition Diagrams) диаграммы переходов состояний;
ERD (Entity-Relationship Diagrams)
диаграммы "сущность-связь".
Применение моделей





На стадии формирования требований к ПО SADT, ERD и DFD
используются для построения модели "AS-IS" и модели "ТОВE“
Модели SADT и DFD отражают существующую и
предлагаемую структуру бизнес-процессов организации и
взаимодействие между ними.
С помощью ERD выполняется описание используемых в
организации данных на концептуальном уровне.
На стадии проектирования DFD используются для описания
структуры проектируемой системы ПО, при этом они могут
уточняться, расширяться и дополняться новыми
конструкциями.
На стадии проектирования ERD уточняются и дополняются
новыми конструкциями, описывающими представление
данных на логическом уровне.
История создания



Метод SADT разработан Дугласом Россом
(SoftTech, Inc.) в 1973т.
Метод SADT поддерживается
Министерством обороны США, которое
было инициатором разработки стандарта
IDEFO (Icam DEFinition) - подмножества
SADT, являющегося основной частью
программы IСАМ (Integrated Computer
Aided Manufacturing - интегрированная
компьютеризация производства),
проводимой по инициативе BВС США.
IDEFO был утвержден в качестве
федерального стандарта США.
Метод SADT


Метод SADT представляет собой
совокупность правил и процедур,
предназначенных для построения
функциональной модели объекта
какой-либо предметной области.
Функциональная модель SADT
отображает функциональную структуру
объекта т.е. производимые им действия
и связи между этими действиям.
Концепции метода SADT :
 графическое
представление
блочного моделирования.;
 строгость и точность;
 отделение организации от
функции.
ПОСТРОЕНИЕ ИЕРАРХИИ
ДИАГРАММ


Модель SАDT представляет собой серию
диаграмм с сопроводительной
документацией, разбивающих сложный
объект на составные части, которые
изображены в виде блоков.
На каждом шаге декомпозиции
диаграмма предыдущего уровня
называется родительской для более
детальной диаграммы.
СОСТАВ ФУНКЦИОНАЛЬНОЙ
МОДЕЛИ



Модель состоит из диаграмм, фрагментов
текстов и глоссария, имеющих ссылки
друг на друга.
Диаграммы — главные компоненты
модели, все функции организации и
интерфейсы на них представлены как
блоки и дуги соответственно.
Место соединения дуги с блоком
определяет тип интерфейса.
Нотация IDEF0
Нотация

IDEF0
Взаимодействие с окружающим миром
описывается в терминах входа, выхода,
управления и механизма
Управление
Вход
Выход
Функция
А0
Механизм
Нотация




IDEF0
Входы преобразуются или
расходуются процессом,
чтобы создать то, что
появится на его выходе.
Управления определяют
условия, необходимые
процессу, чтобы
произвести правильный
выход.
Выходы - данные или
материальные объекты,
произведенные процессом.
Механизмы
идентифицируют средства,
поддерживающие
выполнение процесса
Управление
Вход
Функция
Выход
А0
Механизм
Нотация IDEF0
Символ
Блок
Изображение
Описание
Блок описывает процесс.
Внутри каждого блока
помещается его имя и
номер. Имя должно быть
активным глаголом,
глагольным оборотом или
отглагольным
существительным. Номер
блока размещается в
правом нижнем углу.
Номера блоков
используются для
идентификации на
диаграмме и в
соответствующем тексте.
Нотация IDEF0
Символ
Стрелка
Изображение
Описание
Стрелки обозначают входящие
и исходящие из процесса
объекты (данные).
Каждая сторона
функционального блока имеет
стандартное значение с точки
зрения связи блок-стрелка, В
свою очередь, сторона блока, к
которой присоединена стрелка,
однозначно определяет ее
роль.
Нотация IDEF0
Символ Изображение
Описание
Туннелированная
Туннелированные
стрелки означают,
что данные,
обозначаемые этими
стрелками, не
рассматриваются на
родительской
диаграмме и/или на
дочерней диаграмме.
стрелка
Нотация IDEF0
Символ
Внешняя
ссылка
Изображение
Описание
Внешняя ссылка –
место, сущность или
субъект, которые
находятся за
границами
моделируемой
системы.
Используются для
обозначения
источника или
приемника стрелки
Нотация IDEF0
Символ
Междиаграммная ссылка
Изображен Описание
ие
Элемент, обозначающий
другую диаграмму.
Служит для обозначения
перехода стрелок на
диаграмму другого
бизнес-процесса без
показа стрелки на
вышележащей диаграмме
(при использовании
иерархических моделей).
Моделирование бизнес-процесса
.

На первом этапе моделирования
функциональность предприятия
описывается в целом. Такое
описание называется
контекстной диаграммой
ПОСТРОЕНИЕ ИЕРАРХИИ
ДИАГРАММ
1.


Построение SADT-модели начинается с
представления всей системы в виде
простейшего компонента - одного
блока и дуг, изображающих
интерфейсы с функциями вне системы.
Имя, указанное в блоке, является
общим.
Интерфейсные дуги соответствуют
полному набору внешних интерфейсов
системы в целом.
Контекстная диаграмма
Общее представление
А0
А0
ПОСТРОЕНИЕ ИЕРАРХИИ
ДИАГРАММ
2.


Блок, который представляет систему в
качестве единого модуля,
детализируется на другой диаграмме с
помощью нескольких блоков,
соединенных интерфейсными дугами.
Эти блоки определяют основные
подфункции исходной функции.
Каждая из этих подфункций может
быть декомпозирована подобным
образом в целях большей
детализации.
ПОСТРОЕНИЕ ИЕРАРХИИ
ДИАГРАММ

Дуги, входящие в блок и
выходящие из него на диаграмме
верхнего уровня, являются точно
теми же самыми, что и дуги,
входящие в диаграмму нижнего
уровня и выходящие из нее,
потому что блок и диаграммы
изображают одну и ту же часть
системы.
Более детальное
представление
А1
А2
А3
Моделирование бизнес-процесса

Каждая
подфункция
декомпозируетс
я на более
мелкие – и так
далее до
достижения
необходимой
детализации
описания
Декомпозиция
ПОСТРОЕНИЕ ИЕРАРХИИ ДИАГРАММ




Неприсоединенным дуги
соответствуют входам,
управлениям и выходам
родительского блока.
Источник или получатель
пограничных дуг может быть
обнаружен только на
родительской диаграмме.
Неприсоединенные концы
должны соответствовать дугам
на исходной диаграмме.
Все граничные дуги должны
продолжаться на родительской
диаграмме, чтобы она была
полной и непротиворечивой.
А11
А12
А13
Дуги перенолсятся с
родительской
диаграммы
А121
А122
А123
ПОСТРОЕНИЕ ИЕРАРХИИ ДИАГРАММ



На SADT-диаграммах не
указаны явно ни
последовательность, ни
время.
Обратные связи, итерации,
продолжающиеся процессы и
перекрывающиеся (по
времени) функции могут быть
изображены с помощью дуг.
Обратные связи могyr
выступать в вида
комментариев, замечаний,
исправлений и т. д
Системные требования
Разработка
проекта
Комментарии
А1
Предварительна
я спецификация
Экспертиза
А2
Улучшенный
проект
Пример бизнес-процесса
Законодательство
Отчетность
налогоплательщиков
Внутренние
инструкции
Работа
с отчетностью
юридических
лиц
А1
Отдел по работе с
юридическими
лицами
Отчетность
вышестоящим
организациям
.
Пример дерева диаграмм
А0
Работа Государственной
налоговой инспекции
А1
А2
А3
Работа с
физическими
лицами
Работа с
юридическими
лицами
Работа
вспомогательных
подразделений
А11
А12
А13
Работа по
подоходному
налогу
Работа по налогу
на имущество
Работа по налогу
на землю
Типы связей между
функциями:
случайная;
 логическая;
 временная;
 процедурная;
 коммуникационная;
 последовательная;
 функциональная.

Типы связей

Случайная связь — показывает, что
конкретная связь между функциями
незначительна или полностью отсутствует. Это
относится к ситуации, когда имена данных на
SADT-дугах в одной диаграмме имеют слабую
связь друг с другом.
B
А
C
E
А1
F
D
А2
Типы связей


Логическая связь – данные и функции
собираются вместе благодаря тому, что
они попадают в общий класс или набор
элементов, но необходимых
функциональных отношений между
ними не обнаруживается.
Временная связь – представляет
функции, связанные во времени, когда
данные используются одновременно
или функции включаются параллельно,
а не последовательно.
Типы связей

Процедурная связь - функции сгруппированы
вместе благодаря тому, что они выполняются
в течение одной и той же части цикла или
процесса.
Планировать А
А
А1
А
Согласовать
АиВ
А3
Планировать В
А2
В
В
Типы связей

Коммуникационная - функции
группируются благодаря тому, что они
используют одни и те же входные
данные и/или производят одни и те же
выходные данные
А
В
А1
С
А
А2
Типы связей

Последовательная связь - выход одной
функции служит входными данными для
следующей функции. Связь между элементами
на диаграмме является более тесной, чем в
рассмотренных выше случаях, поскольку
моделируются причинно-следственные
зависимости
А
А1
В
С
А2
Типы связей


Функциональная связь – все элементы
функции влияют на выполнение одной и
только одной функции. Одним из способов
определения функционально-связанных
диаграмм является рассмотрение двух блоков,
связанных через управляющие дуги.
В математических терминах необходимое
условие для простейшего типа
функциональной связи имеет следующий вид:
С=g(B)=g(f(A))
А
В
f
А1
С
g
А2
В таблице представлены все типы связей, рассмотренные выше. Уровни 4-6
устанавливают типы связей, которые разработчики считают важнейшими для
получения диаграмм хорошего качества.
Уровень значимости
Тип связи
Характеристика типа связи
Для функций
Случайная
Для данных
0
Случайная
1
Логическая
2
Временная
Функции одного и того же периода
времени (например, "операции
инициализации")
Данные, используемые в какомлибо временном интервале
3
Процедурная
Функции, работающие в одной и той же
фазе или итераций (например,
"первый проход компилятора")
Данные, используемые во время
одной и той же фазы или
итерации
4
Коммуникационная
Функции, использующие одни и те же
данные
Данные, на которые воздействует
одна и та же деятельность
5
Последовательная
Функции, выполняющие
последовательные преобразования
одних и тех же данных
Данные,
преобразуемые
последовательными
функциями
6
Функциональная
Функции, объединяемые для
выполнения одной функции
Данные, связанные
функцией
Функции одного и того же множества
или типа (например,
«редактировать все входы»)
Случайная
Данные одного и того
множества или типа.
с
же
одной
СТРУКТУРНЫЙ ПОДХОД
К ПРОЕКТИРОВАНИЮ
ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
МОДЕЛИРОВАНИЕ
ПОТОКОВ ДАННЫХ
(ПРОЦЕССОВ)
ОБЩИЕ СВЕДЕНИЙ


Диаграммы потоков данных (DFD) являются
основным средством моделирования
функциональных требований проектируемой
системе. С их помощью эти требования
представляются в виде иерархии
функциональных компонентов (процессов),
связанных потоками данных.
Главная цель представления (DFD) —
продемонстрировать, как каждый процесс
преобразует свои входные данные в
выходные, а также выявить отношения между
этими процессами.
ОБЩИЕ СВЕДЕНИЙ
Для построения DFD традиционно
используются две различные
нотации, соответствующие
методам
 Йордана— Сэрсона
 Геина – Сэрсона.
Модель системы
определяется
как иерархия диаграмм потоков данных,
описывающих асинхронный процесс
преобразования информации от ее входа в
систему до выдачи пользователю.



Диаграммы верхних уровней иерархии
(контекстные диаграммы) определяют
основные процессы или подсистемы с
внешними входами и выходами.
Диаграммы верхних уровней детализируются
при помощи диаграмм нижнего уровня.
Декомпозиция продолжается, создавая
многоуровневую иерархию диаграмм, до тех
пор, пока не будет достигнут уровень
декомпозиции, на котором процессы
становятся элементарными и детализировать
их далее невозможно.
Определение модели


Источники информации (внешние сущности)
порождают информационные потоки (потоки
данных), переносящие информацию к
подсистемам или процессам.
Процессы и подсистемы преобразуют
информацию и порождают новые потоки,
которые переносят информацию к другим
процессам или подсистемам, накопителям
данных или внешним сущностям потребителям информации.
СОСТАВ ДИАГРАММ
ПОТОКОВ ДАННЫХ
внешние сущности;
 системы и подсистемы;
 процессы;
 накопители данных;
 потоки данных;
 информационный канал.

Методологии моделирования
бизнес-процессов

Диаграммы потоков данных (DFD)—
демонстрирует, как каждый процесс
преобразует свои входные данные в
выходные и отношения между этими
процессами.
Нотация DFD
Символ
Внешняя
сущность
Изображен Описание
ие
Материальный
объект или
физическое лицо,
представляющие
собой источник или
приемник
информации
(заказчики,
персонал,
поставщики,
клиенты, склад).
Нотация DFD
Символ
Функция
Изображе
ние
Описание
Определяет
функции
обработки
информации
Нотация DFD
Символ
Изображение
Накопител
ь данных
D1
Реестр налогоплательщиков
Описание
абстрактное
устройство для
хранения
информации
(справочники,
документы, отчеты),
которую можно в
любой момент
поместить в
накопитель и, через
некоторое время
извлечь, причем
способы помещения
Нотация DFD
Символ
Поток
данных
Изображен Описание
ие
Определяет
потоки данных
(документы)
являющиеся
результатом
работ или
поступающие в
систему извне
Нотация DFD
Символ
Изображен Описание
ие
Используется при
Информадетализации потоков
ционный
данных в результате
канал
слияния нескольких
ИК1 Внутренний документооборот
потоков
Рекомендации для
построения DFD - диаграмм




размещать на каждой диаграмме от 3 до 7
процессов.;
не загромождать диаграммы не
существенными на данном уровне деталями;
декомпозицию потоков данных осуществлять
параллельно с декомпозицией процессов.
Эти две работы должны выполняться
одновременно, а не одна после завершения
другой;
выбирать ясные, отражающие суть дела
имена процессов и потоков, при этом
стараться не использовать аббревиатуры.
Порядок построения

Первым шагом при построении иерархии
DFD является построение контекстных
диаграмм. Обычно при проектировании
относительно простых систем строится
единственная контекстная диаграмма со
звездообразной топологией, в центре
которой находится главный процесс,
соединенный с приемниками и
источниками информации, посредством
которых с системой взаимодействуют
пользователи и другие внешние системы.
Порядок построения

Для сложных систем контекстная
диаграмма верхнего уровня
содержит не единственный главный
процесс (система), а набор
подсистем, соединенных потоками
данных.
Порядок построения


Построение диаграмм первого уровня
как декомпозиция системы (подсистем),
которые присутствует на контекстной
диаграмме.
Каждое, событие представляется в виде
процесса с соответствующими
входными и выходными потоками,
накопителями данных, внешними
сущностями и ссылки на другие
процессы для описания связей между
этим процессом и его окружением.
Порядок построения


Построение иерархии DFD, которая
заключается в декомпозиции процессов
более высокого уровня в диаграммы
нижнего уровня.
Каждый процесс на DFD, в свою
очередь, может быть детализирован
при помощи DFD или (если процесс
элементарный) спецификации.
При детализации должны
выполняться следующие правила:


правило балансировки - при детализации
подсистемы или процесса детализирующая
диаграмма в качестве внешних источников или
приемников данных может иметь только те
компоненты (подсистемы, процессы, внешние
сущности, накопители данных), с которыми
имеют информационную связь детализируемые
подсистема или процесс на родительской
диаграмме;
правило нумерации - при детализации процессов
должна поддерживаться их иерархическая
нумерация. Например, процессы,
детализирующие процесс с номером 12,
получают 12.1, 12.2, 12.З и т.д.
Порядок построения


Процесс декомпозиции продолжается
до тех пор, пока процессы могут быть
эффективно описаны с помощью
коротких спецификаций процессов.
Спецификация процесса должна
формулировать основные функции
процесса таким образом, чтобы в
дальнейшем специалист, выполняющий
реализацию проекта, смог выполнить
их или разработать соответствующую
программу.
Решение о завершении детализации процесса и
использовании спецификации принимается
исходя из следующих критериев:




наличия у процесса относительно небольшого
количества входных и выходных потоков данных
(2 - 3 потока);
возможности описания преобразования данных
процессом в виде последовательного алгоритма;
выполнения процессом единственной логической
функции преобразования входной информации в
выходную;
возможности описания логики процесса при
помощи спецификации небольшого объема (не
более 20 — 30 строк).
Спецификации должны
удовлетворять следующим
требованиям:





для каждого процесса нижнего уровня должна
существовать одна и только одна спецификация;
спецификация должна определять способ
преобразования входных потоков в выходные;
нет необходимости определять метод реализации
этого преобразования;
спецификация должна стремиться к ограничению
избыточности - не следует переопределять то,
что уже было определено на диаграмме;
набор конструкций для построения спецификаций
должен быть простым и понятным.

Фактически спецификации представляют собой описания
алгоритмов задач, выполняемых процессами. Спецификации
содержат номер и/или имя процесса, списки входных и
выходных данных и тело (описание) процесса, являющееся
спецификацией алгоритма или операции, трансформирующей
входные потоки данных в выходные.
Процесс: Формирование сводного плана кафедры.
Вход: Индивидуальные планы .
Выход: Сводный план.
Алгоритм:
1. Выбрать из накопителя Индивидуальные планы преподавателей
2. Сформировать «Сводный план кафедры» на основе данных
индивидуальным планам преподавателей» по следующим разделам:
Учебная работа;
Методическая работа;
Научная работа.
3.Поместить документ в накопитель
по
Порядок построения



После построения законченной модели
системы ее необходимо верифицировать
(проверить на полноту и согласованность).
В полной модели все ее объекты
(подсистемы, процессы, потоки данных)
должны быть подробно описаны и
детализированы.
В согласованной модели для всех потоков
данных и накопителей должно
выполняться правило сохранения
информации: все поступающие куда-либо
данные должны быть считаны, а все
считываемые данные должны быть
записаны.
Диаграммы переходов
состояний (STD)

Демонстрирует поведение
разрабатываемой программной
системы при получении
управляющих воздействий (извне)
Узел

Соответствуют состоянию
динамической системы
Имя состояния
Промежуточное
состояние
Терминальное состояние
Дуга

Соответствует переходу системы
из одного состояния в другое
Условие
Действие
Диаграмма переходов
состояния программы
Исходное
состояние
Состояние
завершения
Ввод
Инициализация
Вывод
Вычисление
Завершение
Диаграмма переходов состояния
торгового аппарата
Ожидание
монеты
«Товар доступен»=НЕТ
«Выдать монеты»
Ожидание
выбора
товара
Выдача
товара
Обнаружена
монета
«Оплата
достаточна»
«Выдать
сдачу»
«Оплата достаточна»
«Выдать товар»