Список стереотипов, определенных в UML2 для отношения зависимости

Стереотип

Описание

«call» (вызвать) «create» (создавать) «derive» (производить)   «instantiate» (создать экземпляр) «permit» (разрешать) «realize» (реализовать)   «refine» (уточнить)   «send» (послать, отправлять) «substitute» (заместить) «trace» (проследить) «use» (использовать) «bind» (связывать)

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

 

Стереотипы зависимостей derive, realize, refine и trace являются абстрактными зависимостями. Они существуют для представления двух вариантов одних и тех же элементов. Например, зависимость realize подразумевает связь реализации, то есть реализацию интерфейса. Зависимость trace применяется для соединения друг с другом элементов модели по мере того, как она развивается, например, вариантов использования с их реализацией.

Стереотип instantiate также может использоваться для указания того, что класс – источник создает экземпляр класса – цель. Лучшим примером этого типа связи является получение информации о типе в процессе выполнения программы или так называемое отражение в.NET.

Стереотип permit применяется для указания того, что класс – источник может вызывать закрытые члены класса – цели.

Сигнал идентичен событию, происходящему вне основной последовательности действий. Стереотип s ignal используется для обозначения того, что произошло что-то, что требует ответных действий. Рассматривайте это как событие.

Стереотип substitute применяется, когда класс – источник может быть заменен классом – целью. Чистым видом такой связи является замена классом – потомком класса – родителя. И наконец, стереотип use, обозначающий довольно общий вид связи, подразумевает, что классу – источнику просто необходимо завершение одного из действий над классом – целью. Этот стереотип – более обобщенная форма таких разновидностей отношений зависимости, как call, create, instantiate и send.

В своей замечательной монографии Мартин Фаулер [21] рекомендует в самом общем случае использовать зависимости с классами для иллюстрации транзитивного отношения, когда один объект передается другому в качестве параметра операции. Иногда их применяют с ключевыми словами “parameter” (параметр), “local ” (локальный) и “global” (глобальный). Эти ключевые слова не входят в UML 2.0.

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

Рис.4.18 Пример реализации отношений: агрегация, наследование, ассоциация и зависимость

Отношение «ассоциация» (структурная зависимость) - семантическая связь между классами, предполагающая наличие дополнительного атрибута – ссылки на целевой класс, в составе своего объекта. В нашем примере, класс Самолет должен содержать атрибут – ссылку на объект класса Двигатель. Направление ассоциации делается из предположения о существовании в классе Самолет способа извещения (отправки сообщения) классу Двигатель, но не наоборот. Отношение «зависимость» (функциональная зависимость) показывает, что один класс использует другой. При генерации кода для таких классов к ним не добавляются новые атрибуты, как в случае ассоциации, но создаются специфические для использования языка программирования операторы, необходимые для поддержки отношения. Например, на языке C# в код войдут операторы using, а в С++ - include.

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

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

В нашем примере покажем реализацию отношений агрегация, конкретизация (наследование), ассоциация, а также двух возможностей отношения зависимости.

using System;

using System.Collections.Generic;

using System.Text;

namespace ConsoleApplication1

{

class Двигатель

{

public void Запуск(string str)

{

Console.WriteLine(" {0} - запущен", str);

}

}

class Самолет

{

Двигатель левый, правый; // агрегация

public Самолет()

{

левый = new Двигатель();

правый = new Двигатель();

}

public bool РешениеДиспетчера(Диспетчер d) //зависимость через параметр

{

if (d.Разрешение_на_Взлет())

return true;

else

return false;

}

 

public void ЗапуститьДвигатели()

{

левый.Запуск(" Левый двигатель" );

правый.Запуск(" Правый двигатель" );

Console.WriteLine(" Ура!!! Полетели " );

}

} // класс Самолет

 

class Боинг: Самолет //конкретизация

{

public Боинг(): base() {}

public bool Готовность_к_Полету()

{

Console.WriteLine(" Самолет исправен? " );

bool ans = Convert.ToBoolean(Console.ReadLine());

return ans;

}

}

class Диспетчер

{

public Диспетчер() {}

public bool Разрешение_на_Взлет()

{

Метеослужба meteo = new Метеослужба();

//зависимость через локальный объект

if (meteo.РешениеМетеослужбы())

{ Console.WriteLine(" Вылет разрешаю! " ); return true; }

else

{

Console.WriteLine(" Вылет не разрешаю! Ждем погоды " );

return false;

}

}

}

class Метеослужба

{

Погода wether; // ассоциация

public Метеослужба()

{ wether = new Погода(); }

public bool РешениеМетеослужбы()

{

if (wether.Прогноз())

return true;

else return false;

}

}

class Погода

{

public Погода() {}

public bool Прогноз()

{ Console.WriteLine(" Состояние погоды? " );

bool b = Convert.ToBoolean(Console.ReadLine());

return b;

}

}

class Test

{

static void Main()

{

Боинг boing = new Боинг();

Диспетчер disp = new Диспетчер();

if (boing.Готовность_к_Полету())

{

if (boing.РешениеДиспетчера(disp))

boing.ЗапуститьДвигатели()

}

 

else

Console.WriteLine(" Рейс откладывается по техническим причинам" );

 

Console.ReadKey();

}

}

}

Результат работы программы:

Самолет исправен?

Нет, неисправен → Рейс откладывается по техническим причинам

Исправен → Состояние погоды?

Непогода → Вылет не разрешаю! Ждем погоды

Нормально → Вылет разрешаю!

Левый двигатель – запущен

Правый двигатель – запущен

Ура!!! Полетели

 

Отношение «реализация»

Чаще всего, отношение реализации используется для отношения между интерфейсом и классом, реализующим интерфейс. Интерфейс определяет набор операций, характерных для объектов, обладающих определенными свойствами.

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

На основе рассмотренных отношений между классами, приведем пример (рис. 4.19) полной иерархии классов проекта «Гирлянда из цветных лампочек» (Garland Application) [18].

На рис. 4.19 представлен вариант определения класса ColorableObject на основе интерфейса IColorable. Проиллюстрируем на этом примере основную идею, лежащую в основе концепции интерфейса. Цветом могут характеризоваться не только лампочки, но и самые разнообразные объекты.

В рамках программной модели было бы неплохо иметь какой-нибудь вполне унифицированный механизм работы с такими объектами. Интерфейс IColorable, «в кооперации» с типом – перечислением ColorEnum, предоставляет простейшую модель такого механизма. Тип ColorEnum содержит элементы перечисления, которые мы будем использовать для идентификации цвета. Интерфейс IColorable использует этот тип для определения сигнатур двух методов SetColor() и GetColor(), которые должен поддерживать любой объект, характеризуемый цветом. Интерфейс, как известно, не предоставляет реализацию методов, то есть интерфейс IColorable – это, по существу, чистая абстракция объекта, характеризуемого цветом.

Определив для любого класса отношение реализации интерфейса IColorable, надо обязательно предоставить реализацию операций SetColor() и GetColor(), соблюдая тем самым контракт, установленный интерфейсом. Классом – реализатором является класс ColorableObject (все его объекты считаются поддерживающими интерфейс IColorable).

В такой интерпретации класс ColoredLight может трактоваться как разновидность ColorableObject.

Можно реализовать и другие разновидности ColorableObject.

Графически отношение реализации изображается пунктирной линией с полой стрелкой, направленной от сущности (класса), обеспечивающей реализацию, к сущности, определяющей контракт, то есть, к интерфейсу.

 

 

Рис.4.19. Диаграмма классов GarlandApplication

 

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

void SetWhite (IColorable * arg)

{ arg -> SetColor (WHITE); }

В данный метод, в качестве параметра, можно передать указатель на любой объект, который поддерживает интерфейс IColorable.

В заключение отметим, что большинство современных языков программирования поддерживают интерфейсы в виде встроенных средств языка (включая Java, C#, Visual C++.Net with Managed Extentions). Язык С++ напрямую не поддерживает интерфейсы, однако эквивалентная им семантика может быть выражена с помощью абстрактных классов.

 

Моделирование классов

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

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

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

До сих пор мы использовали классы для определения бизнес – объектов. Все приведенные нами примеры классов относились к долгоживущим (постоянным или перманентным) сущностям бизнес – процессов, таким как: Личность, Компания, Курс, Студент, Заказ, Товар и т.д. Это классы, которые определяют модель базы данных для прикладной области. По этой причине подобные классы часто называют классами – сущностями (entity classes) или модельными классами. Они представляют постоянно хранимые объекты базы данных.

Классы – сущности определяют существо любой информационной системы, поэтому понадобится определить классы – сущности для отдельных таблиц и различных смешанных запросов, включающих обращение сразу к нескольким таблицам. Начиная с этого момента, эти сущности просто моделируются как классы. Можно использовать стереотип < < table > >, если сущности представляют какие-либо таблицы, или вообще не указывать стереотип, если необходимо обозначить какой-то собственный (пользовательский) класс.

Анализ функциональных требований направлен преимущественно на выявление классов – сущностей. Однако для функционирования системы требуются также и другие типы классов. Пользователям системы, например, необходимы классы, которые определяют GUI – объекты (такие как экранные формы интерактивного диалога), называемые пограничными классами (boundary classes) (классами представления –view classes). Основной задачей интерфейсных классов является абстрагирование системы от прямого взаимодействия с внешними системами. Если внешняя система, изменится каким – либо образом, то для дальнейшей работы программы необходимо только изменить интерфейсные классы.

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

Класс-контроллер является связующим кодом, который управляет другими классами и обеспечивает передачу данных между классами-сущностями, интерфейсными классами и бизнес - логикой приложения. Классы-контроллеры могут управлять тем, каким образом и в каком виде данные направляются в интерфейсные классы и через них в другие системы. Существует много шаблонов (patterns), которые определяют общеизвестные элементы управления и интерфейсы пользователя. Широко известным является так называемый шаблон «модель-вид-контроллер» (Model –View- Controller - MVC). В этом шаблоне модель представлена объектами бизнес-логики, видом является графический интерфейс пользователя, а находящиеся между ними классы-контроллеры называются одним термином - контроллер. Рассмотрим, например, Web-страницы, выполненные с использованием библиотеки ASP.NET, как реализованные по технологии MVC. ASPX, или HTML – страница представляет собой вид, контроллером является код приложения, а модель состоит из объектов, чьи данные отображаются на странице. Применение своего шаблона по технологии MVC, в данном случае, будет избыточным и необоснованным.

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

Выявление классов – сущностей, в первую очередь, связано с концептуальной моделью предметной области, как основы диаграммы классов приложения. Построение концептуальной модели предметной области начинается с выявления абстракций, существующих в реальном мире, то есть тех основных концептуальных объектов, которые встречаются (имеют место) в предметной области. Это связано с тем, что требования к программе меняются намного быстрее, чем реальный мир.

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

Лучшими источниками классов являются: высокоуровневое описание задачи, низкоуровневые требования и экспертная оценка задачи и предметной области.

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

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

При определении того, являются ли понятия, присутствующие в упомянутых источниках, искомыми классами системы, могут помочь ответы на некоторые вопросы[11]. Вот эти вопросы:

· Является ли понятие «вместилищем» данных?

· Обладает ли понятие отдельными атрибутами, способными принимать разные значения?

· Можно ли создать для него множество объектов – экземпляров?

· Входит ли понятие в границы прикладной области?

 

Опишем типичные приемы моделирования классов [16].

Словарь системы

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

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

Моделирование словаря системы включает в себя следующие этапы:
1. Определить элементы, которые пользователи и разработчики применяют для описания задачи или ее решения.

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

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

Например, для системы розничной торговли можно выделить базовые классы: Клиент, Заказ, Товар; соотнесенные с ними абстракции, взятые из словаря проблемной области: Отгрузка, Накладная, Склад, и одну абстракцию – Транзакция, которая применяется к заказам и отгрузкам и которая связана с технологией решения задачи.

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

⇐ Предыдущая567891011121314Следующая ⇒

Поделиться: