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

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

354 Глава 15. Дополнительные аспекты диаграмм деятельности

На диаграммах последовательностей может быть представлено все то же

самое, что и на диаграммах обзора взаимодействий. Может возникнуть

вопрос, зачем нужны последние? Причина в том, что диаграммы обзора

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

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

же время они переносят ваше внимание с элементов, например линий

жизни, непосредственно на поток управления. Поэтому эти диаграммы

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

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

В реализации прецедента взаимодействия описывают поведение, опре

деленное в прецеденте. Таким образом, диаграммы обзора взаимодей

ствий могут использоваться для иллюстрации бизнеспроцессов, охва

тывающих прецеденты.

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

В данной главе были представлены некоторые дополнительные воз

можности диаграмм деятельности. Мы изучили следующее:

• Области с прерываемым выполнением действий:

• прерываются, когда маркер проходит по прерывающему ребру;

GetCourseOption

RemoveCourse FindCourse

:Registrar

:RegistrationManager

uml:Course

addCourse( "UML" )

sd AddCourse

«create»

sd ref

LogOn

[add]

[remove]

[find]

sd ManageCourses lifelines :Registrar, :RegistrationManager, :Course

[exit]

else

встроенное взаимодействие

включение взаимодействия

sd ref

sd ref sd ref

Рис. 15.16. Диаграмма обзора взаимодействий

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

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

ются;

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

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

• Контакты исключений:

• выводят объект исключения из действия;

• обозначаются равносторонним треугольником.

• Защищенные узлы:

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

• немедленно прекращают выполнение при формировании соот

ветствующего типа исключения и поток передается в обработ

чик исключения;

• являются мгновенными (instantaneous).

• Узлы расширения:

• представляют коллекцию объектов, входящую в или выходя

щую из области расширения;

• область выполняется один раз для каждого входного элемента.

• Ограничения:

• тип выходной коллекции должен соответствовать типу вход

ной коллекции;

• типы объектов в коллекции, получаемой на входе, и в выход

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

• Режимы:

• iterative – все элементы входной коллекции обрабатываются

поочередно;

• parallel – все элементы входной коллекции обрабатываются

параллельно;

• stream – каждый элемент входной коллекции обрабатывается

по мере поступления в узел;

• нет режима, применяемого по умолчанию.

• Отправка сигналов и прием событий.

• Сигналы:

• информация, передаваемая между объектами асинхронно;

• класс, обозначенный стереотипом «signal»;

• информация хранится в атрибутах.

• Узел действия, отправляющий сигнал:

• инициируется, когда маркер есть на всех входных ребрах;

• выполняется – объект сигнала создается и отправляется;

• затем завершается и предлагает на своих выходных ребрах

маркеры управления.

356 Глава 15. Дополнительные аспекты диаграмм деятельности

• Узел действия, принимающий событие:

• инициируется входящим ребром управления или, если вхо

дящих ребер нет, при запуске деятельностивладельца;

• ожидает события заданного типа:

• выдает маркер, описывающий событие;

• продолжает принимать события, пока выполняется дея

тельностьвладелец;

• для событиясигнала выходным маркером является сигнал.

• Дополнительные обозначения потока объектов:

• входной и выходной эффекты показывают воздействие, оказы

ваемое действием на входные и выходные объекты:

• эффект записывается в скобках рядом с контактом;

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

торому он принимает только те объекты, которые удовлетворя

ют данному условию:

• условие выбора помещается в прикрепленное к потоку объек

тов примечание, обозначенное стереотипом «selection»;

• преобразование – меняет тип объектов потока объектов:

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

току объектов примечание, обозначенное стереотипом «trans

formation».

• При групповой рассылке объект отправляется многим получателям:

• поток объектов обозначается стереотипом «multicast».

• При групповом приеме объекты приходят от многих отправителей:

• поток объектов обозначается стереотипом «multireceive».

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

боры входных и выходных контактов:

• наборы входных параметров содержат входные контакты;

• наборы выходных параметров содержат наборы выходных кон

тактов;

• в каждом выполнении действия может использоваться только

один набор входных и один набор выходных параметров.

• Центральный буфер – это объектные узлы, используемые исключи

тельно в качестве буферов:

• объектный узел обозначается стереотипом «centralBuffer».

• Диаграммы обзора взаимодействий отображают поток между вза

имодействиями и включениями взаимодействий:

• ветвление – узлы принятия решения и слияния;

• параллелизм – узлы ветвления и объединения;

• итерация – циклы на диаграмме.

Проектирование

По договору между издательством «СимволПлюс» и Интернетмага

зином «Books.Ru – Книги России» единственный легальный способ

получения данного файла с книгой ISBN 5932860944, название

«UML 2 и Унифицированный процесс» – покупка в Интернетмагази

не «Books.Ru – Книги России». Если Вы получили данный файл ка

кимлибо другим образом, Вы нарушили международное законода

тельство и законодательство Российской Федерации об охране автор

ского права. Вам необходимо удалить данный файл, а также сооб

щить издательству «СимволПлюс» (piracy@symbol.ru), где именно

Вы получили данный файл.

Рабочий поток проектирования

16.1. План главы

В этой главе рассматривается рабочий поток проектирования в UP.

Один из самых важных рассматриваемых здесь вопросов: как анали

тическая модель превращается в проектную. Второй важный вопрос:

как должны разрабатываться эти модели – вместе или отдельно? Эта

тема обсуждается в разделе 16.3.2. Остальные разделы главы посвя

щены деталям и артефактам проектирования.

16.2. Рабочий поток проектирования

Большая часть работы по проектированию осуществляется по мере пе

рехода от фазы Уточнение к фазе Построение.

Проектирование – основная деятельность моделирования последней час

ти фазы Уточнение и первой половины фазы Построение. Как видно

из рис. 16.2, основное внимание первых итераций направлено на опреде

ление требований и анализ. По мере завершения анализа фокус модели

рования перемещается на проектирование. В значительной степени ана

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

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

токов – аналитическую модель и проектную модель.

UP рекомендует не разделять функции аналитиков и проектировщиков.

За разработку артефактов (таких как прецедент) – от требований через

анализ и проектирование до реализации – должна отвечать одна коман

да. В UP основное внимание направлено не на конкретную деятель

ность, а на поставляемые артефакты и контрольные точки. Иными сло

вами, главное в UP – это «цели», а не «задачи».

Основной целью анализа было построение логической модели систе

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

360 Глава 16. Рабочий поток проектирования

система для удовлетворения требований пользователя. Цель проекти

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

функциональность. Одним из путей решения этой задачи является од

новременное изучение предметной области и области решения. Требо

вания поступают из предметной области, и анализ можно рассматри

вать как ее исследование с точки зрения заказчиков системы. Проек

тирование предполагает объединение технических решений (библио

тек классов, механизмов сохранения объектов и т. д.) для создания

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

в действительности.

При проектировании принимаются решения по стратегическим во

просам, таким как сохранение и распределение объектов, в соответст

вии с которыми и создается проектная модель. Руководитель и архи

тектор проекта должны также разработать политики рассмотрения

любых тактических вопросов проектирования.

изучаем отношения отображения между артефактами

16.2. Рабочий поток проектирования

16.3. Артефакты проектирования – метамодель

16.3.1. Отношения отображения

между артефактами

16.3.2. Нужно ли поддерживать две модели?

16.4. Детализация рабочего

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

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

16.5. Деятельность UP:

Проектирование архитектуры

изучаем поддержку модели

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

16.3. Артефакты проектирования – метамодель 361

16.3. Артефакты проектирования – метамодель

Подсистема – часть физической системы.

На рис. 16.3 представлена метамодель проектной модели. Проектная

модель содержит ряд проектных подсистем (здесь показаны только

две такие подсистемы). Подсистемы – это компоненты (глава 19), ко

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

Начало Уточнение Построение Внедрение

Определение

требований

Анализ

Проектирование

Реализация

Тестирование

Предварительные

итерации

Шаг

n+1

Шаг

n+2

Шаг

m+1

Рис. 16.2. Процесс производства ПО (UP). Адаптировано с рис. 1.5 [Jacobson 1]

с разрешения издательства Addison+Wesley

Проектная модель

«subsystem»

Рис. 16.3. Метамодель проектной модели

362 Глава 16. Рабочий поток проектирования

Хотя некоторые ключевые интерфейсы уже могли быть определены во

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

внимания. Это объясняется тем, что в конечном счете именно интер

фейсы проектных подсистем объединяют систему в единое целое. Их

роль при проектировании архитектуры велика, поэтому поиску и мо

делированию ключевых интерфейсов посвящается очень много време

ни. В примере на рис. 16.3 видно, что подсистеме c1 необходим интер

фейс I, предоставляемый подсистемой c2. Предоставляемый и запра

шиваемый интерфейсы соединяют подсистемы, как вилка и розетка.

Более подробно интерфейсы обсуждаются в главе 19.

Рисунок 16.4 иллюстрирует простой пример отношения «trace» между

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

на аналитической и может считаться просто ее улучшенной и уточнен

ной версией.

Проектную модель можно рассматривать как уточнение аналитиче

ской модели с добавлением деталей и конкретных технических реше

ний. Проектная модель содержит все то же самое, что и аналитиче

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

ны включать детали реализации. Например, аналитический класс мо

жет быть не более чем эскизом с парой атрибутов и только ключевыми

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

определен – все атрибуты и операции (включая возвращаемые типы и

списки параметров) должны быть полностью описаны.

Проектные модели образуются:

• проектными подсистемами;

• проектными классами;

• интерфейсами;

• реализациями прецедентов – проектными;

• диаграммой развертывания.

Аналитическая модель

Проектная модель

концептуальная модель

физическая модель

«trace»

Рис. 16.4. Проектная модель – уточненная версия аналитической модели

16.3. Артефакты проектирования – метамодель 363

Одними из ключевых артефактов проектирования являются интер

фейсы. В главе 19 будет показано, что они позволяют разложить систе

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

При проектировании также создается диаграмма развертывания в пер

вом приближении, которая показывает распределение программной

системы на физических вычислительных узлах. Бесспорно, эта диа

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

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

зации, отложим ее обсуждение до главы 24.

16.3.1. Отношения отображения между артефактами

На рис. 16.5 показаны отношения между ключевыми артефактами

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

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

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

бражаться («trace») в одну проектную подсистему, но так происходит не

всегда. В силу архитектурных и технических причин один пакет ана

лиза может быть разбит на несколько подсистем. При компонентно

ориентированной разработке проектная подсистема представляет один

крупномодульный компонент. В этом случае в зависимости от требуе

мой детализации компонентов может оказаться, что один пакет анали

за фактически раскладывается на несколько подсистем.

Класс анализа может быть превращен в один или более интерфейсов

или проектных классов. Причина этого в том, что классы анализа яв

Пакет анализа

Класс анализа

Реализация прецедента –

аналитическая

Проектная

подсистема

Проектный класс

«interface»

Интерфейс

Реализация прецедента –

проектная

0..* 0..*

0..*

«trace»

Рис. 16.5. Отношения между ключевыми артефактами анализа

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