СиППО (24, 29-41) (Ответы на все вопросы), страница 4

Рис. 2.21.

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

Рассмотрим компоненты диаграммы последовательностей на рис. 2.22.

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

  имя_объекта : имя_класса

Если принадлежность какого-то объекта к классу еще не установлена или нет требуемого класса, то можно указать только имя объекта. Имя класса будет установлено на последующих шагах анализа или проектирования. Если имеется только один объект какого-то класса, то можно  ограничиться только именем класса.  У верхнего края диаграммы, на горизонтальной линии находятся объекты, которые существуют с самого начала работы программы. Линия жизни объекта  изображается пунктирной вертикальной линией. Эта линия служит для обозначения периода времени, в течение которого объект существует и может участвовать в обмене сообщениями.

Рис. 2.22.

Примечание: на диаграмме последовательности ось времени направлена сверху вниз.

Отдельные объекты могут быть уничтожены до завершения работы программы: в таком случае на их линии жизни ставится знак × (объект :Класс2). Часто уничтожение является результатом направления к такому объекту сообщения со стереотипом destroy(). Возможно и создание нового объекта в ходе работы программы. Такой объект  показан не у верхнего края диаграммы, а ниже; к такому объекту направлено сообщение стереотипа create(). На рисунке Объект3 : Класс3.

В процессе функционирования объектно-ориентированных систем  одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Для явного выделения состояния объекта, применяется фокус управления, который изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало активности, а нижняя сторона ее конец. Естественно, фокус управления должен целиком находиться на линии жизни объекта. Периоды активности объекта могут чередоваться периодами ожидания. На рис. 2.22. Объект1 и Объект2 имеют постоянный фокус управления, у :Класс2 периоды активности чередуются; потом объект :Класс2 будет уничтожен. Даже если потом объект этого класса будет вновь создан – то это  будут уже новый объект.

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

∙        Call (вызвать) – сообщение, требующее вызова метода  класса-адресата. Это сообщение может быть рефлексивным, тогда оно требует вызова метода в классе-отправителе.

∙        Return (возвратить) – возвращает результат выполнения сообщения вызвать.

∙        Create (создать) – сообщение, требующее создание другого объекта.

∙        Destroy (уничтожить) – сообщение с требованием уничтожения объекта-адресата.

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

Упрощенная диаграмма последовательности процесса продажи товара показана на рис. 2.23. Процесс продажи состоит из следующих действий:

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

∙        Подтверждение наличия товара на складе.

∙        Продажа товара.

2) Диаграмма кооперации.

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

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

Рис. 2.23.

Рис. 2.24.

Рис. 2.25.

37.  Диаграмма классов, характеристики класса

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

Диаграмма классов служит для представления статической структуры модели системы в терминологии объектно-ориентированного программирования. Диаграмма классов может отражать структуру отдельных классов и их взаимосвязи. Диаграмма классов состоит из классов и отношений между ними. При большой сложности и/или объеме на диаграмме классов можно использовать пакеты. Их внешний вид, назначение и отношения между ними совпадают с описанными в п. 2.2. Обозначение  класса на языке UML показано на рис. 2.7. 

Рис. 2.7.

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

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

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

Классы могут быть отнесены к определенному стереотипу. Стереотип позволяет задать назначение класса. Часть стереотипов определена на UML, но пользователь может расширить их состав. Примеры наиболее существенных стереотипов и их обозначения приведены на рис. 2.8.

Рис. 2.8.

Стереотип Действующее лицо (Actor) нам уже знаком. Стереотип Граничный класс (Boundary)  используется для задания взаимодействия разрабатываемого программного продукта с внешней средой. Поэтому каждому действующему лицу должен соответствовать граничный класс. Стереотип Сущность (Entity) используется для классов, предназначенных  для создания баз данных (т.е. для длительного хранения данных). Сущность Управление (Control) предназначена для управления работой функционирования программным продуктом.   Все стереотипы классов имеют одинаковую структуру, рассмотренную нами выше: название, атрибуты, операции.

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

Рис. 2.15.

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

38.  Диаграмма классов, типы и характеристики отношений. (+можно почитать еще 37 билет)

Между  классами имеются следующие отношения:

∙        Обобщения (generalization),

∙        Ассоциации (association),

∙        Зависимости (dependency),

∙        Реализации (realization).

Отношение обобщения (рис. 2.9.) связывает класс, соответствующий более общему понятию (предок) с менее общими понятиями - классами (потомками).

Рис. 2.9.

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

Рис. 2.10.

На этом рисунке:

Учеба – имя отношения, необязательно.

Имя студента, Название вуза – имена ролей, которые играют связываемые этим отношением классы, необязательно.

1,  1..*    Мощность отношения, ее желательно задать. В нашем случае имеем отношение «один ко многим»: в вузе учится много студентов, но каждый студент учится только в одном вузе. Кроме этого существуют мощности «один к одному» и «многие ко многим». Вместо 1..* можно задать и более конкретные значения. Например, 1.. 4 соответствую от 1 до 4 объектов класса;   0..3 условное отношение от нуля до 3.

Имеется разновидность отношения ассоциации – отношение агрегации. Оно показывает, что один класс содержит в своем составе другие классы. Пример отношения агрегации приведен на рис. 2. 11.(дата состоит из дня, месяца, года). Характеристики этого отношения совпадают с характеристиками отношения ассоциации. Различают агрегацию по ссылке и по значению (именуемое иногда отношением композиции). Отношение композиции (рис.2.12.) предполагает, что составные части не имеют смысла бес своего владельца.

Рис. 2.11.

Рис.2.12.

Отношение зависимости определяет, что изменение одного класса может повлиять на другой класс, который его использует, причем обратное  в общем случае неверно.  Это отношение необходимо указать, если один класс (клиент) использует другой (сервер). Зависимость показана на рис.2.13; изменения в Класс_В (сервер) могут повлиять на Класс_А (клиент).

Рис. 2.13.

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