Язык UML

Введение

Диаграмма последовательности (англ. sequence diagram) — UML-диаграмма, на которой для некоторого набора объектов на единой временной оси показан жизненный цикл объекта (создание-деятельность-уничтожение некой сущности) и взаимодействие актеров (действующих лиц) информационной системы в рамках прецедента.

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

1 Замечания (описание)Здесь представлен основной набор символов диаграммы последовательности, необходимый для того, чтобы суметь прочитать диаграмму.
 Термин Изображение  Описание
 Найденное сообщение    У первого сообщения нет участника, пославшего его, поскольку оно приходит из неизвестного источника. Оно называется найденным сообщением (found message).
 Сообщение    Команда, отправляемая другому участнику. Может содержать только передаваемые данные.
 Линия жизни    Каждая линия жизни имеет полосу активности, которая показывает интервал активности участника при взаимодействии. Она соответству ет времени нахождения в стеке одного из методов участника. В языке UML полосы активности не обязательны, но я считаю их исключительно удобными при пояснении поведения.
 
 Участник    В большинстве случаев можно считать участников диаграммы взаимодействия объектами, как это и было в действительности в UML 1. Но в UML 2 их роль значительно сложнее. Поэтому здесь употребляется термин участники (participants), который формально не входит в спецификацию UML.
 Самовызов    Участник отправляет сообщение (команду) самому себе.
 Возврат    Передача управления обратно участнику, который до этого инициировал сообщение.
 Активация    На изображении это — белый вертикальный прямоугольник. Момент, когда участник начинает действовать в ответ на принятое сообщение.
 Создание    В случае создания участника надо нарисовать стрелку сообщения, на правленную к прямоугольнику участника. Если применяется конст руктор, то имя сообщения не обязательно, но можно маркировать его словом «new» в любом случае. Если участник выполняет что- нибудь непосредственно после создания, например команду запроса, то надоначать активацию сразу после прямоугольника участника.
 Самоудаление    Удаление участника обозначается большим крестом (X). X в конце линии жизни показывает, что участник удаля ет сам себя.
 Удаление из другого объекта    Удаление участника обозначается большим крестом (X). Стрелка сооб щения, идущая в X, означает, что один участник явным образом уда ляет другого.
 Фреймы взаимодействия    
Общая проблема диаграмм последовательности заключается в том, как отображать циклы и условные конструкции.
Прежде всего надо усвоить, что диаграмма последовательности для этого не предназначе на. Подобные управляющие структуры лучше показывать с помощью диаграммы деятельности или собственно кода.
Диаграмма последова тельности применяется для визуализации процесса взаимодействия объектов, а не как средство моделирования алгоритма управления.Как было сказано, существуют дополнительные обозначения. И для циклов, и для условий используются фреймы взаимодействий (inter action frames), представляющие собой средство разметки диаграммы взаимодействия.

2 Как применять технику креативностиДиаграммы последовательности следует применять тогда, когда требуется посмотреть на поведение нескольких объектов в рамках одного прецедента. Диаграммы последовательности хороши для представления взаимодействия объектов, но не очень подходят для точного определения поведения.
Если вы хотите посмотреть на поведение одного объекта в нескольких прецедентах, то примените диаграмму состояния. Если же надо изучить поведение нескольких объектов в нескольких прецедентах или потоках, не забудьте о диаграмме деятельности.
Если требуется быстро исследовать несколько вариантов взаимодействия, лучше использовать CRC-карточки, поскольку это позволяет избежать непрерывного рисования и стирания. Часто бывает удобно поработать с CRC-карточками для просмотра вариантов взаимодействия, а затем с помощью диаграмм взаимодействий фиксировать те взаимодействия, которые будут применяться позже.
Другим полезным видом диаграмм взаимодействий являются коммуникационные диаграммы, которые показывают соединения, и временные диаграммы, показывающие временные интервалы.
Одним из наиболее полезных приемов, соответствующих хорошему стилю ООП, является исследование взаимодействия объектов, поскольку его цель состоит в том, чтобы исследовать работу программы, а не данные. CRC-диаграммы (Class-Responsibility-Collaboration, класс-обязанность-кооперация), придуманные Уордом Каннингемом (Ward Cunningham) в конце 80-х годов, выдержали проверку временем и стали высокоэффективным инструментом решения этой задачи (рис. 4.6). И хотя они не входят в состав UML, все же являются очень популярными среди высококвалифицированных разработчиков в области объектных технологий.
Для использования CRC-карточек вы и ваши коллеги должны собраться за столом. Возьмите различные сценарии и проиграйте их с помощью карточек, поднимая их над столом, в то время когда они активны, и передавая их по кругу в предположении, что они посылают сообщение. Эту технологию почти невозможно описать в книге, но легко продемонстрировать; лучший способ научиться этому состоит в том, чтобы попросить кого-нибудь, кто имеет такой опыт, показать вам это.
Важным моментом в CRC-методике является определение ответственностей. Ответственность (responsibility) – это краткое описание того, что объект должен делать: операция, которую выполняет объект, некоторый объем знаний, который объект поддерживает, или какие-либо важные решения, принимаемые объектом. Идея состоит в том, чтобы вы могли взять любой класс и сформулировать его разумно ограниченные обязанности. Такой образ действия поможет вам яснее представить себе архитектуру классов.
Вторая буква «С» (в CRC) означает взаимодействие (collaboration): другие классы, с которыми должен работать рассматриваемый класс. Это дает вам некоторое представление о связях между классами, но все еще на высоком уровне.
Одно из главных преимуществ CRC-карточек состоит в том, что они способствуют живому обсуждению проектов в среде разработчиков. Если в процессе работы над шаблоном поведения вы хотите посмотреть, как классы его реализуют, то вычерчивание диаграмм взаимодействия, описанных в этой главе, может занять слишком много времени. Обычно требуется просмотреть варианты, а рисование и стирание вариантов на диаграммах может быть очень утомительным. С помощью CRC-карточек разработчики моделируют взаимодействие, поднимая карточки и передавая их по кругу. Это позволяет быстро просчитать варианты.
В процессе работы вы создаете представление об ответственностях и записываете их на карточки. Размышления об ответственностях важны, поскольку рассеивают представление о классах как о бессловесных хранителях данных и помогают членам команды лучше понять поведение каждого класса на высшем уровне. Ответственность может соответствовать операции, атрибуту или, что более точно, неограниченной группе атрибутов и операций.
Опыт показывает, что распространенной ошибкой разработчиков является создание ими длинных списков низкоуровневых ответственностей. Это приводит к непониманию сути. Ответственности должны свободно помещаться на одной карточке. Спросите себя, следует ли разделить класс или лучше отрегулировать ответственности, переместив их на более высокий уровень операторов.
Многие разработчики подчеркивают важность ролевой игры, когда каждый член команды играет роль одного или нескольких классов.

3 Пример использованияДля того чтобы начать обсуждение метода «Диаграмма последовательности» UML (ЮМЛ), рассмотрим простой сценарий.
Предположим, что у нас есть заказ, и мы собираемся вызвать команду для определения его стоимости. При этом объекту заказа (Order) необ ходимо просмотреть все позиции заказа (Line Items) и определить их цены, основанные на правилах построения цены продукции в строке заказа (Order Line). Проделав это для всех позиций заказа, объект за каза должен вычислить общую скидку, которая определяется индиви дуально для каждого клиента.На рис. 4.1 приведена диаграмма, представляющая реализацию дан ного сценария. Диаграммы последовательности показывают взаимо действие, представляя каждого участника вместе с его линией жизни (lifeline), которая идет вертикально вниз и упорядочивает сообщения на странице; сообщения также следует читать сверху вниз.

Одно из преимуществ диаграммы последовательности заключается в том, что почти не придется объяснять ее нотацию. Можно видеть, что экземпляр заказа посылает строке заказа сообщения getQuantity и getProduct. Можно также видеть, как заказ применяет метод к самому себе и как этот метод посылает сообщение getDiscountInfo экземпляру клиента.
Однако диаграмма не все показывает так хорошо. Последовательность сообщений getQuantity, getProduct, getPricingDetails и calculateBasePrice должна быть реализована для каждой строки заказа, тогда как метод calculateDiscounts вызывается лишь однажды.
На приведенной диаграмме именовали участников, используя стиль anOrder. В большинстве случаев это вполне приемлемо. Вот более полный синтаксис: имя : Класс, где и имя, и класс не обязательны, но если класс используется, то двоеточие должно присутствовать.
Каждая линия жизни имеет полосу активности, которая показывает интервал активности участника при взаимодействии. Она соответствует времени нахождения в стеке одного из методов участника. В языке UML полосы активности не обязательны.
У первого сообщения нет участника, пославшего его, поскольку оно приходит из неизвестного источника. Оно называется найденным со общением (found message).
В диаграммах последовательности для создания и удаления участников применяются некоторые дополнительные обозначения (рис. 4.3).

В случае создания участника надо нарисовать стрелку сообщения, направленную к прямоугольнику участника. Если применяется конструктор, то имя сообщения не обязательно, но обычно маркируем его словом «new» в любом случае. Если участник выполняет что -нибудь непосредственно после создания, например команду запроса, то надоначать активацию сразу после прямоугольника участника.
Удаление участника обозначается большим крестом (X). Стрелка сообщения, идущая в X, означает, что один участник явным образом удаляет другого; X в конце линии жизни показывает, что участник удаляет сам себя.
Общая проблема диаграмм последовательности заключается в том, как отображать циклы и условные конструкции. Прежде всего надо усвоить, что диаграммы последовательности для этого не предназначены. Подобные управляющие структуры лучше показывать с помощью диаграммы деятельности или собственно кода. Диаграммы последовательности применяются для визуализации процесса взаимодействия объектов, а не как средство моделирования алгоритма управления.
Как было сказано, существуют дополнительные обозначения. И для циклов, и для условий используются фреймы взаимодействий (inter action frames), представляющие собой средство разметки диаграммы взаимодействия. На рис. 4.4 показан простой алгоритм, основанный на следующем псевдокоде.
foreach (lineitem)
if (product.value > $10K)
careful.dispatch
else
regular.dispatch
end if
end for
if (needsConfirmation) messenger.confirm
end procedure

В основном фреймы состоят из некоторой области диаграммы последовательности, разделенной на несколько фрагментов. Каждый фрейм имеет оператор, а каждый фрагмент может иметь защиту. (В табл. 4.1 перечислены общепринятые операторы для фреймов взаимодействия.)
Для отображения цикла применяется оператор loop с единственным фрагментом, а тело итерации помещается в защиту. Для условной логики можно использовать оператор alt и помещать условие в каждый фрагмент. Будет выполнен только тот фрагмент, защита которого имеет истинное значение. Для единственной области существует оператор opt.


Заключение

Учитывая все вышесказанное, можно заключить, что на языке UML будущее программное обеспечение можно выразить довольно глубоко и разносторонне. Можно выражать не только структурные, но и диаграммы поведения, а это открывает широкие возможности для проектировщиков и программистов, в частности, для обмена проектами и быстрой разработки сложных программ в области обработки больших данных.
Также можно утверждать, что выбранный формат представления и обмена UML-моделями XML Metadata Interchange в полной мере обеспечивает выражение всей UML-модели в текстовой форме. XMI также поддерживает все типы диаграмм, ограничения и большинство вещей которые поддерживает сам язык моделирования UML.

Список использованной литературы

1. OMG Unified Modelling Language (OMG UML). Version 2.5. URL: http://www.omg.org/spec/UML/2.5/PDF.
2. StarUML is a UML tool by MKLab. URL: http://staruml.io/.
3. IBM® Rational® Software Architect Designer (RSAD and formerly RSA) is a comprehensive design, modeling and development tool for end-to-end software delivery URL: http://www-03.ibm.com/software/products/en/ratsadesigner
4. XML Metadata Interchange (XMI) Specification/ Version 2.5.1. URL: http://www.omg.org/spec/XMI/2.5.1/PDF.
5. ArgoUML, leading open source UML modeling tool URL: http://argouml.tigris.org/.
6. Sparx Systems Enterprise Architect is a visual modeling and design tool based on the OMG UML. URL: http://www.sparxsystems.com.au/.