Новиков Ф.А. Учебно-методическое пособие по дисциплине Анализ и проектирование на UML

Подождите немного. Документ загружается.

COM (Component Object Model), определяющей методы создания и

взаимодействия программных объектов различных типов. Технология

COM отличается от технологии CORBA тем, что взаимодействие между

объектами устанавливается непосредственно, а не с помощью

промежуточного агента.

Структура хранения данных. Программы обрабатывают данные, которые хранятся

в памяти компьютера. В парадигме объектно-ориентированного программирования

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

объектов, которые моделируются в UML атрибутами классов. Однако большая

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

определенные данные (не все) должны хранится в памяти компьютера не только во

время сеанса работы приложения, но постоянно, т. е. между сеансами. Объекты,

которые сохраняют (по меньшей мере) значения своих свойств даже после того,

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

для моделирования данного свойства объектов и их составляющих применяется

стандартное именованное значение persistence, которое может быть назначено

классификатору, ассоциации или атрибуту и может принимать одно из двух

значений:

• persistent — экземпляры классификатора, ассоциации или значения атрибута,

соответственно, должны быть хранимыми;

• transient — противоположно предыдущему — сохранять экземпляры не

требуется (значение по умолчанию).

В настоящее время самой распространенным способом хранения объектов является

использование системы управления базами данных (СУБД). При этом хранимому

классу соответствует таблица базы данных, а хранимый объект (точнее говоря,

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

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

К счастью, известны надежные методы решения этого вопроса (см. врезки "Схема

базы данных" в разд. 2.1.2 и "Диаграммы сущность-связь" в разд. 2.1). Эти же

методы (с точностью до обозначений) применяются и в UML в форме ассоциаций с

указанием кратности полюсов.

Структура программного кода. Не секрет, что программы существенно

отличаются по величине — бывают программы большие и маленькие.

Удивительным является то, насколько велики эти различия: от сотен строк кода (и

менее) до сотен миллионов строк (и более). Столь большие количественные

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

маленьких программ структура кода практически не имеет значения, для

больших — наоборот, имеет едва ли не решающее значение. Поскольку UML не

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

непосредственно, однако косвенным образом структура модели существенно

влияет на структуру кода. Большинство инструментов поддерживает

полуавтоматическую генерацию кода для одного или нескольких объектно-

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

модели транслируются в классы

(или эквивалентные им конструкции) целевого

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

транслируют ее в соответствующие "надклассовые" структуры целевой системы

программирования. Таким образом, если задействовано средство автоматической

генерации кода, то структура классов и пакетов в модели фактически полностью

моделирует структуру кода приложения.

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

моделирования этой структуры применяется новое средство UML 2 — диаграмма

внутренней структуры классификатора. Мы не рассматриваем такие структуры в

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

приведенным на рис. 3.2

Рис. 3.2 Диаграмма внутренней структуры классификатора

На диаграмме внутренней структуры классификатора показывается классификатор,

внутри которого имеются части. Частей может быть несколько. Каждая часть

является экземпляром некоторого друго классификатора. Части могут

взаимодействовать друг с другом. Это обозначается с помощью соединителей.

Если нужно показать взаимодействие с внешним миром, то на кранице

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

Структура артефактов в

проекте. Только самые простые приложения состоят из

одного артефакта — исполнимого кода программы. Большинство насчитывает в

своем составе десятки, сотни и тысячи различных компонентов: исполнимых

двоичных файлов, файлов ресурсов, исходного кода, различных сопровождающих

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

приложения важно не только иметь точный полный список всех артефактов, но и

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

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

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

IResourceIDepartment

Department

IChief

-chief:Position[1]

ISubordinate

-Subordinates:Position[*]

Resorces

InBox

<<realize>>

Предоставляемый и требуемый

интерфейсы

Именованный порт

Соеди-

нитель

Часть

компонентов UML, где предусмотрены стандартные стереотипы для описания

компонентов разных типов.

Структура компонентов в приложении. Приложение, состоящее из одной

исполнимой компоненты, имеет тривиальную структуру компонентов,

моделировать которую нет нужды. Но большинство современных приложений

состоят из многих компонентов, даже если и не являются распределенными.

Компонентная структура предполагает описание двух аспектов: во-первых, как

классы распределены по компонентам, во-вторых, как (через какие интерфейсы)

компоненты взаимодействуют друг с другом. Оба эти аспекта моделируются

диаграммами компонентов UML.

Структура используемых вычислительных ресурсов. Многокомпонентное

приложение, как правило, бывает распределенным, т. е. различные компоненты

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

позволяют включить в модель описание и этой

структуры.

3.1.3. Классификаторы

Важнейшим типом дескрипторов являются классификаторы. Классификатор —

это дескриптор множества однотипных объектов. Из этого определения

непосредственно вытекает основное и характеристическое свойство

классификатора: классификатор (прямо или косвенно) может иметь экземпляры.

В UML используются следующие классификаторы:

• класс (см. разд. 2.2.1 и далее);

• интерфейс (см. разд. 3.2.7);

• тип данных (см. разд. 3.2.8);

• узел (см. разд. 3.3.5);

• компонент (см. разд. 3.3.2);

• действующее лицо (см. разд. 2.2.1);

• вариант использования (см. разд. 2.2.2);

• подсистема (см. разд. 5.2.1).

Все классификаторы имеют некоторые общие свойства, которые мы опишем в этом

разделе и будем использовать в дальнейшем.

Во-первых, классификаторы (как и все элементы модели) имеют имена. Имя

служит для идентификации элемента модели и потому должно быть уникально в

данном пространстве имен (см. разд. 2.2.1.). Классификатор может быть

абстрактным

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

выделяется курсивом. Классификатор может быть конкретным (может иметь

прямые экземпляры) и в этом случае его имя записывается прямым шрифтом.

Во-вторых, как уже было сказано, классификатор может иметь экземпляры.

Экземпляры бывают прямые и косвенные.

Если некоторый объект

непосредственно порожден с помощью конструктора

классификатора А, то этот объект называется прямым экземпляром А.

Если классификатор А является обобщением классификатора В или если

классификатор В является реализацией классификатора А, то все экземпляры

классификатора В являются косвенными экземплярами классификатора А.

Данное свойство является транзитивным: если классификатор В является

обобщением классификатора С, то все экземпляры С также являются косвенными

экземплярами А. Именно это обстоятельство позволяет рассматривать абстрактные

классификаторы. Действительно, абстрактный классификатор — это такой

дескриптор множества объектов, в котором нет прямого описания элементов

множества, но данный классификатор связан отношением обобщения с другими

классификаторами и объединение множеств их экземпляров считается множеством

экземпляров данного абстрактного классификатора. Другими словами, множество

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

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

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

В-третьих, классификатор (как и другие элементы модели) имеет видимость.

Видимость определяет, может ли свойство одного классификатора (в том числе

имя) использоваться в другом классификаторе.

Другими словами, если в определенном контексте нечто доступно и может быть

как-то использовано, то оно является видимым (в этом контексте). Если же оно не

видимо, то и не может быть использовано. Видимость является свойством всех

элементов модели (хотя не для всех элементов это свойство является

существенным). Видимость может иметь одно из трех значений:

• открытый (обозначается знаком + или ключевым словом public);

• защищенный (обозначается знаком # или ключевым словом protected);

• закрытый (обозначается знаком – или ключевым словом private).

Открытый элемент модели является видимым везде, где является видимым

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

виден сам класс.

Защищенный элемент модели виден в своем контейнере и во всех контейнерах, для

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

виден в этом классе и во всех наследующих классах.

Закрытый элемент модели виден только в своем контейнере. Например, закрытый

атрибут класса виден только в этом классе.

ЗАМЕЧАНИЕ

Для видимости в UML нет значения по умолчанию. Например, если для атрибута

класса не указано значение видимости, то это не значит, что атрибут по умолчанию

открытый или, наоборот, закрытый. Это означает, что видимость для данного

атрибута в модели не указана и в этом аспекте модель не полна.

В-четвертых, все составляющие классификатора имеют область действия.

Область действия определяет, как проявляет себя составляющая классификатора в

экземплярах, т. е. имеют экземпляры свои значения составляющей или совместно

используют одно значение.

Область действия имеет два возможных значения:

•

экземпляр — никак специально не обозначается, поскольку подразумевается по

умолчанию;

• классификатор — описание составляющей классификатора подчеркивается.

Если областью действия составляющей является экземпляр, то каждый экземпляр

классификатора имеет свое значение составляющей. Например, областью действия

атрибута по умолчанию является экземпляр. Это означает, что каждый объект —

экземпляр класса — имеет свое собственное значение атрибута, которое может

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

этого же класса. Если областью действия составляющей является классификатор,

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

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

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

объектов.

В-пятых, классификатор имеет кратность, т. е. ограничение на количество

экземпляров.

Возможны следующие варианты.

• У классификатора нет экземпляров — такой классификатор называется

службой. Все составляющие службы имеют областью действия классификатор.

Хранение информации, обрабатываемой службой, обеспечивают объекты

использующие службу. Типичный пример — набор процедур общего

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

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

стереотип (utility), определяющий класс как службу.

• Классификатор имеет ровно один экземпляр. Такой классификатор называется

одиночкой. В сущности, между службой и одиночкой различия незначительны,

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

переменных приложения.

• Классификатор имеет фиксированное число экземпляров. Такой вариант не

часто, но встречается. Например, порты в концентраторе.

• По умолчанию классификатор имеет произвольное число экземпляров.

Поскольку этот вариант встречается чаще всего, он никак специально не

указывается.

В-шестых, классификаторы (и только они!) могут участвовать в отношении

обобщения обобщение (см. разд. 3.2.5)

Сказанное в этом разделе мы закончим диаграммой классов из метамодели UML,

описывающей понятие классификатора (рис. 3.3)

Кратность может быть не только у классификаторов, но также у атрибутов и полюсов ассоциаций

(см. разд. 3.2.1).

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

заимствованиями из стандарта — эти диаграммы составлены автором. Хотя в стандарте нет именно

таких диаграмм, какие здесь приводятся, это, тем не менее, диаграммы метамодели UML (с

точностью до возможных ошибок автора).

name

visibility

ModelElement

Classifier

Interface

Class

Actor

Subsystem

Node

DataType

Component

UseCase Signal

Instance

1..*

scope

Feature

Рис. 3.3 Метамодель классификатора

ЗАМЕЧАНИЕ

Диаграмма на рис. 3.3 и последующие диаграммы с фрагментами метамодели UML

не являются заимствованиями из стандарта — эти диаграммы составлены автором.

Хотя в стандарте нет именно таких диаграмм, какие здесь приводятся, это, тем не

менее, диаграммы метамодели UML (с точностью до возможных ошибок автора).

Нам представляется, что возможность пересказывать стандарт "своими словами" не

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

UML.

3.1.4. Идентификация классов

Повторим еще раз: описание классов и отношений между ними является основным

средством моделирования структуры в UML. Но прежде чем переходить к технике

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

описанию. По этому вопросу в литературе приводится множество соображений,

советов, рекомендаций и даже принципов. Само разнообразие подходов

свидетельствует о том, что среди них нет универсального и применимого во всех

случаях. Мы выбрали три приема выделения классов, самых простых (можно

сказать, даже примитивных), а потому, по нашему мнению, самых действенных и

широко применимых:

• словарь предметной области;

•

реализация вариантов использования;

• образцы проектирования.

Словарь предметной области — это набор основных понятий (сущностей) данной

предметной области.

Более точного определения мы дать не можем (см. также вставку "Словарь

предметной области" в разд. 2.1.2), зато мы можем дать легко выполнимый совет.

Рассмотрите внимательно текст технического задания (или иного документа,

лежащего в основе проекта) и выделите в содержательной части имена

существительные — все они являются кандидатами на то, чтобы быть названиями

классов

(или атрибутов классов) проектируемой системы. Разумеется, после этой

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

смысла и опыта, отсекая ненужное.

Рассмотрим пример информационной системы отдела кадров. В тексте

технического задания (см. разд. 2.1.1) первый вводный абзац можно отбросить

сразу — это общие слова. Суть заключена в нумерованных пунктах. Но в этом

тексте вообще все слова являются существительными (кроме союзов). Выпишем их

в том порядке, как они встречаются, но без повторений:

•

прием;

•

перевод;

• увольнение;

• сотрудник;

• создание;

• ликвидация;

• подразделение;

• вакансия;

• сокращение;

• должность.

Заметим, что некоторые их этих слов по сути являются названиями действий (и по

форме являются отглагольными существительными). Фактически, это глаголы,

замаскированные особенностями родного языка. Это ясно видно, если переписать

текст технического задания в форме простых утверждений, как рекомендуется в

разд. 2.1.3. Отбросим замаскированные глаголы. Таким образом, остается список из

четырех слов:

сотрудник,

подразделение;

вакансия;

должность.

При анализе технического задания в разд. 2.1.3 мы отметили (опираясь на знание

предметной области), что вакансия — это должность в особом состоянии. Таким

образом, это слово в списке лишнее и у нас остались три кандидата, которые мы

оставляем в словаре (и заодно присваиваем им английские идентификаторы).

• Сотрудник (Person);

• Подразделение (Department);

• Должность (Position).

Рассмотрим теперь, как выявляются классы в процессе реализации вариантов

использования (см. разд. 2.3). Если при реализации вариантов использования

применяются диаграммы взаимодействия (разд. 2.3.3), то в этом процессе в

качестве побочного эффекта выделяются некоторые классы непосредственно,

поскольку на диаграммах кооперации и последовательности основными

сущностями являются объекты, которые по необходимости нужно отнести к

определенным классам. Использование диаграмм деятельности (разд. 2.3.2) также

может подсказать, какие классы нужно определить в системе, особенно если на

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

вариантов использования описываются на псевдокоде (разд. 2.3.1), то выделить

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

реализуются на псевдокоде или диаграммами деятельности вне связи с объектами,

то

выявление объектной структуры системы просто откладывается "на потом".

Иногда это может быть вполне оправдано — например, архитектор,

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

классов, хочет более глубоко вникнуть в логику бизнес-процессов незнакомой ему

предметной области.

Обсудим это на примере информационной системы отдела кадров. Реализация

вариантов использования SelfFire и AdmFire в разделе 2.3.1 не дает практически

никакой информации для выделения классов. Появление двух новых

существительных ("приказ" и "заявление") наталкивает на мысль, что в системе

может появиться класс Document, но сразу ясно, что это класс будет пассивным

хранилищем информации, не наделенным собственным поведением и это полезное

наблюдение никак не приближает к решению основной задачи: выявить ключевые

классы в системе. Реализация варианта использования HirePerson с помощью

диаграмм деятельности в разд. 2.3.2 существенно углубляет наши знания о

процессе приема на работу, но никак не приближает нас к структуре классов

приложения. Наиболее значительный прогресс в этом направлении дают

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

использования, приведенные в разд. 2.3.3. Два класса — Person и Position — те

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

одни и те же выводы получены разными способами, доверие к ним возрастает.

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

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

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

заслуживает появление класса HireForm.

На самом деле этот класс появился в модели как результат применения образца

проектирования.

Образец проектирования — это стандартное решение типичной задачи в

конкретном контексте.

Синтаксически образец в UML является кооперацией, роли объектов в которой

рассматриваются как параметры, а аргументами являются конкретные классы

модели. В данном случае применен образец View-Model Separation, который

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

прямо манипулировать данными, а класс, ответственный за хранение и обработку

данных, не должен содержать интерфейсных элементов. Таким образом, класс

HireForm появился как недостающий аргумент кооперации View-Model

Separation

(мы еще вернемся к обсуждению применения образцов в главе 5).

Подведем итоги: мы полагаем, что классы в модели идентифицируются в

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

области, согласования уже построенной модели и применения теоретических

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

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

самодостаточным: решающим является здравый смысл и опыт архитектора,

составляющего модель.

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

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

Это совсем не удивительно и вполне естественно, поскольку UML является

"сильно" объектно-ориентированным языком. Класс в UML является основной

структурной единицей. Диаграммы классов наиболее информационно насыщены

по сравнению с другими типами канонических диаграмм UML, инструменты

генерируют код в основном по описанию классов, структура классов точнее всего

соответствует окончательной структуре кода приложения.

На диаграммах классов в качестве сущностей применяются прежде всего классы,

как в своей наиболее общей форме, так и в форме многочисленных стереотипов и

частных случаев: интерфейсы, типы данных, процессы и др. Кроме того, в

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

Сущности на диаграммах классов связываются главным образом отношениями

ассоциации (в том числе агрегирования и композиции) и обобщения. Отношения

зависимости и реализации на диаграммах классов применяются реже.

3.2.1. Классы

Класс — один из самых "богатых" элементов моделирования UML. Описание

класса может включать множество различных элементов, и чтобы они не путались,

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

Стандартных разделов три:

• раздел имени — наряду с обязательным именем может содержать также

стереотип, кратность и список свойств;

• раздел атрибутов — содержит список описаний атрибутов класса;

• раздел операций — содержит список описаний операций класса.

Как и все основные сущности UML, класс обязательно имеет имя, а стало быть

раздел имени не может быть опущен. Прочие разделы могут быть пустыми. Наряду

со стандартными разделами, описание класса может содержать и произвольное

количество дополнительных разделов. Семантически дополнительные разделы

эквиваленты примечаниям. Если инструмент умеет что-то делать с информацией в

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

сохранить эту информацию в модели.

Нотация классов очень проста — это всегда прямоугольник. Если разделов более

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

части, соответствующие разделам. Содержимым раздела в любом случае является

текст.

Текст внутри стандартных разделов должен иметь определенный

синтаксис.

ЗАМЕЧАНИЕ

Некоторые инструменты допускают использование нескольких альтернативных

вариантов синтаксиса для текстов в разделах. Например, синтаксис описания

атрибутов в стиле, рекомендованном UML или же в стиле целевого языка

программирования данного инструмента. Такие вариации допускаются стандартом

при условии, что варианты синтаксиса семантически эквиваленты и могут быть

преобразованы друг в друга без потери информации. В данной книге применяется

стандартный синтаксис.

Раздел имени класса в общем случае имеет следующий синтаксис.

«стереотип» ИМЯ {свойства} кратность

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

фигуры и значки.

В табл. 3.1 перечислены стандартные стереотипы классов.

Таблица 3.1. Стандартные стереотипы классов

Стереотип Описание

actor

действующее лицо

enumeration

перечислимый тип данных

exception

сигнал, распространяемый по иерархии обобщений

implementation

Class

реализация класса

interface

нет атрибутов и все операции абстрактные

metaclass

экземпляры являются классами

powertype

метакласс, экземплярами которого являются все наследники данного класса

process,

thread

активные классы

signal

класс, экземплярами которого являются сообщения

stereotype

стереотип

type

(datatype)

тип данных

utility

нет экземпляров =

служба

Обязательное имя класса может быть выделено курсивом и в этом случае данный

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

экземпляров.

ЗАМЕЧАНИЕ

Если имя подчеркнуто, то это уже не имя класса, а имя объекта.

Класс, а также отдельные элементы его описания могут иметь произвольные

заданные пользователем ограничения и именованные значения.

Кратность класса задается по общим правилам (см. раздел 3.1.3). Наиболее

распространенный случай неограниченной кратности (т. е. класс может иметь

произвольное значение экземпляров) подразумевается по умолчанию и никак не

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

кратность — обычно представляется с помощью стандартного стереотипа

«utility» (см. табл. 3.1).

Рассмотрим пример раздела имени класса для нашей информационной системы

отдела кадров.

Если мы предполагаем, что проектируемая информационная система отдела кадров

будет использоваться на одном предприятии, то целесообразно определить

служебный класс

Company со стереотипом utility для хранения глобальных

атрибутов и операций информационной системы отдела кадров. Раздел имени

такого класса показан на рис. 3.4.