Унифицированный язык моделирования UML Лекция 1 Основные этапы

Унифицированный язык моделирования UML Лекция 1

Основные этапы развития UML Отдельные языки объектно-ориентированного моделирования стали появляться в период между серединой 1970-х и концом 1980-х годов, когда различные исследователи и программисты предлагали свои подходы к объектно-ориентированному анализу и проектированию (ООАП). В период между 1989-1994 гг. общее число наиболее известных языков моделирования возросло с 10 до более чем 50. Многие пользователи испытывали серьезные затруднения при выборе языка ООАП, поскольку ни один из них не удовлетворял всем требованиям, предъявляемым к построению моделей сложных систем. Принятие отдельных методик и графических нотаций в качестве стандартов (IDEF0, IDEF1X) не смогло изменить сложившуюся ситуацию непримиримой конкуренции между ними в начале 90-х годов, которая получила название "войны методов".

Многообразие методов 90-х годов, которые повлияли на UML

Основные этапы развития UML К середине 1990-х некоторые из методов были существенно улучшены и приобрели самостоятельное значение при решении различных задач ООАП. Наиболее известными в этот период становятся: Метод Гради Буча (Grady Booch), получивший условное название Booch или Booch'91, Booch Lite (позже - Booch'93). Метод Джеймса Румбаха (James Rumbaugh), получивший название Object Modeling Technique - ОМТ (позже - ОМТ-2). Метод Айвара Джекобсона (Ivar Jacobson), получивший название Object-Oriented Software Engineering - OOSE. Каждый из этих методов был ориентирован на поддержку отдельных этапов ООАП: метод OOSE содержал средства представления вариантов использования, которые имеют существенное значение на этапе анализа требований в процессе проектирования бизнес-приложений. метод ОМТ-2 наиболее подходил для анализа процессов обработки данных в информационных системах. метод Booch'93 нашел наибольшее применение на этапах проектирования и разработки различных программных систем.

Основные этапы развития UML История развития языка UML берет начало с октября 1994 года, когда Гради Буч и Джеймс Румбах из Rational Software Corporation начали работу по унификации методов Booch и ОМТ. Хотя сами по себе эти методы были достаточно популярны, совместная работа была направлена на изучение всех известных объектно-ориентированных методов с целью объединения их достоинств. При этом Г. Буч и Дж. Румбах сосредоточили усилия на полной унификации результатов своей работы. Проект так называемого унифицированного метода (Unified Method) версии 0.8 был подготовлен и опубликован в октябре 1995 года. Осенью того же года к ним присоединился А. Джекобсон, главный технолог из компании Objectory AB (Швеция), с целью интеграции своего метода OOSE с двумя предыдущими.

Основные этапы развития UML Начиная работу по унификации своих методов, Г. Буч, Дж. Румбах и А. Джекобсон сформулировали следующие требования к языку моделирования. Он должен: Позволять моделировать не только программное обеспечение, но и более широкие классы систем и бизнес-приложений, с использованием объектно-ориентированных понятий. Явным образом обеспечивать взаимосвязь между базовыми понятиями для моделей концептуального и физического уровней. Обеспечивать масштабируемость моделей, что является важной особенностью сложных многоцелевых систем. Быть понятным аналитикам и программистам и поддерживаться специальными инструментальными средствами, реализованными на различных компьютерных платформах.

Основные этапы развития UML Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению первых документов, содержащих описание собственно языка UML версии 0.9 (июнь 1996 г.) и версии 0.91 (октябрь 1996 г.). Эти документы послужили своеобразным катализатором для широкого обсуждения языка UML различными категориями специалистов. Первые отзывы и реакция на язык UML указывали на необходимость его дополнения отдельными понятиями и конструкциями.

Основные этапы развития UML В это же время компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие компании, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому определению нотации, что привело к появлению версии 1.0 языка UML. В январе 1997 года был опубликован документ с описанием языка UML 1.0. Эта версия языка моделирования была достаточно хорошо определена, обеспечивала требуемую выразительность и мощность и предполагала решение широкого класса задач. В этот период поддержка разработки языка UML становится одной из целей консорциума OMG (Object Management Group). С поддержкой консорциума OMG была разработана версия UML 1.3. Она описана в соответствующем документе - "OMG Unified Modeling Language Specification", опубликованном в июне 1999 года.

История развития языка UML

Основные этапы развития UML Сейчас разработчики используют версию UML 2.0 Статус языка UML определен как открытый для всех предложений по его доработке и совершенствованию. Сам язык UML не является чьей-либо собственностью и не запатентован кем-либо. В то же время аббревиатура UML, как и некоторые другие (OMG, CORBA, ORB), является торговой маркой их законных владельцев.

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

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

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

Основные определения языка UML UML —это формальный язык, поэтому он предоставляет словарь и правила комбинирования слов в этом словаре. UML — это язык визуализации. Написание моделей на UML преследует одну простую цель — облегчение процесса передачи информации о системе. За каждым символом UML стоит строго определенная семантика, что позволяет избегать ошибок интерпретации (ответы на вопросы типа «а что имел в виду разработчик Х, когда он описал иерархию классов Y…» и т.п. будут достаточно прозрачны). UML — это язык спецификаций и точных определений. В этом смысле моделирование на UML означает построение моделей, которые точны, недвусмысленны и полны. UML — это язык конструирования. UML не является визуальным языком программирования, но модели в терминах UML могут быть отображены на определенный набор объектно-ориентированных языков программирования. UML предоставляет возможности прямого (существующая модель ® новый код) и обратного (существующий код ® новая модель) проектирования. Достаточно часто средства UML-моделирования реализуют отображения UML-моделей в коде на языках Java, C++, CORBA, VB, Smalltalk. UML — это язык документирования. UML предоставляет средства отображения требований к системе, построения документации, тестов, моделирования необходимых действий для планирования проекта и для управления поставленными конечному пользователю релизами.

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

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

Основные определения языка UML принцип иерархического построения моделей сложных систем Этот принцип предписывает рассматривать процесс построения модели на разных уровнях абстрагирования или детализации в рамках фиксированных представлений. При этом исходная или первоначальная модель сложной системы имеет наиболее общее представление (метапредставление). Такая модель строится на начальном этапе проектирования и может не содержать многих деталей и аспектов моделируемой системы.

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

Общая схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования (ООАП) Программист Отношения между Компонентами Программного обеспечения Системный интегратор Производительность и масштабируемость компонентов системы Системный администратор Топология взаимосвязей и Коммуникаций компонентов системы

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

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

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

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

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

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

Метамодель является экземпляром или конкретизацией мета-метамодели. Главная задача этого уровня - определить язык для спецификации моделей. Данный уровень является более конструктивным, чем предыдущий, поскольку обладает более развитой семантикой базовых понятий. Все основные понятия языка UML - это понятия уровня метамодели. Примеры таких понятий - класс, атрибут, операция, компонент, ассоциация и многие другие.

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

Конкретизация понятий модели происходит на уровне объектов. В настоящем контексте объект является экземпляром модели, поскольку содержит конкретную информацию относительно того, чему в действительности соответствуют те или иные понятия модели. Примером объекта может служить следующая запись в проектируемой базе данных: "Илья Петров, 30 лет, иллюзионист, ул. Невидимая, 10-20, 100-0000".

Пример четырехуровневого мета-моделирования простых записей о котировках акций

Структура языка UML Первый иерархический уровень языка UML составляют сущности, отношения между сущностями и наглядные диаграммы. Язык UML имеет четыре вида сущностей (2 иерархический уровень): структурные, поведенческие, группирующие аннотационные. На третьем уровне дерева показано, что понятие "структурные сущности" является именем семи видов пиктограмм, которые называются классами, интерфейсами, кооперациями, прецедентами, активными классами, компонентами и узлами. Поведенческие сущности делятся на два вида диаграмм: диаграммы взаимодействия и автоматы. Группирующие сущности имеют только один вид пиктограмм, называемых пакетами. Аннотационные сущности также имеют один вид пиктограмм, называемых примечаниями.

Сущности Структурные сущности являются существительными языка. классы (Class) — это набор объектов, разделяющих одни и те же атрибуты, операции, отношения и семантику. Класс реализует один или несколько интерфейсов и изображается виде прямоугольника, включающего имя класса, имена атрибутов, операций, примечание;

интерфейсы (Interface) — это набор операций, которые определяют сервис класса или компоненты. Интерфейс графически изображается в виде круга и, как правило, присоединяется к классу или к компоненту, который реализует данный интерфейс; кооперации (Collaboration) — определяют взаимодействие и служат для объединения ролей и других элементов, которые взаимодействуют вместе так, что получающееся в результате поведение объекта оказывается большим, чем просто сумма всех элементов. Изображается в виде эллипса с пунктирной границей; компоненты (Component) — это физически заменяемые части системы, обеспечивающие реализацию ряда интерфейсов. Компонент — это физическое представление таких логических элементов, как классы, интерфейсы и кооперации. Предметная область компонентов относится к реализации. Изображаются компоненты в виде прямоугольника с ярлыками слева и, как правило, имеют только имя и примечание;

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

активные классы (Active class) — это классы, чьими экземплярами являются активные объекты, которые владеют процессом или потоком управления и могут инициировать управляющее воздействие. Графически такой класс изображается как класс с жирной границей; узлы (Node) — физические объекты, которые существуют во время исполнения программы и представляют собой коммуникационный ресурс, обладающий, по крайней мере, памятью, а зачастую и процессором. Изображаются узлы в виде куба, имеют имя и примечание.

Поведенческие сущности Поведенческие сущности — это динамические части моделей UML. • взаимодействия (Interaction) — включают набор сообщений, которыми обмениваются указанные объекты с целью достижения определенной цели. Взаимодействие описывается в контексте кооперации и изображается направленной линией, маркируется именем операции сверху; • автоматы (State machine) — спецификации поведения, представляющие собой последовательности состояний, через которые проходит в течение своей жизни объект, или взаимодействие в ответ на происходящие события. Автомат прикреплен к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров. Изображается автомат как прямоугольник с закругленными углами.

Группирующие и аннотационные сущности Группирующие сущности — это организационные составляющие моделей UML. К ним относятся пакеты (Package) — обобщенный механизм для организации элементов в группы. Структурные, поведенческие, группирующие сущности могут быть помещены в пакет. Пакеты являются чисто концептуальными сущностями — в отличие от компонентов, существующих во время исполнения программы. Изображается пакет как папка с ярлыком сверху и, как правило, имеет только имя. Аннотационные сущности — это пояснительные составляющие моделей UML, к которым относятся примечания (Note) — пояснительные элементы языка. Они содержат текст комментария, изображаются в виде прямоугольника с загнутым уголком страницы.

Отношения 1. .

Отношения Зависимость - это семантическое отношение между двумя сущностями, такое при котором изменение одной (первичной) сущности вызывает изменение семантики другой, зависимой сущности. Ассоциация – это структурное двунаправленное отношение, описывающее совокупность взаимоотношений между объектами. По сути дела ассоциация является сверткой бинарных отношений между объектами. Пометка единица (1) на левом конце линии ассоциации означает, что в двунаправленном отношении, наряду с многими работниками участвует один работодатель. Единица и звездочка на правом конце линии означает "единица или больше" (1..*). Обобщение - это однонаправленное отношение, называемое "потомок/прародитель", в котором объект "потомок" может быть подставлен вместо объекта прародителя (родителя или предка). Потомок наследует структуру и поведение своего родителя. Стрелка всегда указывает на родителя. Реализация – это семантическое однонаправленное отношение, которое может устанавливаться, во-первых, между интерфейсами и реализующими их классами или компонентами, во-вторых, между прецедентами и реализующими их кооперациями.

Структура языка UML

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

Диаграмма прецедентов (use case diagram) Графически эктор изображается либо " человечком ", либо символом класса с соответствующим стереотипом

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

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

Пример диаграммы прецедентов

Пример диаграммы прецедентов

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

Диаграмма классов (class diagram) Диаграмма классов - это набор статических, декларативных элементов модели. Диаграммы классов могут применяться и при прямом проектировании, то есть в процессе разработки новой системы, и при обратном проектировании - описании существующих и используемых систем. Информация с диаграммы классов напрямую отображается в исходный код приложения - в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C++). Таким образом, диаграмма классов - конечный результат проектирования и отправная точка процесса разработки.

Диаграмма классов (class diagram) Пример генеалогического дерева бытовой техники

Диаграмма классов (class diagram) Пример

Диаграмма классов (class diagram) Пример

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

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

Пример диаграммы объектов (object diagram) Диаграмма отображает взаимосвязь объектов - организационных единиц в некоторой компании.

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

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

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

Диаграмма взаимодействия (кооперации, collaboration diagram) Диаграмма взаимодействия (кооперации) показывает поток сообщений между объектами системы и основные ассоциации между ними и по сути является альтернативой диаграммы последовательностей. Диаграмма взаимодействия (кооперации), как и диаграмма последовательностей, показывает взаимодействие объектов во времени, т. е. в динамике.

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

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

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

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

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

Пример диаграмма активности (деятельности, activity diagram) Оформление заказа в Интернет магазине

Диаграмма развертывания (deployment diagram) Диаграмма развертывания – это графическое представление инфраструктуры, на которую будет развернуто приложение. Она показывает топологию системы и распределение компонентов системы по ее узлам, а также соединения - маршруты передачи информации между аппаратными узлами. Это единственная диаграмма, на которой применяются "трехмерные" обозначения: узлы системы обозначаются кубиками.

Пример диаграммы развертывания (deployment diagram)

Диаграммы UML

Диаграмма состояний (statechart diagram) В отличие от других диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее - одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. Изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Именно для описания реакции объекта на подобные внешние воздействия и используются диаграммы состояний.

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

ДИАГРАММА СОСТОЯНИЙ

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

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

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

Список внутренних действий Эта секция содержит перечень внутренних действий или деятельностей, которые выполняются в процессе нахождения моделируемого элемента в данном состоянии. Каждое из действий записывается в виде отдельной строки и имеет следующий формат: <метка-действия '/' выражение-действия>

Список внутренних действий Метка действия указывает на обстоятельства или условия, при которых будет выполняться деятельность, определенная выражением действия. Перечень меток действия имеет фиксированные значения в языке UML, которые не могут быть использованы в качестве имен событий. Эти значения следующие: entry - эта метка указывает на входное действие; exit - эта метка указывает на выходное действие; do - эта метка специфицирует выполняющуюся деятельность ("do activity) include - эта метка используется для обращения к вложенной диаграмме состояний. Во всех остальных случаях метка действия идентифицирует событие, которое запускает соответствующее выражение действия.

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

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

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

Переход Каждый переход может быть помечен строкой текста, которая имеет следующий общий формат: <сигнатура события>'['<сторожевое условие>']' <выражение действия> При этом сигнатура события описывает некоторое событие с необходимыми аргументами: <имя события>'('<список параметров, разделенных запятыми>')'

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

Сторожевое условие Сторожевое условие (guard condition), если оно есть, всегда записывается в прямых скобках после события и представляет собой некоторое булевское выражение, принимающее одно их двух взаимно исключающих значений: "истина" или "ложь". Если сторожевое условие принимает значение "истина", то соответствующий переход может сработать, в результате чего объект перейдет в целевое состояние. Если же сторожевое условие принимает значение "ложь", то переход не может сработать, и при отсутствии других переходов объект не может перейти в целевое состояние по этому переходу.

Выражение действия Выражение действия (action expression) выполняется в том и только в том случае, когда переход срабатывает. Представляет собой атомарную операцию (достаточно простое вычисление), выполняемую сразу после срабатывания соответствующего перехода до начала каких бы то ни было действий в целевом состоянии. Атомарность действия означает, что оно не может быть прервано никаким другим действием до тех пор, пока не закончится его выполнение. Выражение записывается после знака "/" в строке текста, присоединенной к соответствующему переходу. В общем случае, выражение действия может содержать целый список отдельных действий, разделенных символом ";". Обязательное требование - все действия из списка должны четко различаться между собой и следовать в порядке их записи.

Диаграмма состояний для моделирования почтовой программы-клиента В качестве примера выражения действия (см. рис.) может служить “разорвать телефонное соединение (телефонный номер)”, которое должно быть выполнено сразу после установления истинности ("истина") сторожевого условия "почтовый ящик на сервере пуст".

Составное состояние и подсостояние Составное состояние (composite state) - такое сложное состояние, которое состоит из других вложенных в него состояний (подсостояний (substate)). Допускаются последовательные и параллельные подсостояния.

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

Графическое изображение составного состояния с вложенными параллельными подсостояниями

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

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

Переходы между параллельными состояниями Графически такой переход изображается вертикальной черточкой. Если параллельный переход имеет две или более входящих дуг (рис. а), то его называют соединением (join). Если же он имеет две или более исходящих из него дуг (рис. б), то его называют ветвлением (fork). Текстовая строка спецификации параллельного перехода записывается рядом с черточкой и относится ко всем входящим (исходящим) дугам Графическое изображение параллельного перехода из параллельных состояний (а) и параллельного перехода в параллельные состояния (б)

Переходы между составными состояниями Переход, стрелка которого соединена с границей некоторого составного состояния, обозначает переход в составное состояние (переход b). Он эквивалентен переходу в начальное состояние каждого из подсостояний, входящих в состав данного суперсостояния. Переход, выходящий из составного состояния (переходы f и g), относится к каждому из вложенных подсостояний. Это означает, что объект может покинуть составное суперсостояние, находясь в любом из его подсостояний. Для этого вполне достаточно выполнения события и сторожевого условия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграммы UML

Диаграмма вариантов использования (прецедентов) Тема 1

Определения Диаграмма вариантов использования (прецедентов, use case) является исходной концептуальной моделью системы в процессе ее проектирования и разработки.

Определения Суть диаграммы вариантов использования (прецедентов): проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. Актером, эктором (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит разработчик. Прецедент или вариант использования (use case) служит для описания сервисов (услуг), которые система предоставляет актеру. Каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером.

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

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

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

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

Интерфейсы На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя. В качестве имени может быть существительное, которое характеризует соответствующую информацию или сервис (например, "датчик", "сирена", "видеокамера"), но чаще строка текста (например, "запрос к базе данных", "форма ввода", "устройство подачи звукового сигнала"). Если имя записывается на английском, то оно должно начинаться с заглавной буквы I, например, ISecurelnformation, ISensor

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

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

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

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

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

Отношения между актерами и вариантами использования Между компонентами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров одних актеров и вариантов использования с экземплярами других актеров и вариантов использования. В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования: Отношение ассоциации (association relationship) Отношение расширения (extend relationship) Отношение обобщения (generalization relationship) Отношение включения (include relationship)

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

Основные формы записи кратности отношения ассоциации Для диаграмм вариантов использования наиболее распространенными являются четыре основные формы записи кратности отношения ассоциации: Целое неотрицательное число (включая цифру 0) - количество экземпляров актеров или вариантов использования, которые могут выступать в качестве элементов отношения ассоциации, в точности равно указанному числу. Два целых неотрицательных числа, разделенные двумя точками и записанные в виде: "первое число .. второе число". Эту запись следует понимать как множество целых неотрицательных чисел, следующих в последовательно возрастающем порядке: [первое_число, первое_число+1, первое_число+2, ..., второе_число].

Основные формы записи кратности отношения ассоциации Два символа (число или 0 и символ *), разделенные двумя точками. Здесь символ "*"обозначает произвольное конечное целое неотрицательное число, значение которого неизвестно на момент задания соответствующего отношения ассоциации. Единственный символ "*", который является сокращением записи интервала "0..*“ - количество отдельных экземпляров данного компонента отношения ассоциации может быть любым целым неотрицательным числом. 0 означает, что для некоторых экземпляров соответствующего компонента данное отношение ассоциации может вовсе не иметь места. Если кратность отношения ассоциации не указана, то по умолчанию принимается ее значение, равное 1.

Отношение расширения Отношение расширения определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров. Отношение расширения является направленным. Если имеет место отношение расширения от варианта использования А к варианту использования В, то это означает, что свойства экземпляра варианта использования В могут быть дополнены благодаря наличию свойств у расширенного варианта использования А. Отношение расширения между вариантами использования обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от того варианта использования, который является расширением для исходного варианта использования. Данная линия со стрелкой помечается ключевым словом "extend" ("расширяет").

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

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

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

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

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

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

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

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

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

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

Один из уточненных вариантов диаграммы вариантов использования для примера рассматриваемой системы продажи

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

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

Диаграмма классов Тема 2

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

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

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

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

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

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

Примеры задания имен и типов атрибутов классов цвет: Соlоr - здесь цвет является именем атрибута, Color - именем типа данного атрибута. имя_сотрудника [1..2] : String - здесь имя_сотрудника является именем атрибута, который служит для представления информации об имени, а возможно, и отчестве конкретного сотрудника. Тип атрибута String (Строка) как раз и указывает на тот факт, что отдельное значение имени представляет собой строку текста из одного или двух слов (например, "Кирилл" или "Дмитрий Иванович"). видимость:Boolean - здесь видимость есть имя абстрактного атрибута (курсив здесь не случаен), который может характеризовать наличие визуального представления соответствующего класса на экране монитора. В этом случае тип Boolean означает, что возможными значениями данного атрибута является одно из двух логических значений: истина (true) или ложь (false). При этом значение истина может соответствовать наличию графического изображения на экране монитора, а значение ложь - его отсутствию форма:Многоугольник - здесь имя атрибута форма может характеризовать такой класс, который является геометрической фигурой на плоскости. В этом случае тип атрибута Многоугольник указывает на тот факт, что отдельная геометрическая фигура может иметь форму треугольника, прямоугольника, ромба, пятиугольника и любого другого многоугольника, но не окружности или эллипса.

Примеры записи операций +создать() - может обозначать абстрактную операцию по созданию отдельного объекта класса, которая является общедоступной и не содержит формальных параметров. Эта операция не возвращает никакого значения после своего выполнения. +нарисовать(форма: Многоугольник = прямоугольник, цвет_заливки: Color = (0, 0, 255)) - может обозначать операцию по изображению на экране монитора прямоугольной области синего цвета, если не указываются другие значения в качестве аргументов данной операции. запросить_счет_клиента(номер_счета:Integег):Сиггеnсу - обозначает операцию по установлению наличия средств на текущем счете клиента банка. При этом аргументом данной операции является номер счета клиента, который записывается в виде целого числа (например, "123456"). Результатом выполнения этой операции является некоторое число, записанное в принятом денежном формате (например, $1,500.00). выдать_сообщение():{"Ошибка деления на ноль"} Данное сообщение может появиться на экране монитора в случае попытки деления некоторого числа на ноль, что недопустимо.

Отношения между классами Базовыми отношениями или связями в языке UML являются: Отношение зависимости Отношение ассоциации Отношение обобщения Отношение реализации Отношение агрегации Отношение композиции

Диаграммы UML

Для моделирования динамики поведения на логическом уровне в языке UML могут использоваться сразу несколько канонических диаграмм: кооперации. последовательности состояний, деятельности, Каждая из них фиксирует внимание на отдельном аспекте функционирования системы.

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

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

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

Кооперация Понятие кооперации (collaboration) является одним из фундаментальных понятий в языке UML. Оно служит для обозначения множества взаимодействующих с определенной целью объектов в общем контексте моделируемой системы. Цель самой кооперации состоит в том, чтобы описать особенности реализации отдельных наиболее значимых операций в системе. Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.

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

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

Диаграмма кооперации уровня спецификации Простой класс на диаграмме кооперации обозначается прямоугольником класса, внутри которого записывается строка текста. Эта строка текста называется ролью классификатора (classifier role). Роль классификатора показывает особенность использования объектов данного класса. Обычно в прямоугольнике показывается только секция имени класса, хотя не исключается возможность указания секций атрибутов и операций. Строка текста в прямоугольнике должна иметь следующий формат: '/' <Имя роли классификатора> ':' <Имя классификатора> ['::' <Имя классификатора >]* Здесь Имя классификатора, если это необходимо, может включать полный путь всех вложенных пакетов. При этом один пакет от другого отделяется двойным двоеточием "::". Если не возникает путаницы, можно ограничиться указанием только ближайшего из пакетов, которому принадлежит данная кооперация. Символ "*" применяется для указания возможности итеративного повторения имени классификатора.

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

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

Диаграмма кооперации на уровне примеров. Объекты Объекты являются основными элементами, из которых строится диаграмма кооперации на уровне примеров. Для графического изображения объектов используется такой же символ прямоугольника, что и для классов. Объект (object) является отдельным экземпляром класса, который создается на этапе выполнения программы. Он может иметь свое собственное имя и конкретные значения атрибутов. Применительно к объектам формат строки классификатора дополняется именем объекта и приобретает следующий вид (при этом вся запись подчеркивается): <Имя объекта>'/' <Имя роли классификатора> ':' <Имя классификатора> ['::' <Имя классификатора >]* Имя роли классификатора может не указываться. В этом случае оно исключается из строки текста вместе с последующим двоеточием. Имя роли может быть опущено в том случае, если существует только одна роль в кооперации, которую могут играть объекты, созданные на базе этого класса.

Примеры записи строки текста в прямоугольнике объекта : С - анонимный объект, образуемый на основе класса С. / R - анонимный объект, играющий роль R. / R : С - анонимный объект, образуемый на основе класса С и играющий роль R. О / R - объект с именем О, играющий роль R. О : С - объект с именем О, образуемый на основе класса С. О / R : С - объект с именем О, образуемый на основе класса С и играющий роль R. О - объект с именем О. О : - объект с именем О. / R - роль с именем R : С - анонимная роль на базе класса С. / R : С - роль с именем R на основе класса С.

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

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

Активный объект В контексте языка UML все объекты делятся на две категории: пассивные и активные. Пассивный объект оперирует только данными и не может инициировать деятельность по управлению другими объектами. Однако пассивные объекты могут посылать сигналы в процессе выполнения запросов, которые они получают. Активный объект (active object) имеет свою собственную нить (thread) управления и может инициировать деятельность по управлению другими объектами. Под нитью понимается некоторый облегченный поток управления, который может выполняться параллельно с другими вычислительными нитями или нитями управления в пределах одного вычислительного процесса или процесса управления. Примечание Отличие между процессом и нитью заключается в степени использования ресурсов. Говоря о процессе, имеют в виду ресурсоемкий поток управления, т. е. процесс полностью монополизирует ресурсы системы. Нить может использовать лишь небольшую часть ресурсов системы. Примером может служить выполнение некоторой программы в своем адресном пространстве или в фоновом режиме.

Активный объект Активные объекты на канонических диаграммах обозначаются прямоугольником с более широкими границами. Иногда может быть явно указано ключевое слово (помеченное значение) {active}, чтобы выделить активный объект на диаграмме. Каждый активный объект может инициировать единственную нить или процесс управления и представлять исходную точку потока управления. В приведенном фрагменте диаграммы кооперации активный объект "а: Вызывающий абонент" является инициатором процесса установления соединения для обмена информацией с другим абонентом (на диаграмме не показан).

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

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

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

Стереотипы связей Связь может иметь некоторые стереотипы, которые записываются рядом с одним из ее концов и указывают на особенность реализации данной связи. В языке UML для этой цели могут использоваться следующие стереотипы: "association" - ассоциация (предполагается по умолчанию, поэтому этот стереотип можно не указывать). "parameter" - параметр метода. Соответствующий объект может быть только параметром некоторого метода. "local" - локальная переменная метода. Ее область видимости ограничена только соседним объектом. "global" - глобальная переменная. Ее область видимости распространяется на всю диаграмму кооперации. "self" - рефлексивная связь объекта с самим собой, которая допускает передачу объектом сообщения самому себе.

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

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

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

Формат записи сообщений Каждое сообщение может быть помечено строкой текста, которая имеет следующий формат: < Предшествующие сообщения> < [Сторожевое условие] > <Выражение последовательности> <Возвращаемое значение := имя сообщения> <(Список аргументов)> Предшествующие сообщения - есть разделенные запятыми номера сообщений, записанные перед наклонной черточкой: <Номер сообщения ','>< Номер сообщения> '/' Если список номеров сообщений пуст, то вся запись, включая наклонную черточку (слэш), опускается. Смысл указания предшествующих сообщений заключается в том, что данное сообщение не может быть передано, пока не будут переданы своим адресатам все сообщения, номера которых записаны в данном списке. Пример записи предшествующих сообщений: A3, В4/ С5: ошибка записи (сектор).

Формат записи сообщений Сторожевое условие является обычным булевским выражением и предназначено для разветвления отдельных нитей потока управления. Записывается в квадратных скобках и может быть опущено, если оно отсутствует у данного сообщения. Семантика сторожевого условия обеспечивает передачу сообщения только в том случае, если это условие принимает значение "истина". Пример записи сторожевых условий без номеров предшествующих сообщений: [(х>=0)&(х<=255)] 1.2: отобразить_на_экране_цвет(х) [количество цифр номера = 7] 3.1: набрать_телефонный_номер()

Формат записи сообщений Выражение последовательности - есть разделенный точками список отдельных термов последовательностей, после которого записывается двоеточие: <Терм последовательности'.'><Терм последовательности'.'>':' Каждый из термов представляет отдельный уровень вложенности процедурной последовательности. Верхний уровень соответствует самому левому терму процедурной последовательности . Если все потоки управления параллельные, то вложенность отсутствует. Например: Сообщение с номером "3.1.4" следует за сообщением с номером "3.1.3" в процедурной последовательности "3.1". Сообщения с выражениями "3.15" и "3.16" являются параллельными в процедурной последовательности "3.1".

Формат записи сообщений Возвращаемое значение представляется в форме списка имен значений, возвращаемых по окончании коммуникации или взаимодействия в полной итерации данной процедурной последовательности. Эти идентификаторы могут выступать в качестве аргументов в последующих сообщениях. Если сообщение не возвращает никакого значения, то ни значение, ни оператор присваивания на диаграмме кооперации не указываются. Например: 1.2.3: р:= найти_документ (спецификация_документа) сообщение означает передачу вложенного сообщения с запросом поиска в базе данных нужного документа по его спецификации, причем источнику сообщения должен быть возвращен найденный документ.

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

Пример построения диаграммы кооперации В качестве примера рассмотрим построение диаграммы кооперации для моделирования процесса телефонного разговора с использованием обычной телефонной сети. Первый телефонный аппарат на диаграмме изображен как активный объект, а второй - как пассивный.

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

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

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

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

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

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

Линия жизни объекта Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней (объекты 1 и 2). Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены (разрушены), чтобы освободить занимаемые ими ресурсы. Для таких объектов линия жизни обрывается в момент его уничтожения. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы "X" (объект 3). Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий.

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

Фокус управления В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника (см. объект 1), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона - окончание фокуса управления (окончание активности). Этот прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни (объект 4), если на всем ее протяжении он является активным. Периоды активности объекта могут чередоваться с периодами его пассивности или ожидания. В этом случае у такого объекта имеются несколько фокусов управления (объект 5). Получить фокус управления может только существующий объект, у которого в этот момент имеется линия жизни. Если же некоторый объект был уничтожен, то вновь возникнуть в системе он уже не может. Вместо него лишь может быть создан другой экземпляр этого же класса, который, строго говоря, будет являться другим объектом.

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

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

Графическое изображение различных видов сообщений между объектами на диаграмме последовательности

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

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

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

Ветвление потока управления Графическое изображение тернарного ветвления потока управления на диаграмме последовательности. Моделирование взаимодействия программной системы обслуживания клиентов в банке. Условием ветвления служит сумма снимаемых клиентом средств со своего текущего счета.

Стереотипы сообщений В языке UML предусмотрены некоторые стандартные действия, выполняемые в ответ на получение соответствующего сообщения. Они могут быть явно указаны на диаграмме последовательности в форме стереотипа рядом с сообщением, к которому они относятся. В этом случае они записываются в кавычках. Используются следующие обозначения для моделирования действий: "call" (вызвать) - сообщение, требующее вызова операции или процедуры принимающего объекта.; "return" (возвратить) - сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту. "create" (создать) - сообщение, требующее создания другого объекта для выполнения определенных действий. "destroy" (уничтожить) - сообщение с явным требованием уничтожить соответствующий объект. Посылается в том случае, когда необходимо прекратить нежелательные действия со стороны существующего в системе объекта, либо когда объект больше не нужен и должен освободить задействованные им системные ресурсы; "send" (послать) - обозначает посылку другому объекту некоторого сигнала, который асинхронно инициируется одним объектом и принимается другим. Отличие сигнала от сообщения заключается в том, что сигнал должен быть явно описан в том классе, объект которого инициирует его передачу.

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

Временные ограничения на диаграммах последовательности В отдельных случаях выполнение тех или иных действий на диаграмме последовательности может потребовать явной спецификации временных ограничений, накладываемых на сам интервал выполнения операций или передачу сообщений, явно специфицируя условия их передачи или приема. В языке UML для записи временных ограничений используются фигурные скобки. Примеры: {время_приема_сообщения-время_отправки_сообщения < 1 сек.} {время_ожидания_ответа < 5 сек.} {время_передачи_пакета < 10 сек.} {объект_1. время_подачи_сигнала_тревоги > 30 сек.}

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

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

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

Пример построения диаграммы последовательности После создания анонимный объект "разговор" сразу получает фокус активности и посылает сообщение телефонному аппарату d на выполнение действия - звонка вызова. При этом второй абонент снимает трубку (асинхронное сообщение), тем самым устанавливается прямое соединение между абонентами а и b. После того как абоненты опустят трубки, разговор заканчивается. Тем самым объект "разговор" уничтожается.