Двухместная связь ( Binary Association )
это отношение между двумя классами, включая возможность рефлексивного отношения класса с самим собой. Изображается сплошной линией, соединяющей два класса. Линия может иметь один или несколько соединенных сегментов. Конец линии соединенный с классом называется ролью. Для связи может быть задано имя , которое представляет отношение в целом, оно не должно располагаться вблизи краев линии для того, что бы не возникало конфликтов с именованием ролей.
В следующем примере указано отношение между двумя классами “линия” и “точка”. Отношение имеет имя “Содержать”, роли для каждого из классов называются соответственно “Включает” и “Входит в”:
Рис. 7.7. Пример отношения.
Для каждой роли может быть определена дополнительная информация следующего вида:
· множественность,
· сортировка,
· квалификатор,
· имя роли,
· спецификация интерфейса,
· изменяемость,
· видимость.
множественность, определяет количество экземпляров классов, участвующих в отношении. Множественность определяется в виде одного или нескольких диапазонов:
нижняя граница .. верхняя граница
в качестве нижней или верхней границы может быть задан символ *, обозначающий произвольное количество. Может использоваться перечисление диапазонов через запятую. Пример допустимых вариантов:
1..*
*
сортировка, определяет тип упорядочения элементов для множественности больше чем 1. Возможные значение: упорядочено, неупорядочено.
символ агрегации, это ромб, находящийся между линией и классом. Символ агрегации обозначает, что класс, вблизи которого изображен данный знак является накопителем для класса, находящегося на другом конце связи. Если ромб залит черным цветом, то это обозначает усиленный вариант агрегации, называемый композиция. Символ агрегации может находиться только на одном конце связи.
Рис. 7.8. Пример агрегации
квалификатор, это один или несколько атрибутов, значения которых обеспечивают идентификацию экземпляров класса по данной связи. Множественность, указанная для роли, при наличии квалификатора указывает на количество экземпляров класса, выбираемых одним значением квалификатора. Наиболее часто используются следующие значения для множественности: 0..1 - уникальный экземпляр может быть выбран, но не обязательно будет выбран; 1 - каждое значение квалификатора однозначно выбирает экземпляр класса; * - одному значению квалификатора соответствует множество экземпляров. Графически квалификатор обозначается как прямоугольник, в котором указаны имена атрибутов, являющиеся квалификатором. Прямоугольник располагается между линией связи и классом. Ниже представлен пример в котором классы линия и точка связаны отношением “входить в”. Квалификатором является координата точки. Множественность со стороны класса “точка” равна 0..1, что обозначает, что каждая точка линии должна иметь уникальные координаты. Множественность со стороны класса “линия” равна *, что обозначает, что разные линии могут иметь общие точки.
Рис. 7.9. Пример использования квалификатора
имя роли, произвольный идентификатор конкретизирующий роль связи для одного из классов, указывается на линии вблизи класса.
Рис. 7.10. Пример обозначения роли.
Класс, описывающий связь
(Associaton class). Связь между классами также может обладать свойствами, присущими некоему классу. Для определения таких свойств для связи может быть задан ассоциированный с ней класс. Связь и ассоциированный класс представляют одно целое.
Ассоциированный класс изображается обычным образом в виде прямоугольника и связывается с отношением, для которого он задан, штриховой линией. Имена связи (отношения) и описывающего его класса должны совпадать.
Рис. 7.11. Пример класса, описывающего связь
N - местная связь
( N-ry Association ) Это связь между 3 и более классами. Эта связь графически обозначается ромбом, к которому подходят линии, соединяющие ромб с классами. Имя отношения указывается внутри или вблизи ромба. Класс, описывающий связь присоединяется к ромбу с помощью штрих - пунктирной линии. Пример такой связи представлен на рисунке:
Рис. 7.12. Пример многоместной связи.
Для подобного вида связей не может быть применена агрегация.
Композиция, Сборка.
Композиция ( Composition ) описывает включение классов друг в друга, один из вариантов представления композиции определен при описании двуместной связи ( с помощью закрашенных ромбов на конце линии ). Альтернативная графическая форма для представления композиции - это размещение изображения включаемых классов внутри изображения включающего класса.
Композиция является усиленной формой агрегации и может быть рассмотрена только на основе двуместной связи. В случае композиции объект владелец и его составные части не могут существовать раздельно. Компоненты, участвующие в композиции, не могут одновременно иметь нескольких владельцев. Все компоненты изменяются вместе с владельцем. Графически, композиция может быть представлена в виде "дерева", корнем которого является составной объект, а листьями – его компоненты.
Отличия сборки от композиции может быть продемонстрировано на следующем примере:
1. Сборка. Элементы входят в хэш-таблицу и образуют ее. Они могут существовать друг без друга. Таблица имеет собственную структуру и логику поведения. Она может не содержать ни одного элемента. В то же время элементы могут существовать изолированно от таблицы. Таким образом элементы собираются внутри таблицы и наполняют ее.
2. Композиция. Здание образуется набором внутренних помещений. Но они не могут существовать друг без друга и вне друг друга.
Соответственно такие отличия оказывают влияние на удаление объектов. Для композиции должно быть обеспечено удаление всех составных частей после удаления объемлющего объекта. Каждая часть также должна быть удалена в случае ее исключения из составного объекта.
Обобщение
Обобщение ( Generalization ) - это отношение между общим и уточняющим элементом. Обобщение показывается как сплошная линия с треугольником на конце. Треугольник располагается у общего элемента.
Рис. 7.13. Пример обобщения
Зависимость ( Dependency )
Зависимость ( Dependency ) - это отношение обозначает любую зависимость между любыми элементами модели. Зависимость изображается штриховой линией с направлением. Элемент для которого линия является выходной зависим от элемента на другом конце линии. На линии может быть указано имя отношения.
Рис. 7.14. Пример зависимости
Подобная связь никак не регламентирует вид отношений между объектами а указывает лишь на то, что зависимый класс использует какие-то особенности реализации иного класса
Все отношения между классами сведены в следующую таблицу:
Таблица 7.1. Отношения между классами
| Отношение | Изображение Класс Отношение Класс |
| 1. Наследование ( Inheritance ) |  |
| 2. Сборка ( Aggregation ) |  |
| 3. Композиция ( Composition ) |  |
| 4. Однонаправленная ассоциация ( Uni-directional Association ) |  |
| 5. Двунаправленная ассоциация ( Bi-directional Association ) |  |
| 6. Зависимость ( Dependency ) |  |
| 7. Шаблон ( Template Instantiation ) |  |
Пример диаграммы классов
Пример диаграммы классов представлен на рисунке ниже:
Рис. 7.15. Диаграмма классов для предметной области графического диаграммера.
Диаграммы использования
Диаграмма использования ( use case diagram ) предназначена для отображения внешнего функционирования проектируемой системы и ее взаимодействия с внешним миром пользователями. Эти диаграммы впервые были рассмотрены в книге[ 4 ] Иваром Якобсоном (Ivar Jacobson). Основой подхода являются так называемые блоки использования ( use case ), которые представляют собой некоторый набор функций системы, объединяемых в единое целое с точки зрения пользователя. Один блок использования не обязательно представляет собой одну часть системы или даже единую группу функций. Он представляет собой именно понимание пользователем поведения системы.
Диаграммы использования являются широко применяемыми в различных технологиях проектирования. Их главная задача - спецификация требований к системе на начальных этапах проектирования, когда решаются наиболее общие задачи предназначения разрабатываемой системы. Широкое распространение диаграмм использования привела в частности и к тому, что они имеют очень широкое и иногда различное толкование. Так в книге [ 4 ] автор указывает, что он обнаружил 18 различных определений, которые отличаются друг от друга по очень многим параметрам.
Диаграмма состоит из следующих элементов:
· внешние пользователи ( actors ), это такие воздействия, которые передают или получают информацию для системы, это могут быть физические объекты разной природы от людей и механизмов до программных систем, один физический объект может описываться несколькими пользователями, если он взаимодействует с разными функциями,
· блоки использования ( use case ), это такие группы функций системы, которые объединяются в единое целое для внешнего пользователя,
· связи между блоками использования и связи между блоками использования и внешними пользователям.
Выделены следующие виды связей:
· взаимодействие; ( только между пользователем и блоком использования )
· расширение - данный вид отношения от блока А к блоку В обозначает, что исполнение блока В может дополняется исполнением некоторых функций блока А;
· использование - данный вид отношения от блока А к блоку В обозначает, что исполнение А также включает исполнение блока В;
Графически блоки использования обозначаются эллипсами с указанием имени внутри эллипса или рядом с ним. Внешние пользователи графически обозначаются как прямоугольники с табулятором “Пользователь” или в виде схематичной фигурки человека, с именем под ней.
Графическое обозначение для связей следующее:
· взаимодействие - сплошная линия,
· расширение - линия со стрелкой от блока, предоставляющего расширение к базовому блоку, помеченная словом “extends”
· использование - линия со стрелкой от использующего блока к используемому блоку, помеченная словом “uses”.
Все блоки использования объединяются на рисунке в единый прямоугольник, очерчивающий рамки проектируемой системы.
Примером диаграммы может являться диаграмма, представленная на рис. , демонстрирующая структуру системы учета клиентов Internet для Internet Service Provider ( ISP ).
Внешними пользователями ( actor ) являются:
“клиент” - физическое или юридическое лицо, заказывающее услуги по подключению к сети Internet,
“оператор” - сотрудник ISP, осуществляющий работу с клиентом и системой учета,
“бухгалтер”- бухгалтер ISP,
“системный администратор” - сотрудник ISP, обеспечивающий системное администрирование системы учета клиентов.
Основными задачами “клиента” являются
(1) заключение договора о предоставлении услуг сети Internet,
(2) выбор перечня услуг для работы в сети ( например, создание почтового ящика, создание web-сервера, регистрация и обслуживание домена ),
(3) оплата предоставленных услуг или авансовый платеж,
(4) получение необходимых документов ( договор, счет, счет-фактура, акт о выполненных работах ),
(5) получение статистических отчетов ( состояние счета, сеансы работы, начисления за услуги ),
(6) подключение и работа в режиме on-line.
Основными задачами “бухгалтера” являются
(1) получение отчетов о поступлении платежей
Основными задачами “системного администратора” являются
(1) удаление сведений о клиенте
(2) создание нового вида услуг
Рис. 7.16. Пример диаграммы использования.
Диаграммы использования являются весьма популярными и включаются в различные методики проектирования благодаря своим следующим достоинствам:
формулировка требований, ориентированная на пользователя, т.е. система заведомо проектируется так как ее будет видеть пользователь,
простота модели, ее ориентированность на неподготовленного пользователя,
возможность описания больших проектов за счет декомпозиции на крупные блоки использования, которых в любой системе не так много, как структурных единиц самой системы.
В соответствии с материалами [8] предлагается следующая последовательность формулирования требований к системе с помощью диаграмм использования:
· определить перечень главных пользователей ( внешних входов-выходов ) системы, это целесообразно сделать методом мозгового штурма с участием большого количества людей, начиная от руководителя разработки и кончая программистами;
· определить методику участия внешних пользователей в проекте ( методы привлечения их к составлению требований );
· определить главные цели пользователей ( что они хотят сделать с помощью системы ) и задачи, которые нужно решить для достижения этих целей;
· составить диаграмму использования, в которой каждой задаче каждого пользователя сопоставить блок использования; соединить блоки использования и внешних пользователей, ответственных за данную задачу;
· проверить каждый блок использования какой-либо количественной метрикой, например, можно использовать оценку времени выполнения задачи или объема ресурсов, необходимого для ее решения; на этой стадии полезно составить прототип программного средства, для оценки реализуемости проекта ( но не в коем случае не интерфейса пользователя );
Все перечисленные шаги не должны приводить к слишком сложной модели и занимать слишком много времени. Далее можно перечислить рекомендации по составлению диаграмм использования:
диаграммы должны быть простыми и понятными любому пользователю;
автор проекта и идеи системы должен участвовать в спецификации требований;
каждый участник проекта должен понимать конечную цель и предназначение разрабатываемой системы;
блоки использования должны быть основаны на их целях ( а не, например, структуре );
не использовать слишком много отношений “extends” и “uses” - они усложняют понимание диаграммы;
блоки использования не должны отражать вопросов пользовательского интерфейса;
необходимо вовремя остановить внешних пользователей, т.к. они могут хотеть от системы слишком много и она будет нереализуема.