UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
Рис. 15.13. Групповая рассылка и групповой прием 15.10. Наборы параметров 351 2. Получить UserName и Passphrase – выдает объекты UserName и Passphrase (идентификационная фраза). 3. Получить Card и PIN – выдает объекты Card и PIN. Как видите, каждое из этих действий выдает разный набор объектов. Одним из решений этой проблемы могло бы быть разделение аутентифи кации на три действия для каждого набора объектов, например Authenti cateUserNameAndPassword, AuthenticateUserNameAndPassphrase и Authenticate CardAndPIN. Это разумное решение, но оно имеет несколько недостатков. • Оно делает диаграмму деятельности слишком большой. • Аутентификация распределена на три действия, а не локализована в одном. Применяя наборы параметров, можно создать единственное действие Аутентифицировать, способное обрабатывать разные наборы входных па раметров. На рис. 15.14 представлено действие Аутентифицировать с тремя набора ми входных и двумя наборами выходных параметров. Наборы вход ных параметров: • UserName AND Password; • UserName AND Passphrase; • Card AND PIN. При каждом выполнении этого действия может использоваться толь ко один из этих наборов входных параметров. Поэтому между ними установлено отношение исключающее ИЛИ (XOR). Обратите внимание, что в наборах {UserName, Password} и {UserName, Pass phrase} есть общий контакт UserName. Как показано на рис. 15.14, это можно обозначить путем наложения двух наборов параметров таким об разом, чтобы общие контакты находились в области пересечения. Од Аутентифицировать UserName Password Passphrase PIN Card User [!Аутентифицирован] Получить UserName и Passphrase Получить UserName и Password Получить Card и PIN Выбрать метод аутентификации [password] [passphrase] [card] User Аутентифицировать User входное условие: ( UserName AND Password ) XOR ( UserName AND Passphrase ) XOR ( Card AND PIN ) выходное условие: ( User [Аутентифицирован] ) XOR ( User [!Аутентифицирован] ) набор параметров User [Аутентифицирован] Рис. 15.14. Использование наборов параметров 352 Глава 15. Дополнительные аспекты диаграмм деятельности нако в этом случае очень легко запутаться, поэтому можно использо вать два отдельных контакта UserName, по одному для каждого набора входных параметров. Мы предпочитаем второй вариант решения. На приведенной диаграмме (рис. 15.14) проиллюстрирован синтаксис на ложения контактов на тот случай, если вы решите их использовать. Действие Аутентифицировать имеет следующие наборы выходных пара метров, каждый из которых содержит всего один контакт: • User[Аутентифицирован]; • User[!Аутентифицирован]. Опять же при каждом выполнении деятельности будет использоваться только один из этих наборов выходных параметров. 15.11. Узел «centralBuffer» Центральный буфер – это объектный узел, используемый исключитель но в качестве буфера. Как упоминалось в разделе 14.9.1, все объектные узлы обладают спо собностью буферизации. Центральный буфер – это объектный узел, используемый исключи тельно как буфер между входными и выходными потоками объектов. Он позволяет объединять несколько входных потоков объектов и рас пределять объекты между несколькими выходными потоками объек тов. Когда объектный узел используется как центральный буфер, он должен быть обозначен стереотипом «centralBuffer». На рис. 15.15 показан простой пример, в котором центральный буфер используется для накопления различных типов объектов Order, непре рывно поступающих по нескольким каналам продаж. Объекты Order находятся в буфере в ожидании принимающего их действия Обработать Order. В центральном буфере Order могут сохраняться объекты типа Order или его подклассов: WebOrder (веб заказ), PhoneOrder (заказ по телефону) и PostOrder (заказ по почте). Принять веб Order Принять Order по телефону Принять Order по почте «centralBuffer» Order [Новый] WebOrder [Новый] PhoneOrder [Новый] PostOrder [Новый] Обработать объекты Order Order [Обработанный] Обработать Order Рис. 15.15. Центральный буфер для хранения объектов 15.12. Диаграммы обзора взаимодействий 353 15.12. Диаграммы обзора взаимодействий Диаграммы обзора взаимодействий – особая форма диаграммы деятель ности. Они показывают взаимодействия и включения взаимодействий (interaction occurrences) и используются для моделирования высоко уровневого потока управления между взаимодействиями. Взаимодей ствия и диаграммы взаимодействий подробно обсуждаются в главе 12. Одно особенно мощное применение диаграмм обзора взаимодействий – иллюстрация потока управления между прецедентами. Если каждый прецедент представить как взаимодействие, синтаксис диаграммы дея тельности можно использовать для отображения движения потока управления между ними. Диаграммы обзора взаимодействий – это диаграммы деятельности, пред ставляющие взаимодействия и включения взаимодействий. На рис. 15.16 представлена диаграмма обзора взаимодействий Manage Courses (организация курсов), которая показывает поток между низко уровневыми взаимодействиями LogOn (войти), GetCourseOption (полу чить варианты курсов), FindCourse (найти курс), RemoveCourse (удалить курс) и AddCourse (добавить курс). Каждое из этих взаимодействий представляет прецедент. Таким образом, диаграмма обзора взаимо действий фиксирует поток управления между прецедентами. Обратите внимание, что линии жизни, принимающие участие во взаи модействии, могут быть перечислены после ключевого слова lifelines (линии жизни) в заголовке диаграммы. Такое документирование мо жет быть полезным, поскольку часто линии жизни скрыты внутри включений взаимодействий. Синтаксис диаграмм обзора взаимодействий аналогичен синтаксису диаграмм деятельности, за исключением того, что здесь отображаются встроенные взаимодействия и включения взаимодействий, а не дея тельности и объектные узлы. Можно показать ветвление, параллель ность и цикличность, как описано в табл. 15.1. Данная таблица также предоставляет обзор различий между синтаксисом диаграммы после довательностей и диаграммы обзора взаимодействий. Таблица 15.1 Действие Диаграммы последовательностей Диаграмма обзора взаимодействий Ветвление Комбинированные фрагмен ты alt и opt (раздел 12.10.1) Узлы принятия решения и слия ния (раздел 14.8.2) Параллель ность Комбинированный фраг мент par (раздел 20.5) Узлы ветвления и объединения (раздел 14.8.3) Итерация Комбинированный фраг мент loop (раздел 12.11.1) Циклы на диаграмме 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». • Диаграммы обзора взаимодействий отображают поток между вза имодействиями и включениями взаимодействий: • ветвление – узлы принятия решения и слияния; • параллелизм – узлы ветвления и объединения; • итерация – циклы на диаграмме. IV Проектирование По договору между издательством «Символ Плюс» и Интернет мага зином «Books.Ru – Книги России» единственный легальный способ получения данного файла с книгой ISBN 5 93286 094 4, название «UML 2 и Унифицированный процесс» – покупка в Интернет магази не «Books.Ru – Книги России». Если Вы получили данный файл ка ким либо другим образом, Вы нарушили международное законода тельство и законодательство Российской Федерации об охране автор ского права. Вам необходимо удалить данный файл, а также сооб щить издательству «Символ Плюс» (piracy@symbol.ru), где именно Вы получили данный файл. 16 Рабочий поток проектирования 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), ко торые могут включать различные типы элементов модели. Начало Уточнение Построение Внедрение Определение требований Анализ Проектирование Реализация Тестирование Предварительные итерации Шаг 1 Шаг 2 Шаг n Шаг n+1 Шаг n+2 Шаг m Шаг m+1 Рис. 16.2. Процесс производства ПО (UP). Адаптировано с рис. 1.5 [Jacobson 1] с разрешения издательства Addison Wesley c3 I Проектная модель «subsystem» c1 «subsystem» c2 Рис. 16.3. Метамодель проектной модели 362 Глава 16. Рабочий поток проектирования Хотя некоторые ключевые интерфейсы уже могли быть определены во время анализа, при проектировании им уделяется намного больше внимания. Это объясняется тем, что в конечном счете именно интер фейсы проектных подсистем объединяют систему в единое целое. Их роль при проектировании архитектуры велика, поэтому поиску и мо делированию ключевых интерфейсов посвящается очень много време ни. В примере на рис. 16.3 видно, что подсистеме c1 необходим интер фейс I, предоставляемый подсистемой c2. Предоставляемый и запра шиваемый интерфейсы соединяют подсистемы, как вилка и розетка. Более подробно интерфейсы обсуждаются в главе 19. Рисунок 16.4 иллюстрирует простой пример отношения «trace» между аналитической и проектной моделями: проектная модель базируется на аналитической и может считаться просто ее улучшенной и уточнен ной версией. Проектную модель можно рассматривать как уточнение аналитиче ской модели с добавлением деталей и конкретных технических реше ний. Проектная модель содержит все то же самое, что и аналитиче ская, но все артефакты в ней проработаны более основательно и долж ны включать детали реализации. Например, аналитический класс мо жет быть не более чем эскизом с парой атрибутов и только ключевыми операциями. Однако проектный класс должен быть совершенно точно определен – все атрибуты и операции (включая возвращаемые типы и списки параметров) должны быть полностью описаны. Проектные модели образуются: |