Мелихов А.Ю. Проектирование автоматизированных систем обработки информации и управления
Подождите немного. Документ загружается.
51
Если объекты разрушаются в какой-то момент для освобождения ресурсов системы,
то их линия жизни обрывается в момент уничтожения. Для обозначения такого момента
используется специальный символ в форме латинской буквы «X».
Объекты на диаграмме последовательности могут находиться в двух состояниях,
активном — непосредственно выполняя какие-либо действия, и пассивном, ожидая
сообщения от других объектов. Чтобы явно выделить подобную активность объектов,
применяется фокус управления (focus of control). Фокус управления изображается в форме
вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения
фокуса управления объекта (начало активности), а ее нижняя сторона – окончание фокуса
управления (окончание активности).
Рисунок 17 – Диаграмма последовательностей для варианта использования «Добавление
файла УММ для обработки»
Каждое взаимодействие между объектами описывается совокупностью сообщений,
которыми объекты обмениваются между собой или операций, которые объекты вызывают
для выполнения определенных действий. Сообщение (message) представляет собой
законченный фрагмент информации, который отправляется одним объектом другому.
Объект, принявший сообщение, должен отреагировать на него какой-либо
последовательностью действий, направленных на решение поставленной задачи.
Порядок сообщений указывается в вертикальном направлении. Тип сообщения
отражается с помощью разнообразных стрелок:
• Simple (1) - простая посылка сообщения;
• Synchronous (2) - операция происходит только в том случае, когда клиент посылает
сообщение, а сервер может принять сообщение клиента;
• самоделегирование (3) - распространенное явление в ООП, например, когда объект
вызывает свой собственный (как правило, защищенный) метод.
• Balking (4) - операция происходит только в том случае, когда сервер готов немедленно
принять сообщение, если сервер не готов к приему, клиент не выдает сообщение;
• Timeout (5) - клиент отказывается от выдачи сообщения, если сервер в течение
определенного времени не может его принять;
• Procedure Call (6) - клиент вызывает процедуру сервера и полностью передает ему
управление;
• Asynchronous (7) - клиент выдает сообщение, и, не ожидая ответа сервера, продолжает
выполнение своего программного кода.
• Return (8) - определяет, что происходит возврат из процедуры;
52
Частота посылки сообщений может иметь два варианта:
• Periodic – сообщения поступают от клиента с заданной периодичностью;
• Aperiodic – сообщения поступают от клиента нерегулярно.
Рисунок 18 – Виды сообщений на диаграмме последовательностей
Необходимо придерживаться следующего требования, предъявляемого к имени
сообщения: для повышения информативности имя должно начинаться с глагола add
(добавить), enter (ввести), end (завершить), load (загрузить) и т.д.
Первоначально на этапе анализа системы как модели черного ящика на диаграмме
последовательности система представляется одним объектом. Операции, которые в этом случае
отображаются на диаграмме называются системными. Они составляют открытый интерфейс
системы и предназначены для обработки всех входных системный событий, которые система
выполняет как черный ящик. В последствии для уточнения описаний системных операций (их
предусловий и постусловий) используются диаграммы активностей.
Как и все прочие диаграммы UML, диаграммы последовательностей проходят две
стадии детализации: (i) стадия сбора требований и анализа, когда создаются эскизные версии
диаграмм, на которых отражаются лишь основные объекты и сообщения, предназначенные
прежде всего для согласования с заказчиком понимания, процессов, протекающих в системе
при реализации того или иного прецедента заказчиком процессов; (ii) стадия
проектирования, на которой все диаграммы снабжают максимальным количеством деталей
для упрощения работы программиста и/или документирования итоговых результатов этапа
реализации. При этом на диаграмме последовательностей операции снабжаются сигнатурой
(имя и параметры), а в описании диаграммы приводится их спецификация, включающая в
свой состав указание пред- и постусловий.
53
Рисунок 19 – Диаграмма последовательностей для варианта использования «Добавить файл
УММ для обработки»
Диаграмма сотрудничества (Collaboration Diagram) отличается от диаграммы
взаимодействия тем, что она не акцентирует внимание на последовательности передачи
сообщений. Она имеет форму графа узлы (объекты) которого могут размещаться в
произвольном месте диаграммы.
Так как временная шкала не участвует в демонстрации обмена сообщениями, то эта
диаграмма получается компактней и лучше подходит для того, чтобы проанализировать
взаимодействие всех объектов между собой.
Таким образом, диаграмма последовательностей точно описывает временной порядок
сообщений, но занимает много места, а диаграмма сотрудничества экономит пространство,
но ухудшает прослеживание последовательности передачи сообщений (выполнения
операций).
Рисунок 20 – Диаграмма сотрудничества
На диаграмме сотрудничества порядок передачи сообщений иллюстрируется с
помощью порядковых номеров. Возможно использование следующих типов связей:
54
• Связь Link To Self (связь с самим собой) показывает, что объект имеет обратную связь с
самим собой.
• Link Message / Reverse Link Message (передача сообщения / обратная передача) позволяет
отразить связь, которая подразумевает обязательную передачу сообщения в прямом
(обратном) направлении.
• Data Flow / Reverse Data Flow (поток данных) позволяет отразить связь показывающую,
что происходит передача данных от одного объекта другому в прямом / обратном
направлении.
Отличительной особенностью диаграммы сотрудничества по сравнению с диаграммой
взаимодействия является возможность использовать более богатый набор синтаксических
конструкций. На рис. смоделирована ситуация, которая предусматривает наличие у
экземпляра класса «ConcreteStateA» метода «create». Метод «create» в цикле позволяет
создать мультиобъект (коллекцию) «ConcreteStateB». Причем, поскольку метод «create»
вызывается с аргументом, то это означает, что при создании используется конструктор с
параметрами.
Рисунок 21 – Циклы на диаграмме сотрудничества
При необходимости подобный синтаксические конструкции могут использоваться и
на диаграмме последовательностей, одна это может нарушить идеологию: диаграммы
последовательностей предназначены для акцентирования внимания на порядок передачи
сообщений (вызов операций), а диаграммы сотрудничества для отображения
дополнительных особенностей передачи сообщений.
3.2.2.3. Диаграмма деятельности (Activity Diagram)
Диаграммы деятельности (Activity Diagram) позволяет изобразить поток операций в
системном, производственном или технологическом процессе. Диаграммы деятельности
используется для моделирования прецедента в виде последовательности действий (activity),
описывающих взаимодействие актера с системой. Эта диаграмма концентрирует внимание
на том, какие действия выполняются и кто несет ответственность за их выполнение.
Деятельность изображается на диаграмме в виде
Деятельность может быть двух типов:
action – действие.
send event – посылка события.
В свою очередь действие (action) может имеет имя (name) и выполняться по входу (on
Entry), по выходу (on Exit), во время (Do) и при возникновении события (on Event).
Семантика деятельности «Подготовка диска» в состав которого входит действие
«Форматирование», которое выполняется по входу имеет след. вид:
Рисунок 22 – Изображение действия на диаграмме деятельности
При инициализации действия по событию (on Event) можно указать имя события,
передаваемые аргументы (arguments) и условие, которое должно выполниться для
инициализации действия по данному событию. Семантика деятельности «Технологический
55
процесс», включающее действие «Звонок», которое выполняется при возникновении
события «ПроцессЗакончен» с аргументом «time» и условием «time=0» имеет след. вид:
Рисунок 23 – Изображение действия с событием
Если деятельность имеет тип «send event» - послать событие, то, кроме указания
момента инициализации данной деятельности (on Entry, on Exit, Do, on Event) можно указать
посылаемые аргументы (Send arguments) и целевую деятельность (Send target). Действие
«Звонок» деятельности «Технологический процесс» выполняется при возникновении
события «ПроцессЗакончен» с аргументом «time» и условием «time=0» и заключается в
посылке сообщения деятельности «Завершение процесса» с аргументами (статус и полное
время). В этом случае семантика деятельности «Технологический процесс» имеет след. вид:
Рисунок 24 – Изображение действия с событием и условием осуществления
Диаграмма деятельности кроме собственно деятельностей (activity) может включать в
свой состав состояния (State), синхронизации (Synchronizations), узел решения (слияния) –
decision и разделы (swimlanes-плавательные дорожки).
Состояние (State) – это ситуация в жизни объекта на протяжении которой он
удовлетворяет некоторому условию при этом объект осуществляет определенные действия
или ожидает некоторого события. Так же как и Деятельность состояние может быть двух
типов: action – состояние в котором выполняется заданное действие и send event – состояние,
которое посылает событие с аналогичными настройками момента перехода в состояние или
посылки сообщения.
Перемещение объекта от одной деятельности (состояния) к другой отражается с пом.
стрелки (transition). Спецификация перехода включает в себя:
• событие (event) – это то, что вызывает переход от одной деятельности к другой. Имя
события помещается над связью между состояниями. У события могут быть аргументы.
• защитные условия (guard conditions) – условия, наложенные на осуществление перехода.
Защитные условия указываются вдоль линии перехода после имени события и
заключаются в квадратные скобки.
• действие (action), которое должно быть выполнено в процессе перехода (указывается
вдоль линии перехода после «/»).
• событие, которое может быть послано (send event) целевой деятельности (send target) с
аргументами (send arguments)
Рисунок 25 – Семантика условного перехода
Диаграммы деятельности поддерживает возможность создания вложенных
деятельностей (состояний).
Деятельность может начаться при возникновении некоторого события или в момент
инициализации первой деятельности, обозначается знаком - . Символ завершения
исполнения - .
56
Узел синхронизации (Synchronizations) предназначен для разделения потока на
несколько параллельных потоков или, напротив, объединяет несколько входящих потоков на
один исходящий.
Узел решения – decision должен сопровождаться указанием условия перехода в виде
комментария. При этом каждая ветвь потока должна снабжаться сторожевым условием
(guard condition). Он становится узлом слияния, если объединяет несколько потоков.
Разделы (swimlanes-плавательные дорожки) предназначены для разделения
деятельностей с помощью их группировки по прецедентам, классам, компонентам, ролям и
т.д.
Историческое состояние (обозначается «Н») – это псевдосостояние, которое
восстанавливает предыдущее активное состояние в композитном состоянии. Оно позволяет
композитному состоянию OpenState запоминать, какое из вложенных состояний (StopState
или StartState) было текущим в момент выхода из OpenState, для того, чтобы любой из
переходов
в OpenState возвращался именно в это вложенное состояние, а не в начальное.
Рисунок 26 – Изображение «Исторического состояния»
Диаграмма состояний (Statechart Diagram) является частным случаем диаграммы
деятельности и предназначена для описания состояний объекта и условий перехода между
ними, которые в совокупности характеризуют поведение объекта в течение его жизненного
цикла. Диаграмма состояний по существу является графом специального вида, который
представляет некоторый автомат. Вершинами этого графа являются состояния. Дуги графа
служат для обозначения переходов из состояния в состояние.
57
Рисунок 27 – Пример построения диаграммы деятельности
Диаграммы взаимодействия (sequence и collaboration), а также диаграмма
деятельности (activity) широко используются и на этапе анализа и на этапе проектирования
для документирования результатов. Однако основное назначение этих диаграмм состоит в
анализе предметной области (технологического процесса) для которой разрабатывается
система. Основой же будущей системы является модель предметной области. Поэтому
основной задачей стадии анализа является идентификация понятий предметной области и
представление результатов в виде модели предметной области. По окончании
проектирования эта модель преобразуется в код. В этой связи вопросам построения модели
предметной области требуется уделить особое внимание.
3.2.2.4. Диаграмма классов (Class Diagram)
Модель предметной области отображает основные (с точки зрения проектировщика)
классы понятий (концептуальные классы) в терминах предметной области. На языке UML
модель предметной области представляется в форме диаграммы классов, на которой
изображаются классы понятий реального мира, а не программных компонент. Кроме
концептуальных классов модель предметной области может отображать ассоциации между
классами и атрибуты концептуальных классов. Однако операции на диаграмме классов
модели предметной области не отображаются.
58
Модель предметной области строится итеративно в течение нескольких
итераций фазы развития. На каждой последующей итерации к модели добавляются
новые концептуальные классы или уточняются имеющиеся классы очередного
анализируемого варианта использования.
Наиболее простой прием идентификации концептуальных классов состоит в
выделении существительных из текстового описания предметной области и их рассмотрения
в качестве кандидатов в концептуальные классы или атрибуты.
Например, на рис. представлена диаграмма классов основного сценария варианта
использования П.1 «Добавление файла УММ для обработки», где
Спецификация загрузок УММ
моделирует таблицу БД, в которую будут сохраняться данные (логин пользователя, дата, имя файла)
о загружаемых на сервер файлах УММ. В Спецификации УММ для каждой УММ сохраняется
атрибутивная информация (название УММ, год издания, кол-во страниц и т.д.), состав которой
перечислен в ТЗ.
Рисунок 28 - Диаграмма классов варианта использования П.1 «Добавить файл УММ для
обработки»
На диаграмме класс изображается в виде прямоугольника, снабженного тремя
внутренними зонами: имя класса, атрибуты, операции. Операция устанавливает форму
функции или процедуры (ее сигнатуру). Конкретной реализацией операции является метод.
В качестве имени класса следует использовать существительное в ед. числе.
Рисунок 29 – Изображение класса на диаграмме классов
Объекты обмениваются сообщениями через соединения - связи. Но, для того, что бы
между объектами была связь, между классами этих объектов должна существовать
ассоциация, так как связь между объектами – это экземпляр ассоциации между классами.
Ассоциация – это связь между классами, отражающая некоторое значимое отношение между
ними.
В процессе анализа ассоциаций необходимо придерживаться принципами
минимализма, поскольку, если МПО будет состоять из N классов, то теоретически между
ними можно будет установить N(N-1). В этой связи, в модель включают только те
ассоциации, знания о которых необходимо сохранять в течение некоторого периода.
Не только ассоциация в целом может иметь имя, но и классам на обоих концах
ассоциации могут быть присвоены имена ролей, исполняемые объектами классов, когда они
59
связаны экземпляром данной ассоциации. Стрелка показывает направление передачи
информации (например, посылки сообщения) от одного объекта к другому.
Например, предположим, что компания нанимает n служащих. Ограничения
кратности (множественность - multiplicity) «1» и «n» означают, что объекты Person в данный
момент времени могут быть наняты только одним объектом Company и Person не могут быть
безработными. Объект Company может посылать сообщения объектам Person, но не
наоборот.
Рисунок 30 – Использование символов множественности на диаграмме классов
Недооцененная кратность ограничивает гибкость приложения, например, некоторые
персональные менеджеры не позволяют охранять несколько телефонов для одного человека.
Частным случаем ассоциации является ассоциация-класс (Association Class), которая
обладает как свойствами класса, так и свойствами ассоциации. Ассоциация-класс – это
место, где хранятся относящиеся к ассоциации атрибуты и операции.
Имена полюсов ассоциаций являются обязательными, когда класс имеет ассоциацию с
самим собой (рефлексивная ассоциация), которая означает, что объекты данного класса
имеют связи с другими объектами этого же класса.
Каждый объект Directory может иметь связь с объектами Directory, выступающими в
роли subdirectory, число которых может меняться от 0 до n. C другой стороны у подкаталога
родитель может быть только 1 или не иметься вообще. Кроме того, Directory может иметь
связь с произвольным числом объектов File.
Рисунок 31 – Пример использования рефлексивной ассоциации на диаграмме классов
Ввиду широкого распространения ассоциаций типа многие-ко-многим в UML
предусмотрены специальные классы ассоциации. Подобно обычным классам, классы
ассоциаций могут иметь атрибуты и операции, являющиеся принадлежностью связи, т.е.,
такие, которые не могут быть приписаны ни к одному из объектов-участников ассоциации.
На рис. атрибут accessPermission (разрешение доступа) класса AccessibleBy (Доступно)
относится и
к файлу и пользователю одновременно и не может быть прикреплен только к
одному из них без потери информации.
Рисунок 32 – Класс-ассоциация
Конкретизированные формы
ассоциации (association):
• зависимость (dependency) – однонаправленная связь, показывающая, что один класс
зависит от определений, сделанных в другом. Такая связь имеет место, например, если
один класс использует другой в качестве параметра операции. При генерации кода к
60
исходному классу атрибуты целевого класса добавлены не будет, но в код будет
добавлен оператор типа «#include».
• агрегация (aggregation) – частный случай ассоциации, который выражает отношение
целое-часть (например, автомобиль-двигатель). Агрегация является транзитивной: если
А является частью В, а В – частью С, то А - часть С. Агрегация изображается с помощью
ромба, который ставится около полюса, являющегося агрегатом. Жизненный цикл
объекта–части совпадает с ЖЦ объекта-целого. Более сильная разновидность агрегации –
это связь типа «композиция» (объединение – composition), которая накладывает на
ассоциацию два дополнительных ограничения: (i) составляющая часть может
принадлежать не более чем одному агрегату; (ii) составляющая часть получает срок
жизни агрегата. Композиция обозначается закрашенным ромбом.
Таким образом, агрегация – это способ встраивания нескольких объектов в один объект-
контейнер и использование встраиваемых объектов для реализации методов контейнера.
>>> class Customer:
def __init__(self,name): # присваивание данных атрибутам через ссылку self
self.name=name # создает или изменяет данные именно экземпляра, а не
def state(self): # всего класса в целом
print "My name is ", self.name, " and I am very busy"
>>> student=Customer("Ivan")
>>> student.state()
My name is Ivan and I am very busy
>>> class Group_1161:
def __init__(self):
self.customer=Customer("Ivan") # обращение к классу-части при
self.customer.state() # инициализации класса-контейнера
def state(self,name):
customer=Customer(name) # обращение к методу класса-части
customer.state() # из метода класса-контейнера
>>> group=Group_1161()
My name is Ivan and I am very busy
>>> group.state("Anton") # устанавливается связь между двумя
My name is Anton and I am very busy # классами, т.к. вызов метода класса
# контейнера приводит к вызову одного или нескольких методов класса-части
• обобщение (generalization) – показывает связи наследования между двумя классами
(суперкласс-подкласс). При этом, подклассы наследуют все возможности своих
надклассов (атрибуты, операции, отношения, ограничения) – inheritance. Обобщение
часто используется совместно с абстрактными классами, которые могут иметь
абстрактные атрибуты и операции. Абстрактные классы не создают экземпляров.
Подкласс абстрактного класса реализует абстрактные операции, добавляя новые
возможности, или переопределяя их.
Рисунок 33 – Наследование на диаграмме классов