Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 66
Описание файла
PDF-файл из архива "Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование", который расположен в категории "". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из 7 семестр, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .
Просмотр PDF-файла онлайн
Текст 66 страницы из PDF
В тоже время они переносят ваше внимание с элементов, например линийжизни, непосредственно на поток управления. Поэтому эти диаграммыдолжны использоваться, когда необходимо акцентировать внимание надвижении потока управления через множество взаимодействий.В реализации прецедента взаимодействия описывают поведение, определенное в прецеденте. Таким образом, диаграммы обзора взаимодействий могут использоваться для иллюстрации бизнеспроцессов, охватывающих прецеденты.15.13. Что мы узналиВ данной главе были представлены некоторые дополнительные возможности диаграмм деятельности.
Мы изучили следующее:• Области с прерываемым выполнением действий:• прерываются, когда маркер проходит по прерывающему ребру;15.13. Что мы узнали•••••355когда область прерывается, все ее потоки немедленно прекращаются;• прерывающие ребра отображаются в виде зигзагообразной стрелки или обычной стрелки с пиктограммой зигзага над ней.Контакты исключений:• выводят объект исключения из действия;• обозначаются равносторонним треугольником.Защищенные узлы:• имеют прерывающее ребро, ведущее к обработчику исключения;• немедленно прекращают выполнение при формировании соответствующего типа исключения и поток передается в обработчик исключения;• являются мгновенными (instantaneous).Узлы расширения:• представляют коллекцию объектов, входящую в или выходящую из области расширения;• область выполняется один раз для каждого входного элемента.• Ограничения:• тип выходной коллекции должен соответствовать типу входной коллекции;• типы объектов в коллекции, получаемой на входе, и в выходной коллекции должны быть одинаковыми.• Режимы:• iterative – все элементы входной коллекции обрабатываютсяпоочередно;• parallel – все элементы входной коллекции обрабатываютсяпараллельно;• stream – каждый элемент входной коллекции обрабатываетсяпо мере поступления в узел;• нет режима, применяемого по умолчанию.Отправка сигналов и прием событий.• Сигналы:• информация, передаваемая между объектами асинхронно;• класс, обозначенный стереотипом «signal»;• информация хранится в атрибутах.• Узел действия, отправляющий сигнал:• инициируется, когда маркер есть на всех входных ребрах;• выполняется – объект сигнала создается и отправляется;• затем завершается и предлагает на своих выходных ребрахмаркеры управления.356Глава 15.
Дополнительные аспекты диаграмм деятельности•••••••Узел действия, принимающий событие:• инициируется входящим ребром управления или, если входящих ребер нет, при запуске деятельностивладельца;• ожидает события заданного типа:• выдает маркер, описывающий событие;• продолжает принимать события, пока выполняется деятельностьвладелец;• для событиясигнала выходным маркером является сигнал.Дополнительные обозначения потока объектов:• входной и выходной эффекты показывают воздействие, оказываемое действием на входные и выходные объекты:• эффект записывается в скобках рядом с контактом;• выбор – условие, накладываемое на поток объектов, согласно которому он принимает только те объекты, которые удовлетворяют данному условию:• условие выбора помещается в прикрепленное к потоку объектов примечание, обозначенное стереотипом «selection»;• преобразование – меняет тип объектов потока объектов:• выражение преобразования помещается в прикрепленное к потоку объектов примечание, обозначенное стереотипом «transformation».При групповой рассылке объект отправляется многим получателям:• поток объектов обозначается стереотипом «multicast».При групповом приеме объекты приходят от многих отправителей:• поток объектов обозначается стереотипом «multireceive».Наборы параметров позволяют действию иметь альтернативные наборы входных и выходных контактов:• наборы входных параметров содержат входные контакты;• наборы выходных параметров содержат наборы выходных контактов;• в каждом выполнении действия может использоваться толькоодин набор входных и один набор выходных параметров.Центральный буфер – это объектные узлы, используемые исключительно в качестве буферов:• объектный узел обозначается стереотипом «centralBuffer».Диаграммы обзора взаимодействий отображают поток между взаимодействиями и включениями взаимодействий:• ветвление – узлы принятия решения и слияния;• параллелизм – узлы ветвления и объединения;• итерация – циклы на диаграмме.IVПроектированиеПо договору между издательством «СимволПлюс» и Интернетмагазином «Books.Ru – Книги России» единственный легальный способполучения данного файла с книгой ISBN 5932860944, название«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.5. Деятельность UP:Проектирование архитектуры16.6.
Что мы узналиРис. 16.1. План главысистема для удовлетворения требований пользователя. Цель проектирования – определить в полном объеме, как будет реализовываться этафункциональность. Одним из путей решения этой задачи является одновременное изучение предметной области и области решения. Требования поступают из предметной области, и анализ можно рассматривать как ее исследование с точки зрения заказчиков системы. Проектирование предполагает объединение технических решений (библиотек классов, механизмов сохранения объектов и т.
д.) для созданиямодели системы (проектной модели), которая может быть реализованав действительности.При проектировании принимаются решения по стратегическим вопросам, таким как сохранение и распределение объектов, в соответствии с которыми и создается проектная модель. Руководитель и архитектор проекта должны также разработать политики рассмотрениялюбых тактических вопросов проектирования.36116.3.
Артефакты проектирования – метамодельНачалоУточнениеПостроениеВнедрениеОпределениетребованийАнализПроектированиеРеализацияТестированиеПредварительныеитерацииШаг1Шаг2ШагnШагn+1Шагn+2ШагmШагm+1Рис. 16.2. Процесс производства ПО (UP). Адаптировано с рис. 1.5 [Jacobson 1]с разрешения издательства Addison+Wesley16.3. Артефакты проектирования – метамодельПодсистема – часть физической системы.На рис. 16.3 представлена метамодель проектной модели. Проектнаямодель содержит ряд проектных подсистем (здесь показаны толькодве такие подсистемы).
Подсистемы – это компоненты (глава 19), которые могут включать различные типы элементов модели.«subsystem»c1Проектная модельI«subsystem»c2c3Рис. 16.3. Метамодель проектной модели362Глава 16. Рабочий поток проектированияХотя некоторые ключевые интерфейсы уже могли быть определены вовремя анализа, при проектировании им уделяется намного большевнимания. Это объясняется тем, что в конечном счете именно интерфейсы проектных подсистем объединяют систему в единое целое. Ихроль при проектировании архитектуры велика, поэтому поиску и моделированию ключевых интерфейсов посвящается очень много времени.
В примере на рис. 16.3 видно, что подсистеме c1 необходим интерфейс I, предоставляемый подсистемой c2. Предоставляемый и запрашиваемый интерфейсы соединяют подсистемы, как вилка и розетка.Более подробно интерфейсы обсуждаются в главе 19.Рисунок 16.4 иллюстрирует простой пример отношения «trace» междуаналитической и проектной моделями: проектная модель базируетсяна аналитической и может считаться просто ее улучшенной и уточненной версией.концептуальная модельАналитическая модель«trace»физическая модельПроектная модельРис. 16.4.
Проектная модель – уточненная версия аналитической моделиПроектную модель можно рассматривать как уточнение аналитической модели с добавлением деталей и конкретных технических решений. Проектная модель содержит все то же самое, что и аналитическая, но все артефакты в ней проработаны более основательно и должны включать детали реализации. Например, аналитический класс может быть не более чем эскизом с парой атрибутов и только ключевымиоперациями. Однако проектный класс должен быть совершенно точноопределен – все атрибуты и операции (включая возвращаемые типы исписки параметров) должны быть полностью описаны.Проектные модели образуются:•проектными подсистемами;•проектными классами;•интерфейсами;•реализациями прецедентов – проектными;•диаграммой развертывания.36316.3.
Артефакты проектирования – метамодельОдними из ключевых артефактов проектирования являются интерфейсы. В главе 19 будет показано, что они позволяют разложить систему на подсистемы, которые могут разрабатываться параллельно.При проектировании также создается диаграмма развертывания в первом приближении, которая показывает распределение программнойсистемы на физических вычислительных узлах. Бесспорно, эта диаграмма важна и имеет стратегическое значение. Но поскольку основная работа над диаграммой развертывания осуществляется при реализации, отложим ее обсуждение до главы 24.16.3.1.