Классификация рынка современных ИС

ТЕМА 1. ПРОЕКТИРОВАНИЕ ИС

Информационная система – система ввода, вывода, хранения, обработки данных создаваемая для обеспечения функционирования различных процессов.

Этапы развития ИС

50 гг. – решение отдельных экономических задач;

70 гг. – системы комплексной автоматизации;

80 гг. – системы локальной автоматизации построения АРМ;

90 гг. – развитие телекоммуникаций и появление КИС, которые позволили автоматизировать все функции фирмы и отхватить весь цикл работ.

Типовые задачи, решаемые модулями КИС (рис. 1.1).

Подсистема маркетинга	Производственные подсистемы	Финансовые и учетные подсистемы	Подсистема кад­ров	Прочие подсистемы
Исследование рынкам прогнозирование про­даж	Планирование объе­мов работ и разра­ботка календарных планов	Управление портфелем заказов	Анализ и прогнозирование потребности в тру­довых ресурсах	Контроль за деятельно­стью фирмы
Управление продажами	Оперативный контроль и управление производством	Управление кредитной ПОЛИТИКОЙ	Ведение архи­вов записей о персонале	Выявление оперативных проблем
Рекомендации по производст­ву новой про­дукции	Анализ работы оборудования	Разработка финансового плана	Анализ и планирование подготовки кадров	Анализ управленческих и стратегических ситуаций
Анализ и установление цены	Участие в фор­мировании зака­зов поставщикам	Финансовый анализ и прогнозирование		Обеспечение процесса выработки стратегических решений
Учет заказов	Управление запа­сами	Контроль бюджета, бухгалтер­ский учет и рас­чет зарплаты

Рис. 1.1. Функциональное назначение модулей КИС

 

Классификация рынка современных ИС

В настоящее время наблюдается рост КИС. Отдельные АРМ, например, бухгалтерского учета, считаются уже пройденным этапом.

На рис. 1.2 приведены названия наиболее популярных программных продуктов.

Локальные системы	Малые интегрированные системы	Средние интегрированные системы	Крупные интегрированные системы
БЭСТ, Инотек, Инфософт, Турбо- Бухгалтер, Инфо- Бухгалтер	Concorde XAL, NS-2000, Platinum, Scala, SunSystems, БЭСТ-ПРО, 1С-Предприятие, БОСС-Корпорация, Галактика, Парус, Ресурс	SyteLine, МАХ, IFS, PRMS, Axapta	R/3, Ваал, Oracle Applications, MFG/PRO

Рис. 1.2. Наиболее значимые программные продукты

Проектирование ИС как формализационный процесс

Под проектом ИС понимаются проектно-конструкторскую документацию, в которой представлено описание проектных решений по созданию и эксплуатации ИС в конкретной программной среде.

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

Проектирование ИС представляет собой сложную, трудоемкую и длительную работу. Основная доля трудозатрат приходится на прикладное программное обеспечение (ПО) и базы данных (БД). Производство ПО сегодня – крупнейшая отрасль мировой экономики. Для создания ПО разработана совокупность инженерных методов и средств, объединенных под общим названием «программная инженерия» (software engineering).

Итак, проектирование ИС сегодня является во многом формализованным процессом.

Вопросы.

1. Этапы развития ИС.

2. Особенности КИС.

3. Модули КИС и их функциональное назначение.

4. Существующие программные продукты для реализации ИС.

5. Понятия проекта ИС.

6. Понятие проектирования ИС.

7. Кризис программирования и причины его возникновения.

8. Понятие программной инженерии и этапы ее развития.

ТЕМА 2. ПОНЯТИЕ ЖЦ ПО

Основные процессы

Процесс приобретения состоит из действий и задач заказчика, приобретающего ПО.

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

Процесс разработки предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПО.

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

Процесс сопровождения предусматривает действия и задачи, выполняемые службой сопровождения, при изменениях или адаптации ПО.

Вспомогательные процессы

Процесс документирования предусматривает формализованное описание информации, созданной в течение ЖЦ ПО.

Процесс управления конфигурацией позволяет учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.

Процесс обеспечения качества обеспечивает соответствующие гарантии того, что ПО и процессы его ЖЦ соответствуют заданным требованиям и утвержденным планам.

Процесс верификации состоит в определении правильности ПО.

Процесс аттестации предусматривает определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению.

Процесс совместной оценки предназначен для оценки состояния работ по проекту.

Процесс аудита представляет собой определение соответствия требованиям, планам и условиям договора.

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

 

Организационные процессы

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

Процесс создания инфраструктуры охватывает выбор и поддержку технологии, стандартов и инструментальных средств, выбор и установку аппаратных и программных средств, используемых для разработки, экс­плуатации или сопровождения ПО.

Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО.

Процесс обучения охватывает первоначальное обучение и после­дующее постоянное повышение квалификации персонала.

 

Рис. 2.1. Связи между процессами ЖЦ ПО

Модели и стадии ЖЦ ПО

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

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО.

Модель ЖЦ представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ.

В состав ЖЦ ПО обычно включаются следующие стадии:

1. Формирование требований к ПО.

2. Проектирование.

3. Реализация.

4. Тестирование.

5. Ввод в действие.

6. Эксплуатация и сопровождение.

7. 7 Снятие с эксплуатации.

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ISO/IEC 12207, и, наоборот, один и тот же процесс может выполняться на различных стадиях.

К настоящему времени наибольшее распространение получили каскадная (1970 - 1985 гг.) и спиральная (1986 - 1990 гг.) модель ЖЦ ПО.

Принципиальной особенностью каскадной модели ЖЦ (рис. 2.2) является то что переход на следующую стадию осуществляется только после того как будет полностью завершена работа на текущей стадии, и воз­вратов на пройденные стадии не предусматривается. Каждая стадия закан-чив1ется погнием некоторых результатов, которые служат в качестве игхмных данных для следующей стадии.

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

Рис. 2.2. Каскадная схема разработки ПО

Преимущества применения каскадного способа заключаются в сле­дующем:

· на каждой стадии формируется законченный набор проектной документации;

· удобно планировать сроки завершения всех работ и соответствующие затраты.

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

Недостатком каскадной схемы является то, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. Данный процесс, как правило, носит итерационный характер, т.е. результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. В результате реальный процесс создания ПО принимает иной вид (рис. 2.3). Это приводит к запаздыванию получения результатов. В результате риск создания системы, не удовле­творяющей изменившимся потребностям пользователей, повышается.

Обычно на начальной стадии проекта полностью и точно сформули­ровать все требования к будущей системе не удается. Это объясняется двумя причинами:

· пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки;

· за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.

Рис. 2.3. Реальный процесс разработки ПО

Для преодоления перечисленных проблем в середине 80-х гг. была предложена спиральная модель ЖЦ (рис. 2.4). Ее принципиальной особенностью является то, что ПО создается не сразу, как в случае каскадного подхода, а по частям, с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов, и планируются работы следующей итерации.

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

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

Основная проблема спирального цикла - определение момента пере­хода на следующую стадию.

 

Рис. 2.4. Спиральная модель ЖЦ ПО

Вопросы

1. Понятие ЖЦ.

2. Группы процессов ЖЦ ПО согласно стандарту ISO/IEC 12207:1995.

3. Состав группы основных процессов ЖЦ ПО согласно стандарту ISO/IEC 12207:1995.

4. Состав группы вспомогательных процессов ЖЦ ПО согласно стандарту ISO/IEC 12207:1995.

5. Состав группы организационных процессов ЖЦ ПО согласно стандарту ISO/IEC 12207:1995.

6. Взаимосвязи между процессами ЖЦ.

7. Понятие модели ЖЦ.

8. Стадии ЖЦ.

9. Понятие каскадной модели ЖЦ.

10. Преимущества и недостатки каскадной модели ЖЦ.

11. Понятие спиральной модели ЖЦ.

12. Понятие прототипа.

13. Преимущества и недостатки спиральной модели ЖЦ.

Рис. 3.2. Схема организации деятельности по проектированию ПО ИС (спиральная модель)

Так как получаемый программный продукт является исключительно эксклюзивным, инженеру по ходу проектирования приходится решать массу творческих задач внутри каждого вида работ (рис. 3.3 – 3.6).

 

ЗАДАЧИ РАЗРАБОТКИ ПО ИС

Рис. 3.3. Комплекс задач фазы «Исследование»

Рис. 3.4. Комплекс задач фазы «Уточнение»

Рис. 3.5. Комплекс задач фазы «Построение»

Рис. 3.6. Комплекс задач фазы «Развертывание»

Вопросы для самоконтроля

1. Перечислите (с интерпретацией на чертеже) четыре фазы разработки ПО ИС и содержание работ в этих фазах.

2. Перечислите (с интерпретацией на чертеже) основные виды работ в рамках каждой фазы разработки ПО ИС.

3. Объясните (на чертеже) понятия: фаза разработки; вехи; итерации; прототип.

4. Какие основные задачи решаются в рамках вида работ «Исследование рынка ПО по теме заказа».

5. Какие основные задачи решаются в рамках вида работ «Обсуждение требований заказа».

6. Какие основные задачи решаются в рамках вида работ «Уточнение требований к ПО системы, к среде, к аппаратным средствам».

7. Какие основные задачи решаются в рамках вида работ «Постановка задачи и ее формализация».

8. Какие основные задачи решаются в рамках вида работ «Эскизное проектирование».

9. Что означает каноническое проектирование ИС.

10. Что означает «структурный системный анализ» в контексте эскизного проектирования.

11. Что означает объектно-ориентированный системный анализ в контексте эскизного проектирования.

12. Как используются модели линейного программирования в контексте эскизного проектирования.

13. Как используются модели нелинейного программирования в контексте эскизного проектирования.

14. Как используются модели динамического программирования в контексте эскизного проектирования.

15. Как используются модели «теории игр» в контексте эскизного проектирования.

16. Какие задачи рассматриваются в рамках эвристического и стохастического моделирования.

17. Какие задачи рассматриваются в рамках имитационного моделирования.

18. Какие основные задачи рассматриваются в рамках вида работ «Кодирование-программирование».

19. Какие задачи и как решаются в рамках методологии RAD.

20. Как организуется работа в рамках «Экстремального программирования».

21. Какие основные задачи рассматриваются в рамках вида работ «Сборка системы».

22. Какие основные задачи рассматриваются в рамках вида работ «Тестирование функционирования ПО ИС».

23. Что означает «Внутреннее тестирование».

24. Что означает «Внешнее тестирование».

25. Что означает модульное и интеграционного тестирование.

26. Что означает приемочное тестирование.

27. Какие основные задачи рассматриваются в рамках вида работ «тестирование документации».

28. Какие основные задачи рассматриваются в рамках вида работ «Анализ результатов».

Компетенция инженера

Компетенция – это способность решать проблемы в актуальном режиме в определенной области деятельности.

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

Рассмотрим внутреннюю деятельность инженера на фоне внешней деятельности по ходу процессе решения проблемы проектирование ПО ИС, которая сводится к решению комплекса взаимосвязанных задач (рис. 4.1). Условно разделим множество задач на три кластера задач, т.е. кластер задачи посвященных формализации проблемы (кластер задач типа А); кластер задач, посвященных конструированию решения проблемы (кластер задач типа В) и кластер задач, посвященных исполнению решения проблемы (кластер типа С).

Рис. 4.1. Внутренняя деятельность инженера по решению задач на фоне внешней деятельности

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

Рис. 4.2. Решение задач проектирования ПО ИС во внутренней деятельности инженера

Рис. 4.3. Состояние обладания компетенцией и компетентностью

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

 

Рис. 4.4. Схема разработки прототипов ПО ИС по возрастанию сложности

Согласно логике построения прототипов, очевидно, прототип 2 более сложный, чем прототип 1, а прототип 3 более сложнее прототипа 2 и т.д. ПО этой же логике для построения прототипа 2 требуется выше уровень развития АВС - способностей и обладание большими объемами знаний, чем для построения прототипа 1 и т.д. Если эти требования на уровне развития способностей и обладания знаниями отобразить как достаточные условия для обеспечения умения решать проблему проектирования ПО ИС, то эту ситуацию можно изобразить на лепестковой диаграмме (рис. 4.5).

Рис. 4.5. Соответствие способностей сложности прототипа

Обладание способностями со значениями параметров А, В, С, POL, CHL, характеризующих уровни развития формализационных (А), конструктивных (В) и исполнительских (С) способностей и объемы необходимых знаний-фактов (параметр POL) и знаний-связей (параметр CHL) дают возможность на практике реализовать инженеру соответственно прототип 1, прототип 2, прототип 3 и т.д.

 

Вопросы для самоконтроля

1. Объяснить связь понятий компетенция и умение.

2. Объяснить какие параметры характеризуют качества обладание компетенцией.

3. Что означает компетентный инженер в области программной инженерии.

Сущность методологии IDEFO

Методология функционального моделирования IDEFO - это методология описания системы в целом как множества взаимозависимых действий или функций. На рис. 5.1 приведен пример диаграммы IDEFO.

Рис.5.1. Пример диаграммы IDEFO

Наиболее часто IDEFO применяется как технология исследования и проектирования систем на логическом уровне. По этой причине она, как правило, используется на ранних этапах разработки проекта. Результаты IDEFO анализа могут применяться при проведении проектирования с использованием моделей IDEF3 и диаграмм потоков данных.

 

Рис. 5.2. Каждый тип стрелки соединяется со своей стороной функционального блока

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

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

Стрелки управления. Управление часто существует в виде информации (правил, инструкций, процедур, стандартов и др.), которая влияет на работу блока, но непосредственно не потребляется и не преобразуется в результате. Управление можно рассматривать как специфический вид входа.

Стрелки выхода. Выход — это продукция или информация, получаемая в результате работы функционального блока. Каждый блок должен иметь, как минимум, один выход.

Стрелки механизма исполнения. Механизм исполнения является ресурсом, который непосредственно исполняет моделируемое действие, качестве механизмов исполнения обычно выступают персонал или техника.

Комбинированные стрелки.

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

Рис.5.3. Комбинация стрелок выход — вход

Стрелка выход - управление отражает ситуацию преобладания одного блока над другим, когда один блок управляет работой другого (рис. 5.4).

Рис. 5.4. Комбинированная стрелка выход — управление

Стрелки выход - механизм исполнения встречаются реже и отражают ситуацию, когда выход одного функционального блока применяется в качестве оборудования для работы другого блока (рис. 5.5).

 

Рис. 5.5. Комбинированная стрелка выход — механизм исполнения

Обратные связи

Обратные связи на вход и на управление применяются в случаях, ко­гда зависимые блоки формируют обратные связи для управляющих ими блоков.

На рис. 5.6 показана стрелка выход - обратная связь на управление.

Рис. 5.6. Комбинированная стрелка выход - обратная связь на управление

На рис. 5.7 показана стрелка выход - обратная связь на вход. Стрелка выход - обратная связь на вход обычно применяется для описания циклов повторной обработки чего-либо.

Рис.5.7. Комбинированная стрелка выход - обратная связь на вход

 

Разбиение и соединение стрелок.

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

Рис.5.8. Разбитая на две части и переименованная стрел

 

Туннели

Если одна из стрелок диаграммы отсутствует на родительской диаграмме и не связана с другими стрелками той же диаграммы, точка входа этой стрелки на диаграмму или выхода с нее обозначается туннелем (рис. 5.9). Таким образом, помечаются стрелки, несущественные для родительского уровня.

Туннели также могут применяются для отражения ситуации, когда стрелка, присутствующая на родительской диаграмме, отсутствует в диаграмме декомпозиции соответствующего блока (рис. 5.10

Рис. 5.9. Пример применения туннеля

Рис. 5.10. Еще один пример применения туннеля

 

Типы связей между функциями

Различают связи семи типов: случайная; логическая; временная; процедурная; коммуникационная; последовательная и функциональная связь.

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

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

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

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

Коммуникационная связь - функции группируются благодаря тому, что они используют одни и те же входные данные и/или производят одни и те же выходные данные (рис. 5.11).

Последовательная связь - выход одной функции служит входными данными для следующей функции (рис. 5.12).

Функциональная связь - все элементы функции влияют на выполнение одной и только одной функции (рис. 5.13). В математических терминах: С = g(B) = g(f(A)).

Рис. 5.11 Коммуникационная связь

Рис. 5.12. Последовательная связь

Рис. 5.13. Функциональная связь

Построение моделей IDEF0

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

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

Одним из положительных результатов построения функциональных моделей оказывается прояснение границ моделирования системы.

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

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

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

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

При необходимости дальнейшей детализации отдельных процессов быть использованы диаграммы IDEF3 и DFD, которые будут рассмотрены позднее.

Сущность методологии IDEF3

Методология IDEF3 — это методология описания процессов в виде упорядоченной последовательности событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу.

IDEF3 не имеет жестких синтаксических или семантических ограничений. На рис. 5.14 изображен пример описания процесса с использованием методологии IDEF3.

Рис. 5.14 Описание процесса с использованием методологии IDEF3

 

Рис. 5.15. Связь типа «Временное предшествование» между блоками 1 и 2

Рис. 5.16. Объектная связь между действиями 1 и 2

Рис. 5.17. Связь типа «Нечеткое отношение»

Соединения

Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса. Различают следующие виды соединений:

1. Разворачивающие соединения. Данные соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других действий.

2. Сворачивающие соединения. Данные соединения используются для объединения потоков. Завершение одного или нескольких действий вызывает начало выполнения только одного другого действия.

В модели IDEF3 определены три типа асинхронных соединений (табл. 5.1).

Примеры использования асинхронных соединений представлены на рис. 5.18, 5.19, 5.20.

«И»-соединения. На рис. 5.18 после обнаружения пожара инициируются включение пожарной сигнализации, вызов пожарной охраны, и начинается тушение пожара. Запись в журнал производится только тогда, когда все три перечисленных действия завершены.

Соединение «ИЛИ». На рис. 5.19 соединение J2 может активировать проверку данных чека и (или) проверку суммы наличных. Проверка чека инициируется, если покупатель желает расплатиться чеком, проверка суммы наличных - при оплате наличными. И то, и другое действие инициируется при частичной оплате чеком и частичной - наличными.

Соединение «Исключающее ИЛИ». На рис. 5.20 соединение «Исключающее ИЛИ» используется для отображения того факта, что студент не может одновременно быть направлен на лекции по двум разным курсам.

Таблица 5.1. Типы соединений в модели IDEF3

Графическое обозначение	Название	Вид	Правила инициирования
	Соединение «И»	Разворачивающее	Каждое конечное действие обязательно инициируется
Сворачивающее	Каждое исходное действие обязательно должно завершиться
	Соединение «ИЛИ»	Разворачивающее	Одно (или более) конечное действие инициируется
Сворачивающее	Одно (или более) исходное действие должно завершиться
	Соединение «Исключающее ИЛИ»	Разворачивающее	Одно и только одно конечное действие инициируется
Сворачивающее	Одно и только одно исходное действие должно завершиться

 

Рис. 5.18. «И»-соединения

Рис. 5.19. Соединение «ИЛИ»

Рис. 5.20. Соединение «Эксклюзивное ИЛИ»

В рассмотренных примерах все действия выполнялись асинхронно, не должны были выполняться одновременно. Однако есть случаи, когда время начала или окончания параллельно выполняемых действий должно быть одинаковым, т.е. действия должны выполняться синхронно.

Для моделирования такого поведения системы используются синхронные соединения.

В модели IDEF3 определены два вида синхронных соединений (табл. 5.2). Рис. 5.21 иллюстрирует модель синхронного соединения.

Таблица 5.2 Синхронные соединения модели IDEF3

Графическое обозначение	Название	Вид	Правила инициирования
	Соединение «И»	Разворачивающее	Все действия начнутся одновременно
Сворачивающее	Все действия закончатся одновременно
	Соединение «ИЛИ»	Разворачивающее	Может быть, несколько действий начнутся одновременно
Сворачивающее	Может быть, несколько действий закончатся одновременно

 

Рис. 5.21. Синхронное соединение

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

Синхронное разворачивающее соединение не обязательно должно иметь парное себе синхронное сворачивающее соединение. Действительно, начинающиеся одновременно действия вовсе не обязаны оканчиваться одновременно.

Типы разворачивающего и сворачивающего соединений не обяза­тельно должны совпадать. На рис. 5.22 разворачивающее «И»-соединение имеет парное сворачивающее «ИЛИ»-соединение. Интерпретация соединения Л аналогична случаю, показанному на рис. 5.18. Соединение J2 интерпретируется следующим образом: после включения пожарной сигнализации и (или) вызова пожарных, и (или) начала тушения производится запись в журнал.

Рис. 5.22. Пример комбинации двух типов соединений

Однако следует помнить, что определенные сочетания соединений могут приводить к логическим ошибкам. Чтобы избежать таких ошибок, необходимо соблюдать следующие правила (данные правила имеют рекомендательный характер и не являются строго обязательными):

1. Разворачивающее соединение «ИЛИ» не может иметь парное сворачивающее соединение «И». На рис. 5.23а показан пример, когда разворачивающее «ИЛИ» имеет парное сворачивающее «И». Это приводит к логическим ошибкам. Например, после работы 1 может оказаться, что активизировалась только работа 2. В этом случае работа 4 никогда не будет активизирована, т.к. для этого требуется окончание работ 2 и 3, а работа 3 не была активизирована.

2. Разворачивающее соединение «Исключающее ИЛИ» не может иметь парное сворачивающее соединение «И» (см. рис.5. 236). В этом случае возникает логическая ошибка, аналогичная ошибке, рассмотренной в пункте 1.

3. Разворачивающее соединение «ИЛИ» не может иметь парное сворачивающее соединение «Исключающее ИЛИ» (см. рис. 5.23в). Логическая ошибка возникает в том случае, когда после завершения работы 1 запускается обе работы – 2 и 3. Однако, для запуска работы 4 требуется завершение одной и только одной работы (только работы 2 или только работы 3).

4. Разворачивающее соединение «И» не может иметь парное сворачивающее соединение «Исключающее ИЛИ» (см. рис.5.23г). В этом случае возникает логическая ошибка, аналогичная ошибке, рассмотренной в пункте 3. После завершения работы 1 запускаются обе работы - 2 и 3, а для активизации работы 4 требуется, чтобы завершилась одна и только одна работа - или 2, или 3.

Также не следует использовать в паре разворачивающее соединение «Исключающее ИЛИ» и сворачивающее «ИЛИ». В этом случае после разворачивающего соединения активизируется одна и только одна работа, поэтому сворачивающее соединение «ИЛИ» лучше заменить на сворачивающее «Исключающее ИЛИ».

Рис.5.23. Неверное использование соединений

Соединения могут комбинироваться для создания более сложных правил ветвления (рис. 5.24).

 

Рис. 5.24. IDEF3-диаграмма с комбинацией соединений

Требования 1DEF3 к описанию бизнес-процессов

Предполагается, что в построении диаграммы принимают участие ее автор и один или несколько экспертов предметной области, которые будут представлять описание процесса.

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

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

 

Рис.5.25. Пример диаграмм DFD

 

Рис. 5.26. Функциональный блок DFD в нотации Гейна- Сарсона

Внешние сущности обеспечивают необходимые входы для системы и/или являются приемниками для ее выходов. Одна внешняя сущность может одновременно предоставлять входы (функционируя как поставщик) и принимать выходы (функционируя как получатель). Внешние сущности изображаются как прямоугольники (рис. 5.27).

Рис. 5.27. Обозначение внешней сущности

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