Материал: Учебник Рекомендовано Федеральным государственным учреждением

Рис. 4.21. Диаграмма деятельности для варианта использования
«Поставка товара»
Теперь рассмотрим пример построения диаграммы деятель­
ности. В предыдущем примере для конкретизации описания ва­
риантов использования в АИС «Склад оптовой торговли» был разработан текстовый сценарий. Этот сценарий дополняет диа­
грамму, раскрывая содержание отдельных действий, выполняемых
125

Рис. 4.22. Диаграмма деятельности для варианта использования
«Продажа товара»
системой и актерами. Однако вместо описания вариантов исполь­
зования или в дополнение к ним можно использовать диаграммы деятельностей. Диаграмма деятельности позволяет проиллюстри­
ровать вариант использования с требуемой степенью подробности.
Имеет смысл уточнять только те варианты использования, краткое
126

Объект 1
Объект 2
Объект 3
(
)
(
)
(
)
Рис. 4.23. Вариант диаграммы деятельности с дорожками
описание которых недостаточно для понимания сущности ре­
шаемых проблем. Диаграммы деятельностей можно использовать вместо текстового описания вариантов использования или в до­
полнение к ним.
В рамках разрабатываемой модели построим диаграммы дея­
тельности для реализации вариантов использования «Продажа товара» и «Поставка товара». На рис. 4.20 показан вариант диа­
граммы деятельности для описания последовательности действий при поставке товаров.
Однако диаграмма деятельности позволяет проиллюстрировать вариант использования с различной степенью подробности, и диаграмму деятельности для варианта использования «Поставка товара» можно представить следующим образом (рис. 4.21).
Проанализировав вариант использования «Продажа товара», построим диаграмму деятельности для варианта использования
«Продажа товара» (рис. 4.22).
Полная модель системы может содержать несколько диаграмм деятельности, каждая из которых описывает последовательность реализации либо наиболее важных вариантов использования (ти­
пичный ход событий и все исключения), либо нетривиальных операций классов.
Помимо стандартного формата описания UML предлагает вариант с «плавательными дорожками». Этот формат удобен для описания случая, когда в варианте использования участвуют не­
сколько действующих лиц. При этом все состояния действия на диаграмме деятельности делятся на отдельные группы, отделя­
ющие друг от друга вертикальными линиями (рис. 4.23). Приме­
нение дорожек открывает дополнительные возможности для на­
глядного представления бизнес-процессов, позволяя специфици­
ровать деятельность подразделений предприятий (рис. 4.24).
В случае типового проекта большинство деталей реализации действий могут быть известны заранее на основе анализа суще­
ствующих систем или предшествующего опыта разработки систем-
127

Рис. 4.24. Пример применения диаграммы деятельности с дорожками
для варианта использования «Оформление заказа»
прототипов. Использование типовых решений может существен­
но сократить время разработки и избежать возможных ошибок при реализации проекта.
4.3.5. Диаграммы последовательности
Рассмотренные диаграммы деятельности используются для спецификации динамики поведения систем, время в явном виде
128

в них не присутствует. Однако временной аспект поведения может иметь существенное значение при моделировании синхронных процессов, описывающих взаимодействия объектов. Именно для этой цели в языке UML используются диаграммы последователь­
ности — графические модели, которые для определенного сцена­
рия варианта использования показывают динамику взаимодей­
ствия объектов во времени.
Для построения диаграммы последовательностей системы не­
обходимо:
— идентифицировать каждое действующее лицо (объект) и изобразить для него линию жизни;
— из описания варианта использования определить множество системных событий и их последовательность;
— изобразить системные события в виде линий со стрелкой на конце между линиями жизни действующих лиц и системы, а так­
же указать имена событий и списки передаваемых значений.
На диаграмме последовательности изображаются исключитель­
но те объекты, которые непосредственно участвуют во взаимодей­
ствии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключе­
вым моментом является именно динамика взаимодействия объ­
ектов во времени. При этом диаграмма последовательности име­
ет как бы два измерения.
Первое измерение — слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни. Внутри прямоугольника записывают имя объекта и имя класса, разделенные двоеточием. При этом вся за­
пись подчеркнута, что является признаком объекта, который, как известно, представляет собой экземпляр класса (рис. 4.25).
Не исключается ситуация, когда имя объекта может отсутство­
вать на диаграмме последовательности. В этом случае указывает­
ся только имя класса, а сам объект считается анонимным.
Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия (объект 1). Правее изо­
бражается другой объект, который непосредственно взаимодей­
ствует с первым. Таким образом, все объекты на диаграмме по­
следовательности образуют некоторый порядок, определяемый степенью активности этих объектов при взаимодействии друг с другом.
Второе измерение диаграммы последовательности — верти­
кальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы.
При этом взаимодействия объектов реализуются посредством со­
129

общений, которые посылаются одними объектами другим. Со­
общения изображаются в виде горизонтальных стрелок с именем сообщения. Кроме того, их показывают в определенном порядке в соответствии со временем своего возникновения. Другими сло­
вами, сообщения, расположенные на диаграмме последователь­
ности выше, инициируются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, посколь­
ку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа «раньше-позже».
Линия жизни объекта служит для обозначения периода време­
ни, в течение которого объект существует в системе и, следова­
тельно, может потенциально участвовать во всех ее взаимодей­
ствиях. На диаграмме линия жизни изображается пунктирной вертикальной линией, ассоциированной с единственным объек­
том. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы по­
следовательности.
Построение диаграммы последовательности целесообразно начинать с выделения из всей совокупности тех и только тех клас­
сов, объекты которых участвуют в моделируемом взаимодействии.
После этого все объекты наносят на диаграмму с соблюдением некоторого порядка инициализации сообщений. Здесь необходи­
мо установить, какие объекты будут существовать постоянно, а какие временно — только на период выполнения ими требуемых действий. Когда объекты определены, можно приступать к специ­
фикации сообщений. При этом следует учитывать те роли, кото­
рые играют сообщения в системе.
Рис. 4.25. Различные графические примитивы диаграммы последова­
тельности
130

Рис. 4.26. Вариант диаграммы последовательности для моделирования
операции продажи товара
В качестве примера построим диаграмму последовательности для реализации варианта использования «Продажа товара» в АИС
«Склад оптовой торговли» (рис. 4.26).
Данная диаграмма содержит два объекта и одного актера. Объ­
екты не являются постоянно активными, что показано с помощью соответствующих фокусов управления. В качестве имен сообще­
ний указаны имена операций, которые специфицированы у соот­
ветствующих классов. Предложения-условия некоторых сообще­
ний записаны обычным текстом в квадратных скобках. Эти условия отражают возможность ветвления процесса продажи и выполнения исключительного сценария соответствующего вари­
анта использования, однако другие варианты использования на данной диаграмме не показаны.
4.4. Сравнение структурного и объектно-
ориентированного методов моделирования
В функциональных моделях (DFD-диаграммах потоков данных,
IDEF-диаграммах) главными структурными компонентами явля­
ются функции (операции, действия, работы), которые на диа­
граммах связываются между собой потоками информации.
131

Несомненным достоинством функциональных моделей явля­
ется реализация структурного подхода к проектированию инфор­
мационной системы по принципу «сверху-вниз», когда каждый функциональный блок может быть декомпозирован на множество подфункций, задач и т.д., выполняя, таким образом, модульное проектирование информационной системы. Для функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления.
При функциональном подходе объектные модели данных в виде
ER-диаграмм «объект — свойство — связь» разрабатываются от­
дельно.
Главный недостаток функциональных моделей заключается в том, что процессы и данные существуют отдельно друг от друга — помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане. Кроме того, не ясны усло­
вия выполнения процессов обработки информации, которые динамически могут изменяться.
Перечисленные недостатки функциональных моделей отсут­
ствуют в объектно-ориентированных моделях, где главным струк­
турообразующим компонентом выступает класс объектов с на­
бором функций, которые могут обращаться к атрибутам этого класса. Для классов объектов характерна иерархия обобщения, позволяющая осуществлять наследование не только атрибутов
(свойств) объектов от вышестоящего класса объектов к ниже­
стоящему классу, но и функций (методов).
В случае наследования функций можно абстрагироваться от конкретной реализации процедур (абстрактные типы данных), которые различаются для определенных подклассов ситуаций. Это дает возможность обращаться к подобным программным модулям по общим именам (полиморфизм) и повторно использовать про­
граммный код при модификации программного обеспечения.
Таким образом, адаптивность объектно-ориентированных систем к изменению предметной области по сравнению с функциональ­
ным подходом значительно выше.
При объектно-ориентированном подходе изменяется и прин­
цип проектирования ИС. Сначала выделяют классы объектов, а далее в зависимости от возможных состояний объектов (жизнен­
ного цикла объектов) определяют методы обработки (функцио­
нальные процедуры), что обеспечивает наилучшую реализацию динамического поведения информационной системы.
Для объектно-ориентированного подхода разработаны графиче­
ские методы моделирования предметной области, обобщенные в языке унифицированного моделирования UML. Однако по нагляд­
ности представления модели пользователю-заказчику объектно-ори- ентированные модели явно уступают функциональным моделям.
132

При выборе методики моделирования предметной области обычно в качестве критерия выступает степень ее динамичности.
Для регламентированных задач больше подходят функциональные модели, для более адаптивных бизнес-процессов (управления рабочими потоками, реализации динамических запросов к ин­
формационным хранилищам) — объектно-ориентированные.
Однако в рамках одной и той же ИС для различных классов задач могут требоваться различные виды моделей, описывающих одну и ту же проблемную область. В таком случае нужно использовать комбинированные модели предметной области.
Таким образом, каждая из рассмотренных методик позволяет решить задачу построения формального описания рабочих про­
цедур исследуемой системы. Все методики позволяют построить модели «как есть» и «как должно быть». В то же время каждая из этих методик обладает существенными недостатками. В целом их можно охарактеризовать следующим образом: недостатки при­
менения отдельной методики лежат не в области описания реаль­
ных процессов, а в неполноте методического подхода.
Функциональные методики нагляднее дают представление о существующих функциях в организации, о методах их реализации.
Причем, чем выше степень детализации исследуемого процесса, тем лучше они позволяют описать систему. Под лучшим описа­
нием в данном случае понимается наименьшая ошибка при по­
пытке по полученной модели предсказать поведение реальной системы. На уровне отдельных рабочих процедур их описание практически однозначно совпадает с фактической реализацией в потоке работ.
На уровне общего описания системы функциональные мето­
дики допускают значительную степень свободы в выборе общих интерфейсов системы, ее механизмов и т.д., т.е. в определении границ системы. Хорошо описать систему на этом уровне позво­
ляет объектный подход, основанный на понятии сценария ис­
пользования. Ключевым является понятие о сценарии использо­
вания как о сеансе взаимодействия действующего лица с системой, в результате которого действующее лицо получает нечто, имеющее для него ценность. Использование критерия ценности для поль­
зователя дает возможность отбросить не имеющие значения де­
тали потоков работ и сосредоточиться на тех функциях системы, которые оправдывают ее существование. Однако и в этом случае задача определения границ системы, выделения внешних пользо­
вателей является сложной.
Технология потоков данных, исторически возникшая первой, легко решает проблему границ системы, поскольку дает возмож­
ность за счет анализа информационных потоков выделить внеш­
ние сущности и определить основной внутренний процесс. Одна­