Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование

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

194 Глава 8. Выявление классов анализа

8.4.4. Выявление классов из других источников

Помимо анализа существительное/глагол, CRCанализа и стереотипов

RUP существует множество других потенциальных источников клас

сов, которые необходимо учитывать. Мы ищем четкие абстракции, ко

торые проецируются на реальные сущности предметной области. По

добным же образом можно найти классы и в реальном мире.

• Все физические объекты, такие как самолет, люди и гостиницы,

могут обозначать класс.

• Документооборот – еще один богатый источник классов. Такие ве

щи, как счета, заказы и сберегательные книжки, могут указывать

на возможные классы. Однако при рассмотрении системы докумен

тооборота необходимо быть очень осторожными. Во многих компа

ниях она развивалась в течение многих лет с сохранением поддерж

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

система, возможно, пытается заменить! Самая неприятная работа

для ОО аналитика/проектировщика – автоматизация устаревшей

бумажной системы.

• Известные внешние интерфейсы, такие как экраны, клавиатуры,

периферийные устройства и другие системы, также могут быть ис

точником предполагаемых классов, особенно в случае встроенных

систем.

• Концептуальные сущности – это сущности, важные для функцио

нирования предприятия, но не являющиеся конкретными сущно

стями. Примером такой сущности может быть LoyaltyProgram (про

грамма лояльности), например призовая карта. Конечно, сама про

грамма не является конкретной сущностью (ее нельзя пощупать!),

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

класс.

8.4.4.1. Базовые шаблоны

Базовые шаблоны могут предоставить готовые компоненты аналитиче

ской модели.

В нашей книге «Enterprise Patterns and MDA» [Arlow 1] описывалось по

нятие, названное нами базовые шаблоны (archetype patterns). Это шаб

лоны бизнеспонятий, настолько распространенных в бизнессистемах,

что мы решили считать их понастоящему базовыми. То есть их можно

смоделировать один раз и затем использовать повторно, а не моделиро

вать вновь и вновь в каждой новой бизнессистеме. Основная мысль

книги состоит в том, что шаблоны можно использовать в исходном или

измененном виде, создавая аналитическую модель из компонентов мо+

дели (model components). Эта техника называется компонентно+ориен+

тированным моделированием (component+based modeling).

8.5. Создание аналитической модели в первом приближении 195

Мы предоставляем следующие базовые шаблоны:

• Customer Relationship Management;

• Inventory;

• Money;

• Order;

• Party;

• Party relationship;

• Product;

• Quantity;

• Rule.

Каждый шаблон разработан очень подробно и отличается содержа

тельностью. Их использование позволит сохранить массу человеко

дней или даже человекомесяцев работы. Если шаблон не вполне под

ходит для моделируемой системы, он может служить источником по

лезных идей для написания собственных классов анализа. Это лучше,

чем начинать с чистого листа.

Использование шаблонов – это, наверное, самый эффективный способ

выявления классов моделей: просто взять их с полки!

8.5. Создание аналитической модели

в первом приближении

Чтобы создать аналитическую модель в первом приближении, необхо

димо в инструментальном средстве моделирования объединить в одну

UMLмодель результаты анализа существительное/глагол, CRCана

лиза, стереотипов RUP и изучения других источников классов (осо

бенно базовых шаблонов). Объединение осуществляется следующим

образом:

1. Сравниваются все источники классов.

2. Классы анализа, атрибуты и обязанности, полученные из разных

источников, объединяются и вводятся в инструментальное средст

во моделирования.

2.1. С помощью глоссария проекта выявляются синонимы и омо

нимы.

2.2. Находятся различия в результатах трех методов. Отличия ука

зывают на неопределенности или моменты, требующие более

тщательной проработки. Обработайте эти различия сейчас или

оставьте это на будущее.

3. Участники (или линии между клеящимися записками на доске)

представляют отношения между классами. Моделирование отно

шений будет обсуждаться в главе 9.

196 Глава 8. Выявление классов анализа

4. Корректируются имена классов, атрибутов и обязанностей согласно

какомулибо стандартному соглашению о присваивании имен, при

нятому в компании, или в соответствии с простыми соглашениями,

изложенными в главе 7.

Результатом этой деятельности является набор классов анализа, в ко

тором у каждого класса может быть несколько ключевых атрибутов

и должно быть от трех до пяти обязанностей. Это аналитическая мо

дель в первом приближении.

8.6. Что мы узнали

В этой главе мы описали, что такое классы анализа, и рассмотрели ме

тоды поиска таких классов с помощью анализа существительное/гла

гол, мозгового штурма CRC, применения стереотипов RUP и проверки

других источников классов.

Вы узнали следующее:

• В результате UPдеятельности Анализ прецедентов получаем классы

анализа и реализации прецедентов.

• Классы анализа представляют четкую, точно определенную абст

ракцию предметной области.

• Предметная область – это область, в которой возникла необходи

мость в программной системе.

• Классы анализа должны точно и четко проецироваться в реаль

ное бизнеспонятие.

• Бизнеспонятия часто нуждаются в уточнении во время анализа.

• Аналитическая модель содержит только классы анализа – любые

классы, вытекающие из соображений проектирования (области ре

шения), должны быть исключены.

• Классы анализа включают:

• высокоуровневый набор предполагаемых атрибутов;

• высокоуровневый набор операций.

• Каковы признаки хорошего класса анализа?

• Имя класса отражает его назначение.

• Класс является четкой абстракцией, которая моделирует один

конкретный элемент предметной области.

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

предметной области.

• У класса анализа небольшой, определенный набор обязанностей:

• обязанность – это контракт или обязательство, которое класс

имеет перед своими клиентами;

8.6. Что мы узнали 197

• обязанность – семантически связный набор операций;

• класс должен иметь не более трехпяти обязанностей.

• Класс имеет высокую внутреннюю связность (cohesion) – все

свойства класса служат реализации его назначения.

• Класс имеет низкую связанность с другими классами (coupling) –

для реализации своего назначения класс должен взаимодейство

вать с небольшим числом классов.

• Каковы признаки плохого класса анализа?

• Он является функтоидом – классом с одной операцией.

• Он является всемогущим классом – классом, делающим все.

Классам, в именах которых присутствуют слова «system» или

«controller», следует уделять больше внимания.

• У него глубокое дерево наследования – в реальности деревья на

следования, как правило, небольшие.

• У него низкая внутренняя связность.

• У него высокая связанность с другими классами.

• Анализ существительное/глагол:

• Ищите существительные или именные группы; это потенциаль

ные классы или атрибуты.

• Ищите глаголы или глагольные группы; это потенциальные обя

занности или операции.

• Процедура: собрать относящуюся к делу информацию и проана

лизировать ее.

• CRCанализ – мощная и одновременно забавная техника мозгового

штурма.

• Важные моменты предметной области записываются на клея

щихся записках (стикерах).

• Каждая записка разделена на три ячейки:

• класс – содержит имя класса;

• обязанности – содержит список обязанностей этого класса;

• участники – содержит список других классов, с которыми

взаимодействует данный класс.

• Процедура CRCанализа – мозговой штурм:

• попросите членов команды назвать «сущности», которые дей

ствуют в их области деятельности, и запишите их на клея

щихся записках;

• попросите команду обозначить обязанности сущностей и за

пишите их в ячейке обязанностей на записке;

• попросите команду определить классы, которые могли бы ра

ботать совместно, и запишите их в ячейке участников каждой

198 Глава 8. Выявление классов анализа

записки; если стикеры приклеены на доску, нарисуйте между

ними линии.

• Стереотипы RUP могут использоваться с целью сосредоточить ана

лиз на трех типах классов:

• «boundary» – класс, играющий роль посредника во взаимодейст

вии системы и ее окружения;

• «control» – класс, инкапсулирующий характерное поведение пре

цедента;

• «entity» – класс, используемый для моделирования постоянной

информации о чемто.

• Учтите другие источники классов:

• физические объекты, документооборот, интерфейсы с внешним

миром и концептуальные сущности;

• базовые шаблоны – ориентированное на компоненты моделиро

вание.

• Создание аналитической модели в первом приближении:

• сравниваются результаты анализа существительное/глагол,

CRCанализа, применения стереотипов RUP и проверки других

источников классов;

• разрешаются синонимы и омонимы;

• отличия результатов разных техник указывают на области неоп

ределенности;

• результаты объединяются в аналитическую модель в первом

приближении.

Отношения

9.1. План главы

В этой главе рассматриваются отношения между объектами и между

классами. Чтобы понять, что такое отношение, прочтите раздел 9.2.

Далее обсуждаются: в разделе 9.3 – связи (отношения между объекта

ми), в разделе 9.4 – ассоциации (отношения между классами) и в раз

деле 9.5 – зависимости (универсальные отношения).

9.2. Что такое отношение?

Отношения – это семантические (значимые) связи между элементами

модели. Отношения – это способ объединения сущностей в UML. Нам

уже встречались некоторые типы отношений:

• между актерами и прецедентами (ассоциация);

• между прецедентами и прецедентами (обобщение, «include», «ex

tend»);

• между актерами и актерами (обобщение).

UMLотношения объединяют сущности.

В этой главе рассматриваются взаимоотношения между объектами

и между классами. Начнем со связей и ассоциаций, а в главе 10 обсу

дим обобщение и наследование.

Чтобы создать функциональную ОО систему, нельзя позволять объек

там оставаться в гордом одиночестве. Их необходимо объединять, что

бы они могли выполнять полезную для пользователей системы работу.

Соединения между объектами называются связями. Когда объекты

работают совместно, говорят, что они взаимодействуют.

200 Глава 9. Отношения

9.5.2.4. «derive»

9.2. Что такое отношение?

9.6. Что мы узнали

9.3. Что такое связь? 9.4. Что такое ассоциация? 9.5. Что такое зависимость?

9.3.1. Диаграммы

объектов

9.3.2. Пути

9.4.1. Синтаксис ассоциации

9.4.3. Возможность

навигации

9.4.2. Кратность

9.4.5. КлассыQ

ассоциации

9.4.2.1. Рефлексивные

ассоциации

9.4.4. Ассоциации

и атрибуты

9.4.2.2. Иерархии и сети

9.4.6. Квалифицированные

ассоциации

9.5.1. Зависимости

использования

9.5.2. Зависимости

абстракции

9.5.3. Зависимости

доступа

9.5.1.1. «use» 9.5.2.1. «trace» 9.5.3.1. «access»

9.5.1.2. «call» 9.5.2.2. «substitute» 9.5.3.2. «import»

9.5.1.3. «parameter» 9.5.2.3. «refine» 9.5.3.3. «permit»

9.5.1.4. «send»

9.5.1.5. «instantiate»

Рис. 9.1. План главы

9.3. Что такое связь? 201

Если между объектами установлена связь, то и между их классами

должно существовать какоето семантическое соединение. В этом есть

здравый смысл: чтобы объекты могли общаться друг с другом напря

мую, классы этих объектов должны какимто образом знать друг

о друге. Соединения между классами называются ассоциациями. Свя

зи между объектами на самом деле являются экземплярами ассоциа

ций между их классами.

9.3. Что такое связь?

Чтобы создать объектноориентированную программу, объекты долж

ны общаться друг с другом. В сущности, исполняющаяся ОО програм

ма – это гармоничное сообщество взаимодействующих объектов.

Объекты обмениваются сообщениями через соединения, называемые

связями.

Связь – это семантическое соединение между двумя объектами, кото

рое обеспечивает им возможность обмена сообщениями. Исполняю

щаяся ОО система содержит множество объектов, которые появляют

ся и исчезают, и множество связей (которые тоже появляются и исче

зают), объединяющих эти объекты. Через эти связи происходит обмен

сообщениями между объектами. Получив сообщение, объект иниции

рует соответствующую операцию.

Разные ОО языки программирования реализуют связи поразному. Java

реализует связи как объектные ссылки; C++ может реализовывать

связи как указатели, как ссылки или путем прямого включения одно

го объекта в другой.

Каким бы ни был подход, минимальное требование для установления

связи: по крайней мере один из объектов должен иметь объектную

ссылку на другой.

9.3.1. Диаграммы объектов

Диаграмма объектов – это диаграмма, представляющая объекты и их

отношения в некоторый момент времени. Это как снимок части испол

няющейся ОО системы в определенный момент, показывающий объ

екты и связи между ними.

Соединенные связями объекты могут исполнять различные роли по от

ношению друг к другу. На рис. 9.2 можно видеть, что объект ila играет

роль chairperson (председатель) в его связи с объектом bookClub (книж

ный клуб). На диаграмме объектов это отображается путем размеще

ния имени роли на соответствующем конце связи. Имена ролей могут

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

объект bookClub всегда играет роль «клуба», поэтому нет особого смысла

202 Глава 9. Отношения

показывать это на диаграмме. Это никак не улучшило бы понимания

отношений объектов.

На рис. 9.2 показано, что в определенный момент времени объект ila

играет роль chairperson. Однако важно понимать, что связи – это дина+

мические соединения (dynamic connections) объектов. Иначе говоря,

они могут быть непостоянными во времени. В данном примере роль

chairperson может передаваться объектам erica или naomi, и можно было

бы без труда создать диаграмму объектов, отображающую эту новую

ситуацию.

Обычно одна связь соединяет только два объекта, как показано на

рис. 9.2. Однако UML допускает соединение нескольких объектов од

ной связью. Такую связь называют nарной. Она изображается в виде

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

Многие разработчики моделей (и мы в том числе) считают такую идио

му ненужной. Она редко используется и не всегда поддерживается

средствами моделирования UML. Поэтому не будем ее рассматривать.

Диаграммы объектов – это моментальные снимки работающей ОО сис

темы.

На рис. 9.2 можно найти три связи между четырьмя объектами:

• связь между bookClub и ila;

• связь между bookClub и erica;

• связь между bookClub и naomi.

Для задания направления движения сообщений по связи используется

возможность навигации.

На рис. 9.2 связи двунаправленные, поэтому можно сказать, что связь

соединяет ila с bookClub или что связь соединяет bookClub с ila.

chairperson

secretary

member

BookClub

naomi:Person

erica:Person

ila:Person

bookClub:Club

имя роли

двунаправленная связь

Рис. 9.2. Двунаправленные связи между объектами

9.3. Что такое связь? 203

Если связь однонаправленная, для задания направления движения со

общений по связи используется возможность навигации.

Если навигация возможна, на конце связи помещают стрелку; в про

тивном случае связь завершают крестом (навигация не допускается).

Возможность навигации немного похожа на улицу с односторонним

движением. Сообщения могут проходить только в том направлении,

куда указывает стрелка.

Спецификация UML 2 допускает три разных способа отображения воз

можности навигации, которые подробно обсуждаются в разделе 9.4.3.

В данной книге используется самое распространенное обозначение:

• все кресты опускаются;

• двунаправленные ассоциации изображаются без стрелок;

• однонаправленные ассоциации изображаются с одной стрелкой.

Единственным настоящим недостатком этого способа отображения яв

ляется отсутствие возможности показать, что решение о навигации

еще не принято, потому что отсутствие символов навигации подразу

мевает, что связь «не допускает навигации».

Например, на рис. 9.3 показано, что связь между :PersonDetails

и :Address

однонаправленная. Это значит, что у объекта :PersonDetails есть объект

ная ссылка на объект :Address

, но не наоборот. Сообщения могут пере

сылаться только от :PersonDetails

к :Address.

9.3.2. Пути

Обозначения UML, такие как пиктограмма объекта, пиктограмма пре

цедента и пиктограмма класса, соединяются с другими обозначения

ми путями. Путь – это «связанные последовательности графических

сегментов» (другими словами, линия!), объединяющие два или более

обозначений. Существует три стиля представления путей:

• прямоугольный – путь состоит из ряда горизонтальных и верти

кальных сегментов;

• наклонный – путь является последовательностью одной или более

наклонных линий;

• кривой – путь является кривой линией.

Какой стиль пути использовать, вопрос личных предпочтений. Стили

могут даже смешиваться на одной диаграмме, если это делает ее более

:Address:PersonDetails

исходный объект целевой объект

однонаправленная связь

Рис. 9.3. Однонаправленная связь между объектами