Лекция 7 - hydronship.net

Лекция 7
Типичные приемы моделирования
Простые кооперации
Любой класс функционирует совместно с другими, реализуя семантику, выходящую за границы каждого отдельного
элемента. Таким образом, кроме определения словаря системы нужно уделить внимание визуализации, специфицированию, конструированию и документированию различных способов совместной работы вошедших в словарь сущностей.
Для моделирования такого «сосуществования» применяются диаграммы классов.
Создавая диаграмму классов, моделируется часть сущностей и отношений, описываемых в представлении системы с
точки зрения проектирования. Желательно, чтобы каждая диаграмма описывала только одну кооперацию.
Моделирование кооперации осуществляется следующим образом:
1. Идентифицируются механизмы, которые предполагается моделировать. Механизм - это некоторая функция или поведение части моделируемой системы, появляющееся в результате взаимодействия сообщества классов, интерфейсов и
других сущностей. (Механизмы, как правило, тесно связаны с прецедентами, см. главу 16.)
2. Для каждого механизма идентифицируются классы, интерфейсы и другие кооперации, принимающие участие в рассматриваемой кооперации. Идентифицируются также отношения между этими сущностями.
3. Проверяется работоспособность системы с помощью прецедентов (см. главу 15). Здесь, в процессе проектирования,
можно обнаружить, что некоторые части системы оказались пропущены, а некоторые - семантически неправильны и
выполнить коррекцию.
4. Идентифицированные элементы заполняются содержанием. Для классов обычно начинают с правильного распределения функционирования. Позже это становится конкретными атрибутами и операциями.
В качестве примера на рис. 8.2 показаны классы, взятые из реализации автономного робота. Основное внимание
здесь уделено тем классам, которые участвуют в механизме движения робота по заданной траектории. Как видно из рисунка,
существует один абстрактный класс Мотор с двумя конкретными потомками, МоторПоворотногоМеханизма и
ГлавныйМотор, которые наследуют пять операций их родителя. Эти два класса, в свою очередь, являются частью класса
Привод. Класс АгентТраектории связан отношением ассоциации «один к одному» с классом Привод и отношением «один
ко многим» - с классом ДатчикСтолкновений. Для класса АгентТраектории не показано ни атрибутов, ни операций, хотя
приведены обязанности.
В описанную систему, конечно, входит значительно больше классов, но внимание на диаграмме заостряется только
на таких абстракциях, которые непосредственно участвуют в движении робота. Некоторые указанные классы могут присутствовать и на других диаграммах. Например, хотя здесь это не показано, АгентТраектории сотрудничает по крайней
мере еще с двумя классами (Окружение и АгентЦели) в механизме более высокого уровня, управляющем поведением робота при наличии конфликтующих целей. ДатчикСтолкновений и Привод, а также их части сотрудничают с другим, не
показанным на диаграмме классом АгентОтказа в механизме, отвечающем за постоянный контроль аппаратных сбоев.
Описывая каждую из этих коопераций в отдельных диаграммах, можно создать простое для восприятия представление о
системе с различных точек зрения.
Логическая схема базы данных
Многие моделируемые системы содержат устойчивые объекты, то есть такие, которые можно сохранять в базе данных
и впоследствии извлекать при необходимости (см. главу 23). Для этого чаще всего используют реляционные, объектноориентированные или гибридные объектно-реляционные базы данных. UML позволяет моделировать и логические схемы
баз данных и сами физические базы (см. главу 29).
Диаграммы классов UML включают в себя, как частный случай, диаграммы «сущность-связь» (E-R диаграммы), которые часто используются для логического проектирования баз данных. Но если в классических E-R диаграммах внимание сосредоточено только на данных, то диаграммы классов позволяют моделировать также и поведение. В реальной базе данных подобные логические операции обычно трансформируются в триггеры или хранимые процедуры.
Моделирование схемы базы данных осуществляется следующим образом:
1. Идентифицируются классы модели, состояние которых должно сохраняться и после завершения работы создавшего их
приложения.
2. Создается диаграмма классов, содержащая эти классы, и они характеризуются как устойчивые с помощью стандартного помеченного значения persistent (устойчивый). Для работы со специфическими деталями базы данных можно
определить и свои собственные помеченные значения.
3. Раскрываются структурные особенности классов. В общем случае это означает, что надо детально специфицировать
их атрибуты и обратить особое внимание на ассоциации и их кратности.
4. Отыскиваются типичные структурные образцы, усложняющие проектирование физической базы данных, например
циклические ассоциации, ассоциации «один к одному» и парные ассоциации. При необходимости создаются промежуточные абстракции для упрощения логической структуры.
5. Рассматривается поведение этих классов, раскрывая операции, важные для доступа к данным и поддержания их целостности. В общем случае для лучшего разделения обязанностей бизнес-правила, отвечающие за манипуляции наборами
объектов, должны быть инкапсулированы в слое, находящемся над этими устойчивыми классами.
6. Следует использовать в своей работе инструментальные средства, позволяющие преобразовать логический проект в физический.
Примечание Рассмотрение логического проектирования базы данных выходит за рамки данной книги, цель которой состоит только в том, чтобы показать, как моделировать схемы с помощью языка UML На практике все
сводится к применению стереотипов (см. главу 6), настроенных на конкретный тип используемой базы данных (реляционной или объектно-ориентированной).
В качестве примера на рис. 8.3 показана совокупность классов, взятых из информационной системы вуза. Этот рисунок
является расширением приведенной ранее диаграммы классов
и содержит достаточное количество деталей для конструирования физической базы данных. В левой нижней части диаграммы расположены классы Студент, Курс и Преподаватель. Между классами Студент и Курс есть ассоциация, показывающая, что студенты могут посещать курсы. Более того, каждый студент может посещать любое
количество курсов и на каждый курс может записаться любое число студентов. Все шесть классов на диаграмме
помечены как устойчивые (persistent), то есть их экземпляры должны содержаться в базе данных или каком-то
ином хранилище. Приведены также атрибуты всех шести классов. Обратим внимание, что все атрибуты являются
примитивными типами (см. главу 4). Моделируя схему, отношения с непримитивными типами лучше всего представлять с помощью явного агрегирования (см. главы 5 и 10), а не с помощью атрибутов.
Два класса (Вуз и Факультет) содержат несколько операций, позволяющих манипулировать их частями. Эти операции
включены из-за их важности для поддержания целостности данных (например, добавление или удаление Факультета
затрагивает целый ряд других объектов).
Существует много других операций, которые стоило бы рассмотреть при проектировании этих и иных классов,
например
запрос о необходимых предварительных знаниях перед зачислением студента на курс. Но это, скорее, бизнесправила,
а нерасполагать их на более высоком уровне абстракоперации по поддержанию целостности данных, поэтому
лучше
ции.
Прямое и обратное проектирование
Моделирование, конечно, важная вещь, но Следует помнить, что основным результатом деятельности
группы
разработчиков являются не диаграммы, а программное обеспечение. Все усилия по созданию моделей направлены
то,
чтобы
только
на в оговоренные сроки написать программу, которая отвечает изменяющимся потребностям пользователей и бизнеса.
Поэтому
очень важно, чтобы ваши модели и основанные на них реализации соответствовали друг другу, причем
С
минимальными затратами по поддержанию синхронизации между ними (см. главу 1).
с минимальИногда UML применяется так, что создаваемая модель впоследствии не отображается ни в какой программный
код. Если моделируется бизнес-процесс с помощью диаграмм действий (см. главу 19), то во многих действиях
например,
будут
участвовать люди, а не компьютеры. В других случаях необходимо моделировать системы, составными частями
которыхуровне
на
данном
абстракции являются только аппаратные средства (хотя на другом уровне абстракции вполне мочто
содержат встроенные процессоры с соответствующим программным обеспечением).
жет они
оказаться,
Но чаще всего модели все-таки преобразуются в код. Хотя UML не определяет конкретного способа отображения
на
какойлибо
объектно-ориентированный язык, он проектировался с учетом этого требования. В наибольшей степени это
относится к классов, содержание которых без труда отображается на такие известные объектнодиаграммам
программирования,
как Java, C++, Smalltalk, Eiffel, Ada, ObjectPascal и Forte. Кроме того, в проект UML была заориентированные языки
ложена
возможность отображения на коммерческие объектные языки, например Visual Basic.
Примечание Раскрытие темы отображения UML на конкретные языки программирования для прямого и обратного
проектирования выходит за рамки данной книги. На практике этот процесс сводится к использованию
стереотипов и помеченных значений (см. главу 6), настроенных на определенный язык.
Прямым проектированием (Forward engineering) называется процесс преобразования модели в код путем отображения на
некоторый язык реализации. Процесс прямого проектирования приводит к потере информации, поскольку напиязыке
санныеUML
на модели семантически богаче любого из существующих объектно-ориентированных языков. Фактичеразличие
и является
основной причиной, по которой мы, помимо кода, нуждаемся и в моделях. Некоторые струкски именно
это
турные
свойства системы, такие как кооперации, или ее поведенческие особенности, например взаимодействия, могут
визуализированы
в UML, но в чистом коде наглядность теряется.
быть легко
Прямое проектирование диаграммы классов производится следующим образом:
1. Идентифицируются правила отображения модели на один или несколько языков программирования по выбору. Это
допустимо делать как при работе над одним конкретным проектом, так и для организации в целом.
2. В зависимости от семантики выбранных языков, вероятно, придется отказаться от использования некоторых
возможностей
UML. Например, язык UML допускает множественное наследование, а язык программирования Smalltalk - только
одиночное.
В связи с этим можно или запретить авторам моделей пользоваться множественным наследованием (что сделает
создаваемые модели зависимыми от языка), или разработать идиомы для трансляции таких расширенных возможноконструкции,
поддерживаемые данным языком программирования (что усложнит отображение).
стей
в
3. Применяйте помеченные значения для специфицирования языка программирования. Это можно сделать как на
уровне
индивидуальных классов (если нужна тонкая настройка), так и на более высоком уровне, например для пакетов
коопераций.
или
4. Пользуйтесь инструментальными средствами для прямого проектирования моделей.
На рис. 8.4 изображена простая диаграмма классов, на которой проиллюстрирована реализация образца (см. главу
28) обязанностей. В данном примере представлены три класса: Client (Клиент), EventHandler (Обработчикцепочки
GUIEventHandler
(ОбработчикСобытийГИП). Первые два из них являются абстрактными, а последний - конкретСобытий)
и
ным. Класс содержит обычную для данного образца операцию handleRequest (обработатьЗапрос), хотя в расEventHandler
случае было добавлено два скрытых атрибута.
сматриваемом
Определенное для каждого класса помеченное значение показывает, что они будут преобразованы в код на
языке Java. Прямое проектирование в данном случае легко осуществимо с помощью специального инструмента.
Так, для класса EventHandler будет сгенерирован следующий код:
public abstract class EventHandler {
EventHandler successor;
private Integer currentEventID;
private String source;
EventHandler () {}
public void handleRequest () {}
}
Обратным проектированием (Reverse engineering) называется процесс преобразования в модель кода, записанного на каком-либо языке программирования. В результате этого процесса вы получаете огромный объем информации, часть которой находится на более низком уровне детализации, чем необходимо для построения полезных моделей. В то же время обратное проектирование никогда не бывает полным. Как уже упоминалось, прямое проектирование ведет к потере информации, так что полностью восстановить модель на основе кода не удастся, если только
инструментальные средства не включали в комментариях к исходному тексту информацию, выходящую за пределы семантики языка реализации. Пример, представленный на рис. 3.3, был создан с помощью обратного проектирования библиотеки классов языка Java.
Обратное проектирование диаграммы классов осуществляется так:
1. Идентифицируйте правила для преобразования из выбранного вами языка реализации. Это можно сделать на
уровне
проекта или организации в целом. С помощью инструментального средства укажите код, который вы хотите Подвергнуть обратному проектированию.
2. Воспользуйтесь
этим
средством
для
создания
новой
модели
или
для
модификации ранее созданной.
3. Пользуясь инструментальными средствами, создайте диаграмму классов путем опроса полученной модели. Можно начать, например, с одного или нескольких классов, а затем расширить диаграмму, следуя вдоль некоторых отношений или добавив соседние классы. Раскройте или спрячьте детали содержания диаграммы в зависимости от
ваших намерений.
Советы
Создавая диаграмму классов на языке UML, помните, что это всего лишь графическое изображение статического вида системы с точки зрения проектирования. Взятая в отрыве от остальных, ни одна диаграмма классов не может и не должна охватывать этот вид целиком. Диаграммы классов описывают его исчерпывающе, но каждая в отдельности - лишь один из его аспектов.
Хорошо структурированная диаграмма классов обладает следующими свойствами:
•
заостряет внимание только на одном аспекте статического вида системы с точки зрения проектирования;
•
•
содержит лишь элементы, существенные для понимания данного аспекта;
показывает детали, соответствующие требуемому уровню абстракции, опуская те, без которых можно обойтись;
•
не настолько лаконична, чтобы ввести читателя в заблуждение относительно важных аспектов семантики.
При изображении диаграммы классов руководствуйтесь следующими правилами:
•
дайте диаграмме имя, связанное с ее назначением;
•
располагайте элементы так, чтобы свести к минимуму число пересекающихся линий;
•
пространственно организуйте элементы так, чтобы семантически близкие сущности располагались рядом;
•
чтобы привлечь внимание к важным особенностям диаграммы, используйте примечания и цвет;
•
старайтесь не показывать слишком много разных видов отношений; как правило, в каждой диаграмме классов
должны доминировать отношения какого-либо одного вида.
Часть III. Изучение структурного моделирования Глава 9. Углубленное изучение классов
Классы - это самые важные строительные блоки объектно-ориентированных систем. Однако классы являются
всего лишь одной из разновидностей более общих строительных блоков UML- классификаторов. Классификатор это механизм, описывающий структурные и поведенческие свойства. К числу классификаторов относятся классы,
интерфейсы, типы данных, сигналы, компоненты, узлы, прецеденты (варианты использования) и подсистемы.
Классификаторы, и в особенности классы, характеризуются большим количеством дополнительных свойств,
кроме простейших, таких как атрибуты и операции, которые были описаны в предыдущих разделах (см. главу 4).
Можно моделировать кратность, видимость, сигнатуры, полиморфизм и другие характеристики. Язык UML позволяет определить семантику класса с расчетом па любой нужный вам уровень формализации.
В UML существует несколько разновидностей классификаторов и классов;
важно выбрать ту из них, которая позволяет лучше всего моделировать необходимую вам абстракцию реальности.
Введение
На определенном этапе строительства дома вам надлежит принять решение о том, какие материалы нужно использовать (см. главу 2). В самом начале достаточно лишь указать, что это будет дерево, камень или сталь. Такой
степени детализации довольно для того, чтобы двигаться дальше. На выбор материалов, разумеется, будут влиять
требования проекта, - например, сталь и бетон подойдут, если дом должен выдерживать натиск ураганов. Впоследствии ваш выбор определит дальнейшее развитие проекта, - скажем, выбрав дерево вместо стали, вы должны будете учитывать, что оно выдерживает меньшую нагрузку.
По мере дальнейшей работы над проектом базовые решения придется уточнить и добавить ряд деталей, которые
позволят конструктору произвести расчеты на прочность, а строителям - приступить к возведению дома. Например, вы можете выбрать не просто дерево, но дерево определенной твердости или пропитанном определенным составом, который защищает древесину от насекомых.
Те же самые правила применимы и к созданию программного обеспечения. В самом начале работы над проектом достаточно сказать, что вы собираетесь использовать класс Клиент, выполняющий определенные обязанности
(см. главу 6). По мере уточнения архитектуры и перехода к конструированию придется определить структуру класса (его атрибуты) и его поведение (операции), необходимые и достаточные для выполнения указанных обязанностей. Наконец, дойдя до стадии преобразования модели в исполняемую систему, вы должны будете смоделировать и
такие детали, как, видимость отдельных атрибутов и операций, семантику параллелизма класса в целом и его операций, а также реализуемые классом интерфейсы.
Как видно из рис. 9.1, язык UML позволяет определять большое количество развитых свойств класса. Эта нотация
дает возможность визуализировать, специфицировать, конструировать и документировать класс на любом желаемом уровне