11. Моделирование бизнес-процессов спецификация требований на основе структурного подхода

На сегодняшний день в программной инженерии существуют два основных подхода к разработке ПО АСОИУ: функционально-модульный или структурный. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй, объектно-ориентированный подход использует объектную декомпозицию.

Итак, сущность структурного подхода к разработке ПО АСОИУ заключается в его декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те — на задачи и так далее до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу вверх", от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.

Базовыми принципами структурного подхода являются:

• принцип "разделяй и властвуй"

• принцип иерархического упорядочения - принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

• принцип абстрагирования – выделение существенных аспектов системы и отвлечение от несущественных;

• принцип непротиворечивости — обоснованность и согласованность элементов системы;

• принцип структурирования данных - данные должны быть структурированы и иерархически организованы.

В структурном подходе используются в основном две группы средств, описывающих функциональную структуру системы и отношения между данными.

• DFD (Data Flow Diagrams) — диаграммы потоков данных;

• SADT(Structured Analysis and Design Technique - метод структурного анализа и проектирования) — модели и соответствующие функциональные диаграммы; (IDEF0)

• ERD (Entity-Relationship Diagrams) — диаграммы "сущность-связь".

Диаграммы потоков данных и диаграммы "сущность-связь" - наиболее часто используемые в CASE-средствах виды моделей.

12. Модели объекта автоматизации. Методика информационного проектирования idef3.

Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую АСОИУ, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.

Правила формирования моделей бизнес-процессов в IDEF3

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

№	Наименование	Описание	Графическое представление
1	Процесс (операция, работа)	Объект служит для описания операций (работ), выполняемых подразделениями/сотрудниками предприятия.
2	Ссылочный объект	Объект, используемый для описания ссылок на другие диаграммы модели, циклические переходы в рамках одной модели, различные комментарии к операциям.

№	Тип стрелки	Графическое представление
1	Стрелка предшествования. Соединяет последовательно выполняемые операции.
2	Стрелка отношения. Используется для привязки объектов-комментариев к операциям.
3	Стрелка потока объектов. Показывает поток объектов (финансовых, материальных) от одной операции к другой.

1. Каждая операция имеет название и уникальный номер.

2. Название операции выражается глаголом или отглагольным существительным.

3. Стрелки связей обозначают взаимосвязи между выполняемыми операциями, которые могут выражаться через связь операций посредством потока объектов или последовательность выполнения операций во времени.

4. Связь между операциями, выраженная как последовательность выполнения во времени может быть двух видов:

   1. старшая связь;

   2. связь-отношение.

5. Старшая связь показывает, что для начала работы одной операции необходимо завершение выполнения другой. Старшая связь изображается однонаправленной сплошной стрелкой с одним наконечником.

6. Связь-отношение показывает, что для выполнения операции нет необходимости в завершении выполнения другой операции . необходимо только начать выполнение этой операции. Связь-отношение изображается однонаправленной пунктирной стрелкой с одним наконечником.

7. Рекомендуется строить диаграммы IDEF3 так, чтобы стрелки, обозначающие связи были направлены слева направо, либо сверху вниз.

8. Объект модели типа «перекресток» используется для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом выполнения следующей операции.

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

10. Стрелки могут сливаться и разветвляться только через перекрестки.

Таблица 5

№	Наименование	Описание		Граф. представл
		Смысл в случае слияния стрелок	Смысл в случае разветвления стрелок
1	Асинхронное «И»	Все предшествующие операции должны быть выполнены.	Все следующие операции должны быть запущены
2	Синхронное «И»	Все предшествующие операции должны быть завершены одновременно	Все следующие операции должны быть запущены одновременно
3	Асинхронное «ИЛИ»	Одна или несколько предшествующих операций должны быть завершены	Одна или несколько следующих операций должны быть запущена
4	Синхронное «ИЛИ»	Одна или несколько предшествующих операций должны быть завершены одновременно.	Одна или несколько следующих операций запускаются одновременно
5	Исключающее «ИЛИ»	Только одна предшествующая операция должна быть завершёна	Только одна следующая операция запускается

1. При построении диаграмм в IDEF3, используется принцип декомпозиции. В результате декомпозиции образуется иерархическая структура диаграмм IDEF3.

2. Родительская диаграмма, расположенная на вершине иерархической структуры диаграмм, должна быть либо диаграммой IDEF0, либо диаграммой DFD.

3. В случае, если IDEF3 диаграммы не дополняют IDEF0 модель или DFD модель, а являются самостоятельной моделью, то на указанной родительской диаграмме верхнего уровня должна быть обозначена цель моделирования с точки зрения создателя модели (контекстная диаграмма).

4. В качестве контекстной диаграммы рекомендуется использовать контекстную диаграмму, выполненную в IDEF0 нотации.

5. Диаграммы должны содержать не менее 3 и не более 8 операций.

6. Связь через потоки объектов должна иметь имя, которое является уникальным.

7. Старшая связь и связи-отношения могут иметь имя.

8. Каждому перекрестку присваивается уникальный номер.