А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 7

Если поместить его внутри классаStudent, то придется вводить его для каждого посещаемого студентомкурса, что слишком сильно увеличит размер этого класса. Если жепоместить его внутри класса Course, то придется задавать его для каждогопосещающего этот курс студента.Чтобы решить эту проблему, можно создать ассоциацию-класс. В этоткласс следует поместить атрибут Grade, относящийся к связи между31курсом и студентом. Нотация UML для ассоциации-класса представлена нарис. 1.8.Рис 1.8. Ассоциация-классАссоциация-класс определяет дополнительное ограничение, согласнокоторому двум участвующим в ассоциации объектам можетсоответствовать только один экземпляр ассоциации-класса. Диаграмма нарис. 1.8 не допускает, чтобы студент мог получать по курсу более чем однуоценку.

Если необходимо, чтобы такое допускалось, то ассоциацию-классGrade следует преобразовать в обычный класс, связанный ассоциациями склассами Student и Course.Зависимость (dependency) - связь между двумя элементами модели,при которой изменения в спецификации одного элемента могут повлечь засобой изменения в другом элементе. Зависимость - слабая форма связимежду клиентом и сервером (клиент зависит от сервера и не имеет знанийо сервере). Зависимость изображается пунктирной линией, направленнойот клиента к серверу (рис. 1.9).ClientSupplierРис 1.9. ЗависимостьЗависимость между двумя элементами имеет место в том случае, еслиизменения в определении одного элемента могут повлечь за собойизменения в другом.

Что касается классов, то причины для зависимостеймогут быть самыми разными: один класс посылает сообщение другому;один класс включает часть данных другого класса; один класс используетдругой в качестве параметра операции. Если класс меняет свой интерфейс,то любое сообщение, которое он посылает, может утратить свою силу.32Обобщение (generalization) - связь "тип-подтип" - реализует механизмнаследования (inheritance).

Большинство объектно-ориентированныхязыков непосредственно поддерживают концепцию наследования. Онапозволяет одному классу наследовать все атрибуты, операции и связидругого. В языке UML связи наследования называют обобщениями иизображают в виде стрелок от класса-потомка к классу-предку (рис. 1.10).Общие атрибуты, операции и/или связи отображаются на верхнемуровне иерархии. Помимо наследуемых, каждый подкласс имеет своисобственные уникальные атрибуты, операции и связи.Рис 1.10.

Обобщение1.4. Унифицированный язык моделирования UMLУнифицированный язык моделирования UML (Unified ModelingLanguage)[3, 13, 15] представляет собой язык для определения,представления, проектирования и документирования программных систем,организационно-экономических систем, технических систем и другихсистем различной природы. UML содержит стандартный набор диаграмм инотаций самых разнообразных видов.UML - это преемник того поколения методов объектноориентированного анализа и проектирования, которые появились в конце1980-х и начале 1990-х годов.

Создание UML фактически началось в конце331994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединениюих методов Booch и OMT (Object Modeling Technique) под эгидойкомпании Rational Software. К концу 1995 г. они создали первуюспецификацию объединенного метода, названного ими Unified Method,версия 0.8. Тогда же в 1995 г. к ним присоединился создатель методаOOSE (Object-Oriented Software Engineering) Ивар Якобсон. Такимобразом, UML является прямым объединением и унификацией методовБуча, Рамбо и Якобсона, однако дополняет их новыми возможностями.Главными в разработке UML были следующие цели:• предоставитьпользователямготовыйкиспользованиювыразительный язык визуального моделирования, позволяющий имразрабатывать осмысленные модели и обмениваться ими;• предусмотреть механизмы расширяемости и специализации длярасширения базовых концепций;• обеспечитьнезависимостьотконкретныхязыковпрограммирования и процессов разработки.• обеспечить формальную основу для понимания этого языкамоделирования (язык должен быть одновременно точным идоступным для понимания, без лишнего формализма);• стимулироватьрострынкаобъектно-ориентированныхинструментальных средств;• интегрировать лучший практический опыт.UML находится в процессе стандартизации, проводимом OMG (ObjectManagement Group) - организацией по стандартизации в области объектноориентированных методов и технологий, в настоящее время принят вкачестве стандартного языка моделирования и получил широкуюподдержку в индустрии ПО.

UML принят на вооружение практическивсеми крупнейшими компаниями - производителями ПО (Microsoft, IBM,Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически всемировые производители CASE-средств, помимо IBM Rational Software,поддерживают UML в своих продуктах (Together (Borland), Paradigm Plus(Computer Associates), System Architect (Popkin Software), Microsoft VisualModeler и др.). Полное описание UML можно найти на сайтахhttp://www.omg.org и http://www.rational.com.Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагаетследующий набор диаграмм:• Структурные (structural) модели:o диаграммы классов (class diagrams) - для моделированиястатической структуры классов системы и связей междуними;o диаграммы компонентов (component diagrams) - длямоделирования иерархии компонентов (подсистем) системы;34o диаграммы размещения (deployment diagrams) - длямоделирования физической архитектуры системы.• Модели поведения (behavioral):o диаграммы вариантов использования (use case diagrams) - длямоделированиябизнес-процессовитребованийксоздаваемой системе;o диаграммы взаимодействия (interaction diagrams) (диаграммыпоследовательности (sequence diagrams) и кооперативныедиаграммы (collaboration diagrams)) - для моделированияпроцесса обмена сообщениями между объектами;o диаграммы состояний (statechart diagrams) - длямоделирования поведения объектов системы при переходе изодного состояния в другое;o диаграммы деятельности (activity diagrams) - длямоделирования поведения системы в рамках различныхвариантов использования, или потоков управления.1.4.1.

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

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

На рис. 1.11 показан пример такойдиаграммы для банковской системы.35На данной диаграмме человеческие фигурки обозначаютдействующих лиц, овалы - варианты использования, а линии и стрелки различные связи между действующими лицами и вариантамииспользования.На этой диаграмме показаны два действующих лица: клиент икредитная система. Существует также шесть основных действий,выполняемых моделируемой системой: перевести деньги, сделать вклад,снять деньги со счета, просмотреть баланс, изменить PIN-код и сделатьплатеж.Рис.

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

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

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