Главная » Все файлы » Просмотр файлов из архивов » PDF-файлы » Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование

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

Описание файла

PDF-файл из архива "Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование", который расположен в категории "книги и методические указания". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из седьмого семестра, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .

Просмотр PDF-файла онлайн

Текст 92 страницы из PDF

23.3. Модель реализации как часть проектной моделиМодель реализации – это часть проектной модели.Модель реализации – это часть проектной модели, занимающаяся вопросами реализации. Она определяет, как проектные элементы представляются артефактами и как эти артефакты развертываются на узлах. Артефакты представляют описания реальных сущностей, такихкак исходные файлы, а узлы представляют описания оборудованияили сред выполнения, в которых эти сущности развертываются. Отношения между проектной моделью и моделью реализации показаны нарис. 23.4.Отношение «manifest» между артефактами и компонентами указываетна то, что артефакты являются физическими представлениями компонентов.

Например, компонент может состоять из класса и интерфейса,которые реализованы единственным артефактом: файлом, содержащим исходный код.Проектные компоненты – это логические сущности, которые группируют проектные элементы. А артефакты реализации проецируются на510Глава 23. Рабочий поток реализацииПроектная модельМодель реализации«device»n1«manifest»«component»c1«artifact»a1узел«artifact»a2артефакт«manifest»«device»n2«component»c2«manifest»«artifact»a2Рис. 23.4. Отношения между проектной моделью и моделью реализацииреальные, физические механизмы группировки целевого языка реализации.23.4. Детализация рабочего потока реализацииКак видно из рис. 23.5, в рабочем потоке реализации участвуют архитектор, системный интегратор и разработчик компонентов. В любой изэтих трех ролей могут выступать отдельные аналитики или проектировщики или небольшие команды аналитиков или проектировщиков.Их основное внимание будет направлено на производство моделей развертывания и реализации (часть реализации архитектуры).

Интегрирование системы, реализация классов и тестирование элементов (unittesting) выходят за рамки рассмотрения этой книги – это вопросы реализации, а не анализа и проектирования. (Обратите внимание, что нарис. 23.5 в оригинальный рисунок было внесено изменение: Реализацияподсистемы заменена на более общую Реализацию компонента, посколькуэто более правильно с точки зрения UML 2.)23.5. АртефактыОсновной артефакт рабочего потока реализации с точки зрения ООаналитика или проектировщика – модель реализации. Эта модельсостоит из диаграмм компонентов, показывающих, как артефактыпредставляют компоненты, и диаграммы нового типа – диаграммыразвертывания. Диаграмма развертывания моделирует физическиевычислительные узлы, на которых будут развертываться программ51123.6.

Что мы узналиАрхитекторРеализация архитектурыСистемный интеграторИнтегрирование системыРеализация классаРазработчик компонентовРеализация компонентаПроведение тестирования элементовРис. 23.5. Рабочий поток реализации. Адаптировано с рис. 10.16 [Jacobson 1]с разрешения издательства Addison+Wesleyные артефакты, и отношения между этими узлами. Подробно диаграммы развертывания рассматриваются в главе 24.23.6. Что мы узналиРеализация главным образом касается создания кода.

Однако ОО аналитик или проектировщик может быть привлечен для создания модели реализации. Мы узнали следующее:•Рабочий поток реализации – основной поток фазы Построения.•Реализация заключается в преобразовании проектной модели в исполняемый код.•Моделирование реализации имеет важное значение, если:•предполагается использовать модель при прямой разработке (генерации кода);•осуществляется CBD с целью обеспечения повторного использования кода.•Модель реализации – часть проектной модели.•Артефакты представляют описания реальных сущностей, такихкак исходные файлы:••компоненты представляются артефактами;•артефакты развертываются на узлах.Узлы представляют описания оборудования и сред выполнения.24Развертывание24.1.

План главыВ этой главе рассматриваются деятельность UP Реализация архитектуры(Architectural implementation) и способ создания диаграммы развертывания. Эта диаграмма показывает, как разрабатываемое программноеобеспечение будет развертываться на физическом оборудовании и каксоединяется это оборудование. В разделе 24.5 предлагается простойпример на языке Java.24.2. Деятельность UP: Реализация архитектуры24.3.

Диаграмма развертывания24.4. Узлы24.5. Артефакты24.6. Развертывание24.7. Что мы узналиРис. 24.1. План главы51324.2. Деятельность UP: Реализация архитектуры24.2. Деятельность UP: Реализация архитектурыРеализация архитектуры состоит в определении важных с точки зренияархитектуры компонентов и проецировании их на физическое оборудование.Эта деятельность состоит в определении важных с точки зрения архитектуры компонентов и проецировании их на физическое оборудование. То есть здесь мы занимаемся моделированием физической структуры и распределения системы. Ключевая фраза – «важный с точкизрения архитектуры». В принципе можно было бы полностью смоделировать физическое развертывание системы. Но это имело бы небольшую практическую ценность, потому что подробности развертываниямногих компонентов с точки зрения архитектуры не очень важны.

Исключением является случай, когда код генерируется из модели. Тогда,вероятно, понадобится более подробная модель развертывания, чтобыгенератор кода знал, куда помещать выходные артефакты, и мог создавать соответствующие дескрипторы развертывания и компоноватьфайлы.Деятельность UP Реализация архитектуры представлена на рис. 24.2. В оригинальный рисунок внесены два изменения (измененные артефакты затушеваны):Описание архитектуры[реализацияи развертывание]МодельразвертыванияАрхитекторПроектная модельРеализацияархитектурыАртефакт«subsystem»КомпонентОписание архитектуры[проектированиеи развертывание]УзелРис. 24.2. Деятельность UP Реализация архитектуры.

Адаптированос рис. 10.17 [Jacobson 1] с разрешения издательства Addison+Wesley514Глава 24. Развертывание••Согласно UML 2 подсистема показана как обозначенный стереотипом компонент, а не как пакет, обозначенный стереотипом.Результирующие артефакты и узлы деятельности показаны явно(в оригинальном рисунке они были неявными).С точки зрения ОО аналитика/проектировщика основная деятельность Реализации архитектуры – создание одной или более диаграмм развертывания.

Диаграмма развертывания объединяет компоненты, артефакты и узлы для определения физической архитектуры системы. Далее глава посвящена подробному обсуждению диаграмм этого типа.Другая деятельность – дополнение описания архитектуры важными с точки зрения архитектуры деталями развертывания и реализации.24.3. Диаграмма развертыванияВ UML развертывание – это процесс распределения артефактов по узлам или экземпляров артефактов по экземплярам узлов. Скоро мы перейдем к подробному обсуждению артефактов и узлов.Диаграмма развертывания проецирует программную архитектуру на аппаратную архитектуру.Диаграмма развертывания определяет физическое оборудование, на котором будет выполняться программная система, а также описывает,как программное обеспечение развертывается на это оборудование.Диаграмма развертывания проецирует программную архитектуру,созданную при проектировании, на исполняющую ее физическую архитектуру системы. В распределенных системах она моделирует распределение программного обеспечения по физическим узлам.Существует две формы диаграмм развертывания.Дескрипторная форма диаграммы развертывания – артефакты, развернутые на узлах.1.

Дескрипторная форма (descriptor form) – содержит узлы, отношения между узлами и артефакты. Узел представляет тип оборудования (например, ПК). Аналогично артефакт представляет тип физического программного артефакта, например Java JARфайл.2. Экземплярная форма (instance form) – включает экземпляры узлов,отношения между экземплярами узлов и экземпляры артефактов.Экземпляры узлов представляют конкретную, идентифицируемуючасть оборудования (например, ПК Джима). Экземпляр артефактапредставляет конкретный экземпляр типа программного обеспечения, например определенную копию FrameMaker (www.

adobe.com),использованную для написания этой книги, или конкретный JAR51524.4. Узлыфайл. Если детали конкретных экземпляров неизвестны (или неважны), могут использоваться анонимные экземпляры.Экземплярная форма диаграммы развертывания – экземпляры артефактов развертываются на экземплярах узлов.Хотя диаграмма развертывания рассматривается как деятельность рабочего потока реализации, ее первое приближение часто создается припроектировании как часть процесса выбора окончательной аппаратнойархитектуры. Можно начать с создания дескрипторной формы диаграммы развертывания, ограничившись узлами и их связями, а затемуточнить ее и превратить в одну или более экземплярных форм, представляющих возможные компоновки анонимных экземпляров узлов.Когда станут известны подробности об оборудовании сайта, на котором будет развертываться проект, при необходимости можно создатьэкземплярную форму диаграммы развертывания, показывающуюфактически используемые на этом сайте компьютеры и устройства.Таким образом, создание диаграммы развертывания – это процесс издвух этапов:1.

Свежие статьи
Популярно сейчас