Моделируем сервис-ориентированную архитектуру при помощи IBM Rational Software Architect: Часть 2. Моделирование предметной...

Источник: IBM Developerworks Россия

Грегори Ходжкинсон, ведущий специалист по SOA, 7irene (IBM Tier 1 Business Partner) & Бертран Портье, IT-архитектор, IBM

Перед началом работы

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

О данной серии

В этой серии из нескольких статей рассказывается о том, как моделировать сервис-ориентированные архитектуры (SOA) при помощи IBM®Rational® Software Architect. Хотя изначально это программное решение предназначалось для разработчиков архитектуры программного обеспечения и для поддержки их деятельности, оно может оказаться полезным также специалистам, выполняющим другие роли в процессе разработки программного обеспечения, в том числе тем, кто вносит свой вклад в разработку архитектуры ПО, например, бизнес-аналитикам или тем, кто использует эту архитектуру в качестве отправной точки собственной деятельности, например, проектировщикам программного обеспечения и разработчикам (занимающимся реализацией архитектуры, проектированием и созданием ПО). Кроме того, в этой серии объясняются многие основные концепции SOA, которые могут заинтересовать и других специалистов.

Эти учебные руководства концентрируются на трех темах:

Архитектура: описывает, из чего состоит архитектура и как она вписывается в общий процесс разработки программного обеспечения;
Сервисы: создают архитектуру SOA-системы (сервисы - основное понятие этой архитектуры);
Модели: демонстрируют, как Rational Software Architect поддерживает использование принципа разработки, управляемой моделями (MDD) при создании спецификации сервис-ориентированной архитектуры.

В части 1 описывается архитектура программного обеспечения и определяется место сервисов в ней. Затем рассказывается о программном продукте Rational Software Architect и его функциях и инструментах, имеющих отношение к SOA- и архитектуре. Учебный пример с воображаемым бизнесом по прокату DVD-дисков через интернет, который используется на протяжении всей серии статей, помогает проиллюстрировать главные задачи:

описание рабочих продуктов, используемых в качестве исходных для деятельностей сервис-ориентированной архитектуры, в том числе моделей бизнес-компонентов, бизнес-процессов, примеров использования системы и внешних систем, являющихся частью проектной модели;
пошаговое описание процедуры определения модели сервиса, отображающей архитектуру, в Rational Software Architect, включая потребителей сервиса, спецификации сервиса, разделы сервиса, индивидуальных и составных поставщиков сервиса, сервисы, координацию совместных действий сервисов, взаимодействия сервисов и каналы сервисов;
объяснение того, как модель сервиса затем используется на следующих этапах процесса разработки программного обеспечения, таких как проектирование и реализация.

О данном учебном руководстве

В части 1 мы представили учебный пример "Прокат видеодисков", который используется во всех учебных руководствах данной серии. Затем мы поместили архитектуру сервиса в инфраструктуру IBM Rational Unified Process (RUP) и для справки рассказали об IBM SOA Solution Stack. Наконец, мы упомянули о различных рабочих продуктах, которые были использованы как исходные при построении архитектуры сервиса, а затем воспользовались учебным примером для того, чтобы продемонстрировать два из таких продуктов: модель архитектуры бизнеса (описана в части 1 как компонентная бизнес-модель) и модель бизнес-процесса . Модель архитектуры бизнеса и модель бизнес-процесса представляют собой этапы моделирования по принципу "сверху вниз". Во второй части серии мы описываем следующую по порядку модель: модель предметной области .

Цели

Изучив данное учебное руководство, вы сможете:

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

Необходимые условия

Чтобы извлечь максимум пользы из этого учебного руководства, очень полезно (но не обязательно) иметь представление о трех концепциях:

сервис-ориентированная архитектура (service-oriented architecture, SOA);
IBM Rational Software Architect V7.0 (рекомендуется пакет исправлений fix 002 или более поздняя версия);
унифицированный язык моделирования Unified Modeling Language (UML).

Мы настоятельно рекомендуем вам изучить часть 1 данной серии учебных руководств прежде, чем перейти к данной части.

Требования к системе

Rational Software Architect версии 7 (рекомендуется пакет исправлений fix 002 или более поздняя версия)

Работа с предметной областью бизнеса

Мы уже очень коротко упоминали о модели предметной области в части 1 этой серии. Напомним, что это краткое определение было таким: "консолидированное представление бизнес-информации". Ниже мы приводим более полное определение из IBM Terminology:

модель, в которой фиксируются самые важные типы объектов в контексте предметной области. Объекты предметной области представляют собой имеющиеся сущности или события, происходящие в среде, в которой работает система. Модель предметной области является подмножеством модели анализа бизнеса.

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

Позиционирование модели предметной области

В инфраструктуре IBM Rational Unified Process (RUP) предметная область - это рабочий продукт, принадлежащий к дисциплине Business Modeling, в рамках которой она иногда описывается как вариант модели анализа бизнеса. В терминах RUP модель предметной области "описывает информационный контент организации". Она принадлежит к роли Аналитик Бизнес-процесса и чаще всего создается на начальном этапе проектирования в стиле RUP. Модель предметной области можно рассматривать как представление визуализации (визуального представления) структурных отношений между бизнес-факторами, которые описываются в бизнес-глоссарии рабочего продукта. Мы рассматриваем модель предметной области как один из рабочих продуктов, создаваемых в ходе применения принципа моделирования "сверху вниз", наряду с моделью бизнес-процесса и моделью архитектуры бизнеса..

Как убедиться, что решение адекватно

Дисциплина Business Modeling в RUP поставляет набор моделей бизнеса, призванных улучшить наше понимания структурных и поведенческих аспектов бизнеса. Как разработчикам ИТ-систем, это нужно нам для того, чтобы иметь определенный контекст для создаваемых систем. Кроме всего прочего, как мы могли бы узнать, что разрабатываемые ИТ-системы и бизнес, для поддержки которого они разрабатываются, соответствуют друг к другу, если у нас нет ясного представления об этом бизнесе? Поэтому именно указанная потребность в "хорошем соответствии" и определяет цель бизнес-моделирования.

На рисунке 1 представлена схема обратного анализа, на которой от ИТ-системы к рабочим продуктам, созданным на этапах бизнес-моделирования "сверху вниз", проведены соединительные линии (в терминах RUP рабочие продукты на этом рисунке определены как продукт или решение ). Эти соединительные линии полезны при оценке качества соответствия вашей ИТ-системы.

Рисунок 1. Соединительные линии в схеме обратного анализа, помогающие оценить качество соответствия ИТ-системы потребностям бизнеса

Мы определили бы значение этих линий от продукта/решения следующим образом:

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

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

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

Создание модели предметной области в Rational Software Architect

Модели предметных областей, без сомнения, являются самыми простыми из всех моделей UML, которые мы предполагаем создать в данной серии учебных руководств. По сути, в этом разделе она является примером для описания ряда основных средств и функций UML-моделирования в Rational Software Architect. Для начала работы:

Запустите Rational Software Architect. Выберите команду Window > Open perspective > Modeling, чтобы открыть представление Modeling;
Выберите команду File > New > Project, а затем выберите из списка UML Project и нажмите кнопку Next;
Введите в качестве имени проекта SOA Tutorial и снимите выделение. В этом проекте создайте новую модель UML (мы создадим в ней первый UML-проект отдельным действием, чтобы показать, как это делается);

Параметры UML Project после этого должны выглядеть так, как на рисунке 2.

Рисунок 2. Создание нового проекта
Снимок экрана, иллюстрирующий создание нового проекта

Совет:
если в шаге 2 выбрать обычный проект, то результат будет тем же.

Теперь в этом проекте нужно создать предметную область.

Выделите проект SOA Tutorial . Нажмите на нем правой кнопкой мыши и выберите команды New > UML Model;
В диалоговом окне New UML Model сохраните выделение на шаблоне Standard и нажмите кнопку Next;
Введите имя файла Domain Model и снимите выделение. Создайте в модели схему по умолчанию;
Нажмите кнопку Finish.

Теперь в нашем проекте SOA Tutorial есть пустая предметная область, показанная на рисунке 3.

Рисунок 3.Только что созданная, но незаполненная предметная область
Снимок экрана, демонстрирующий пустую предметную область

Теперь необходимо придать этой предметной области определенную структуру. Это можно сделать, создав пакет для предметной области, которую мы будем моделировать.

Какая именно предметная область нам нужна? В бизнес-процессе Return Video, моделирование бизнес-процессов, описанное в части 1, сосредоточено на компоненте функциональной области Online Rentals. Изучив схему архитектуры бизнеса (рисунок 6 в части 1), можно заметить, что функциональная область является частью предметной области Rental. Значит, предметная область, на которой мы сконцентрируемся, это предметная область Rental.

Создание пакета предметной области

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

Выделите Domain Model, нажмите на ней правой кнопкой мыши, а затем выберите команды Add UML > Package. Присвойте пакету имя Rental;
Удалите главную диаграмму Main diagram; для этого нажмите на ней правой кнопкой мыши и выберите из контекстного меню команду Delete from Model;
Создайте новую диаграмму; для этого нажмите правой кнопкой мыши на пакете Rental, а затем выберите команды Add Diagram > Class Diagram. Присвойте диаграмме классов имя Rental.

Теперь у нас есть модель предметной области с пакетом предметной области Rental и диаграмма Rental Domain, показанные на рисунке 4, которые готовы принять информацию предметной области.

Рисунок 4. Пакет предметной области Rental
Снимок экрана с изображением предметной области rental

Использование первоначальной модели предметной области, созданной на этапе бизнес-моделирования

В части 1 в роли бизнес-аналитика вы создали проект WebSphere Business Modeler (WebSphere modeler), чтобы моделировать бизнес-процессы в рамках этого проекта. При этом мы определили набор бизнес-объектов внутри пакета IBM WebSphere Business Modeler, который получил название Business items (Рисунок 5).

Рисунок 5. Дерево проекта DVD Rental в WebSphere modeler DVD Rental

Теперь мы воспользуемся одной из функций интеграции Rational Software Architect WebSphere modeler (мы имеем в виду функцию интеграции WebSphere modeler, которая является компонентом Rational Software Architect) для открытия проекта WebSphere из Rational Software Architect, чтобы можно было просмотреть его как UML.

Выберите команду File > Import. На странице мастера импорта Import выберите опцию Existing Project into workspaceи нажмите кнопку Next;
На странице Import Projects мастера выделите каталог Root и укажите рабочую область WebSphere modeler;
Убедитесь в том, что проект DVD Rental выделен в списке Projectsи нажмите кнопку Finish;

Обозреватель проектов Project Explorer в вашей рабочей области должен выглядеть так же, как на рисунке 6.

Рисунок 6. Проект DVD Rental, импортированный в Rational Software Architect

В иерархии проекта DVD Rental выберите Models и выполните двойной щелчок мышью на DVD Rental, чтобы открыть этот проект. Этот проект является представлением модели бизнес-процесса в форме UML, открытым только для чтения. Функция интеграции Rational Software Architect-WebSphere modeler предоставляет отображение элементов модели в WebSphere modeler в элементы моделей UML. Теперь мы можем ознакомиться с UML-представлением модели бизнес-процесса;
Просмотрите элементы модели проекта в обозревателе проектов Project Explorer (Рисунок 7). Вы должны знать эту структуру и элементы модели из части 1.

Рисунок 7. Дерево проекта DVD Rental, развернутое в Project Explorer
Снимок экрана, показывающий элементы модели проекта DVD Rental в Project Explorer

Нас особенно интересует пакет Business items. В этом простом примере есть только один элемент модели, Video. Обратите внимание на то, что UML-стереотип <<BusinessEntity>>(Бизнес-сущность) применяется к этому бизнес-объекту. Указанный стереотип определен в профиле Rational UML для бизнес-моделирования. Ссылки на дополнительные ресурсы с информацией об этом профиле или об интеграции Rational Software Architect-WebSphere Modeler можно найти в разделе Ресурсы.

В следующем разделе мы используем бизнес-сущность Video, чтобы проложить к ней трассируемую связь от класса предметной области Video (из модели предметной области).

Моделирование классов предметной области

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

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

Рассматривая бизнес-процесс Return Video в части 1, вы уже познакомились с несколькими классами предметной области. Далее мы приводим последовательность процесса, где потенциальные классы предметной области ("элементы") выделены полужирным шрифтом.

Участник системы DVD2U ,воспользовавшись предоплаченным конвертом, отправляет видео-диск обратно в хранилище DVD2U;
По желанию он заходит в свою учетную запись DVD2U через Web-браузер и обновляет список фильмов, записывая в него отравленные по почте (сданные) фильмы;
По завершении этих действий система извлекает информацию о репутации данного участника;
Спустя один или два дня специальный сотрудник DVD2U, получающий почтовые отправления (Receiving Clerk) и работающий в хранилище, получает отправленный участником видео-диск;
Затем упомянутый сотрудник проверяет состояние видео-диска;
Если указанный участник сообщил в DVD2U о возврате видеодиска и репутация этого участника хорошая, то система обновляет соответствующий профиль участника, чтобы информировать его о том, что необходимо оплатить следующий фильм из его списка;
После проверки дискасотрудник Receiving Clerk записывает квитанцию для этого диска в систему;
Система добавляет копию диска обратно в общее хранилище.

Давайте начнем с первого потенциального класса предметной области: участника системы Member.

Откройте диаграмму Rental Domain выполнив двойной щелчок на ней в обозревателе проектов Project Explorer;
Нажмите правой кнопкой мыши в области открытой диаграммы в редакторе диаграмм Diagram Editor. Затем выберите команды Add UML > Class. Присвойте классу имя Member;
Убедившись, что новый класс выделен, перейдите в секцию Stereotypes представления Properties;
Введите domainType в поле Keywords и нажмите клавишу Enter;
Повторите шаги 2 и 3 для остальных потенциальных классов предметной области.

Примечание:
мы воспользовались ключевым словом для описания нашего класса предметной области. Есть и другие варианты - воспользоваться предопределенными стереотипами Rational Software Architect, конкретнее, стереотипом <<BusinessItem>> из профиля Business Modeling, или создать новый профиль UML, который будет определять стереотип <<domainType>>.

На рисунке 8 показано, как должна выглядеть диаграмма предметной области.

Рисунок 8. Потенциальные классы предметной области
Снимок экрана с изображением диаграммы предметной области

Трассируемость с моделью бизнес-процессов:

класс предметной области Video в модели предметной области представляет тот же "элемент", что и бизнес-объект video в модели бизнес-процесса. Это просто другое представление на более низком уровне абстракции (более детализированное представление). Теперь можно записать это в нашу модель предметной области, добавив трассируемую связь от класса предметной области Video к бизнес-объекту Video.

Перетащите при помощи мыши бизнес-сущность Video из проекта DVD Rental в область диаграммы предметной области.

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

С диаграммы предметной области переведите курсор на класс предметной области Videoи немного подождите;
Когда появится исходящая соединительная линия, перетащите ее конец на бизнес-сущность Video;
Выберите из меню команду Trace (Рисунок 9).

Рисунок 9. Создание трассируемой связи
Трассируемая связь

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

Рисунок 10. Трассируемая связь абстракции

Совет:
в нашем учебном руководстве мы показываем только один пример трассируемости и не будем выполнять описанные действия для других элементов модели. Трассируемость очень полезна для отслеживания того, как проект выполняет требования. Например, можно создать трассируемые связи элементов модели в Rational Software Architect с требованиями в IBM Rational RequisitePro и проанализировать влияние изменений в требованиях или высокоуровневой модели на проект.

Рационализация классов предметной области

Теперь давайте рассмотрим потенциальные классы предметной области, которые нужно рационализировать. В нашем примере мы сделали следующий вывод:

каждый участник всегда имеет профиль участника MemberProfile и учетную запись Account.. Следовательно, мы решили свернуть эти три класса предметной области в один. Другими словами, когда мы говорим об участнике, мы также подразумеваем ссылку на профиль участника и его учетную запись;
класс предметной области Video определен слишком неоднозначно. В описании процесса мы видим, что данный термин используется как минимум в двух значениях:
- для идентификации уникального названия видеофильма;
- для идентификации конкретной копии видеофильма.
По этой причине мы переименуем Video в VideoTitle, чтобы сделать определение более точным;
Классы List и MovieList ссылаются на один и тот же элемент, поэтому их можно свернуть в один класс. Мы меняем их на класс VideoList, чтобы обеспечить большую согласованность имен (используем не movie, а video ).

Результат применения этих выводов к диаграмме показан на рисунке 11. Чтобы внести эти изменения, мы:

удаляем классы предметной области, которые нам больше не нужны, нажав правой кнопкой мыши на классе предметной области либо в обозревателе проектов Project Explorer, либо в редакторе диаграмм Diagram Editor, а затем выбрав из контекстного меню команду Delete from Model;
переименуем классы предметной области; для этого выполним на них щелчок левой кнопкой мыши в редакторе диаграмм Diagram Editor, нажмем клавишу F2, после чего введем новое имя , а затем снова нажмем Enter.

Рисунок 11. Рационализированный набор классов предметной области
Снимок экрана, отображающий классы предметной области

Моделирование ассоциаций классов предметной области

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

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

Давайте рассмотрим процедуру применения этого первого заключения к нашей модели предметной области.

Нажмите кнопку Associacion в представлении Palette (см. рисунок 12);

Рисунок 12. Кнопка Association в представлении Palette
Снимок экрана: кнопка Association в представлении Association

Затем нажмите мышью на классе предметной области Member в редакторе диаграмм Diagram Editor и, удерживая кнопку мыши, перетащите ассоциацию на класс предметной области VideoList;

Результат показан на рисунке 13.

Рисунок 13. Ассоциации между классами Member и VideoList

Случайно кратность этой ассоциации оказалась правильной, поэтому нам не придется ее изменять. Тем не менее, давайте подумаем о будущем и рассмотрим пример, который нуждается в изменении.

После 1 и 2 шага создайте ассоциацию между классами VideoList и VideoTitle;

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

Рисунок 14. Первоначальная ассоциация между VideoList и VideoTitle

Выделите ассоциацию между VideoList и VideoTitle, а затем перейдите на вкладку General представления Properties и измените параметр multiplicity (кратность) роли VideoList на * (символ звездочки), а multiplicity (кратность) роли VideoTitle на 1..* (Рисунок 15);

Рисунок 15. Изменение ассоциации между VideoList и VideoTitle

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

Примечание:
на этой диаграмме мы удалили имена ролей, чтобы сделать ее менее сложной для чтения.

Рисунок 16. Добавление ассоциаций в диаграмму предметной области

Моделирование атрибутов классов предметной области

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

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

Нажмите правой кнопкой мыши на Member в редакторе диаграмм Diagram Editor и выберите из контекстного меню команды Add UML > Attribute;
Выберите для нового атрибута имя userName;
Тем же способом добавьте фамилию (name)и адрес (address) в качестве атрибутов Member;

Результат показан на рисунке 17 (обратите внимание на альтернативный способ для быстрого добавления атрибутов при помощи панели действий).

Рисунок 17. Member и его новые атрибуты

Измените тип каждого из этих атрибутов, выполнив щелчок мышью на Member в редакторе диаграмм Diagram Editor, а затем в секции Атрибуты представления Properties;
Нажмите и отпустите левую кнопку мыши в столбце Type рядом со значением userName в этом списке, а затем нажмите кнопку;
Введите String в диалоговом окне Search. Выберите из результирующего списка String - UMLPrimitiveTypes::String (возможно, это значение будет единственным в списке);
Нажмите кнопку OK;
Выполните те же действия, чтобы задать для двух других атрибутов тот же тип String;

Результат должен быть таким, как на рисунке 18. Обратите внимание на то, что записи в списке атрибутов отображаются для ассоциаций с классами VideoList, MemberStanding и VideoCopy (первые три записи).

Рисунок 18. Определение типов атрибутов
Снимок экрана: определение типов атрибутов

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

Чтобы смоделировать эту ситуацию, мы заменим ассоциацию между двумя классами предметной области пересечением классов предметной области. При помощи описанных выше шагов удалите ассоциацию между указанными классами, создайте новую предметную область с именем MemberRental и новое соединение ассоциаций MemberRental с каждым из классов Member и VideoCopy. Результат показан на рисунке 19.

Рисунок 19. Новое пересечение классов предметной области MemberRental

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

Создайте новый пакет PrimitiveTypes в модели предметной области;
Нажмите правой кнопкой мыши на этом новом пакете, а затем выберите из контекстного меню команды Add UML > Primitive Type;
Присвойте этому типу имя Timestamp. Этот примитивный тип данных мы будем использовать для атрибутов, которые содержат комбинацию даты и времени;
Теперь добавьте новый атрибут с именем estimatedMemberReceipt;
Определяя тип атрибута, выполните те же шаги, что и ранее, с добавлением следующей строки поиска Timestamp -- Domain Model::PrimitiveTypes::Timestamp и выберите примитивный тип Timestamp из этого списка, как показано на рисунке 20;

Рисунок 20. Выбор примитивного типа Timestamp

Аналогичным образом добавьте VideoListTitle между VideoList и VideoTitle. Обратите внимание на то, что VideoListTitle в действительности является частью VideoList. Мы заметили это, настраивая атрибут агрегации ассоциации;
Выделите ассоциацию между VideoList и VideoListTitle, затем перейдите в секцию Stereotypes в представлении Properties;
На стороне ассоциации, соответствующей VideoList установите значение Aggregation в Composite (выбрав соответствующую опцию, как показано на рисунке 21);

Рисунок 21. Установка значения composite для атрибута aggregation

После добавления дополнительных атрибутов текущая диаграмма предметной области будет выглядеть так, как показано на рисунке 22.

Рисунок 22. Диаграмма предметной области Rental после добавления атрибутов

В MemberRental классы returnNotification, estimatedWarehouseArrival и memberComments не будут иметь значений, в начале существования MemberRental. Поэтому вам нужно пометить их как необязательные, что делается посредством определения кратности.

Выделите класс предметной области MemberRental на диаграмме;
В секции Attributes представления Properties задайте для параметра Multiplicity каждого из этих классов значение 0..1, как показано на рисунке 23;

Рисунок 23. Настройка кратности атрибутов классов предметной области

Чтобы эта информация отображалась на диаграмме, необходимо изменить параметры фильтра отображения для предметной области MemberRental в диаграмме:

Нажмите правой кнопкой мыши на классе предметной области MemberRental на диаграмме, а затем выберите команды Filters > Show Signature.

Моделирование перечислений в предметной области

Иногда полезно добавить дополнительные детали в диаграмму предметной области в виде перечисления. Из справки по Rational Software Architect: "Допускается добавление в модель перечислений, которые позволяют системам программного обеспечения указывать дискретные наборы значений". В нашем примере мы используем перечисления для отображения дискретных наборов значений, существующих в данной предметной области бизнеса.

На нашей диаграмме предметной области есть два участка (они показаны на рисунке 16), в которых можно заметить дискретные наборы значений:

Member.memberStanding (ассоциация);
VideoListTitle.status (атрибут).

Давайте сначала рассмотрим атрибут VideoListTitle.status. Мы создадим новое перечисление VideoListTitleStatus для отображения набора возможных значений.

Нажмите правой кнопкой мыши на пустом участке диаграммы предметной области, выберите из контекстного меню команды Add UML > Enumerationи задайте для него имя VideoListTitleStatus;
Нажмите правой кнопкой мыши на новом перечислении и выберите команды Add UML > Enumeration Literal, а затем введите ADDED;

Теперь у нас есть новое перечисление VideoListTitleStatus с возможным значением ADDED.

Добавьте следующие допустимые значения для этого состояния как перечисляемые константы (точно так же, как в предыдущем случае): PARKED, SENT, RETURNED;
Замените тип для VideoListTitle.status этим новым перечислением;
Выделите атрибут VideoListTitle.status. В секции General представления Properties измените значение Type на VideoListTitleStatus;
Нажмите правой кнопкой мыши на атрибуте VideoListTitle.status, а затем выберите из контекстного меню команды Filters > Show as Association;

После этого атрибут будет отображаться на диаграмме как ассоциация с перечислением VideoListTitle.

Измените класс предметной области MemberStanding на перечисление MemberStanding;
Добавьте допустимые значения STANDARD, VALUED и HIGH-RISK;
Добавьте еще одно перечисление с именем VideoCopyStatus и допустимыми значениями RENTED_OUT, BEING_RETURNED, RECEIVED_INTO_STOCK и READY_FOR_RENTAL.

Теперь эти перечисления существуют на диаграмме предметной области (рисунок 24).

Рисунок 24. Диаграмма предметной области Rental с добавленными перечислениями

Моделирование ограничений предметной области

Сложные правила можно добавить в диаграмму предметной области в форме ограничений. Еще раз обратимся к справке по Rational Software Architect:

в UML-моделях ограничение - это дополнительный механизм, который позволяет уточнить семантику элементов UML-модели. Ограничение уточняет элемент модели посредством выражения условия или ограничения в текстовой инструкции, которой должен удовлетворять элемент модели.

На нашей диаграмме предметной области все еще не отражены три ситуации, известные нам об этой предметной области:

если копия видеофильма на данный момент поступила в хранилище или готова к выдаче, то она будет числиться в фонде хранилища и ей будет соответствовать определенное место в хранилище;
если копия видеофильма в данный момент находится "на руках", то для нее будет определен статус проката участнику системы, в котором будут указаны сведения о ее отправке и предполагаемая дата ее получения участником;
если в данный момент осуществляется возврат копии видеофильма, то для нее будет определен статус проката, в котором будет отмечен ее возврат и указана дата предполагаемой доставки в хранилище.

Добавьте в диаграмму новое ограничение.

Нажмите правой кнопкой мыши на VideoCopy, а затем выберите команды Add UML > Constraintиз контекстного меню;
Введите текст ограничения в следующей форме:

        "status == RECEIVED_INTO_STOCK or 
        status == READY_FOR_RENTAL implies warehouseStock != NULL"

Результат добавления еще двух ограничений в диаграмму предметной области показан на рисунке 25.

Рисунок 25. Диаграмма предметной области Rental с добавленными ограничениями

Рисунок 25. Диаграмма предметной области Rental с добавленными ограничениями

Дополнительные идеи по структурированию модели предметной области

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

Тем не менее, следует отметить еще один момент: в контексте нашей карты компонентной бизнес-модели, показанной в части 1 этой серии, сейчас имеются два класса предметной области, смоделированных в составе предметной области Rental, которые, вероятно, больше подошли бы к предметной области Warehousing. Это такие классы предметной области, как Warehouse и WarehouseStock. Давайте исправим это упущение.

Создайте пакет предметной области Warehousing, выполнив шаги, описанные для пакета предметной области Rental Domain;
Переместите класс предметной области Warehouse в этот пакет предметной области, перетащив его при помощи мыши в представление обозревателя проектов Project Explorer;
Выполните те же действия для класса предметной области WarehouseStock;
Не забудьте переместить и две ассоциации, связанные с классом WarehouseStock.

Результат показан на рисунке 26.

Рисунок 26. Пакет новой предметной области Warehousing

После размещения элементов предметной области Warehousing на диаграмме предметной области Warehousing мы получим результат, показанный на рисунке 27.

Рисунок 27. Предметная область Warehousing
Снимок экрана с изображением диаграммы предметной области Warehousing

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

Что дальше?

В этом учебном руководстве представлена всесторонняя информация о том, как моделировать "консолидированные представления бизнес-информации" при помощи моделей предметных областей. В нем объясняется необходимость разработки модели предметной области с учетом SOA-решения в смысле нацеленности на "качество соответствия". В ней подробно описывается создание модели предметной области в Rational Software Architect, начиная с набора бизнес-объектов в WebSphere Business Modeler и заканчивая соотнесением модели предметной области с этими бизнес-объектами. Мы рассказали о моделировании предметной области, включая классы предметной области, ассоциации, атрибуты, перечисления и ограничения. Модели предметной области представляют собой третий уровень моделей при разработке "сверху вниз" , о которой мы рассказываем в этой серии учебных руководств, еще два уровня - это модель архитектуры бизнеса и модель бизнес-процесса .

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

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