Учебники / Силич М.П. МиАБ. Учебник

Относительно единиц работ имеется лишь одно правило: в блок может входить и из блока может выходить только одна связь последовательности. Для отображения множества входов и выходов используются перекрестки. В отличие от нотации IDEF0, в нотации IDEF3 стороны блока, изображающего работу (функцию, процесс), не используют для привязки входов различного типа [12].

В методологии IDEF3 разрешается множественная декомпозиция работ. При этом для одной и той же работы может быть создано несколько диаграмм декомпозиции. Это позволяет в одной модели описать альтернативные варианты реализации работы — сценарии развития ситуаций.

Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ: номер работы состоит из номера родительской работы, номера декомпозиции и собственного номера работы на текущей диаграмме [20]. Например, номер А13.1.2 означает, что родительская работа имеет код А13, номер декомпозиции 1 и номер работы на текущей диаграмме 2.

Основным достоинством методологии IDEF3 в сравнении с методологией IDEF0 является возможность явно показать последовательность выполнения процесса. Недостатком является тот факт, что отобразить оборудование, используемое работой (функцией), управление, входные и выходные данные и другое можно только посредством привязки к работе ссылки с комментарием относительно связанных с работой объектов. Это менее наглядно, чем явное указание объектов (в виде меток) и их роли (через соединение меток дугами с определенной стороной блока) в IDEF0-модели.

3.2.3. Методология моделирования DFD

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

ные компоненты (процессы, которые преобразуют входные данные в выходные) и представляется в виде сети, связанной потоками данных [17].

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

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

Рис. 3. 11. Элементы DFD-диаграммы в нотации Гейна-Сарсона:

а— процесс; б — поток данных; в — хранилище данных;

г— внешняя сущность

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

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

Внешние сущности. Внешние сущности определяют элементы вне контекста системы, которые участвуют в процессе

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

пример: заказчик, персонал, поставщик, клиент, склад, банк.

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

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

Диаграммы могут быть дополнены мини-спецификациями и словарями.

ввода свойств компонентов, а соответствующий программный код генерируется автоматически.

Внимание программистов переключилось с непосредственного написания программного кода на предшествующие этапы — анализ предметной области и проектирование программы. Появились методы объектно-ориентированного анализа и проекти-

рования (OOA/OOD — Object-Oriented Analysis/Design), кото-

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

Язык UML объединил наиболее известные методы OOA/OOD и очень быстро приобрел широкую популярность среди разработчиков программного обеспечения.

Основными «строительными блоками» UML являются диаграммы, которые условно можно разделить на две категории:

структурные модели, описывающие структуру системы, – классы, компоненты, подсистемы и т. д.;

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

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

Моделирование бизнеса с помощью UML предполагает последовательное построение двух видов моделей:

1)прецедентной модели (аналога модели поведения), опиисывающей функциональность — бизнес-процессы (прецеденты), их взаимодействие с окружением;

2)объектной модели (аналога структурной модели), описывающей внутреннее устройство бизнеса — объекты, участвующие в выполнении бизнес-процессов, их взаимодействие.

3.3.2. Прецедентная модель бизнеса

Построение прецедентной модели бизнеса (Business Use Case Model) начинается с формирования так называемой внешней диаграммы, или диаграммы вариантов использования (Use Case Diagram). Она описывает бизнес так, как он виден извне, т. е. как он воспринимается клиентами и другим окружением. Данная диаграмма отражает представление о том, что делает бизнес, а не как делает.

Основными элементами диаграммы являются прецедент (вариант использования, business use case), актор (действующее лицо, business actor), отношение ассоциации, зависимость, отношение обобщения, примечание. Условные обозначения этих элементов приведены на рис. 3.13, пример диаграммы — на рис. 3.14.

Рис. 3.13. Элементы диаграммы вариантов использования модели бизнеса: а — актор; б — прецедент; в — ассоциация; г — зависимость; д — обобщение; е — примечание

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

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

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

отношение обобщения (см. рис. 3.14).

Между прецедентами и акторами устанавливаются отношения коммуникации (отношения ассоциации со стереотипом communicate). Они моделируют информационные и материальные потоки, т. е. обмен прецедентов с субъектами окружения объектами материальной или информационной природы (данными, документами продукцией, сырьем и т. д.). Следует заметить, что между акторами отношения коммуникации обычно не указываются, так как с точки зрения бизнес-системы они не

представляют интереса. Между прецедентами отношения коммуникации, как правило, также не устанавливаются, так как в процессе своего выполнения они не «обращаются» друг к другу. Допустимо установление отношений зависимости между прецедентами, а также отношений, структурирующих прецеденты, — отношений обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend). Подробнее структуризация прецедентов будет рассмотрена ниже.

Для каждого элемента модели составляется спецификация. В спецификации актора указывается наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др. Спецификация прецедента содержит его наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов.

Наиболее важным для описания прецедента является документ, называемый «потоком событий» (flow of events). Он описывает сценарии осуществления прецедента в виде последовательности шагов процесса. Рассмотрим для примера поток событий прецедента «Продажа продукта»:

1) Продавец получает заявку Клиента; 2) если в заявке указан готовый продукт, то Продавец про-

веряет наличие требуемого продукта на складе. Если продукта нет в наличии, прецедент заканчивается. Иначе прецедент продолжается с шага 4;

3) если в заявке указывается заказной продукт, то Продавец формирует заказ и передает его Изготовителю продукта:

3а — Изготовитель производит продукт; 3б — Изготовитель сообщает о готовности изделия Про-

давцу и отправляет продукт на Склад;

4)Продавец сообщает Клиенту о готовности продукта и принимает от Клиента оплату;

5)Продавец сообщает Отправителю количество продукта и адрес клиента и заказывает транспорт;

6)Отправитель получает продукт со склада и доставляет его Клиенту.