Лекция №8, Унифицированный язык моделирования

« Назад

 

1. Язык моделирования UML и UMLдиаграммы

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

Унифицированный язык моделирования UML – Unified Modeling Language (основатели Гради Буч, Джеймс Румбах (Рамбо), Ивар Якобсон (Айвар Джекобсон)) находится в процессе стандартизации, проводимом консорциумом OMG (Object Management Group) в настоящее время принят на вооружение практически всеми крупнейшими компаниями – производителями программного обеспечения (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств поддерживают UML в своих продуктах (Rational Rose, Paradigm Plus, Microsoft Visual Modeler, System Architect).

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

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

- информационные системы масштаба предприятия;

- банковские и финансовые услуги;

- телекоммуникации;

- транспорт;

- оборонная промышленность, авиация и космонавтика;

- розничная торговля;

- медицинская электроника;

- наука.

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

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

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

UML поддерживает стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 2.0 (последняя версия UML 2.3 опубликована в мае 2010 года), представляет следующий набор диаграмм для моделирования:

- диаграммы вариантов использования (прецедентов) (концептуальная) (use case diagrams) – для моделирования бизнес процессов организации и требований к создаваемой системе;

- диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

- диаграммы поведения системы (behavior diagrams):

-- диаграммы взаимодействия (interaction diagrams):

--- диаграммы последовательности (sequence diagrams)

--- кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;

-- диаграммы состояний (state chart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;

-- диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;

-диаграммы реализации (implementation diagrams):

-- диаграммы компонентов (component diagrams) – для моделирования иерархии подсистем системы;

-- диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

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

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

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

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

Транзакция [transaction] – минимальная логически операция, которая имеет смысл и может быть совершена только полностью.

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

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

Рис. 1 - Обозначение диаграммы прецедентов

Рис. 2 - Пример диаграммы вариантов использования

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

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

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

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

Рис. 3 - Пример диаграммы вариантов использования

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

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

- не моделируйте связи между действующими лицами. По определению действующие лица находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к её компетенции.

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

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

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

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

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

- главный раздел: имя прецедента, экторы, цель, краткое описание, тип, ссылки на другие прецеденты;

- раздел «Типичный ход событий»: действия экторов, отклики системы;

- раздел «Исключения»: исключение 1, исключение 2, исключение 3,…

Пример сценариев для банкомата:

Таблица 1. Главный раздел

Прецедент	Снятие наличных по кредитной карте
Экторы	Клиент, Банк
Цель	Получение требуемой суммы наличными
Краткое описание	Клиент запрашивает требуемую сумму. Банкомат обеспечивает доступ к счету клиента. Банкомат выдает клиенту наличные
Тип	Базовый
Ссылки на другие прецеденты	Включает в себя прецеденты: - проверка ПИН-кода кредитной карты; - идентификация кредитной карты.

Таблица 2. Раздел «Типичный ход событий»

Действие эктора	Отклик системы
1. Клиент вставляет кредитную карту в устройство чтения банкомата   Исключение №1: Кредитная карта недействительна	2. Банкомат проверяет кредитную карту 3. Банкомат предлагает ввести ПИН-код
4. Клиент вводит персональный ПИН-код Исключение №2: Клиент вводит неверный ПИН-код	5. Банкомат проверяет ПИН-код   6. Банкомат отображает опцию меню
7. Клиент выбирает снятие наличных со своего счета	8. Система делает запрос в Банк для выяснения текущего состояния счета клиента 9. Банкомат предлагает ввести требуемую сумму
10. Клиент вводит требуемую сумму 11. Банк проверяет введенную сумму Исключение №3: Требуемая сумма превышает сумму на счете клиента	12. Банкомат изменяет состояние счета клиента, выдает наличные и чек
13. Клиент получает наличные и чек	14. Банкомат предлагает клиенту забрать кредитную карту
15. Клиент получает свою кредитную карту	16. Банкомат отображает сообщение о своей готовности к работе

Таблица 3. Раздел «Исключения»

Действие эктора	Отклик системы
Исключение №1. Кредитная карта недействительна или неверно вставлена
15. Клиент получает свою кредитную карту	3. Банкомат отображает информацию о неверно вставленной карте 14. Банкомат возвращает клиенту его кредитную карту
Исключение №2. Клиент вводит неверный ПИН-код
4. Клиент вводит новый ПИН-код	6. Банкомат отображает информацию о неверном ПИН-коде
Исключение №3. Требуемая сумма превышает сумму на счете клиента
10. Клиент вводит новую требуемую сумму	12. Банкомат отображает информацию о превышении кредита

Подводя итоги, можно выделить такие цели создания диаграмм прецедентов:

- определение границы и контекста моделируемой предметной области на ранних этапах проектирования;

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

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

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

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

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

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

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

Рис. 4 - Абстрактный класс

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

Имя атрибута – без пробелов, уникально, информативно.

Например, у класса Компания могут быть атрибуты:

Название: String,

Адрес: String,

Число Служащих: Integer.

Операции класса – поведение всех объектов данного класса (соответствует методам в VB). Имеет список параметров.

Например:

Проверить ПИН код()

Печать Справки()

4. Отношения между классами

Рис. 5 - Вид стрелок

Ассоциация – имя ассоциации является необязательным, либо без стрелки (двунаправленная связь), либо в виде стрелки, либо рядом значок, указывающий направление чтения следования классов:

Рис. 6 - Пример асоциации

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

Обобщение – отношение между родителем (стрелка) и потомком. Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения.

Рис. 7 - Агрегация

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

Рис. 8 - Композиция

Композиция – частный случай агрегации, когда составные части тесно связаны с целым, они не могут существовать отдельно от целого, при удалении целого удаляются и составные части (окно графического интерфейса).

Рис. 9 - Интерфейс

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

Для бизнес-систем:

– Управляющий класс – за координацию действий других классов. По одному для прецедентов и для диаграмм классов. Или на прямоугольнике класса надпись <<control>>.

– Класс-сущность – соответствует отдельной таблице для постоянного хранения информации, в которую передается информация из других классов (<<entity>>).

– Граничный класс – располагается на границе системы с внешней средой, но является частью системы (<<boundary>>).

 – Сотрудник – элемент бизнес-системы <<worker>>.

 – Сотрудник для связи с окружением – для связи в бизнес процессах с бизнес-экторами (<<caseworker>>).

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

Рис. 10 - Пример построения диаграммы классов

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

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

В UML взаимодействие объектов понимается как обмен информацией между ними. При этом информация принимает вид сообщений.

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

– Вызов процедуры (операции) или передача потока управления (синхронные сообщения, инициируются по завершении некоторого действия или при выполнении некоторого условия).

– Асинхронное сообщение – клиент передает сообщение и продолжает выполнять свою деятельность, не ожидая ответа.

– Возврат из вызова процедуры.

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

Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия.

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

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

6. Диаграммы кооперации

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

Рис. 11 - Диаграмма последовательности для прецедента Управление Банкоматом

Пример диаграммы кооперации системы управления банкоматом смотрите на рис. 12.

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

Рис. 12 - Диаграмма кооперации для прецедента Управление Банкоматом

7. Диаграммы состояний

Диаграммы состояний применяются для того, чтобы объяснить, каким образом работают сложные объекты. Несмотря на то что смысл понятия "состояние" интуитивно понятен, все же приведем его определение в таком виде, в каком его дают классики и Zicom Mentor:

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

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

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

8. Диаграмма деятельности (активности, activity diagram)

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

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