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

Почему не «взлетел» UML

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

«Сегодня программирование - это не инженерная наука, а прикладная математика. При этом программисты сразу учатся писать код», - уточняет заведующий кафедрой Технологии программирования Университета ИТМО Анатолий Шалыто.

Чаще всего архитектура решения объясняется на словах или с применением простейших блок-диаграмм. Универсальный язык моделирования (UML), основанный на базе нескольких предыдущих стандартов, таких как метод Гради Буча (Booch), метод Джима Румбаха (OMT) и метод Айвара Джекобсона (OOSE), должен был помочь в этом вопросе. И на него возлагали определенные надежды.

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

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

«Многие считают, что этот язык слишком объемный, - говорит исследователь и предприниматель Хорди Кабот (Jordi Cabot). - Это связано с большим количеством диаграмм, доступных в UML».

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

Подобная судьба ожидала и множество других решений, которые, однако, не являются полноценными альтернативами UML. Речь идет о системе условных обозначений для моделирования бизнес-процессов (BPMN), моделях сущность-связь (ERM), диаграммах потоков данных (DFD), диаграммах состояний и др. Как отмечает Крис Фурман (Cris Fuhrman), все это не более, чем инструменты общения.

Переход к автоматам

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

Этапы разработки программной системы со сложным поведением

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

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

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

Автоматное описание в ООП

Принципы автоматного подхода находят применение и в объектно-ориентированном программировании. Это возможно благодаря концепции «автоматы и объекты управления как классы». Такая модель принята, например, в инструментальном средстве автоматного программирования UniMod. Архитектура системы со сложным поведением, построенная согласно этому принципу представлена на рисунке ниже.

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

В целом же процесс проектирования системы со сложным поведением можно описать следующим образом:

1. Проведение объектной декомпозиции, когда система разбивается на множество самостоятельных взаимодействующих сущностей.
2. Сопоставление сущностей с классами, определение интерфейсов классов и отношений.
3. Выделение тех сущностей, которые обладают сложным поведением, - именно для их описания будет применяться автоматный подход.
4. Задание набора управляющих состояний для каждой сущности. Запросы и команды сопоставляются с входными и выходными переменными управляющего автомата, а компоненты интерфейса - с его событиями. На их основе строится сам управляющий автомат.
5. Реализация неавтоматизированных классов на выбранном объектно-ориентированном языке. Генерация кода может выполняться как автоматически, так и вручную.

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

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

1.5.1. Диаграмма использования

Диаграмма использования (use case diagram) ‒ это наиболее общее представление функционального назначения системы.

Диаграмма использования призвана ответить на главный вопрос моделирования: что делает система во внешнем мире?

На диаграмме использования применяются два типа основных сущностей: варианты использования 1 и действующие лица 2 , между которыми устанавливаются следующие основные типы отношений:

• ассоциация между действующим лицом и вариантом использования 3 ;
• обобщение между действующими лицами 4 ;
• обобщение между вариантами использования 5 ;
• зависимости (различных типов) между вариантами использования 6 .

На диаграмме использования, как и на любой другой, могут присутствовать комментарии 7 . Более того, это настоятельно рекомендуется делать для улучшения читаемости диаграмм.

Основные элементы нотации, применяемые на диаграмме использования, показаны ниже. Детальное описание приведено в разделе 2.2 .

1.5.2. Диаграмма классов

Диаграмма классов (class diagram) ‒ основной способ описания структуры системы.

Это не удивительно, поскольку UML в первую очередь объектно-ориентированный язык, и классы являются основным (если не единственным) "строительным материалом".

На диаграмме классов применяется один основной тип сущностей: классы 1 (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:

• ассоциация между классами 2 (с множеством дополнительных подробностей);
• обобщение между классами 3 ;
• зависимости (различных типов) между классами 4 и между классами и интерфейсами.

Некоторые элементы нотации, применяемые на диаграмме классов, показаны ниже. Детальное описание приведено в главе 3 .

1.5.3. Диаграмма автомата

Диаграмма автомата (state machine diagram) ‒ это один из способов детального описания поведения в UML на основе явного выделения состояний и описания переходов между состояниями.

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

На диаграмме автомата применяют один основной тип сущностей ‒ состояния 1 , и один тип отношений ‒ переходы 2 , но и для тех и для других определено множество разновидностей, специальных случаев и дополнительных обозначений. Перечислять их все во вступительном обзоре не имеет смысла.

Детальное описание всех вариаций диаграмм автомата приведено в разделе 4.2 , а на следующем рисунке показаны только основные элементы нотации, применяемые на диаграмме автомата.

1.5.4. Диаграмма деятельности

Диаграмма деятельности (activity diagram) ‒ способ описания поведения на основе указания потоков управления и потоков данных.

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

На диаграмме деятельности применяют один основной тип сущностей ‒ действие 1 , и один тип отношений ‒ переходы 2 (передачи управления и данных). Также используются такие конструкции как развилки, слияния, соединения, ветвления 3 , которые похожи на сущности, но таковыми на самом деле не являются, а представляют собой графический способ изображения некоторых частных случаев многоместных отношений. Семантика элементов диаграмм деятельности подробно разобрана в главе 4 . Основные элементы нотации, применяемые на диаграмме деятельности, показаны ниже.

1.5.5. Диаграмма последовательности

Диаграмма последовательности (sequence diagram) ‒ это способ описания поведения системы на основе указания последовательности передаваемых сообщений.

Фактически, диаграмма последовательности ‒ это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.

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

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

Ось времени может быть направлена горизонтально, в этом случае считается, что время течет слева направо.

На следующем рисунке показаны основные элементы нотации, применяемые на диаграмме последовательности. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Пунктирная линия, выходящая из него, называется линией жизни (lifeline) 4 . Это не обозначение отношения в модели, а графический комментарий, призванный направить взгляд читателя диаграммы в правильном направлении. Фигуры в виде узких полосок, наложенных на линию жизни, также не являются изображениями моделируемых сущностей. Это графический комментарий, показывающий отрезки времени, в течении которых объект владеет потоком управления (execution occurrence) 5 или другими словами имеет место активация (activation) объекта. Составные шаги взаимодействия(combined fragment) 6 позволяют на диаграмме последовательности, отражать и алгоритмические аспекты протокола взаимодействия. Прочие детали нотации диаграммы последовательностей см. в главе 4 .

1.5.6. Диаграмма коммуникации

Диаграмма коммуникации (communication diagram) ‒ способ описания поведения, семантически эквивалентный диаграмме последовательности.

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

Таким образом, на диаграмме коммуникации также как и на диаграмме последовательности применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 и один тип отношений ‒ связи 2 . Однако здесь акцент делается не на времени, а на структуре связей между конкретными экземплярами.

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

1.5.7. Диаграмма компонентов

Диаграмма компонентов (component diagram) ‒ показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.

Основной тип сущностей на диаграмме компонентов ‒ это сами компоненты 1 , а также интерфейсы 2 , посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:

• реализации между компонентами и интерфейсами (компонент реализует интерфейс);
• зависимости между компонентами и интерфейсами (компонент использует интерфейс) 3 .

На рисунке показаны основные элементы нотации, применяемые на диаграмме компонентов. Детальное описание приведено в главе 3 .

1.5.8. Диаграмма размещения

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

Таким образом, на диаграмме размещения, по сравнению с диаграммой компонентов, добавляется два типа сущностей: артефакт 1 , который является реализацией компонента 2 и узел 3 (может быть как классификатор, описывающий тип узла, так и конкретный экземпляр), а также отношение ассоциации между узлами 4 , показывающее, что узлы физически связаны во время выполнения.

На рисунке показаны основные элементы нотации, применяемые на диаграмме размещения. Для того чтобы показать, что одна сущность является частью другой, применяется либо отношение зависимости «deploy» 5 , либо фигура одной сущности помещается внутрь фигуры другой сущности 6 . Детальное описание диаграммы приведено в главе 3 .

UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (англ. generalization ), агрегация (англ. aggregation ) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

История

Предпосылки появления языка моделирования UML обозначились в связи с бурным развитием во второй половине XX века объектно-ориентированных языков программирования (Simula 67 , Smalltalk , Objective C , C++ и др). Вследствие непрекращающегося усложнения создаваемых программных продуктов возникла нужда в учёте всё новых и новых возможностей языков и средств разработки при анализе, формулировании требований и в процессе проектирования программных приложений. Например, в короткий промежуток времени с 1989 года по 1994 год количество объектно-ориентированных инструментов выросло с десятка до более, чем полусотни. Однако, многие разработчики затруднялись подобрать язык моделирования, который бы полностью отвечал всем их потребностям. В результате выделилось новое поколение методов разработки, среди, которого особую популярность приобрели метод Буча , созданный Якобсоном Object-Oriented Software Engineering (OOSE ) и разработанный Рамбо (Object Modeling Technique (OMT ). Помимо них существовали и другие завершённые технологии, например Fusion , Shlaer-Mellor и Coad-Yourdon , однако всем из них были присущи не только преимущества, но и существенные недостатки .

До UML 1.x

UML 1.x

На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation , Hewlett-Packard , i-Logix, IntelliCorp, IBM , ICON Computing, MCI Systemhouse, Microsoft , Oracle Corporation , Rational Software , Texas Instruments и Unisys . Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года . В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики.

Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные, соответственно, в июне , сентябре и марте 2003 года .

UML 1.4.2 принят в качестве международного стандарта ISO /IEC 19501:2005 .

UML 2.x

Формальная спецификация версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development - MDD . Последняя версия UML 2.5 опубликована в июне 2015 года.

UML 2.4.1 принят в качестве международного стандарта ISO /IEC 19505-1, 19505-2 .

Диаграммы

В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):

Диаграммы композитной структуры могут использоваться совместно с диаграммами классов. Диаграмма развёртывания Диаграмма автомата Диаграмма вариантов использования Основная задача - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы. Диаграммы коммуникации и последовательности Диаграммы коммуникации и последовательности транзитивны , выражают взаимодействие, но показывают его различными способами и с достаточной степенью точности могут быть преобразованы одна в другую. Диаграмма коммуникации (Communication diagram, в UML 1.x - диаграмма кооперации , collaboration diagram ) - диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов). Диаграмма последовательности (Sequence diagram) - диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются. Диаграмма сотрудничества - Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений. По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм. Диаграмма обзора взаимодействия Диаграмма обзора взаимодействия - разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления. Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе. Диаграмма синхронизации Диаграмма синхронизации (Timing diagram) - альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени. Преимущества UML UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках ; UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы; Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом; UML расширяет и позволяет вводить собственные текстовые и графические

достаточно было добавить новый компонент, что несколько проще.

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

Архитектура	Сценарий a	Сценарий b	Сценарий c	Сценарий d
Каналы и фильтры
Репозиторий

Таблица 6. Итоги оценки двух вариантов архитектуры индексатора.

+ обозначает возможность не изменять компонент, - - необходимость изменения компонента,

* - необходимость добавления одного компонента

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

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

UML. Виды диаграмм UML

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

UML предлагает использовать для описания архитектуры 8 видов диаграмм. 9-й вид UML диаграмм, диаграммы вариантов использования (см. Лекцию 4), не относится к архитектурным представлениям. Кроме того, и другие виды диаграмм можно использовать для описания внутренней структуры компонентов или сценариев действий пользователей и прочих элементов, к архитектуре часто не относящихся. В этом курсе мы не будем разбирать диаграммы UML в деталях, а ограничимся обзором их основных элементов, необходимым для общего понимания смысла того, что изображено на таких диаграммах.

Диаграммы UML делятся на две группы - статические идинамические диаграммы .

Статические диаграммы

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

Диаграммы классов (class diagrams ) показываютклассы илитипы сущностей системы, характеристики классов (поля иоперации ) и возможные связи между ними. Пример диаграммы классов изображен на Рис. 31.

Классы представляются прямоугольниками, поделенными на три части. В верхней части показывают имя класса, в средней - набор его полей, с именами, типами, модификаторами доступа (public ‘+’,protected ‘#’,private ‘-’) и начальными значениями, в нижней - набор операций класса. Для каждой операции показывается ее модификатор доступа и

сигнатура.

На Рис. 31 изображены классы Account, Person, Organization, Address, CreditAccountи

абстрактный класс Client .

Класс CreditAccount имеетprivate полеmaximumCredit типаdouble , а такжеpublic методgetCredit() иprotected методsetCredit() .

Интерфейсы , т.е. типы, имеющие только набор операций и не определяющие способов их реализации, часто показываются в виде небольших кружков, хотя могут изображаться и как обычные классы. На Рис. 31 представлен интерфейсAccountInterface .

Рисунок 31. Диаграмма классов.

Наиболее часто используется три вида связей между классами - связи по композиции, ссылки, связи по наследованию и реализации.

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

Композицией на Рис. 31 является связь между классами Organization иAddress .

Ссылочная связь (илислабая агрегация ) обозначает, что объект некоторого классаA имеет в качестве поля ссылку на объект другого (или того же самого) классаB , причем ссылки на один и тот же объект классаB могут иметься в нескольких объектах классаA .

И композиция, и ссылочная связь изображаются стрелками, ведущими от класса A к классуB . Композиция дополнительно имеет закрашенный ромбик у начала этой стрелки. Двусторонние ссылочные связи, обозначающие, что объекты могут иметь ссылки друг на друга, показываются линиями без стрелок. Такая связь показана на Рис. 31 между классами

Account и Client.

Эти связи могут иметь описание множественности , показывающее, сколько объектов классаB может быть связано с одним объектом классаA . Оно изображается в виде текстовой метки около конца стрелки, содержащей точное число или нижние и верхние границы, причем бесконечность изображается звездочкой или буквой n. Для двусторонних

связей множественности могут показываться с обеих сторон. На Рис. 31 множественности, изображенные для связи между классами Account иClient , обозначают, что один клиент может иметь много счетов, а может и не иметь ни одного, и счет всегда привязан ровно к одному клиенту.

Наследование классов изображается стрелкой с пустым наконечником, ведущей от наследника к предку. На Рис. 31 классCreditAccount наследует классуAccount , а классы

Person и Organization- классу Client.

Реализация интерфейсов показывается в виде пунктирной стрелки с пустым наконечником, ведущей от класса к реализуемому им интерфейсу, если тот показан в виде прямоугольника. Если же интерфейс изображен в виде кружка, то связь по реализации показывается обычной сплошной линией (в этом случае неоднозначности в ее толковании не возникает). Такая связь изображена на Рис. 31 между классомAccount и интерфейсом

AccountInterface.

Один класс использует другой, если этот другой класс является типом параметра или результата операции первого класса. Иногда связи по использованию показываются в виде пунктирных стрелок. Пример такой связи между классомPerson и перечислимым типомAddressKind можно видеть на Рис. 31.

Ссылочные связи, реализованные в виде ассоциативных массивов или отображений (map)

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

На Рис. 31 такая связь ведет от класса Person к классуAddress , показывая, что объект классаPerson может иметь один адрес для каждого значения ключаkind , т.е. один домашний и один рабочий адреса.

Диаграммы классов используются чаще других видов диаграмм.

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

Такие диаграммы используются довольно редко.

Рисунок 32. Диаграмма объектов.

Диаграммы компонентов (component diagrams) представляют компоненты в нескольких смыслах - атомарные составляющие системы с точки зрения ее сборки, конфигурационного управления и развертывания. Компоненты сборки и конфигурационного управления обычно представляют собой файлы с исходным кодом, динамически подгружаемые библиотеки, HTML-странички и пр., компоненты развертывания - это компоненты JavaBeans, CORBA, COM и т.д. Подробнее о таких компонентах см. Лекцию 12.

Компонент изображается в виде прямоугольника с несколькими прямоугольными или другой формы «зубами» на левой стороне.

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

Диаграммы этого вида используются редко.

Рисунок 33. Диаграмма компонентов.

На диаграмме компонентов, изображенной на Рис. 33, можно также увидеть пакеты , изображаемые в виде «папок», точнее - прямоугольников с прямоугольными «наростами» над левым верхним углом. Пакеты являются пространствами имен и средством группировки диаграмм и других модельных элементов UML - классов, компонентов и пр. Они могут появляться на диаграммах классов и компонентов для указания зависимостей между ними и отдельными классами и компонентами. Иногда на такой диаграмме могут присутствовать только пакеты с зависимостями между ними.

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

Физические устройства, называемые узлами системы (nodes ), изображаются в виде кубов или параллелепипедов, а физические соединения между ними - в виде линий.

На диаграммах развертывания может быть показана привязка (в некоторый момент времени или постоянная) компонентов развертывания системы к физическим устройствам

Например, для указания того, что компонент EJB AccountEJB исполняется на сервере приложений, а аплет AccountInfoEditor - на рабочей станции оператора банка.

Рисунок 34. Диаграмма развертывания.

Аннотация: Предметом этого курса является The UML - унифицированный язык моделирования. В предыдущей лекции было рассказано о том, что же такое UML, о его истории, назначении, способах использования языка, структуре его определения, терминологии и нотации. Было отмечено, что модель UML - это набор диаграмм. В этой лекции мы рассмотрим такие вопросы: почему нужно несколько видов диаграмм; виды диаграмм; ООП и последовательность построения диаграмм

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

Мы строим модели сложных систем, потому что не можем описать их полностью, "окинуть одним взглядом". Поэтому мы выделяем лишь существенные для конкретной задачи свойства системы и строим ее модель, отображающую эти свойства. Метод объектно-ориентированного анализа позволяет описывать реальные сложные системы наиболее адекватным образом. Но с увеличением сложности систем возникает потребность в хорошей технологии моделирования. Как мы уже говорили в предыдущей лекции, в качестве такой "стандартной" технологии используется унифицированный язык моделирования ( Unified Modeling Language , UML ), который является графическим языком для спецификации, визуализации, проектирования и документирования систем. С помощью UML можно разработать подробную модель создаваемой системы, отображающую не только ее концепцию, но и конкретные особенности реализации. В рамках UML -модели все представления о системе фиксируются в виде специальных графических конструкций, получивших название диаграмм.

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

Почему нужно несколько видов диаграмм

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

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

Да, не слишком информативно. А что же такое тогда подсистема? Чтобы прояснить ситуацию, обратимся к классикам:

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

Что ж, ничего не попишешь, придется искать определение подсистемы. Там же сказано, что подсистема - это совокупность элементов, часть из которых задает спецификацию поведения других элементов. Ян Соммервилл объясняет это понятие таким образом:

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

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

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

Модель - это некий (материальный или нет) объект , отображающий лишь наиболее значимые для данной задачи характеристики системы. Модели бывают разные - материальные и нематериальные, искусственные и естественные, декоративные и математические...

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

В ходе медицинских исследований опыты на животных часто предшествуют клиническим испытаниям медицинских препаратов на людях. В таком случае животное выступает в роли материальной естественной модели человека.

Уравнение, изображенное выше - тоже модель, но это модель математическая, и описывает она движение материальной точки под действием силы тяжести.

Осталось лишь сказать, что такое диаграмма . Диаграмма - это графическое представление множества элементов. Обычно изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Примеров диаграмм можно привести множество. Это и знакомая нам всем со школьных лет блок-схема , и схемы монтажа различного оборудования, которые мы можем видеть в руководствах пользователя, и дерево файлов и каталогов на диске, которое мы можем увидеть, выполнив в консоли Windows команду tree , и многое-многое другое. В повседневной жизни диаграммы окружают нас со всех сторон, ведь рисунок воспринимается нами легче, чем текст...

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

Несмотря на то что в предыдущем абзаце мы весьма вольготно обошлись с понятием модели, следует понимать, что в контексте приведенных выше определений ни одна отдельная диаграмма не является моделью . Диаграммы - лишь средство визуализации модели, и эти два понятия следует различать. Лишь набор диаграмм составляет модель системы и наиболее полно ее описывает, но не одна диаграмма , вырванная из контекста.

Виды диаграмм

UML 1.5 определял двенадцать типов диаграмм , разделенных на три группы:

• четыре типа диаграмм представляют статическую структуру приложения;
• пять представляют поведенческие аспекты системы;
• три представляют физические аспекты функционирования системы (диаграммы реализации).

Текущая версия UML 2.1 внесла не слишком много изменений. Диаграммы слегка изменились внешне (появились фреймы и другие визуальные улучшения), немного усовершенствовалась нотация , некоторые диаграммы получили новые наименования.

Впрочем, точное число канонических диаграмм для нас абсолютно неважно, так как мы рассмотрим не все из них, а лишь некоторые - по той причине, что количество типов диаграмм для конкретной модели конкретного приложения не является строго фиксированным. Для простых приложений нет необходимости строить все без исключения диаграммы. Например, для локального приложения не обязательно строить диаграмму развертывания. Важно понимать, что перечень диаграмм зависит от специфики разрабатываемого проекта и определяется самим разработчиком. Если же любопытный читатель все-таки пожелает узнать обо всех диаграммах UML , мы отошлем его к стандарту UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Напомним, что цель этого курса - не описать абсолютно все возможности UML , а лишь познакомить с этим языком, дать первоначальное представление об этой технологии.

Итак, мы кратко рассмотрим такие виды диаграмм, как:

• диаграмма прецедентов ;
• диаграмма классов;
• диаграмма объектов ;
• диаграмма последовательностей;
• диаграмма взаимодействия;
• диаграмма состояний;
• диаграмма активности ;
• диаграмма развертывания .

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

Диаграмма прецедентов (use case diagram)

Любые (в том числе и программные) системы проектируются с учетом того, что в процессе своей работы они будут использоваться людьми и/или взаимодействовать с другими системами. Сущности, с которыми взаимодействует система в процессе своей работы, называются экторами , причем каждый эктор ожидает, что система будет вести себя строго определенным, предсказуемым образом. Попробуем дать более строгое определение эктора. Для этого воспользуемся замечательным визуальным словарем по UML Zicom Mentor :

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

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

Внимательный читатель сразу же может задать вопрос: а почему эктор, а не актер ? Согласны, слово "эктор" немного режет слух русского человека. Причина же, почему мы говорим именно так, проста - эктор образовано от слова action , что в переводе означает действие . Дословный же перевод слова "эктор" - действующее лицо - слишком длинный и неудобный для употребления. Поэтому мы будем и далее говорить именно так.

Рис. 2.1.

Тот же внимательный читатель мог заметить промелькнувшее в определении эктора слово "прецедент". Что же это такое? Этот вопрос заинтересует нас еще больше, если вспомнить, что сейчас мы говорим о диаграмме прецедентов . Итак,

Прецедент (use-case) - описание отдельного аспекта поведения системы с точки зрения пользователя (Буч).

Определение вполне понятное и исчерпывающее, но его можно еще немного уточнить, воспользовавшись тем же Zicom Mentor "ом:

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

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

формирование общих требований к поведению проектируемой системы;

разработка концептуальной модели системы для ее последующей детализации;

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