Файл: Основы проектирования программ. Этапы создания программного обеспечения (Обобщенная характеристика процесса разработки программного обеспечения).pdf

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

Методология IDEF0 предполагает, что модель – это не просто совокупность диаграмм, а содержит все необходимые данные о моделируемой области. Данные о модели задаются в свойствах модели [18].

В общих свойствах (general) приводится указание имени модели, названия проекта, автора модели, временных рамок модели (Time Frame) - AS-IS и ТО-ВЕ. Как правило, сначала создается модель существующей организации работы - AS-IS (как есть). Изучение функциональной модели дает возможность понимания того, где можно выявить самые слабые места, в чем будут заключаться преимущества новых бизнес-процессов, а также того, насколько глубокие изменения произойдут в существующей структуре организации бизнеса. Детализация бизнес-процессов дает возможность выявления недостатков организации даже там, где функциональность может показаться очевидной. Выявленные в модели AS-IS недостатки могут быть исправлены в процессе создания модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов. В некоторых случаях текущая AS-IS и будущая ТО-ВЕ модели имеют сильные отличия, поэтому переход от начального к конечному состоянию неочевиден. Здесь требуется третья модель, которая описывает процесс перехода от начального к конечному состоянию системы, так как данный переход тоже является бизнес-процессом.

Для придания диаграммам удобочитаемости, в стандарте IDEF0 принято ограничения сложности: на диаграмме могут быть 3-6 активностей, вместе с тем колво подходящих к одной активности и выходящих из одной активности дуг предполагается до 4.

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

Каждая активность модели нумеруется. Номер включает в себя префикс и число. Может использоваться префикс любой длины, но, как правило, используется префикс А. Контекстная активность обладает номером А0. Активности, которые получили после декомпозиции контекстной активности номера А1, А2, A3 и т. д. У работ декомпозиции нижнего уровня есть номер родительской активности, а также очередной порядковый номер, к примеру у активностей декомпозиции A3 будут номера А31, А32, А33, А34 и т. п. Активности формируют иерархию, в которой каждая активность может обладать одной родительской и несколькими дочерними работами, формируя дерево. Это дерево называется деревом узлов, а вышеописанная нумерация - нумерацией по узлам [7].

---

Диаграммы IDEF0 обладают двойной нумерацией. Прежде всего, диаграммы обладают номерами по узлу. Контекстная диаграмма всегда обладает номером А-0, декомпозиция контекстной диаграммы - номером А0, другие диаграммы декомпозиции - номерами по соответствующему узлу (к примеру, Al, A2, А21, А213 и т. д.).

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

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

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

Связь по входу (output-input), при которой стрелка выхода вышестоящего блока направляется на вход нижестоящей работы.

Связь по управлению (output-control), при которой выход вышестоящего блока направляют на управление нижестоящего блока. Связь по управлению отражает доминирование вышестоящей работы.

Обратная связь по входу (output-input feedback), при которой выход нижестоящей активности направляется на вход вышестоящей. Такую связь, как правило, используют в целях описания циклов.

Обратная связь по управлению (output-control feedback), при которой выход нижестоящего блока направляют на управление вышестоящего. Обратная связь по управлению нередко указывает на эффективное управление бизнес - процессами.

Связь выход-механизм (output-mechanism), при которой выход одной работы направляют на механизм другой. Данную взаимосвязь используют реже остальных, она отражает, что одна активность подготавливает ресурсы, требуемые для выполнения другой активности [1].

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

---

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

Туннелирование применяться может в целях изображения малозначимых стрелок. Если на той или иной диаграмме нижнего уровня требуется изображением малозначимых данных или объектов, которые не следует отображать на диаграммах вышестоящего уровня, то требуется туннелирование стрелок на самом нижнем уровне. Другой пример туннелирования – это ситуация, при которой миграция стрелки механизма происходит с верхнего уровня на нижний, при этом на нижнем уровне данный механизм применяется одинаково во всех работах. Здесь стрелку механизма на нижнем уровне можно удалить, после чего на родительской диаграмме ее можно туннелировать, на родительской диаграмме острие стрелки будет изображаться в круглых скобках. В комментарии к стрелке либо же в словаре может быть указано, что механизм будет применяться во всех работах дочерней диаграммы декомпозиции.

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

Следующей рассмотренной методологией является методология DFD. Цель методологии - построить модель рассматриваемой системы в форме диаграммы потоков данных (Data Flow Diagram - DFD). Диаграммы потоков данных используются, в первую очередь, для описания документооборота, а также обработки информации, но допускают и представление иных объектов.

В процессе создания диаграммы потоков данных применяются 4 ключевых понятия:

• потоки данных,
• процессы (работы) преобразования входных потоков данных в выходные,
• внешние сущности,
• накопители данных (хранилища).

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

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

---

Хранилище (накопитель) данных осуществляет моделирование данных, которые будут оставаться в памяти между процессами. Данные, находящиеся в хранилище, могут быть использованы в любое время после их получения, вместе с тем данные могут быть выбраны в любом порядке. Именем хранилища должно определяться его содержимое, имя хранилища должно быть существительным.

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

Помимо ключевых элементов, в состав DFD входят словари данных, а также миниспецификации.

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

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

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

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

---

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

• у процесса есть относительно небольшое количество входных и выходных потоков данных (два-три потока);
• возможность описания преобразования указанных процессов в виде последовательного алгоритма;
• исполнение процессом единственной логической функции преобразования входных данных в выходные;
• возможность описания логики процесса с помощью спецификации небольшого объема (до 20-30 строк).

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

Еще одной методологией моделирования бизнес-процессов является методология IDEF3. IDEF3 – это стандарт документирования технологических процессов, которые происходят в организации, и предоставляет инструментарий к наглядному исследованию и моделированию их сценариев. Образец диаграммы IDEF3 показан на рис. 3.

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

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

Существенные взаимоотношения между действиями отображают при помощи связей. Все связи в IDEF3 – однонаправленные, и, хотя стрелка может быть начата или закончена на любой стороне блока, который обозначает действие, диаграммы IDEF3, как правило, организуются слева направо так, что стрелки начинаются на правой и оканчиваются на левой стороне блоков [1].

---