Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Методические аспекты

проектирования

ПО 171

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

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

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

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

интерфейсов.

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

виды связей. К основным типам связей относятся связи ассоциа-

ции, зависимости и обобщения.

Ассоциация (association)

— это семантическая связь между

классами. Ее изображают на диаграмме классов в виде обыкно-

венной линии (рис. 2.39). Ассоциация отражает структурные свя-

зи между объектами различных классов.

Company

Employs

Person

Рис. 2.39.

Ассоциация

Агрегация (aggregation)

представляет собой форму ассоциации

—

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

его частями (компонентными объектами).

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

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

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

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

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

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

ющее:

• между компонентными объектами и их составными объек-

тами установлено отношение

зависимости

по

существова-

нию

(следовательно, удаление составного объекта распрост-

раняется вниз по иерархии отношения, так что связанные

компонентные объекты также удаляются);

• афегация

транзитивна

(если объект С\ является частью

объекта В\, а

51 — частью

У41,

тогда С\ является

частью

У41Л*

• афегация

асимметрична (нерефлексивна)

(если объект В\ яв-

ляется частью объекта

У41,

ТО

объект

^41

не является частью

В\);

• афегация

стационарна

(если объект В\ является частью объ-

екта А\, то он не может быть частью объекта

(/ ^ 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 приняты следующие нотации для обозначения

мощности.

Значения мощности

Мощность

•

0..*

1..*

0..1

1..1

Значение

Много

Нуль

Один

Нуль или больше

Один или больше

Нуль или один

Ровно один

Например, при разработке системы регистрации курсов в

университете можно определить классы Course (учебный курс) и

Student (студент). Между ними установлена связь, означающая

посещение курсов студентами. Если один студент может посе-

щать

от

нуля до

четырех

курсов,

на одном курсе могут занимать-

ся от

10 до 20

студентов,

то на диаграмме классов это можно изоб-

разить следующим образом (рис. 2.43).

Course

0..4 10..20

Student

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

Частным случаем ассоциации является ассоциация-класс

(Association class), которая обладает как свойствами класса, так и

свойствами ассоциации. Ассоциация-класс - это место, где хра-

нятся относящиеся к ассоциации атрибуты и операции. Экземп-

лярами ассоциации-класса являются связи, у которых есть не

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

только ссылки на объекты, но

значения

атрибутов.

Ассоциация-

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

Допустим, что имеются два класса, Student и Course, и воз-

никла необходимость добавить атрибут Grade (оценка).

таком

случае возникает вопрос, в какой класс надо его добавить. Если

поместить его внутри класса Student, то придется вводить

его

для

каждого посещаемого студентом курса, что слишком сильно уве-

личит размер этого класса. Если же поместить его внутри класса

Course, то придется задавать его для каждого посещающего этот

курс студента.

Чтобы решить эту проблему, можно создать ассоциацию-

класс.

этот класс следует поместить атрибут Grade, относящий-

ся к связи между курсом и студентом. Нотация UML для ассоци-

ации-класса представлена на

рис.

2.44.

Course

0..4 i 10..20

Grade

Student

Рис 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

graduate

ParttimeStudent

maxNumCourses

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

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

Общие атрибуты, операции

и/или

связи отображаются на

верхнем уровне иерархии.

Помимо наследуемых, каждый подкласс имеет свои

собственные уникальные атрибуты, операции и связи.

2.5.

УНИФИЦИРОВАННЫЙ ЯЗЫК

МОДЕЛИРОВАНИЯ UML

Унифицированный язык моделирования

UML^

(Unified Modeling

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) по отношению к создавае-

мой системе. Такие диаграммы показывают, какие действующие

лица инициируют варианты использования. Из них также видно,

когда действующее лицо получает информацию от варианта ис-

пользования. Направленная от варианта использования к

действующему лицу стрелка показывает, что вариант использова-

ния предоставляет некоторую информацию, используемую