4966

61

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

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

–формирование требований к проектируемой системе;

–осмысление и осознание поведения системы проектировщиком;

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

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

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

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

1)аннотационные сущности – пояснительные части к элементам диаграмм модели UML, иначе, комментарии для дополнительного описания (рисунок 12);

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

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

4)отношения – отображают характер связи между структурными элементами диаграммы.

Рисунок 13 – Пример фрагмента диаграммы вариантов использования

На рисунке 13 изображён элемент в виде папки, который относится к структурным элементам языка UML и называется «пакет». Наименование пакета «Идентификация клиента». Пакеты предназначены для визуализации систем и подсистем с целью обзорности структуры и разумной ограниченности рассматриваемых моделей (например, сценариями удачных выполнений действий). Пакеты могут включать в себя другие, вложенные, пакеты (рекомендуется не более трёх уровней вложенности). Между пакетами могут иметь место стандартные отношения (см. далее). Пример визуализации систем при помощи пакетов приведён на рисунке 14. На рисунке 15 не указана принадлежность прецедентов к пакетам с целью акцентирования внимания читателя на применении отношений, тем не менее пакеты подразумеваются по умолчанию, т.к. сами диаграммы не могут «висеть в воздухе» и не принадлежать какой-либо модели.

Вид системы с точки зрения реализации

Сценарий 1 Сценарий 2

Рисунок 14 – Пример визуализации систем при помощи пакетов

В языке UML имеется несколько стандартных видов отношений, которые применяются для построения диаграмм вариантов использования:

63

1)ассоциации (association relationship);

2)включения (include relationship);

3)расширения (extend relationship);

4)обобщения (generalization relationship) .

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

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

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

64

рения между вариантами использования обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от того варианта использования, который является расширением для базового варианта использования. Данная линия со стрелкой должна быть помечена стереотипом <<extend>>. Пример отношения <<extend>> приведён на рисунке 15.

Отношение обобщения определяет взаимосвязь базового варианта использования с другим вариантом использования, который является разновидностью базового варианта использования. Иными словами, имеет место отношение «предок − потомок». Пример подобных отношений мы приводили при обсуждении виртуальных функций («оплата кредита»  «клерк банка принимает оплату наличными»). Графически отношение обобщения обозначается сплошной линией со стрелкой в форме не закрашенного треугольника, которая указывает на родительский вариант использования. Пример отношения обобщения приведён на рисунке 15.

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

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

66

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

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

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

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

67

Этот процесс носит название «описание контракта класса», т.е. определение того, что должен будет делать экземпляр данного класса. Выполнить неформальное описание класса можно непосредственно в секциях, предназначенных для разграничения элементов класса. Пример класса приведён на рисунке 16. Ещё раз обращаем внимания читателя на применимость понятий класс и объект как экземпляр класса. В случае описания сущности предметной области мы применяем класс, в случае описания конкретных событий на основании альтернативных сценариев мы говорим об экземпляре класса, т.е. объекте.

Указанный на рисунке 16 пример пакета может быть связан с другим пакетом, в котором будет описано формальное отражение неформального описания контракта класса. Такая связь может быть реализована посредством отношения

Секция списка атрибутов (параметров) класса.

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

69

«расширение». Правила формального описания класса просты и приближены к языку С++.

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

Секция имени класса состоит из следующих обозначений:

1)имя класса (если класс абстрактный – курсивом);

2)имя базового класса (если существует);

3)дополнительные свойства – имя автора и т.п. (необязательное поле).

Секция списков атрибутов класса

Атрибут класса – это элемент данных класса, т.е. элемент данных, который

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

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

<признак видимости><имя атрибута>:<тип атрибута>=<значение по умолчанию>{свойства}

при этом:

–признак видимости – имеет С++ семантику видимости членов класса (если признак опущен, то это означает, что область видимости не определена), признак видимости «public» – (обозначается символом «+») означает, что любая сущность, имеющая доступ к объекту определяемого класса, имеет доступ и к этому атрибуту; признак видимости «protected»– (обозначается символом «#») означает, что к атрибуту имеют доступ только методы данного класса и его потомков; признак видимости «private»– (обозначается символом «–») означает, что атрибут доступен только методам класса;

–имя атрибута– это идентификатор, представляющий имя атрибута;

–тип атрибута – зависящее от языка реализации описание типа атрибута;

–значение по умолчанию – начальное (не обязательное) значение для атрибута вновь созданного объекта (по условию из сценария);

–свойства – строка дополнительных свойств элемента таких, например, как const, static и др., если свойства не указываются, то скобки {} опускаются.

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

70

вания С++ (тип может представлять собой простой базовый тип или тип определённый разработчиком), как, например:

Int counter; //переменная целого типа Int * intPointer; //указатель на целый тип

OtherСlass *; // указатель на класс OtherСlass

Секция списков операций класса

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

<признак видимости> <имя>(список параметров):[<тип возвращаемого значения>] {свойства}

при этом:

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

–тип возвращаемого значения – (не обязательно), зависящее от языка реализации описание типа значения, возвращаемого функцией, если оно не указано, то предполагается, что функция не возвращает значения (void для C/C++), для конструкторов класса возвращаемое значение отсутствует;

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

<имя1>:<тип>=<значение по умолчанию>, <имя2>:<тип>=<значение по умолчанию>,…

при этом:

–имя – имя параметра;

–тип – зависящее от языка реализации описание типа параметра;

–значение по умолчанию – значение параметра (по условию сценария). Примечание: операции, определённые в классе, можно разделить на группы,

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

Отношения в диаграмме классов

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