1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

Методические аспекты проектирования ПО

171

•компонентом исходного кода;

•компонентом времени выполнения (run time);

•исполняемым компонентом.

Компонент обеспечивает физическую реализацию набора интерфейсов.

Между элементами объектной модели существуют различные виды связей. К основным типам связей относятся связи ассоциа­

ции, зависимости и обобщения.		семантическая связь между
Ассоциация (association) — это
классами. Ее изображают на диаграмме классов в виде обыкно­
венной линии (рис. 2.39). Ассоциация отражает структурные свя­
зи между объектами различных классов.
Company	Employs	Person

Рис. 2.39. Ассоциация

Агрегация (aggregation) представляет собой форму ассоциации

— более сильный тип связи между целым (составным) объектом и его частями (компонентными объектами).

Существуют четыре возможных семантики для агрегации:

1)агрегация типа «Безраздельно обладает»;

2)агрегация типа «Обладает»;

3)афегация типа «Включает»;

4)афегация типа «Участник».

Афегация типа «Безраздельно обладает» устанавливает следу­ ющее:

•между компонентными объектами и их составными объек­ тами установлено отношение зависимости по существова­ нию (следовательно, удаление составного объекта распрост­ раняется вниз по иерархии отношения, так что связанные компонентные объекты также удаляются);

•афегация транзитивна (если объект С\ является частью объекта В\, а 51 — частью У41, тогда С\ является частью У41Л*

•афегация асимметрична (нерефлексивна) (если объект В\ яв­ ляется частью объекта У41, ТО объект ^41 не является частью

В\);

•афегация стационарна (если объект В\ является частью объ­ екта А\, то он не может быть частью объекта Ai (/ ^ 1)).

172

Глава 2

Агрегация типа «Обладает» поддерживает первые три свой­ ства агрегации «Безраздельно обладает», к которым относятся:

•зависимость по существованию;

•транзитивность;

•асимметричность.

Агрегация типа «Включает» слабее, чем афегация типа «Об­ ладает», она поддерживает транзитивность и асимметричность.

Афегация типа «Участник» обладает свойством целенаправ­ ленного фуппирования независимых объектов — фуппирования, при котором не делается предположений относительно свойства зависимости по существованию, транзитивности, асимметрич­ ности или стационарности. Компонентный объект в афегации типа «Участник» может одновременно принадлежать более чем одному составному объекту.

Язык UML обеспечивает офаниченную поддержку афега­ ции. Сильная форма афегации является в UML композицией. В композиции составной объект может физически содержать ком­ понентные объекты. Компонентный объект может принадлежать только одному составному объекту. Композиция языка UML в большей или меньшей степени соответствует афегациям типа «Безраздельно обладает» и «Обладает».

Слабая форма афегации в UML называется просто агрегаци­ ей. При этом составной объект физически не содержит компоне­ нтный объект. Один компонентный объект может обладать нес­ колькими связями ассоциации или афегации. Иначе говоря, аг­ регация в языке UML соответствует афегациям типа «Включает» и «Участник».

Афегация изображается линией между классами с ромбом на стороне целого объекта (рис. 2.40). Сплошной ромб представля­ ет композицию (рис. 2.41).

Whole	\о>	Part
	Рис 2.40. Агрегация
Whole		Part

Рис 2.41. Композиция

Методические аспекты проектирования ПО

173

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

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

Связи можно уточнить с помощью имен связей или ролевых имен. Имя связи — это обычно глагол или глагольная фраза, опи­ сывающая, зачем она нужна. Например, между классом Person (человек) и классом Company (компания) может существовать ассоциация. Если человек является сотрудником компании, ас­ социацию можно назвать «employs» (нанимает) (см. рис. 2.39).

Имена у связей определять не обязательно. Обычно это дела­ ют, если причина создания связи не очевидна. Имя показывают около линии соответствующей связи.

Для уточнения роли, которую ифает каждый класс в связях ассоциации или афегации, применяют ролевые имена (рис. 2.42). Возвращаясь к примеру с классами Person и Company, мож­ но сказать, что класс Person ифает роль сотрудника класса Company. Ролевые имена — это обычно имена существительные или основанные на них фразы, их показывают на диафамме ря­ дом с классом, ифающим соответствующую роль. Как правило, пользуются или ролевым именем, или именем связи, но не обои­ ми сразу. Как и имена связей, ролевые имена не обязательны, их дают, только если смысл связи не очевиден.

Мощность (multiplicity) показывает, как много объектов участ­ вует в связи. Мощность — это число объектов одного класса, свя-

Company +Employer +Employee Person

Рис 2.42. Ролевые имена

174

Глава 2

занных с одним объектом другого класса. Понятие мощности связи в объектной модели аналогично понятиям мощности и класса принадлежности связи в модели «сущность-связь» (с точ­ ностью до расположения показателя мощности на диаграмме). Для каждой связи можно обозначить два показателя мощности — по одному на каждом конце связи.

В языке UML приняты следующие нотации для обозначения мощности.

	Значения мощности
Мощность	Значение
•	Много
О	Нуль
1	Один
0..*	Нуль или больше
1..*	Один или больше
0..1	Нуль или один
1..1	Ровно один

Например, при разработке системы регистрации курсов в университете можно определить классы Course (учебный курс) и Student (студент). Между ними установлена связь, означающая посещение курсов студентами. Если один студент может посе­ щать от нуля до четырех курсов, а на одном курсе могут занимать­ ся от 10 до 20 студентов, то на диаграмме классов это можно изоб­ разить следующим образом (рис. 2.43).

Course

Student

0..4 10..20

Рис 2.43. Мощность связи

Частным случаем ассоциации является ассоциация-класс (Association class), которая обладает как свойствами класса, так и свойствами ассоциации. Ассоциация-класс - это место, где хра­ нятся относящиеся к ассоциации атрибуты и операции. Экземп­ лярами ассоциации-класса являются связи, у которых есть не

Методические аспекты проектирования ПО

175

только ссылки на объекты, но и значения атрибутов. Ассоциациякласс подобна связи с атрибутами в модели «сущность-связь».

Допустим, что имеются два класса, Student и Course, и воз­ никла необходимость добавить атрибут Grade (оценка). В таком случае возникает вопрос, в какой класс надо его добавить. Если поместить его внутри класса Student, то придется вводить его для каждого посещаемого студентом курса, что слишком сильно уве­ личит размер этого класса. Если же поместить его внутри класса Course, то придется задавать его для каждого посещающего этот курс студента.

Чтобы решить эту проблему, можно создать ассоциациюкласс. В этот класс следует поместить атрибут Grade, относящий­ ся к связи между курсом и студентом. Нотация UML для ассоци­ ации-класса представлена на рис. 2.44.

Course

Student

0..4 i 10..20

Grade

Рис 2.44. Ассоциация-класс

Ассоциация-класс определяет дополнительное ограничение, согласно которому двум участвующим в ассоциации объектам может соответствовать только один экземпляр ассоциации-клас­ са. Диаграмма на рис. 2.44 не допускает, чтобы студент мог полу­ чать по курсу более чем одну оценку. Если необходимо, чтобы та­ кое допускалось, то ассоциацию-класс Grade следует преобразо­ вать в обычный класс, связанный ассоциациями с классами Student и Course.

Зависимость (dependency) — связь между двумя элементами модели, при которой изменения в спецификации одного элемен­ та могут повлечь за собой изменения в другом элементе. Зависи­ мость — слабая форма связи между клиентом и сервером (клиент зависит от сервера и не имеет знаний о сервере). Зависимость изображается пунктирной линией, направленной от клиента к серверу (рис. 2.45).

176	Глава 2
Client I	^ Supplier

Рис 2.45. Зависимость

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

Обобщение (generalization) — связь «тип-подтип» реализует ме­ ханизм наследования (inheritance). Большинство объектно-ори­ ентированных языков непосредственно поддерживают концеп­ цию наследования. Она позволяет одному классу наследовать все атрибуты, операции и связи другого. В языке UML связи насле­ дования называют обобщениями и изображают в виде стрелок от класса-потомка к классу-предку (рис. 2.46).

student

name address studentiD

+get tuitionO

+add scheduleO

•b delete scheduie()

FulitimeStudent	ParttimeStudent
graduate	maxNumCourses

Рис 2.46. Обобщение

Методические аспекты проектирования ПО

177

Общие атрибуты, операции и/или связи отображаются на верхнем уровне иерархии.

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

2.5. УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML

Унифицированный язык моделирования UML^ (Unified Mo

Language) представляет собой язык для определения, представле­ ния, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

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

•предоставить пользователям готовый к использованию вы­ разительный язык визуального моделирования, позволяю­ щий им разрабатывать осмысленные модели и обменивать­ ся ими;

•предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;

•обеспечить независимость от конкретных языков програм­ мирования и процессов разработки.

^ Фаулер М., Скотт К. UML в кратком изложении. Применение стан­ дартного языка объектного моделирования: Пер. с англ. — М.: Мир, 1999.

178

Глава 2

•обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

•стимулировать рост рынка объектно-ориентированных инструментальных средств;

•интефировать лучший практический опыт.

UML находится в процессе стандартизации, проводимом OMG (Object Management Group) — организацией по стандарти­ зации в области объектно-ориентированных методов и техноло­ гий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. UML принят на вооружение почти всеми крупнейшими компа­ ниями ~ производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, почти все мировые производи­ тели CASE-средств, помимо IBM Rational Software, поддержива­ ют UML в своих продуктах (Together (Borland), Paradigm Plus (Computer Associates), System Architect (Popkin Software), Microsoft Visual Modeler и др.). Полное описание UML можно найти на сайтах http://www.omg.org и http://www.rational.com.

Стандарт UML версии L1, принятый OMG в 1997 г., предла­ гает следующий набор диафамм:

• Структурные (structural) модели:

диафаммы классов (class diagrams) -- для моделирования ста­ тической структуры классов системы и связей между ними; диафаммы компонентов (component diagrams) — для модели­ рования иерархии компонентов (подсистем) системы; диафаммы размещения (deployment diagrams) — для модели­ рования физической архитектуры системы.

• Модели поведения (behavioral):

диафаммы вариантов использования (use case diagrams) — для моделирования бизнес-процессов и функциональных требо­ ваний к создаваемой системе;

диафаммы взаимодействия (interaction diagrams): диафаммы последовательности (sequence diagrams) и коопе­

ративные диафаммы (collaboration diagrams) — для моделиро­ вания процесса обмена сообщениями между объектами; диафаммы состояний (statechart diagrams) — для моделирова­ ния поведения объектов системы при переходе из одного сос­ тояния в другое;

Методические аспекты проектирования ПО

179

диафаммы деятельности (activity diagrams) — для моделирова­ ния поведения системы в рамках различных вариантов ис­ пользования, или потоков управления.

2 . 5 . 1 . ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

Идея описания функциональных требований в виде вариан­ тов использования (use case) была сформулирована в 1986 г. Иваром Якобсоном. Эта идея была признана конструктивной и полу­ чила широкое одобрение. Впоследствии наиболее значительный вклад в решение проблемы определения сущности вариантов ис­ пользования и способов их описания внес Алистер Коберн^

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

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

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

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

Для наглядного представления вариантов использования применяются диафаммы вариантов использования. На рис. 2.47 показан пример такой диафаммы для банковской системы.

^ Коберн А. Современные методы описания функциональных требова­ ний к системам.: Пер. с англ. - М.: ЛОРИ, 2002.

180

Глава 2

Клиент	Изменить PIN-код
	Просмотреть	Снять деньги со
	баланс	счета

Сделать платеж

Кредитная система

Рис. 2.47. Пример диаграммы вариантов использования

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

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