Научная электронная библиотека

Монографии, изданные в издательстве Российской Академии Естествознания

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Соловьев С. В., Цой Р. И., Гринкруг Л. С.,

ТЕНДЕНЦИИ В РАЗВИТИИ ЯЗЫКА UML И РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Унифицированный язык моделирования UML (Unified Modeling Language) завоевал широкое признание в качестве стандартного отраслевого языка для определения, визуализации, создания и документирования артефактов программных систем. Он упрощает сложный процесс проектирования программного обеспечения (ПО) путем создания «чертежа» для построения системы. Созданием языка UML руководили ведущие специалисты по методологии компании Rational Software - Грэйди Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson) и Джим Рамбо (Jim Rumbaugh). Язык UML в электронном мире. Язык UML был специально разработан для распределенной, параллельной и связанной среды. Он основан на объектах. Объекты распределены - каждый поддерживает свое собственное состояние, отличное от других. Объекты параллельны - каждый из них потенциально может действовать параллельно с другими. Объекты связаны - каждый из них может отправлять другим сообщения через сеть соединений. Язык UML не привязан к какой-либо отдельной платформе или языку программирования, поэтому он хорошо подходит для соединения сетей различных систем. Он разрабатывался с учетом гибкости и поэтому способен адаптироваться к возникающим новым проблемам.

Разработка языка UML началась в компании Rational в 1995 году с объединения методов Буча и OMT. Процесс разработки было решено сделать общедоступным. В 1997 году созданная общими усилиями многих компаний спецификация языка была принята группой OMG (Object Managing Group, рабочей группой по развитию стандартов объектного программирования). Это был язык UML версии 1.1. Компания Rational передала права на UML группе OMG, c целью сделать этот язык общедоступным стандартом. С тех пор комиссия OMG, включающая представителей различных компаний, работала над разъяснением и исправлением ошибок исходной спецификации, выпустив ее обновление в 1998 г. (версия 1.3). Затем выпуск второго обновления (версия 1.4). В процессе обновления были устранены многие внутренние проблемы в метамодели языка UML, пояснены неопределенности исходного документа, улучшено единообразие обозначений и исправлен ряд средств, использующихся в специализированных областях, пересмотрены формулировки отношений между прецедентами. Усилия компании Rational по расширению языка UML. Параллельно с работой по очистке документации по UML было предпринято несколько инициатив по расширению языка UML для новых прикладных областей, включая системы и базы данных Web. Некоторые из этих инициатив были предприняты группой OMG, другие - отдельными компаниями, такими как Rational.

Джим Коннален (Jim Conallen) вместе с другими специалистами Rational разработал способ моделирования web-систем с помощью языка UML и приложения Rational Rose. Эта возможность предлагается в виде профиля UML, позволяющего разработчикам моделей представлять различные виды элементов web-приложения - клиентские и серверные страницы, формы, кадры и т.д. Профиль содержит набор стереотипов для различных элементов и их отношений. Этот подход описан в книге Коналлена Building Web Applications with UML (Addison Wesley Longman, 2000). Данный профиль входит в состав последних версий Rational Rose.

Почти все приложения электронного бизнеса используют базы данных. Одной из наиболее сложных проблем разработки систем долго являлось координирование языков программирования и баз данных, поскольку их различные способы объявления структуры данных приводят к противоречиям и трудностям при переносе информации между программами и базами данных. Использование единой модели UML, лежащей в основе, как программного кода, так и схем баз данных, позволяет избежать многих из этих проблем. Компания Rational разработала для UML профиль моделирования баз данных, который поддерживается в различных версиях приложения Rational Rose. Этот профиль позволяет разработчику сконструировать логическую модель информации и модель таблиц физической базы данных, полученную на основе этой информации. Наличие двух моделей позволяет разработчику настроить и оптимизировать структуру базы данных, что имеет немаловажное значение при разработке баз данных. Поскольку обе модели связаны между собой, изменения в одной из них отражаются на другой, что позволяет избежать противоречий.Инициативы группы OMG. Инициативы группы OMG реализуются через процесс создания RFP (запросов на предложения). Ниже приведены несколько основных инициатив OMG.Моделирование систем реального времени - важнейшая инициатива, добавившая в язык UML возможность моделирования систем реального времени. Важным аспектом систем реального времени является их архитектурная структура. В 1999 году был разработан профиль UML под названием UML-RT, который позволяет иерархически строить системы из инкапсулированных модулей (капсул) с четко определенными интерфейсами (портами) и явными каналами связи (соединителями).

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

Обработка данных предприятия - в этой области было выдвинуто несколько инициатив: распределенная объектная обработка данных предприятия (EDOC, Enterprise Distributed Object Computing) и интеграция приложений предприятия (EAI, Enterprise Application Integration). Эти инициативы будут определять профили, описывающие способы создания крупных, распределенных, параллельных систем предприятия, управляемых событиями.

Процесс разработки - касается структуры определения процессов разработки программного обеспечения. Ее создание могло бы обеспечить стандартный способ определения таких процессов, как RUP (Rational Unified Process).

Другие инициативы - существует еще несколько связанных инициатив, таких как стандарт хранения данных, сопоставление CORBA и UML, а также формат XMI для обмена моделями UML в текстовом формате. Работа над созданием UML 2.0. В качестве стандарта UML во многих отношениях подобен языку программирования.  Инфраструктура UML. Реорганизация внутренней структуры метамодели UML в более модульный вид для повышения расширяемости и лучшего соответствия другим стандартам OMG, в особенности использованию метаобъектов (MOF, meta-object facility) и формату обмена XMI. Эта инициатива не затрагивает непосредственно конечных пользователей, но упрощает изменение языка и создание профилей, которые в результате должны стать более понятными и удобными.

 OCL. Язык ограничения объектов (OCL, Object Constraint Language) является описательным текстовым языком для создания ограничений. Он используется в спецификации UML, выражая правила для корректно построенных моделей. Этот язык нуждается в собственной метамодели (в UML) и дополнительных возможностях для поддержки последних изменений UML. Цель этой инициативы достаточно узка и не затрагивает непосредственно большинство конечных пользователей.

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

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

После разработки изменений для UML 2.0 на них будет наложено требование поддержки максимально возможной совместимости с существующими моделями UML. Унифицированный Язык Моделирования UML

Этап проектирования и моделирования при создании программного обеспечения (ПО) может занимать до 80 % всех ресурсов.

Часто приводимая формула 40/20/40, т.е. 40 % на проектирование и моделирование, 20 % на написание кода и 40 % на компиляцию, интеграцию, отладку, повторное кодирование, повторную интеграцию.

В отчете GAO (Global Accounting Center) - главного вычислительного центра США за 1979 г., содержащим результаты изучения качества выпускаемого ПО, были приведены исследования проектов, которые можно классифицировать следующим образом:

 60 % проектов страдали из-за нарушения сроков;

 50 % проектов страдали от превышения стоимости;

 45 % заказанных программ не могли быть использованы;

 29 % программ так никогда и не были поставлены;

 19 % требовали переработки;

 2 % могли использоваться без изменения.

Причинами послужили:

 неудовлетворительное проектирование;

 отсутствие или неправильность оценки затрат;

 недостаточная продуктивность;

 трудно сопровождаемый код;

 отсутствие или недостаток документации;

 недостаточное тестирование.

Увеличивающаяся сложность ПО требовала построения более сложных моделей, что привело к появлению запроса на создание общего языка моделирования. В 1980-1990 годах появилось около 50 таких разработок. Три наиболее успешные из них (Booch, OMT и OOSE) были объединены в 1995 году в один Унифицированный Язык Моделирования (Unified Modeling Language - UML).

При создании UML преследовались следующие цели:

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

 позволять моделировать не только программное обеспечение, но и более широкие классы систем и бизнес-приложений, с использованием объектно-ориентированных понятий;

 предоставить механизмы расширения и специализации для расширения заложенных концепций;

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

 предоставить формальную базу для понимания языка моделирования;

 интегрировать лучший практический опыт разработок.

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

При этом общие положения выглядят так:

1. Каждая сложная система имеет самое лучшее приближение через набор небольших и почти независимых представлений модели. Ни одно из представлений не является достаточным.

2. Каждая модель может быть выражена на различных уровнях точности или абстракции.

3. Лучшие модели приближены к реальности.

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

При представлении модели UML предоставляет следующие диаграммы:

1. Диаграммы сценариев - use case diagram. Позволяют отобразить, описать и «задокументировать» желаемое поведение системы с точки зрения взаимодействия с ней внешних объектов. Сценарием также можно назвать какой-либо набор логически связанных между собой действий, приводящих к какому-то «логическому состоянию» системы, т.е. это описание «на высоком уровне абстракции»: какие случаи, ситуации обрабатывает приложение, какие реально действующие лица взаимодействуют с системой.

2. Диаграммы классов - class diagram. Набор статических, декларативных элементов модели, таких как классы, интерфейсы и их отношения и описания.

3. Диаграммы описания:

 диаграммы состояния - state chart diagram;

 диаграммы активности - activity diagram.

4. Диаграммы взаимодействия:

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

 диаграммы взаимодействия - collaboration diagram. Поток сообщений между объектами в объектно-ориентированном приложении, подразумевают основные ассоциации между объектами.

5. Диаграммы реализации:

 диаграммы компонентов - component diagram. Программные компоненты, которые составляют повторно используемые части ПО, их интерфейсы и их внутренние отношения;

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

Существует множество технологий и инструментальных средств, с помощью которых можно реализовать оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. В большинстве случаев эти технологии предъявляют жесткие требования к процессу разработки и используемым ресурсам, а попытки трансформировать их под конкретные проекты оказываются безуспешными. Эти технологии представлены CASE-средствами верхнего уровня или CASE-средствами полного жизненного цикла (upper CASE tools или full life-cycle CASE tools). Они не позволяют оптимизировать деятельность на уровне отдельных элементов проекта, и, как следствие, многие разработчики перешли на CASE-средства нижнего уровня (lower CASE tools). Однако они столкнулись с новой проблемой - проблемой организации взаимодействия между различными командами, реализующими проект.

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

Толчок к разработке этого направления информационных технологий дало распространение объектно-ориентированных языков программирования в конце 1980, начале 1990 годов. Пользователям хотелось получить единый язык моделирования, который объединил бы в себе всю мощь объектно-ориентированного подхода и давал бы четкую модель системы, отражающую все ее значимые стороны. К середине девяностых явными лидерами в этой области стали методы Booch (Grady Booch), OMT-2 (Jim Rumbaugh), OOSE-Object-Oriented Software Engineering (Ivar Jacobson). Однако эти три метода имели свои сильные и слабые стороны: OOSE был лучшим на стадии анализа проблемной области и анализа требований к системе, ОМТ-2 был наиболее предпочтителен на стадиях анализа и разработки информационных систем, Booch лучше всего подходил для стадий дизайна и разработки.

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

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

В настоящее время консорциум пользователей UML Partners вклю­чает представителей информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

 является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС;

 содержит механизмы расширения и специализации базовых концепций языка.

UML - это стандартная нотация визуального моделирования про­граммных систем, которая была принята консорциумом Object Managing Group (OMG) в 1997 году, и поддерживается мно­гими объектно-ориентированными CASE-продуктами.

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

 строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;

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

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

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

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

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

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

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

На рис. 42 приведено графическое изображение класса «Заказ» в нотации UML.

Синтаксис UML для свойств классов (в отдельных программных средствах, например, в IBM UML Modeler, порядок записи параметров может быть иным):

 < признак видимости > < имя атрибута > : < тип данных > = < значение по умолчанию > < признак видимости > < имя операции > < (список аргументов) > 

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

Рис. 42. Изображение класса в UML

 public (общий) - любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции;

 protected (защищенный) - только любой потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком «#»;

 private (закрытый) - только данный класс может пользоваться этими свойствами. Обозначаются символом «-».

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

 instance (экземпляр) - у каждого экземпляра класса есть собственное значение данного свойства;

 classifier (классификатор) - все экземпляры совместно используют общее значение данного свойства (выделяется на диаграммах подчеркиванием).

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

 не содержащие ни одного экземпляра - тогда класс становится служебным (Abstract);

 содержащие ровно один экземпляр (Singleton);

 содержащие заданное число экземпляров;

 содержащие произвольное число экземпляров.

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

Диаграммы классов

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

Классы отображают типы объектов системы. Между классами возможны различные отношения, представленные на рис. 43:

 зависимости, которые описывают существующие между классами отношения использования;

 обобщения, связывающие обобщенные классы со специализирован­ными;

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

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

Рис. 43. Отображение связей между классамиАссоциация - это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа («клиент» может сделать «заказ»). Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. При необходимости направление навигации может задаваться стрелкой. Допускается задание ассоциаций на одном классе. В этом случае оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса. Ассоциации может быть присвоено имя, описывающее семантику отношений. Каждая ассоциация имеет две роли, которые могут быть отражены на диаграмме (рис. 44). Роль ассоциации обладает свойством множественности, которое показывает, сколько соответствующих объектов может участвовать в данной связи.

Рис. 44. Свойства ассоциации

Рис. 44 иллюстрирует модель формирования заказа. Каждый заказ может быть создан единственным клиентом (множественность роли 1..1). Каждый клиент может создать один и более заказов (множественность роли 1..n). Направление навигации показывает, что каждый заказ должен быть «привязан» к определенному клиенту.

Такого рода ассоциация является простой и отражает отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Если приходится моделировать отношение типа «часть-целое», то используется специальный тип ассоциации - агрегирование. В такой ассоциации один из классов имеет более высокий ранг (целое - класс «заказ», рис. 43) и состоит из нескольких меньших по рангу классов (частей - класс «строка заказа»). В UML используется и более сильная разновидность агрегации - композиция, в которой объект-часть может принадлежать только единственному целому. В композиции жизненный цикл частей и целого совпадают, любое удаление целого обязательно захватывает и его части.

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

Диаграммы использованияДиаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент - это типичное взаимодействие пользователя с системой, которое при этом:

 описывает видимую пользователем функцию;

 может представлять различные уровни детализации;

 обеспечивает достижение конкретной цели, важной для пользователя.

Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актерами, actors). Действующие лица используют систему (или используются системой) в данном прецеденте. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы.На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: «использование» и «расширение» (рис. 45). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа «использование» позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания.

На рис. 45 показано, что при исполнении прецедента «формирование заказа» возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов «оценить риск сделки» и «согласовать цену» необходимо выполнить одно и то же действие - рассчитать стоимость заказа.

Рис. 45. Связи на диаграммах прецедентов

Динамические аспекты поведения системы отражаются приведенными ниже диаграммами.

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

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

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

 вводятся строки заказа;

 по каждой строке проверяется наличие товара;

 если запас достаточен, то инициируется поставка;

 если запас недостаточен, то инициируется повторный заказ.

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

Рис. 46. Диаграмма последовательности обработки заказа

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

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

Рис. 47. Кооперативная диаграмма прохождения заказа

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

Рис. 48. Диаграмма состояний

Имеется также два вида псевдосостояний: начальное состояние, в котором находится только что созданный объект, и конечное состояние, которое объект не покидает, как только туда перешел.

Переходы имеют метки, которые синтаксически состоят из трех необязательных частей:

 < Событие > < [Условие] > < Действие > .

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

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

Основными элементами диаграмм деятельности являются (рис. 49):

 овалы, изображающие действия объекта;

 линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия «И»);

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

 стрелки - отражают последовательность действий, могут иметь метки условий.

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

Рис. 49. Диаграмма деятельности - обработка заказа

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

Узлы делятся на два типа:

 устройства - узлы системы, в которых данные не обрабатываются;

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

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

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