Читальный зал -->  Диаграммы параллельных состояний 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [ 18 ] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

Ассоциации

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

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

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

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

Так, например, на рис. 4.1 конец ассоциации, направленной от класса Заказ к классу Строка заказа, имеет название Позиции заказа. Если такая метка отсутствует, концу ассоциации присваивается имя класса-цели; например, конец ассоциации от класса Заказ к классу Клиент может быть назван клиент-Конец ассоциации также обладает кратностью, которая показывает, сколько объектов может участвовать в данном отношении. На рис. 4.1 символ * возле класса Заказ для ассоциации между классами Заказ и Клиент показывает, что с одним клиентом может быть связано много згпсазов; напротив, символ 1 показывает, что каждый из заказов может поступить только от одного клиента.

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

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

лать ни одного заказа, но верхний предел количества заказов, сделанных одним клиентом, никак не ограничен (разумеется, теоретически!). 1 означает диапазон то есть заказ должен быть сделан одним и только одним клиентом.

На практике наиболее распространенными вариантами кратности являются 1 , * и 0..1 (либо ноль, либо единица). В более общем случае для кратности может использоваться единственное число (например, 11 для количества игроков футбольной команды), диапазон (например, 2..4 для количества игроков карточной игры канаста) или дискретная комбинация из чисел или диапазонов (например, 2,4 для количества дверей в автомобиле).

С точки зрения спецификации ассоциации представляют собой ответственности классов.

На рис. 4.1 предполагается, что существует один или более методов, связанных с классом Клиент, с помощью которых можно узнать, какие заказы сделал конкретный клиент. Аналогично в классе Заказ существуют методы, с помощью которых можно узнать, какой Клиент сделал конкретный Заказ и какие Строки заказа входят в этот Заказ.

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

Следуя подобному соглашению, в языке Java, например, я могу определить следующий интерфейс для класса Заказ:

class Order {

public Customer getCustomerO; public Set getOrderLinesO;

(Order - Заказ, Customer - Клиент, OrderLines - Строки заказа)

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

Ассоциация несет также определенную ответственность за обновление соответствующего отношения. Так, например, должен существовать некоторый способ связи класса Заказ с классом Клиент. Детали этого способа на диаграмме не -показаны; можно было бы включить спецификацию класса Клиент в конструктор для класса Заказ. Или это может быть метод добавитьЗаказ, ассоциированный с классом Клиент. Как мы увидим позже, такой способ связи можно сделать более явным посредством добавления операций в блок класса на диаграмме.

Однако эта ответственность не распространяется на структуру данных. Рассматривая диаграмму с точки зрения спецификации, я не могу высказать никаких предположений относительно структуры данных для классов. Я не могу сказать, да мне и не следует знать, содержит ли в действительности класс Заказ указатель на класс Клиент или же класс Заказ реализует свою функциональность посредством выполнения некоторого программного запроса к каждому экземпляру класса Клиент, чтобы выяснить, связан ли он с данным классом Заказ. Диаграмма описывает только интерфейс - и ничего более.

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

class Order {

private Customer .customer;

private Set orderLlnes; class Customer {

private Set .orders;

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

Теперь посмотрим на рис. 4.2. В основном он совпадает с рис. 4.1, за исключением того, что я добавил стрелки к ассоциациям. Эти стрелки показывают направление навигации.

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

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

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [ 18 ] 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

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



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.

Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы.