UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
22.5.2. Глубокая предыстория Глубокая предыстория запоминает последнее подсостояние того же или более низкого уровня, чем псевдосостояние глубокой предыстории. Browsing goT oBasket goT oCatalog DisplayingItem DisplayingIndex DisplayingBasket CheckingOut goT oCheckout return Alphabetical ByCategory goT oCatalog goT oCheckout BrowseCatalog browseIndex exit alphabetical byCategory selectProduct goT oIndex псевдосостояние неглубокой предыстории H Рис. 22.12. Неглубокая предыстория 22.6. Что мы узнали 503 С помощью глубокой предыстории можно запоминать не только ак тивное подсостояние того же уровня, что и псевдосостояние предысто рии, но и подподсостояния любого уровня вложенности. На рис. 22.13 автомат был модифицирован для использования глубо кой предыстории. В данном случае мы будем не только возвращаться в состояние DisplayingIndex или DisplayingItem, но и восстанавливать тип индекса ( Alphabetical или ByCategory). Это можно было бы смоделировать и без применения глубокой предыстории, но все было бы намного сложнее. Как и неглубокая, глубокая предыстория может иметь множество вхо дящих переходов, но только один исходящий переход. Исходящий пе реход срабатывает при первом входе в суперсостояние, когда нет по следнего подсостояния, которое было запомнено. 22.6. Что мы узнали UML предоставляет богатый синтаксис конечных автоматов, который позволяет представлять сложное поведение в виде лаконичных авто матов. Мы узнали следующее: • Составные состояния могут содержать один или более вложенных подавтоматов – подсостояния наследуют все переходы своего супер состояния. Browsing goT oBasket goT oCatalog DisplayingItem DisplayingIndex DisplayingBasket CheckingOut goT oCheckout return Alphabetical ByCategory псевдосостояние глубокой предыстории H* goT oCatalog goT oCheckout BrowseCatalog browseIndex exit alphabetical byCategory selectProduct goT oIndex Рис. 22.13. Глубокая предыстория 504 Глава 22. Дополнительные аспекты конечных автоматов • Каждый подавтомат существует в собственной области. • Конечное псевдосостояние действует только в рамках области. • Терминальное псевдосостояние используется для завершения всех областей. • Последовательное составное состояние содержит только один вло женный подавтомат. • Параллельное составное состояние содержит два или более вложен ных подавтоматов, которые выполняются параллельно. • При входе в состояние происходит ветвление, и подавтоматы на чинают свое параллельное выполнение. • Если у всех подавтоматов есть состояние остановки, суперсо стояние нельзя покинуть, пока не будут завершены все подавто маты; это объединение. • Если подавтоматы осуществляют явные переходы во внешние состояния, можно покинуть суперсостояние без объединения. • Состояние подавтомата – это ссылка на другой конечный автомат: • упрощает сложные конечные автоматы; • обеспечивает повторное использование конечных автоматов. • Взаимодействие подавтоматов: • значения атрибутов – один подавтомат задает значение атрибу та, а другие подавтоматы проверяют это значение. • Предыстория позволяет суперсостоянию запоминать последнее подсостояние перед исходящим переходом. • Неглубокая предыстория позволяет суперсостоянию перед исхо дящим переходом запоминать последнее подсостояние того же уровня, что и само псевдосостояние неглубокой предыстории: • при возвращении в псевдосостояние неглубокой предыстории переход направляется в последнее подсостояние, которое бы ло запомнено; • при первом входе (последнее подсостояние отсутствует) сра батывает единственный выходной переход псевдосостояния неглубокой предыстории. • Глубокая предыстория позволяет суперсостоянию перед исходя щим переходом запоминать последнее подсостояние любого уровня: • при возвращении в псевдосостояние глубокой предыстории переход направляется в последнее подсостояние, которое бы ло запомнено; • при первом входе (последнее подсостояние отсутствует) сра батывает единственный выходной переход псевдосостояния глубокой предыстории. V Реализация 23 Рабочий поток реализации 23.1. План главы В рабочем потоке реализации для ОО аналитика или проектировщика работы очень мало, поэтому эта часть книги самая маленькая. Тем не менее здесь есть некоторые вопросы, требующие внимательного рас смотрения. Хотя основная деятельность потока реализации – произ водство кода, здесь по прежнему присутствуют некоторые элементы UML моделирования. 23.2. Рабочий поток реализации Рабочий поток реализации всерьез начинается в фазе Уточнение и яв ляется основным потоком фазы Построение (рис. 23.2). 23.6. Что мы узнали 23.2. Рабочий поток реализации 23.3. Артефакты реализации – метамодель 23.4. Детализация рабочего потока реализации 23.5. Артефакты Рис. 23.1. План главы 508 Глава 23. Рабочий поток реализации Поток реализации – основной поток фазы Построение. Реализация состоит в преобразовании проектной модели в исполняе мый код. С точки зрения аналитика или проектировщика цель реали зации – производство модели реализации, если в этом возникает необ ходимость. Эта модель включает распределение (преимущественно так тическое) проектных классов по компонентам. Как это делается, в боль шой степени зависит от целевого языка программирования. Реализация состоит в преобразовании проектной модели в исполняе мый код. Основное внимание в процессе реализации направлено на производст во исполняемого кода. Создание модели реализации может быть побоч ным продуктом этого процесса, но не явной деятельностью моделиро вания. На самом деле многие инструментальные средства моделирова ния позволяют создавать модель реализации из исходного кода путем обратного проектирования. Это предоставляет программистам возмож ность эффективно выполнять моделирование реализации. Однако есть два случая, когда очень важно, чтобы опытные аналитики или проектировщики провели явное моделирование реализации. • Если предполагается генерировать код прямо из модели, понадобит ся определить такие детали, как исходные файлы и компоненты (ес ли не используются применяемые по умолчанию значения у средст ва моделирования). Начало Уточнение Построение Внедрение Определение требований Анализ Проектирование Реализация Тестирование Предварительные итерации Шаг 1 Шаг 2 Шаг n Шаг n+1 Шаг n+2 Шаг m Шаг m+1 Рис. 23.2. Рабочий поток реализации. Адаптировано с рис. 1.5 [Jacobson 1] с разрешения издательства Addison Wesley 23.3. Артефакты реализации – метамодель 509 • Если осуществляется компонентно ориентированная разработка (CBD) с целью повторного использования компонентов, распределе ние проектных классов и интерфейсов по компонентам становится стратегически важным вопросом. Вероятно, вы захотите сначала смоделировать эту часть проекта, а не перекладывать все на плечи одного программиста. В этой главе рассматривается, что включает в себя процесс создания модели реализации. 23.3. Артефакты реализации – метамодель Отношения между моделью реализации и проектной моделью очень просты. Фактически модель реализации – это представление проект ной модели с точки зрения реализации. Иными словами, модель реа лизации – это часть проектной модели, что и отражено на рис. 23.3. Модель реализации – это часть проектной модели. Модель реализации – это часть проектной модели, занимающаяся во просами реализации. Она определяет, как проектные элементы пред ставляются артефактами и как эти артефакты развертываются на уз лах. Артефакты представляют описания реальных сущностей, таких как исходные файлы, а узлы представляют описания оборудования или сред выполнения, в которых эти сущности развертываются. Отно шения между проектной моделью и моделью реализации показаны на рис. 23.4. Отношение « manifest» между артефактами и компонентами указывает на то, что артефакты являются физическими представлениями компо нентов. Например, компонент может состоять из класса и интерфейса, которые реализованы единственным артефактом: файлом, содержа щим исходный код. Проектные компоненты – это логические сущности, которые группи руют проектные элементы. А артефакты реализации проецируются на Проектная модель Модель реализации Рис. 23.3. Модель реализации как часть проектной модели 510 Глава 23. Рабочий поток реализации реальные, физические механизмы группировки целевого языка реа лизации. 23.4. Детализация рабочего потока реализации Как видно из рис. 23.5, в рабочем потоке реализации участвуют архи тектор, системный интегратор и разработчик компонентов. В любой из этих трех ролей могут выступать отдельные аналитики или проекти ровщики или небольшие команды аналитиков или проектировщиков. Их основное внимание будет направлено на производство моделей раз вертывания и реализации (часть реализации архитектуры). Интегри рование системы, реализация классов и тестирование элементов (unit testing) выходят за рамки рассмотрения этой книги – это вопросы реа лизации, а не анализа и проектирования. (Обратите внимание, что на рис. 23.5 в оригинальный рисунок было внесено изменение: Реализация подсистемы заменена на более общую Реализацию компонента, поскольку это более правильно с точки зрения UML 2.) 23.5. Артефакты Основной артефакт рабочего потока реализации с точки зрения ОО аналитика или проектировщика – модель реализации. Эта модель состоит из диаграмм компонентов, показывающих, как артефакты представляют компоненты, и диаграммы нового типа – диаграммы развертывания. Диаграмма развертывания моделирует физические вычислительные узлы, на которых будут развертываться программ Проектная модель «component» c1 «component» c2 Модель реализации «device» n1 «device» n2 «artifact» a2 «manifest» «manifest» «artifact» a1 «artifact» a2 «manifest» узел артефакт Рис. 23.4. Отношения между проектной моделью и моделью реализации 23.6. Что мы узнали 511 ные артефакты, и отношения между этими узлами. Подробно диа граммы развертывания рассматриваются в главе 24. 23.6. Что мы узнали Реализация главным образом касается создания кода. Однако ОО ана литик или проектировщик может быть привлечен для создания моде ли реализации. Мы узнали следующее: • Рабочий поток реализации – основной поток фазы Построения. • Реализация заключается в преобразовании проектной модели в ис полняемый код. • Моделирование реализации имеет важное значение, если: • предполагается использовать модель при прямой разработке (ге нерации кода); • осуществляется CBD с целью обеспечения повторного использо вания кода. • Модель реализации – часть проектной модели. • Артефакты представляют описания реальных сущностей, таких как исходные файлы: • компоненты представляются артефактами; • артефакты развертываются на узлах. • Узлы представляют описания оборудования и сред выполнения. Реализация архитектуры Реализация класса Реализация компонента Разработчик компонентов Архитектор Системный интегратор Проведение тестирования элементов Интегрирование системы Рис. 23.5. Рабочий поток реализации. Адаптировано с рис. 10.16 [Jacobson 1] с разрешения издательства Addison Wesley 24 Развертывание 24.1. План главы В этой главе рассматриваются деятельность UP Реализация архитектуры ( Architectural implementation) и способ создания диаграммы развертыва ния. Эта диаграмма показывает, как разрабатываемое программное обеспечение будет развертываться на физическом оборудовании и как соединяется это оборудование. В разделе 24.5 предлагается простой пример на языке Java. 24.7. Что мы узнали 24.2. Деятельность UP: Реализация архитектуры 24.3. Диаграмма развертывания 24.4. Узлы 24.5. Артефакты 24.6. Развертывание Рис. 24.1. План главы 24.2. Деятельность UP: Реализация архитектуры 513 24.2. Деятельность UP: Реализация архитектуры Реализация архитектуры состоит в определении важных с точки зрения архитектуры компонентов и проецировании их на физическое оборудо вание. Эта деятельность состоит в определении важных с точки зрения архи тектуры компонентов и проецировании их на физическое оборудова ние. То есть здесь мы занимаемся моделированием физической струк туры и распределения системы. Ключевая фраза – «важный с точки зрения архитектуры». В принципе можно было бы полностью смоде лировать физическое развертывание системы. Но это имело бы неболь шую практическую ценность, потому что подробности развертывания многих компонентов с точки зрения архитектуры не очень важны. Ис ключением является случай, когда код генерируется из модели. Тогда, вероятно, понадобится более подробная модель развертывания, чтобы генератор кода знал, куда помещать выходные артефакты, и мог соз давать соответствующие дескрипторы развертывания и компоновать файлы. Деятельность UP Реализация архитектуры представлена на рис. 24.2. В ори гинальный рисунок внесены два изменения (измененные артефакты за тушеваны): Архитектор Реализация архитектуры Проектная модель Модель развертывания Компонент Описание архитектуры [проектирование и развертывание] Артефакт Узел Описание архитектуры [реализация и развертывание] «subsystem» Рис. 24.2. Деятельность UP Реализация архитектуры. Адаптировано с рис. 10.17 [Jacobson 1] с разрешения издательства Addison Wesley 514 Глава 24. Развертывание • Согласно UML 2 подсистема показана как обозначенный стереоти пом компонент, а не как пакет, обозначенный стереотипом. • Результирующие артефакты и узлы деятельности показаны явно (в оригинальном рисунке они были неявными). С точки зрения ОО аналитика/проектировщика основная деятельно сть Реализации архитектуры – создание одной или более диаграмм развер тывания. Диаграмма развертывания объединяет компоненты, арте факты и узлы для определения физической архитектуры системы. Да лее глава посвящена подробному обсуждению диаграмм этого типа. Другая деятельность – дополнение описания архитектуры важными с точ ки зрения архитектуры деталями развертывания и реализации. 24.3. Диаграмма развертывания В UML развертывание – это процесс распределения артефактов по уз лам или экземпляров артефактов по экземплярам узлов. Скоро мы пе рейдем к подробному обсуждению артефактов и узлов. Диаграмма развертывания проецирует программную архитектуру на ап паратную архитектуру. Диаграмма развертывания определяет физическое оборудование, на ко тором будет выполняться программная система, а также описывает, как программное обеспечение развертывается на это оборудование. Диаграмма развертывания проецирует программную архитектуру, созданную при проектировании, на исполняющую ее физическую ар хитектуру системы. В распределенных системах она моделирует рас пределение программного обеспечения по физическим узлам. Существует две формы диаграмм развертывания. Дескрипторная форма диаграммы развертывания – артефакты, развер нутые на узлах. 1. Дескрипторная форма (descriptor form) – содержит узлы, отноше ния между узлами и артефакты. Узел представляет тип оборудова ния (например, ПК). Аналогично артефакт представляет тип физи ческого программного артефакта, например Java JAR файл. 2. Экземплярная форма (instance form) – включает экземпляры узлов, отношения между экземплярами узлов и экземпляры артефактов. Экземпляры узлов представляют конкретную, идентифицируемую часть оборудования (например, ПК Джима). Экземпляр артефакта представляет конкретный экземпляр типа программного обеспече ния, например определенную копию FrameMaker (www. adobe.com), использованную для написания этой книги, или конкретный JAR 24.4. Узлы 515 файл. Если детали конкретных экземпляров неизвестны (или не важны), могут использоваться анонимные экземпляры. Экземплярная форма диаграммы развертывания – экземпляры артефак тов развертываются на экземплярах узлов. Хотя диаграмма развертывания рассматривается как деятельность ра бочего потока реализации, ее первое приближение часто создается при проектировании как часть процесса выбора окончательной аппаратной архитектуры. Можно начать с создания дескрипторной формы диа граммы развертывания, ограничившись узлами и их связями, а затем уточнить ее и превратить в одну или более экземплярных форм, пред ставляющих возможные компоновки анонимных экземпляров узлов. Когда станут известны подробности об оборудовании сайта, на кото ром будет развертываться проект, при необходимости можно создать экземплярную форму диаграммы развертывания, показывающую фактически используемые на этом сайте компьютеры и устройства. Таким образом, создание диаграммы развертывания – это процесс из двух этапов: 1. В рабочем потоке проектирования основное внимание сосредоточено на узле или экземплярах узла и соединениях. 2. В рабочем потоке реализации – на распределении экземпляров ар тефактов по экземплярам узлов (экземплярная форма) или арте фактов по узлам (дескрипторная форма). В следующих двух разделах подробно рассматриваются узлы и арте факты. 24.4. Узлы Узел представляет тип вычислительного ресурса. Спецификация UML 2.0 [UML2S] гласит: «Узел представляет тип вы числительного ресурса, на который могут быть развернуты артефакты для выполнения». Существует два стандартных стереотипа для узлов: |