07 Проектирование классов и взаимодействия.pptx

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

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

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

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

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

Если все данные

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

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

использования
Классы должны обеспечивать поведение, указанное в функциональных требо­ваниях спецификации вариантов

использования.

Определение клас­сов включает выделение этих требо­ваний и выбор классов и их совместной работы, необ­ходимых для выполнения этих требований.

Концептуальные классы, которые определяют бизнес-объекты в БД, дол­жны быть выделены заранее. Концептуальные классы станут в проекте классами пакета entity (сущность).

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

управления электронной почтой

электронной почтой
Модель включает ассоциации между сотрудничающими классами.
Соглас­но PCMEF-структуре все

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

способ хранения констант. Элементы данных в интерфейсе, в противоположность UML-интерфейсу,

не­явно заданы как public (внешний), static (статический) и final (заключитель­ный). Следовательно, они являются константами.

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

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

проекта. Ограниче­ния включают нефункциональные требования (FURPS+), определенные в документе дополнительной спецификации.
Структурные ограничения задают требования к разработке исходного проекта классов.
Разработка проекта на основе структурных требований завершается моди­фикациями и дополнениями к классам, определенным из требований пользо­вателя.
Поэтому процесс может начаться с таблицы, используемой для опре­деления классов, на основании требований сценария использования, и затем таблица должна быть расширена, чтобы включить столбцы, которые пред­ставляют модификации и дополнения.

управления электронной почтой

2 приводят к созданию улучшенной модели клас-сов.
К модели до­бавлен пакет

entity. Пакеты entity и mediator составляют пакет domain (предмет-ная область) как один из PCMEF-слоёв.
Пакет acquaintance имеет три новых интерфейса, реализован-ные классами в пакете entity. Новые операции, определенные во время структурной проработки, показаны в соответству-ющих классах.

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

словами, кто должен послать сообщение методу-конструктору другого класса, чтобы инициализировать новый объект этого класса.
Классы в более высоких слоях могут инициализировать классы в (соседних) более низких слоях, но не наоборот.
Первый объект должен быть инициализирован в начале программы. На­чальная точка компьютерной программы находится в главном методе. Главный метод инициализирует первый объект — это объект класса, который содержит главный метод.
Java требует массив объ­ектов String в качестве аргумента метода main. Пара­метр args содержит аргументы, если таковые вообще имеются, помещаемые в командную строку при запуске программы.
Класс, содержащий метод main, находится в пакете presentation и называется PMain.

Показать, кто создает новые экземпляры других классов можно, рисуя отношения зависимости между классами со стереотипом «instantiate» (инициализация).

класс В, объекту А необходима ссылка на объект В. Если

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

Рисунок изображает диа-грамму инициализации для управления электрон­ной почтой. Связи ассоциации не смодели-рованы.

которое со­средоточено на наблюдаемом обмене информацией между объектами, существующими во

время взаимодействия

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

упорядоченный во времени обмен сообщениями между объектами (partName : ClassName

[multiplicity]) в процессе взаимодействия.

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

fragment) состоит из ключевого слова и одного или несколь-ких вложенных

фраг-ментов:
ref – ссылка на другое взаи­модействие;
loop – цикл;
alt – условный фраг-мент;
opt – условный фраг-мент с одним вложен-ным фрагментом;
par – параллельно вы-полняющиеся фраг-менты.

быть более полезны для анализа сообщений от(к) конкретного(му) объекта(у). Они

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

diagram)
является разно­видностью диаграммы деятельности, в которой узлы-объекты замене­ны взаимодействиями и

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

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

путь» взаимодействия:
регистрационное имя (login);
выход (exit);
просмотр непосланных сообщений (view unsent messages);
отображение

текста сообщения (display message text);
передача сообщения по электронной почте (email message);
«неудачный путь» взаимодействия:
неправильное имя пользователя или неправильный пароль (incorrect username or password);
неправильная опция (incorrect option);
слишком много сообщений (too many messages);
сообщение не может быть послано по электронной почте (email could not be sent).

пароль»

послано по электронной почте»

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

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

коммуникации (до UML 2.0 известная как диаграмма сотрудничест­ва или кооперации)

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