Рекомендации по структурированию моделей при помощи ПО IBM Rational. Часть 2.

Билл Смит, менеджер по продуктам Rational, управляемая моделями разработка, IBM

В статье рассказывается о том, как изобразить артефакты моделей IBM Rational Unified Process (RUP) в пакетах IBM Rational Software Modeler , IBM Rational Systems Developer или IBM Rational Software Architect (далее перечисленные продукты обобщенно именуются "рассматриваемыми продуктами" или просто "программным обеспечением, ПО"). Кроме того, в статье предлагаются рекомендации по внутренним организационным структурам подмножества этих артефактов. Чтобы вам было легче понять, каким артефактам следует уделить внимание, мы попробуем объяснить бизнес-ценность каждого конкретного продукта, но в наши задачи не входит:

пересмотр формулировок концептуальной основы артефактов;
предоставление их расширенных описаний;
описание процессов или методов определения их подробной семантики или контента диаграмм.

Разделы данной статьи охватывают следующие темы:

поддержка определенных в RUP типов моделей в рассматриваемых продуктах;
влияние стиля моделирования RUP на организацию моделей и коллективное моделирование;
что имеет смысл моделировать;
бизнес- ценность, структура и контент следующих трех моделей RUP:
- модель прецедентов (решения);
- модель анализа (решения);
- модель проектирования.

Целевая аудитория:

Данная статья (часть 2 серии статей) предназначена для специалистов, интересующихся применением рекомендаций по моделированию классического процесса Rational Unified Process при работе в рассматриваемых продуктах.

Примечание
описываемый RUP-ориентированный, управляемый прецедентами подход к организации модели - не единственный возможный подход. В процессе разработки также находятся рекомендации по структурированию моделей для стиля организации моделей управляемой бизнесом разработки для SOA (сервис-ориентированной архитектуры) (иногда называемой BDD4SOA) и для управляемой моделями разработки систем (Model Driven Systems Development) (RUP for MDSD).

После того, как несколько лет назад корпорация IBM приобрела компанию Rational Software, был начат процесс адаптации RUP к другим инфраструктурам процессов IBM, а также расширения RUP за счет рекомендаций для таких развивающихся технологий, как SOA и моделирование бизнес-процессов. До этого рекомендации по моделированию, предложенные унифицированным процессом Rational (Rational Unified Process) (и получившие развитие в книгах Терри Кватрани (Terry Quatrani), Джима Коналлена (Jim Conallen), Эрика Нейбурга (Eric Naiburg), Роберта Максимчука (Robert Maksimchuck) и других), некоторое время оставались довольно статичными. В этих рекомендациях описывается набор моделей - модели прецедентов, модели анализа и модели проектирования - представляющий собой тщательно продуманный взгляд на предметные области проблемы и решения систем. Данный подход в большей степени ориентирован на процесс, в котором прецеденты являются первыми создаваемыми артефактами моделирования, и допускается использование практически любого типа технической архитектуры. Полезность этого набора моделей была подтверждена многими реальными проектами. Теперь мы называем такой подход и стиль моделирования стилем рекомендаций по моделированию "общего" или "классического" RUP.

Реализация типов моделей RUP в инструментах UML-моделирования Rational на базе Eclipse

В RUP каждая модель относится к определенному типу, например, модель UML-прецедентов, модель анализа или модель данных. В рассматриваемых продуктах типы UML-моделям на самом деле не назначаются. Следовательно, отображение типов моделей RUP на эти продукты является, по преимуществу, вопросом ряда договоренностей, в том числе по поводу следующих моментов:

какие имена назначаются моделям/ЛЕ;
какие профили к ним применяются;
какой контент можно создавать в моделях/ЛЕ.

Рассматриваемые продукты включают несколько шаблонов моделей, которые можно использовать при создании моделей/ЛЕ. Некоторые из таких шаблонов подразумевают определенный тип модели и принцип организации модели, которые соответствуют RUP. Вы встречаетесь с шаблонами при создании новых моделей/ЛЕ и можете строить новые модели по этим шаблонам.

На рисунке 1 показаны страницы мастера создания моделей new model wizard. На снимке экрана слева можно увидеть некоторые из стандартных шаблонов. На правом снимке экрана мы видим, что в качестве шаблона или отправной точки можно также использовать собственную модель.

Рисунок 1. Мастер New UML Model

В таблице 1 перечислены часто используемые типы моделей RUP и способы их использования в рассматриваемых продуктах. В дальнейшем в этой статье предполагается, что используются именно эти отображения и описанные далее подходы.

Примечание:
рекомендации по внутренней организации Моделей прецедентов, анализа и проектирования, представленные в следующих разделах данной статьи, касаются организационных структур, которые определены в стандартных шаблонах моделей, предоставляемых рассматриваемыми продуктами. Но эти шаблоны ни в коем случае не представляют собой единственный способ организации таких моделей. При выборе способа организации логического контента моделей необходимо учитывать множество факторов.

Таблица 1. Часто используемые типы моделей RUP

Модель RUP	Способы использования в рассматриваемых продуктах
Модель бизнес-прецедента	Модель/ЛЕ, созданная на основе стандартного шаблона Blank Model (Пустая модель) с применением профиля Business Modeling (Бизнес-моделирование). Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для модели бизнес-прецедентов Модель/ЛЕ, созданная на основе определяемой пользователем модели с применением профиля Business Modeling. Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для модели бизнес-прецедентов
Объектная модель бизнеса	Модель/ЛЕ, созданная на основе стандартного шаблона Blank Model (Пустая модель) с применением профиля Business Modeling (Бизнес-моделирование). Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Объектной модели бизнеса Модель/ЛЕ, созданная на основе определяемой пользователем модели с применением профиля Business Modeling. Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Объектной модели бизнеса
(Решение) Модель прецедентов	Модель/ЛЕ, созданная на основе стандартного шаблона Use-Case Model (Модель прецедентов). Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Модели прецедентов Модель/ЛЕ, созданная на основе определяемой пользователем модели. Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Модели прецедентов Модель/ЛЕ, созданная на основе стандартного шаблона Blank Model (Пустая модель). Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Модели прецедентов
(Решение) Модель анализа	Модель/ЛЕ, созданная на основе стандартного шаблона Analysis Model (Модель анализа). Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Модели анализа. Модель/ЛЕ, созданная на основе определяемой пользователем модели. Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Модели анализа. Модель/ЛЕ, созданная на основе стандартного шаблона Blank Model (Пустая модель). Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Модели анализа. Модель/ЛЕ, созданная на основе стандартного шаблона модели Проектирования корпоративных информационных систем (Enterprise IT Design Model). Рекомендуется использовать пакеты `<<analysis>>`; содержащие контент уровня анализа, ограниченный в соответствии с руководством RUP для Модели анализа
Модель взаимодействия с пользователем (User Experience Model)	Модель/ЛЕ, созданная на основе стандартного шаблона Blank Model (Пустая модель). Рекомендуется ограничить допустимый контент модели в соответствии рекомендациями, прилагаемыми к RUP-конфигурации User Experience Modeling (в составе конфигурации IBM® Rational® Method Composer). Рекомендуется использовать графические редакторы Web Diagram Editor или Java™ Visual Editor в IBM® Rational® Software Architect или IBM® Rational® Application Developer.
Модель проектирования	Для ИТ: модель/ЛЕ, созданная на основе стандартного шаблона модели Проектирования корпоративных информационных систем (Enterprise IT Design Model). Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Модели проектирования. Для ИТ или систем: модель/ЛЕ, созданная на основе стандартного шаблона Blank Model (Пустая модель). Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Модели проектирования. Для ИТ или систем :модель/ЛЕ, созданная на основе определяемой пользователем модели. Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Модели проектирования.
Модель реализации	В UML не поддерживается. Рекомендуется использовать специальную функцию моделирования кода для 3GL. Рекомендуется использовать UML-модель проектирования, но при генерации кода применить преобразование с опцией замены UML-элементов "Replace UML elements", что позволит сделать модель проектирования комбинированной, включающей контент уровня реализации.
Модель развертывания	Модель/ЛЕ, созданная на основе определяемой пользователем модели. Ограничивает допустимый контент в соответствии с руководством RUP для Модели развертывания. Модель/ЛЕ, созданная на основе стандартного шаблона Blank Model (Пустая модель). Рекомендуется ограничить допустимый контент в соответствии с руководством RUP для Объектной модели бизнеса
Модель данных	Рекомендуется использовать логические и физические модели данных в зависимости от их поддержки инструментом IBM® Rational® Data Architect.

Организация моделей в RUP

В части 1 мы рассказывали об аспектах коллективного моделирования и принципах строгой архитектуры и монопольного владения. Эти принципы сохраняют свое первостепенное значение при использовании стиля моделирования RUP, но и сам стиль добавляет некоторые независимые аспекты, которые тоже необходимо учитывать.

Чтобы проиллюстрировать этот момент, давайте вновь обратимся к использованию базового кода и рассмотрим трехуровневую архитектуру приложения. Мы можем разбить такой базовый код на модули по принципу монопольного владения, исходя исключительно из соображений, связанных с функциональностью приложения. В принципе, именно такой подход изображен на рисунке 1:решение разбивается на общие утилиты и сервисы приложения и модули приложений.

Но это не единственный способ разбиения, и, возможно, он не поддерживает монопольное владение, если разработчики обладают комплектом узкоспециализированных навыков. Например, можно также порекомендовать дополнительное разбиение модулей приложения в соответствии с распределением артефактов по уровням описываемой трехуровневой архитектуры. На практике, если разработчики специализируются на разработке приложений клиентской, а не серверной стороны, то тип владения может зависеть в большей степени от уровня, чем от функциональности приложения, тем не менее, принцип строгой архитектуры требует, чтобы учитывались оба аспекта разбиения моделей).

RUP предлагает аналогичный набор аспектов, относящихся к организации моделей, но различные артефакты моделей RUP не соответствуют уровням архитектуры решения. Они соответствуют разным уровням абстракции, которые , возможно, потребуют выражения в процессе разработки. Оказывается, что инициатива OMG Model-Driven Architectures, MDA( управляемой моделями архитектуры) подразумевает аналогичную стратификацию моделей на других уровнях абстракции. В таблице 2 приведены примерные сравнительные характеристики принципов RUP и MDA.

Таблица 2. Сравнительная характеристика типов моделей RUP и MDA

Типы моделей RUP	Типы моделей MDA	Назначение и примечания
Модель бизнес-прецедентов Модель бизнес-анализа	CIM (Вычислительно независимая модель)	Для отображения управляемых бизнесом требований и вычислительно-независимых представлений решений.
Модель прецедента решения Модель анализа решения Модель взаимодействия с пользователем (User Experience Model) Логическая модель данных	PIM (Платформенно-независимая модель)	Для отображения вычислительно-зависимых, но независимых от платформы требований к решению и представлений решений.
Модель проектирования решения	PIM или PSM	Для отображения либо платформенно-независимых представлений проекта решения, либо представлений, характеризующихся какими-либо аспектами, зависящими от конкретной платформы. Модель проектирования решения может эволюционировать из PIM в PSM естественным образом .
Модель реализации Физическая модель данных Модель развертывания	PSM	Для отображения платформенно-зависимых аспектов проектирования решения.

Так же, как специалисты, разрабатывающие код реализации, могут специализироваться в разработке на стороне клиента или сервера, Web-разработчики могут иметь специализацию в области анализа бизнес-требований, разработки требований решений, анализа решений, проектирования решений, проектирования информации и т. д. Тем не менее, при работе на детализированном уровне абстракции проекта, они могут остро нуждаться в согласовании структуры модели проектирования со структурой базового кода (особенно в тех случаях, если используется автоматизированная генерация кода). В таблице 3 приводятся рекомендации по поводу того, как можно расставить приоритеты между различными аспектами при планировании стратегии для практического моделирования по процессу RUP.

Таблица 3. Стратегии определения владельцев контента модели

Для следующих типов моделей RUP	Стройте стратегию определения владельцев, исходя из перечисленных ниже соображений
Модель бизнес-прецедента Модель бизнес-анализа	Выделение совместно используемого и общего контента Специализированные навыки Бизнес-ориентированное структурное разбиение проблемной области (например, на подразделения, рабочие потоки, стратегические инициативы)
Модель прецедента решения Модель анализа решения Модель взаимодействия с пользователем Модель предметной области (иногда называется также эталонной информационной моделью (Reference Information Model) или логической моделью данных (Logical Data Model)	Выделение совместно используемого и общего контента Специализированные навыки Функционально-ориентированное разбиение проблемной области (на приложения, рабочие потоки, модули и т. п.)
Модель проектирования решения Физическая модель данных Модель реализации	Выделение совместно используемого и общего контента Дополнительные принципы построения стратегии: Если коллективы разработчиков характеризуются комплексным набором квалифицированных кадров, сосредоточьтесь на разбиении по функциональности и принципах сильной сцепленности и слабой связанности. Для коллективов разработчиков с узкоспециализированным набором квалифицированных кадров может оказаться необходимым сначала сосредоточиться на архитектурных уровнях, выбранных технологиях реализации и т. д., тем самым выполнив эффективную функциональную декомпозицию второстепенного аспекта владения контентом (который, тем не менее, остается первостепенным архитектурным аспектом). В рассматриваемых продуктах, в отличие от ранее выпускавшихся продуктов Rational для моделирования, модель реализации состоит из базового кода и диаграмм кода.
Модель развертывания	Согласование с Моделью проектирования Согласование с правами владения ресурсами инфраструктуры (машинами, сетями и т. п.)

Можно назвать еще один аспект - нестабильность, которая обычно зависит от того, на каком этапе плана разработки вы в данный момент находитесь. По мере развития у вас понимания сути вещей и наилучших функциональных принципов группирования вам, вероятно, часто придется выполнять реорганизации проекта (особенно на ранних итерациях проектов, создаваемых с нуля).

В RUP-ориентированных процессах моделирования существует тенденция к сильной взаимосвязи между структурой Моделей прецедентов и Моделей анализа (по меньшей мере, на ранних стадиях процесса), поскольку RUP предполагает вполне автоматизированный процесс загрузки контента в Модель анализа на основе контента Модели прецедента. Таким образом, чтобы загрузить контент в Модель анализа, используйте следующие артефакты:

одну кооперацию <<Use-Case Realization>> (владеющую одним или более взаимодействиями) и один класс <<Control>> для каждого прецедента;
один класс <<Boundary>> для каждого отношения между прецедентом и деятелем (актером);
любое количество классов<<Entity>>, возможно, полученных в результате анализа имен существительных в описаниях прецедента или, может быть, в результате разработки модели предметной области.

Преимущества: данный метод предполагает хранение контента анализа в тех же пакетах, в которых хранятся прецеденты (что подразумевает и их размещение в одной модели), например, по следующим причинам:

это может упростить выполнение определенных задач, связанных с реорганизацией прецедентов (например, переименования пакетов или перегруппировки прецедентов);
благодаря этому легче понять, каким образом следует изменить контент, чтобы он отражал остальные типы реорганизации прецедента (например, проще заметить, когда необходимо изменить имя [UML кооперации] или класса <<Control>> при переименовании какого-либо прецедента).

Способы согласования: в этом случае не обеспечивается поддержка монопольного владения прецедентом бизнес-аналитиком и монопольного владения контентом анализа системным аналитиком или разработчиком архитектуры программного обеспечения. Значит, вам, возможно, придется принять решение об объединении контента прецедента и анализа посредством ряда итераций до получения стабильной структуры, а затем реорганизовать контент анализа в отдельную модель/ЛЕ (со структурой, которая отражает структуру Модели прецедента), чтобы сделать возможным монопольное владение со стороны разработчика архитектуры программного обеспечения. В дальнейшем можно переместить контент анализа в отдельную модель/ЛЕ, структур пакета которой будет отражать структуру контента прецедента.

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

В части 1 мы советовали: "Вот лучшая рекомендация по моделированию - моделируйте только то, что имеет очевидную ценность для бизнеса". В этой статье мы увидели, что RUP предлагает довольно много разных типов моделей, представляющих различные аспекты и уровни абстракции предметных областей проблемы и предполагаемого решения. Эти типы предложены потому, что они обеспечили добавление экономической ценности, по меньшей мере, в некоторых ситуациях. Перед ними встают следующие вопросы: "Обеспечит ли каждый из них добавление экономической ценности во всех ситуациях?" Ответ "нет."

Из первого вопроса вытекает второй:: "Как определить, что окажется полезным в конкретной ситуации?" На этот вопрос нельзя ответить со всей определенностью. Хотя в данной статье не предполагается обсуждение ценности моделирования вообще и ценности каждой модели RUP в частности, мы попытаемся пролить свет на то, когда следует использовать определенные типы моделей RUP. В таблице 4 указаны: потенциальные ценные стороны каждого типа модели RUP, затраты на создание и обслуживание, а также указания по поводу того, какие варианты можно использовать в качестве альтернативы. Как правило, описания добавляемой бизнес- ценности достаточно понятны, но важно учитывать, что трассируемость представляет собой бизнес-ценность, по меньшей мере, для двух разных направлений:

совместимость;
анализ влияния.

Таблица 4. Преимущества, способы согласования и альтернативы для различных моделей RUP

Тип модели RUP	Преимущества, способы согласования и альтернативы
Модель бизнес-прецедентов	Преимущества: обеспечивает лучшее понимание бизнес-проблем, требований и потенциальных возможностей совершенствования; способствует более эффективному обсуждению бизнес-проблем и потенциальных решений с заинтересованными лицами в данном направлении бизнеса и в других направлениях; может обеспечивать нисходящую трассируемость (например, до требований в репозитории, Модели бизнес-анализа или до требований и модели). Способы согласования: разработка и обслуживание модели; возможно, синхронизация контента модели бизнес-прецедента с нисходящими требованиями или моделями; возможно создание и обслуживание взаимосвязей нисходящей трассируемости. Альтернативы: бизнес-документы (отчеты, презентации); модели бизнес-процессов.
Модель бизнес-анализа	Преимущества: обеспечивает лучшее понимание требований, характеристик и стоимости бизнес-решений; возможно, нисходящая трассируемость (до требований в репозитории и модели прецедентов решения). Способы согласования: разработка и обслуживание модели; возможно, синхронизация модели бизнес-анализа с восходящими и нисходящими требованиями и моделями; возможно создание и обслуживание взаимосвязей трассируемости. Альтернативы: бизнес-документы (отчеты, презентации); модели бизнес-процессов.
Модель прецедента решения	Преимущества: обеспечивает лучшее понимание требований решения; повышает эффективность доведения информации о масштабе проекта и требованиях к нему до сведения заинтересованных лиц; возможно, обеспечение восходящей трассируемости (например, до требований в репозитории или Модели бизнес-анализа); возможно, обеспечение латеральной трассируемости до других моделей и артефактов (моделей взаимодействия с пользователем, коду прототипа, контрольным примерам тестирования). Возможно, обеспечение нисходящей трассируемости до других моделей (в том числе, кода); возможно, автоматизированная генерация контента нисходящих моделей (влечет за собой необходимость разработки пользовательского инструментария); возможно, автоматизированная генерация схемы контрольных примеров. Способы согласования: разработка и обслуживание модели; возможно, синхронизация контента модели прецедентов решения с восходящими (например, моделью бизнес-анализа) и нисходящими моделями (например, Моделью анализа решения); возможно, создание и обслуживание согласующих элементов восходящей и нисходящей или латеральной трассируемости; возможно, разработка пользовательского инструментария. Альтернативы: документы спецификации; прототипы.
Модель анализа решения	Преимущества: обеспечивает лучшее понимание требований к решению и характеристик решения, которое способствует выбору лучшего архитектурного варианта до фиксации кода в репозитории; возможно, восходящая трассируемость (например, до Модели прецедентов решения); возможно, нисходящая трассируемость до других моделей (в том числе, до моделей кода); возможно, автоматизированная генерация контента нисходящей модели (требует разработки пользовательского инструментария); в качестве альтернативы, может эволюционировать в Модель проектирования. Способы согласования: разработка и обслуживание модели; возможно, синхронизация с восходящими (например, Моделью прецедентов ) и нисходящими моделями (например, Моделью реализации или Моделью проектирования); возможно, создание и обслуживание согласующих элементов нисходящей трассируемости; возможно, разработка пользовательского инструментария. Альтернативы: документы спецификации; прототипы.
Модель взаимодействия с пользователем	Преимущества: обеспечивает лучшее понимание требований к решению; позволяет эффективно довести до сведения заинтересованных лиц масштаб решения, требования к нему и особенности взаимодействия с пользователем; может обеспечивать нисходящую трассируемость (например, до требований в репозитории, Модели бизнес-анализа или до требований и модели); возможно обеспечение латеральной трассируемости до других моделей и артефактов (Моделей прецедентов или анализа решения, кода прототипа, контрольных примеров); возможно, нисходящая трассируемость до других моделей (в том числе, модели кода); возможно, автоматизированная генерация контента нисходящих моделей, в том числе, моделей кода (влечет за собой разработку пользовательского инструментария); возможно, автоматизированная генерация планов контрольных примеров (влечет за собой разработку пользовательского инструментария). Способы согласования: проектирование, разработка и обслуживание стиля моделирования взаимодействия с пользователем и (вероятно) UML-профиля; разработка и обслуживание Модели взаимодействия с пользователем; возможно, синхронизация контента модели прецедентов решения с восходящими (например, Моделью бизнес-анализа) и нисходящими (например, Моделью анализа решения) моделями; возможно, создание и обслуживание согласующих элементов восходящей и нисходящей или латеральной трассируемости; возможно, разработка пользовательского инструментария. Альтернативы: документы спецификации; схемы взаимодействия с пользователем (инструментарий бизнес-партнеров Rational); прототипы.
Модель предметной области (иногда называется также эталонной информационной моделью (Reference Information Model) или логической моделью данных (Logical Data Model)	Преимущества: обеспечивает лучшее понимание предметной области реального бизнеса; предоставляет обучающие пособия для информирования о предметной области бизнеса; повышает эффективность проектов баз данных; возможно, нисходящая трассируемость (например, до Модели анализа или Модели проектирования решения); возможно, загрузка контента в нисходящие модели, такие, как Модели анализа или проектирования решения (влечет за собой разработку пользовательского инструментария); возможно, загрузка контента в Логические модели данных (при помощи инструментов Rational Data Architect) из моделей предметной области (или наоборот); способствует более эффективному доведению бизнес-проблем и потенциальных решений до сведения заинтересованных лиц в данном направлении бизнеса и в других направлениях; эффективное обсуждение проблем согласования и интеграции информации, поддержка работ по разработке данных. Способы согласования: разработка и обслуживание модели предметной области; возможно, синхронизация модели предметной области с логическими моделями данных или нисходящими моделями программного обеспечения (анализа или проектирования решения); синхронизация Модели прецедентов решения с восходящими (например, Моделью бизнес-анализа) и нисходящими (например, Моделью анализа решения) моделями; возможно, создание и обслуживание согласующих элементов восходящей и нисходящей или латеральной трассируемости; возможно, разработка пользовательского инструментария. Альтернативы: Документы спецификации
Модель проектирования решения	Преимущества: предоставляет возможность описать и оценить альтернативные подходы к проектированию без фиксации в коде; обеспечивает лучшее понимание требований к решению и характеристик решения, которое способствует выбору лучшего архитектурного варианта до фиксации кода в репозитории; возможно, восходящая трассируемость (например, до Модели прецедентов решения или Модели анализа решения); возможно, нисходящая трассируемость до уровня кода; возможно, автоматизированная генерация кода (с применением пользовательских преобразований или стандартных преобразований, которые поставляются в составе рассматриваемых продуктов). Способы согласования: разработка и обслуживание модели; возможно, синхронизация с восходящими моделями или требованиями; возможно, синхронизация с моделями кода; возможно, создание и обслуживание согласующих элементов нисходящей трассируемости; возможно, разработка пользовательского инструментария. Альтернативы: документы спецификации; прототипы; модели кода и код.
Физическая модель данных	Преимущества: предоставляет графические (диаграммные) режимы исследования и проверки реализации решения и помощь в понимании данной реализации (что особенно ценно в фазе сопровождения и при смене сотрудников). Способы согласования: обслуживание диаграмм.
Модель реализации решения	Преимущества: предоставляет графические (диаграммные) режимы исследования и проверки реализации решения и помощь в понимании данной реализации (что особенно ценно в фазе сопровождения и при смене сотрудников). Способы согласования: обслуживание диаграмм (хотя обзорные (Browse) диаграммы могут предоставить больше пользы и не требуют обслуживания).
Модель развертывания решения	Преимущества: предоставляет средства для понимания требований и затрат на развертывание решений, что является полезным в фазах сбора и осмысления требований, проектирования и реализации. Способы согласования: обслуживание моделей
Все типы моделей	Преимущества: обеспечивает более эффективное взаимодействие с различными заинтересованными в проекте лицами; служит основой для инфраструктур управления решением; предоставляет документацию, связанную с обеспечением соответствия законодательным нормам (особенно относящуюся к трассируемости от требований через реализацию к уточнениям).

В рассматриваемых продуктах предоставляется возможность создания новой модели/ЛЕ на основе шаблона модели прецедентов. (Вы можете также создать пользовательскую модель/ЛЕ и использовать ее в качестве шаблона).

Стандартный шаблон Модели прецедентов ( Use-Case Model)

Эти шаблоны могут определять специфическое подмножество средств UML, которые обычно используются при моделировании прецедентов (другими словами, при работе с моделями на основе шаблонов палитры для рисования и раскрывающиеся меню будут содержать только те UML-элементы, которые обычно используются специалистами по моделированию прецедентов). Шаблоны также предоставляют набор контента по умолчанию, как показано на рисунке 2. В данной статье мы не будем объяснять, как использовать контент компоновочных блоков прецедентов и поисковые строки, но вы можете найти подробные инструкции в примечаниях к шаблонам.

Рисунок 2. Контент по умолчанию шаблона модели прецедентов в рассматриваемых продуктах

Этот шаблон в качестве основы организации модели использует метод логического разбиения функциональности. (Это проявляется в использовании шаблона пакета ${functional.area} в качестве основного компоновочного блока модели прецедента.) На рисунке 3 изображен обычный пример такого типа организации модели прецедента.

Рисунок 3. Пример модели прецедента, организованной в соответствии с методом разбиения функциональности

Как уже говорилось в разделе об организации моделей в RUP, это не единственный возможный подход к логическому разбиению. Он был выбран для использования с данным шаблоном по следующим причинам:

Он обычно хорошо проецируется на вопросы разделения труда при работе коллектива специалистов над моделью прецедента.

С этим подходом у вас будут наилучшие шансы создать такую структуру модели прецедента, которую будет легко отобразить на модели проектирования и реализации при введении в организации монопольного владения функциональными модулями (хотя структура моделей проектирования и реализации может отражать и аспекты разделения на уровни, чаще всего она будет также отражать аспекты функциональной декомпозиции и компонентов). Это может оказаться особенно важным, если вы планируете использовать преобразования для загрузки контента в каждый успешный низлежащий уровень абстракции. Если вы будете генерировать такой заполняющий контент в модели анализа или модели проектирования, исходя из модели прецедента, то наличие согласованных структур пакетов (или, как минимум, аналогичных структур) в таких моделях может упростить разработку и настройку преобразования.

Данный шаблон также предполагает использование одного из нижеперечисленных организационных методов:

Использование пакета верхнего уровня для документирования Деятелей (Актеров) с широкими или универсальными полномочиями (специалистов, участвующих в наборе прецедентов, который размещается в нескольких ориентированных на функции пакетах).

Использование пакетов <<perspective>> для документирования диаграмм, изображающих представления, которые выбиваются из своей функциональной области (но семантические элементы модели остаются организованными по функциональным областям)

Миграция между Rational XDE и Rational Rose

Рекомендации по структурированию модели прецедента в чем-то являются пересмотром ранних рекомендаций для RUP, которые заключались в создании двух пакетов верхнего уровня - одного для Деятелей (Актеров) и еще одного - для прецедентов. Затем, когда этого потребует возрастающая сложность и увеличивающийся размер модели, мы будем использовать пакеты более низкого уровня для создания ориентированных на функции группировок, как показано в примере с использованием XDE, который представлен на рисунке 4.

Рисунок 4. Пример с использованием XDE (согласно врезке)

Контент Модели прецедента

В данной статье мы не предлагаем подробное учебное руководство о том, как создавать хорошие прецеденты, или о том, что следует и что не следует делать, чтобы эффективно использовать прецеденты. Тем не менее, мы вкратце расскажем, что следует включать в модель прецедентов кроме Деятелей и Прецедентов.

Рекомендуем: создайте в корне модели Main-диаграмму, изображающую другие пакеты модели и поддерживающую анализ таких пакетов и соответствующих им Main-диаграмм.

Рекомендуем: в каждый пакет прецедента включите диаграмму, изображающую прецеденты пакета, любые отношения между ними и Деятелей (Actor), которые в них участвуют. Если количество прецедентов достаточно велико, может потребоваться более одной диаграммы.

Рекомендуем: опишите основной и альтернативный поток каждого прецедента в поле Documentation, как показано на рисунке 5. (Форматирование в примере было выполнено путем создания текстового шаблона для описания прецедента с использованием редактора RTF (rich text format, расширенный текстовый формат) с последующим копированием и вставкой этого шаблона в поле Description для прецедента).

Рисунок 5. Документирование описаний потока прецедента в свойстве прецедента Documentation

Желательно: если это оправдывается сложностью прецедента, добавьте диаграмму деятельности и скомпонуйте ее таким образом, чтобы она отражала общие потоки деятельности данного прецедента (см. рисунок 6). Обоснование: Это поможет отобразить условия, соответствующие каждому потоку (основному (Main), альтернативному (Alternative) или особому (Exceptional) и гарантировать, что все эти потоки в конце концов сольются. (В семантическом смысле результатом добавления диаграммы деятельности будет добавление элемента Деятельность, принадлежащего элементу Прецедент, с диаграммой в составе этой деятельности).

Желательно: создать модель реализации по типу "черного ящика" для каждого из именованных потоков (Main, Alternative и Exceptional) данного прецедента.

Добавить в прецедент Нечеткое поведение (Opaque Behavior) и присвоить ему имя потока.
Добавить в это поведение Диаграмму последовательности (семантически в результате добавления диаграммы последовательности будет добавлен элемент Взаимодействие (Interaction), которым владеет элемент Нечеткое поведение, с диаграммой в составе этого Взаимодействия).
Скомпонуйте Диаграмму последовательности (или Диаграмму коммуникации) для каждого экземпляра взаимодействия.

Миграция между Rational XDE и Rational Rose

В UML 1 для этой цели мы использовали бы экземпляр Кооперации, а не Нечеткое Поведение.

Экземпляры Нечеткого поведения не следует путать с реализацией прецедентов на уровне проекта или анализа, о которых пойдет речь в следующих разделах. Последние представляют собой реализации прецедентов по типу "белого ящика" и описывают взаимодействия между внутренними элементами решения. Предлагаемые здесь элементы Нечеткое поведение (см. рисунок 6) являются исключительно взаимодействиями по типу "черного ящика" между Деятелями и системой. Они предоставляют для далеких от техники заинтересованных лиц высокоуровневую картину взаимодействия пользователей с системой. Нечеткое поведение может помочь определить, какие представления (окна или страницы) понадобятся в данной реализации. Они также формально устанавливают правила присваивания имен разным потокам (сценариям) прецедента путем назначения соответствующих имен семантическим элементам модели (элементам Нечеткое Поведение).

Желательно: если вы используете рекомендации RUP для идентификации архитектурно значимых представлений архитектуры и, особенно, если вы планируете вести документ Software Architecture Document, добавьте пакет верхнего уровня <<perspective>> , который будет содержать диаграммы прецедента, изображающие архитектурно значимые прецеденты. Возможно, вы захотите дать этому пакету имя Use-Case View of Architecture (Представления архитектуры для прецедента). В качестве альтернативы вы можете включить этот пакет в Модель обзора архитектуры.

Модель анализа представляет собой первое приближение к решению. Это вспомогательное средство, которое используется, главным образом, для документирования информации о предметной области бизнеса, демонстрирует предполагаемые элементы решения на высоком (близком к бизнесу) уровне абстракции и, тем самым, помогает перейти от требований к окончательному проекту. Именно здесь мы используем классы анализа и реализации прецедентов на аналитическом уровне. Именно через процесс моделирования реализаций прецедентов (главным образом, при помощи Диаграммы последовательности) приходит понимание того, какие классы реального проекта необходимы для решения. Если говорить конкретно, это будут классы, соответствующие жизненно важным линиям, которые, согласно нашему пониманию, необходимы на диаграммах последовательности. Существует также несколько практических правил (общих рекомендаций), которые можно применить, чтобы создать контент Модели анализа на основе контента Модели прецедента. (Далее мы коротко расскажем об этом.)

В RUP решение по поводу того, должна ли Модель анализа вестись независимо от Модели проектирования, является специфичным для конкретного проекта. Это решение принимается с учетом ваших предположений в отношении того, оправдает ли ведение отдельной Модели анализа потраченное на нее время. Можно иметь в виду несколько вариантов :

Как уже говорилось в разделе об организации моделей в RUP, на ранних фазах проекта, когда контент еще отличается высокой нестабильностью (или на любом этапе, если создание модели анализа и модели прецедента выполняется одними и теми же специалистами), храните контент анализа в той же модели/ЛЕ, что и Модель прецедента. Применяйте к моделям профиль RUPAnalysis и используйте пакеты с ключевым словом <<analysis>> для разделения контента Модели анализа и контента Модели прецедента В дальнейшем вы сможете извлечь контент аналитического уровня в отдельную модель/ЛЕ, которой можно будет управлять любым из описанных здесь способов.
Создайте Модель анализа независимо от Модели прецедента (она должна размещаться в отдельной логической модели, построенной на основе шаблона Модели анализа). Затем вручную или при помощи преобразований типа модель-модель создайте уточненные версии элементов анализа в отдельной Модели проектирования. Благодаря этому у вас будет возможность продолжить ведение отдельной Модели анализа или отказаться от нее.
Выполните те же действия, но затем просто позвольте Модели анализа эволюционировать в Модель проектирования естественным образом. (Надо сказать, что в RUP упоминается возможность создания классов анализа и реализаций прецедента на аналитическом уровне в Модели проектирования, а затем развития их непосредственно в их проектных формах, начиная с этого момента). В этом случае вы начинаете моделирование с реализации прецедентов с использованием классов анализа, а затем, через некоторое время, уточняете их, чтобы истинные интерфейсы проекта приобрели форму ролей в моделируемых поведениях.
Сочетание первого и второго варианта можно использовать для обслуживания своего рода Модели анализа в той же модели, что и Модель проектирования. Если используется этот подход, то, в процессе создания Модели проектирования создаются пакеты, в которых сохраняются некоторые чисто аналитические перспективы. С этой целью аналитический контент выделяется в пакеты, к которым применяется ключевое слово <<analysis>>.

Стандартный шаблон Модели анализа

В рассматриваемых продуктах предоставляется возможность создания новой модели/ЛЕ на основе шаблона Модели анализа. (Вы можете также создать пользовательскую модель/ЛЕ и использовать ее в качестве шаблона). Шаблоны могут определять специфическое подмножество средств UML, которые обычно используются при выполнении моделирования анализа. То есть, при работе с моделями на основе шаблонов палитры для рисования и раскрывающиеся меню будут содержать только те UML-'элементы, которые используются специалистами по созданию моделей анализа.

Кроме того, к моделям/ЛЕ, созданным на основе таких шаблонов, применяется профиль RUPAnalysis, а шаблоны предоставляют набор контента по умолчанию, как показано на рисунке 7. (В данной статье мы не будем объяснять, как использовать контент Компоновочных блоков анализа и поисковые строки, но в примечания, которые имеются в самих шаблонах, такие инструкции присутствуют.)

Рисунок 7. Контент по умолчанию шаблона Модели анализа в рассматриваемых продуктах

Как и шаблон Модели прецедента, шаблон Модели анализа отдает предпочтение использованию логического разбиения функциональности в качестве метода построения структуры модели. (Это проявляется в использовании шаблона пакета ${functional.area} в качестве основного компоновочного блока модели прецедента.) На рисунке 8 изображен обычный пример такого типа структуры Модели анализа, обусловленный указанным предпочтением.

Рисунок 8. Пример высокоуровневой организации Модели анализа

он обычно хорошо проецируется на вопросы разделения труда при работе коллектива специалистов над Моделью анализа;
он хорошо проецируется в восходящем направлении на шаблон, лежащий в основе организации Модели прецедента, если вам нужно применить пользовательские преобразования, чтобы загрузить контент Моделей анализа из Моделей прецедентов;
с этим подходом у вас будут наилучшие шансы создать такую Модель анализа, которую будет легко отобразить на Модели проектирования и реализации при использовании в организациях, в которых поощряется использование монопольного владения функциональными модулями. (Хотя структура моделей проектирования и реализации может отражать и аспекты разделения на уровни, чаще всего она будет также отражать аспекты функциональной декомпозиции или компонентов.) Это может оказаться особенно важным, если вы планируете использовать преобразования для загрузки контента в каждый успешный низлежащий уровень абстракции.

Данный шаблон также предполагает использование нижеперечисленных организационных методов:

выделение элементов модели анализа (стереотипизированных классов) в отдельные подпакеты пакетов каждой функциональной области;
использование пакетов <<perspective>> для документирования диаграмм, изображающих представления, которые выбиваются из своей функциональной области (но семантические элементы модели остаются организованными по функциональным областям).

На рисунке 8 проиллюстрированы некоторые методы структурирования Модели анализа на основе общего подхода, обусловленного использованием шаблона Модели анализа. Вариант этого подхода изображен далее по тексту на рисунке 9. (рисунок был сделан по 6 версии рассматриваемых продуктов, в которых в обозревателе проектов Project Explorer используются другие значки. Различие между описанными вариантами заключается в том, что в последнем из них пакет верхнего уровня использовался для отделения реализаций прецедентов от классов анализа. В этом пакете верхнего уровня мы видим набор подпакетов, соответствующих ориентированным на функции пакетам верхнего уровня. Потенциальное преимущество такой изоляции реализаций прецедентов заключается в том, что она допускает реорганизацию структуры пакетов верхнего уровня, не влияя на структуру реализаций прецедентов. Это может иметь смысл (особенно если Модель анализа эволюционирует в Модель проектирования естественным образом ) по той причине, что структура пакетов для классов, вероятно, будет нуждаться в развитии, чтобы не совпадать со структурой, которая изначально была выбрана для прецедентов.)

Рисунок 9. Варианты высокоуровневой организации Модели анализа

В зависимости от конкретной ситуации могут найтись причины для использования какого-либо соглашения о назначении имен, которое облегчит слияние и повторное использование контента моделей, созданных несколькими рабочими группами, даже группами из других (партнерских) компаний. Если это имеет значение, подумайте об использовании обратного соглашения о пространстве доменных имен, как на рисунке 10 (этот рисунок также создан по 6 версии рассматриваемых продуктов). Обратите внимание, что это не имеет большого значения собственно для моделирования анализа, но если вы используете подход, позволяющий Модели анализа естественным образом эволюционировать в Модель проектирования, и поощряете многократное использование или бизнес-интеграцию на уровне проекта, возможно, вы захотите заранее спланировать это подобным образом. У этого подхода есть еще одно преимущество: поскольку он может хорошо отображаться на структуру кода, сгенерированного из моделей анализа и проектирования, он может упростить последующую настройку конфигурации преобразования типа "модель-текст (код)".

Рисунок 10. Пример использования соглашения об инвертированном пространстве доменных имен Интернет

Контент Модели анализа

Выяснить, какие классы анализа необходимы, можно несколькими способами. Один из способов - начать с создания Диаграммы последовательности, которая строится на реализациях прецедентов. В процессе создания диаграммы вы поймете, какие опорные линии вам понадобятся. Как правило, каждое направление представляет собой предполагаемый класс анализа. Определив таким образом, какие классы необходимы, вы можете создать их в пакетах реализации прецедентов Модели анализа, но не оставить в них (например, вы можете перенести их в пакеты, ориентированные на функции, как показано на предыдущих рисунках).

Еще один способ определения необходимых классов анализа: Создайте в Модели анализа классы в соответствии со следующими рекомендациями:

для каждого прецедента (в Модели прецедента) добавьте в Модель анализа один класс <<control>>. Классы управления представляют бизнес-логику, ассоциируемую с этим прецедентом. (Впоследствии, в проекте, они также отобразятся на аспекты типа управления сеансами.);

для каждого отношения Деятель-прецедент (в Модели прецедента) добавьте в Модель анализа один класс <<boundary>>. Классы <<boundary>> представляют собой интерфейсы между решением и человеком-деятелем или между решением и определенной внешней системой. Классы <<boundary>>, которые соответствуют человеку-деятелю, вероятно, в конечном итоге, отобразятся на один или более артефактов интерфейса пользователя в проекте или реализации, тогда как классы <<boundary>> , соответствующие внешней системе, могут в конечном итоге отобразиться на какой-либо вид уровня адаптеров в проекте или реализации;

через процесс анализа CRC-карт (CRC - Class, Responsibilities, Collaboration) или описания прецедентов, идентифицируйте дополнительные классы <<control>> (глаголы) и классы <<entity>> (имена существительные);

дополнительные потенциальные источники классов <<entity>> - это Модели предметной области, Логические модели данных, Модели мастер-данных и бизнес- глоссарии.

Независимо от того, каким способом вы определяли классы анализа, вы почти обязательно обнаружите, что необходимо внести изменения в исходную, ориентированную на функции, структуру пакетов. Следующие рекомендации относятся к контенту Модели анализа и развитию структуры Модели анализа:

Рекомендуем: модель анализа должна содержать реализации прецедентов уровня анализа, которые описывают, как выполняются прецеденты в смысле коопераций классов анализа. Каждая реализация прецедента (представленная UML-кооперацией) соответствует UML-прецеденту в Модели прецедента. Вероятно, она должна иметь то же имя, что и данный Прецедент, а также быть производной или находиться в отношении реализации к Прецеденту (см. рисунок8 ).

Рекомендуем: для любого именованного потока прецедентов (заданного ранее в Модели прецедентов), который, по вашему мнению, необходимо моделировать как реализацию на уровне анализа, добавьте в Кооперацию Диаграмму последовательности, которая будет отображать реализацию этого потока. Это вызовет автоматическое добавление UML-Взаимодействия как сущности, владеющей данной Диаграммой последовательности. См. рисунок 11. (На рисунке 11 обратите внимание на то, что некоторые параметры Preferences настроены таким образом, чтобы большая часть семантического UML-контента типа свойств подвергалась фильтрации. По умолчанию этот контент отображается в обозревателе проектов Project Explorer. Возможно, вы захотите настроить параметры Preference, чтобы представление выглядело так же.).

Рисунок 11. Кооперации (реализации прецедентов), владеющие Диаграммами последовательности.

Предлагаем: после того, как вы создали Диаграмму последовательности для потока прецедентов, вы можете выделить Взаимодействие, которому она принадлежит в обозревателе проектов Project Explorer, и добавить к нему Диаграмму коммуникации. В новую Диаграмму коммуникации будут автоматически загружены экземпляры классов анализа, которые имеются на Диаграмме последовательности.

Предлагаем: создайте отношение зависимости-реализации между каждой реализацией прецедента (UML-Кооперацией) и соответствующим прецедентом из модели прецедентов (см. рисунок 12 далее). Поскольку для того, чтобы разобраться в отношениях трассируемости, можно использовать функции типа Актуальных диаграмм и Анализа трассируемости, на самом деле нет необходимости хранить постоянные диаграммы для отображения отношений трассируемости. Следовательно, вы можете создавать отношения с использованием какой-либо временной диаграммы. Например, так:

добавьте в Кооперацию диаграмму произвольной формы;
перетащите на эту диаграмму при помощи мыши элемент Кооперация;
перетащите на нее также прецедент (возможно, из другой модели);
создайте отношение зависимости;
и, наконец, в обозревателе проектов Project Explorer, удалите диаграмму из Кооперации.

Предлагаем: включите в каждую реализацию прецедента Диаграмму участников, которая будет показывать, какие классы анализа участвуют в данной реализации (то есть, экземпляры классов анализа, которые отображаются на диаграммах взаимодействия, описывающих реализацию прецедента) и отношения между этими классами, поддерживающие кооперацию, описываемую диаграммами взаимодействия. Эта диаграмма может содержать классы сущностей и классы объектов передачи данных. См. рисунок 12.

Рисунок 12. Пример Диаграммы участников реализации прецедента

В рассматриваемых продуктах предоставляется возможность создания новой модели/ЛЕ на основе шаблонов Модели проектирования. Это те шаблоны, которые можно использовать для проектирования (а, возможно, и для анализа) при выборе бизнес-приложений. (Можно также создать пользовательскую модель/ЛЕ и использовать ее в качестве шаблона).

Стандартный шаблон Проектирования корпоративных информационных систем (Enterprise IT Design Model)

Эти шаблоны могут определять специфическое подмножество средств UML, которые обычно используются при моделировании проектирования (другими словами, при работе с моделями на основе этого шаблона палитры для рисования и раскрывающиеся меню будут содержать только те UML-элементы, которые обычно используются специалистами по проектированию). Кроме того,™к моделям/ЛЕ, создаваемым из этих шаблонов, применяется профиль преобразования Enterprise Java Beans (EJB) и загружается контент по умолчанию из данных шаблонов (см. рисунок 13). В данной статье мы не будем объяснять, как использовать контент компоновочных блоков прецедентов и поисковые строки, но вы найдете подробные инструкции в примечаниях, которые имеются в шаблонах. .

Рисунок 13. Контент по умолчанию шаблона Модели проектирования корпоративных информационных систем в рассматриваемых продуктах

Как уже говорилось ранее в разделе "Организация моделей в RUP", описанные здесь подходы - не единственные, которые стоит рассмотреть. Например, характер специализации трудовых ресурсов в ваших коллективах разработчиков может говорить о том, что при выборе принципа организации модели следует в большей степени опираться на архитектурные уровни (и в меньшей степени - на функциональную декомпозицию) .

На рисунке 14 показаны методы структурирования моделей проектирования, основанные на общем принципе, который диктуется шаблоном Модели проектирования корпоративных информационных систем (Enterprise IT Design Model).

Рисунок 14. Организация Модели проектирования на высоком уровне

Это следующие методы и варианты:

Отделите спецификации от проектов реализации (типа интерфейсов и поддерживаемых паттернов взаимодействий). На иллюстрации показано использование пакетов верхнего уровня Соглашения проекта и Проекты реализации в качестве одного из способов реализации. Альтернативой описанному методу будет размещение спецификаций и проектов реализаций в отдельных моделях/ЛЕ.
Используйте пакеты низлежащих уровней для создания ориентированных на функции группировок.
В пакетах, объединяющих семантические элементы модели, разместите диаграммы, которые описывают специфические для данной группировки представления, но не отображают элементы за ее пределами. Эта рекомендация подходит независимо от того, на чем строится группировка - на функционально ориентированных подмножествах предметной области бизнеса, архитектурных уровнях или на чем-либо еще. Дайте диаграмме по умолчанию имя, соответствующее имени пакета или компонента и скомпонуйте ее таким образом, чтобы она представляла обзор контента данного пакета. Благодаря этому некоторые диаграммы будут ближе к тем моментам, которые они отображают, что упростит навигацию по модели и ее понимание.
Подумайте об использовании инвертированного пространства доменных имен Интернета в Модели проектирования. Основания:
1. (В принципе, это те же основания, по которым применение описанных методов важно для зависимых от языка реализаций):
  - сценарии, связанные с работой по интеграции, при которых используется несколько управляемых моделями приложений (особенно с партнерскими компаниями);
  - сценарии с многократным использованием.
2. Вероятно, это упростит последующую конфигурацию преобразований для реализации (отображение имен и размещений исходной модели на целевую).

Чтобы избежать осложнений и возможной путаницы в отображении пространств имен старайтесь использовать для пакетов такие имена, которые будут корректными в целевых платформах реализации. (Часто это просто означает следующее: Не используйте в именах символы пробелов или знаков пунктуации кроме символов подчеркивания.)
Подумайте об использовании строчных букв для имен пакетов, чтобы их было проще отличить от имен классов в пакете.
Подумайте об использовании разных имен для Интерфейсов и Компонентов или классов, которые их реализуют. Для имен интерфейсов и реализаций используйте либо ILoan и Loan, либо Loan и LoanImpl. На самом деле, это не обязательно в модели, но часто является хорошей идеей для сгенерированного кода. Следовательно, это еще одна область, в которой вы можете сократить для себя объем работы, связанной с конфигурированием последующих преобразований.

Если вы решили не использовать отдельную Модель анализа, но хотите работать с определенным контентом на аналитическом уровне абстракции в Модели проектирования и при этом планируете использовать преобразования "модель-текст (код)", то подумайте о выделении контента уровня анализа (из которого, предположительно, не планируется генерировать код) в пакеты, стереотипизированные как <<analysis>> (такие пакеты будут проигнорированы в процессе преобразования.)

Для документирования представлений элементов проектирования высокого уровня, идущих в разрез с общей концепцией, используйте диаграммы в пакетах <<perspective>>. Обоснование: Создайте особые представления, представления архитектурно значимого контента и представления, которые апеллируют к другим типам заинтересованных лиц, сохранив организацию семантических элементов модели в функционально-ориентированные группировки.

Совет:
важно понимать, что структура организации пакетов в Моделях проектирования с течением времени будет развиваться.

Первоначальная организация Модели проектирования в практике использования RUP, как правило, будет в большей или меньшей степени соответствовать организации восходящей Модели прецедентов или анализа. (Структура пакетов классов анализа часто подвергается значительной реорганизации по мере того, как она разрабатывается, для лучшей поддержки многократного использования и непредвиденных функциональных требований.) Однако в конечном итоге эта организация должна эволюционировать, отражая принцип структурирования архитектуры на компоненты и сервисы, поскольку этот подход к завершающей фазе организации проекта впоследствии сможет предоставить лучшие возможности для создания пакетов активов многократного использования. Кроме того, это самый естественный переход от проекта к набору проектов и папок, которые будут содержать артефакты реализации, сгенерированные из этого проекта (код, метаданные, документация).

Безусловно, для организации проекта в завершающей фазе можно (а в некоторых случаях даже рекомендуется) использовать и альтернативные подходы. Например, если вы выбираете Web-приложения на базе платформы Java™ Enterprise, то в структуре проекта можно предусмотреть соглашения Rational Software Architect и Rational Application Developer, касающиеся проектов J2EE (см. врезку).

Соглашения Rational

Говоря в общем, соглашения Rational предполагают:

один Корпоративный проект на приложение или сервис или более крупную подсистему;
для каждого Корпоративного проекта - один Web-проект для уровня презентации и несколько EJB-проектов (причем EJB-проекты, как правило, соответствуют компонентам, сервисам или менее крупным подсистемам, а для уровней "session EJB" и "domaiin entity EJB" каждого компонента или подсистемы используется отдельный EJB-проект);
дополнительные Web-проекты для любых сервисов, предлагаемых как Web-сервисы;
дополнительно: Любое количество Java-проектов, включающих вспомогательные классы, фирменные компоненты инфраструктуры и т. п.

В частности, вы можете создать пакеты проекта верхнего уровня, которые будут соответствовать архитектурным уровням (Уровень представления и Бизнес-уровень, причем Бизнес-уровень подразделяется на Сеансовый уровень и Уровень предметной области). В общем-то, этот подход не является платформенно-нейтральным, поэтому его можно порекомендовать только в тех случаях, если проектируемое решение не будет реализовано на каких-либо платформах, кроме J2EE.

Этот подход к организации проектов не является платформенно-нейтральным, поэтому можно рекомендовать его только в тех случаях, если проектируемое решение будет реализовано в среде Enterprise Java. Но в большинстве случаев при создании n-уровневых приложений имеет место ситуация, при которой опыт разработчика и разделение труда соответствуют уровню презентации и бизнес-уровню. Следовательно, и в этом случае вы должны использовать пакеты верхнего уровня, соответствующие архитектурным уровням, но при этом вы все же должны обеспечить отображение структуры проекта в набор выбранных проектов и папок, направив дополнительные усилия на конфигурирование преобразований генерации кода. (Для определения особенно сложных отображений можно также использовать специальную дополнительную модель, так называемую модель отображения) . Но, в общем-то, следует с осторожностью использовать организацию модели с опорой на конкретную архитектуру, а не на функциональную сцепленность, слабую связанность и монопольное владение.

Контент Модели проектирования

Жестких правил в отношении того, какой контент включать в Модель проектирования, не существует. Способ, которым вы моделируете конкретный аспект проекта (или, в данном случае, если вас даже просто беспокоит моделирование определенного аспекта) должен зависеть от того, какую бизнес-ценность сможет добавить данный подход к моделированию. Для одних коллективов получение максимального преимущества от моделирования означает определение рекомендаций (и, может быть, UML-профилей) для использования небольшого, но весьма выразительного набора представлений, которые поступают на вход настроенных преобразований, генерирующих большую часть реализации. Для других, задачи которых в большей степени ориентированы на четкое отображение контракта на проектирование для поддержки (неавтоматизированной) оффшорной разработки реализации, более детализированное представление на уровне UML-модели может больше отвечать поставленным задачам.

Учитывая все вышесказанное, некоторые из подходов, описываемые следующими иллюстрациями, могут оказаться полезными для тех, кто планирует моделировать значительные объемы деталей проекта. На рисунке 15 изображена проектируемая модель для сервиса Интернет-аукциона, демонстрирующая представление его контента на высоком уровне. Данная модель проектирования представляет собой естественное развитие модели анализа.

Рисунок 15. Незавершенная модель проектирования для сервиса Интернет-аукциона

На рисунке 16 обратите внимание на то, что контракт на использование для сервиса ListingService определен в виде одного Интерфейса. (Структура пакетов классов анализа часто подвергается значительной реорганизации в ходе разработки для обеспечения лучшей поддержки многократного использования и непредвиденных функциональных требований.) Соответствующий контракт на реализацию определяется набором реализаций прецедентов на уровне проекта. (Остальные компоненты могут участвовать только в одном системном прецеденте, а их контракты на реализацию могут размещаться в одних и тех же реализациях прецедентов). Обратите внимание на следующую особенность: в то время, как реализации прецедентов на аналитическом уровне отображают кооперации между классами анализа, реализации на уровне проектирования отображают кооперации между менее абстрактными элементами проектирования.

Рисунок 16. Контракт на проектирование, смоделированный в виде интерфейса и реализаций прецедентов на уровне проектирования

На рисунках 16 и 17 обратите внимание на то, что объекты передачи данных (data transfer objects, DTO, включены в состав проекта реализации. Эти DTO-объекты используются в качестве типов параметров предоставляемых операций и могут также отображаться на конструкции реализации типа XML- схемы или объекты данных сервиса (service data objects, SDO). Для компонентов, которые не предназначены для распределенного использования, можно использовать только специфические для реализации объекты передачи данных (например, реальные Java-классы), поскольку спецификации типов используются в качестве параметров операций. Однако для сервисов, предполагающих распределенное использование (Web-сервисов) типа ListingService необходимо, чтобы операции сервиса не ссылались на объекты в локальном адресном пространстве, то есть, чтобы для представления полезной нагрузки сообщений использовались DTO-объекты, указанные в спецификации. Для примера с сервисом ListingService DTO-объекты в действительности определены таким образом, чтобы обеспечить их соответствие набору спецификаций сообщений, определенных в гипотетическом отраслевом стандарте (как видно из рисунка 16).

Рисунок 17. Подход, в котором для представления проектирования реализации используются классы и методы

Один из возможных подходов к определению проектов реализаций изображен на одном из предыдущих рисунков, 17, на котором структура реализации определяется при помощи простых классов, содержащих операции. Этот подход довольно типичен для моделей проектирования, созданных при помощи UML 1.

Еще один возможный подход, который, возможно, больше отвечает целям UML 2, изображен на рисунке 18, на котором мы видим, что используются Компоненты и что эти Компоненты владеют не Операциями, а Поведениями (в данном случае, Взаимодействием).

Рисунок 18. Альтернативный подход к представлению проекта реализации при помощи Компонентов, которыми владеют Поведения

Рекомендации для остальных моделей RUP

По сравнению с Моделями прецедентов решения, анализа решения и проектирования, о нижеперечисленных моделях RUP нам не придется говорить долго:

Модель бизнес-прецедента;
Модель бизнес-анализа;
Модель развертывания;
Модель информации;
Модель реализации.

Для этих моделей в программном обеспечении для управления архитектурой Rational шаблоны не предусмотрены. Как правило, структуру таких моделей рекомендуется строить по принципу монопольного владения

Структура Моделей бизнес-прецедентов и бизнес-анализа, вероятно, не должна слишком отличаться от их аналогов на уровне решения.

Модели реализации в рассматриваемых продуктах состоят из проектов Eclipse, а также артефактов кода и метаданных и диаграмм, на которых изображены эти артефакты. Следовательно, архитектура реализации будет непосредственно определять схему структуры модели реализации.

Структура Моделей развертывания, как правило, будет иметь очень мало восходящих или нисходящих включений. Просто делайте то, что имеет больше смысла в вашей ситуации. Например:
- спецификации конфигураций продуктов отделены от спецификаций тестовых конфигураций;
- обзоры (кластеров, центров данных или корпораций) обслуживаются в пакетах <<perspective>>;
- в рассматриваемых продуктах организация пакетов в сочетании с ключевыми словами используется в качестве упрощенного подхода к специализации и классификации узлов и артефактов. Более сложный подход заключается в разработке специализированного UML-профиля, который будет определять специализированные стереотипы и свойства, являющиеся подходящими для описания и документирования типов ресурсов, используемых в конкретной среде.

Ссылки по теме