Главная страница « Информация « 3 курс « ООАП«

Построение UML-модели в среде Visual Paradigm 16.1. Система обработки заказов


Пособие составлено доц. кафедры СП, канд. физ.-мат. наук Малышко В. В.

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

Содержание


1. Сведения о среде Visual Paradigm 16.1
2. Система обработки заказов. Начальное описание
3. Определение требований к системе
      Упражнение 3.1. Создание действующих лиц
      Упражнение 3.2. Создание вариантов использования
      Упражнение 3.3. Добавление описаний вариантов использования
      Упражнение 3.4. Построение диаграмм деятельности в модели вариантов использования
4. Анализ системы
      Упражнение 4.1. Создание структуры модели в соответствии с соглашениями моделирования
      Упражнение 4.2. Анализ варианта использования «CRUD данных о заказах»
      Упражнение 4.3. Анализ варианта использования «Войти в систему»
5. Проектирование системы
      Упражнение 5.1. Проектирование архитектуры системы
      Упражнение 5.2. Проектирование элементов системы
      Упражнение 5.3. Проектирование схемы реляционной базы данных

1. Сведения о среде Visual Paradigm 16.1


      Visual Paradigm Community Edition [www.visual-paradigm.com] версии 16.1 -- среда объектно-ориентированного проектирования на языке UML, распространяемая бесплатно для некоммерческого использования. Для установки следует загрузить дистрибутив со страницы загрузки, установить его. Среда является многоплатформенной. GUI среды для разных платформ различается. В пособии описана реализация для Windows. При установке укажите путь, например, C:\Program Files\Visual Paradigm CE. Для запуска среды вызывается исполняемый файл Visual Paradigm.exe из директории C:\Program Files\Visual Paradigm CE\bin. При первых запусках среда будет предлагать сообщить своё имя и e-mail для получения регистрационного кода. Получив код по электронной почте, следует активировать лицензию. Некоторые функции среды доступны только в её платных версиях. Упражнения составлены с таким расчётом, что для их выполнения достаточно возможностей бесплатной версии (Community Edition).

      Запустив среду, указываем путь к рабочей области (workspace), в которой будет находиться файл нашего проекта. Если автоматически не появилось окно Workspace Launcher, Вы можете самостоятельно настроить путь к рабочей области через меню File -> Switch Workspace (или возможный вариант: Help -> Switch Workspace). Настроим вид окна приложения. Вкладка меню Window -> Application options -> General -> вкладка Appearance (или возможный вариант: меню -> Tools -> Application options -> General -> вкладка Appearance). Устанавливаем User Interface: Classic; Look & Feel Theme: Gray. Чтобы настройки вступили в силу, перезапускаем среду. Если Вы оставите настройку User Interface: Sleek, то вид окон и меню будет значительно отличаться. Далее в пособии будут приводиться скриншоты и для режима Sleek, а также возможные варианты пунктов меню и проч.

      Необходимо начинать не с пустого проекта, а с шаблона, в котором уже создана основная структура модели, добавлены стереотипы и проектные механизмы JDBC и XMLRPCInterchange. Загружаем архив шаблона [zip] с веб-странички курса. Разворачиваем его в рабочую область. В рабочей области появился каталог с пиктограммами стереотипов, описание стереотипов stereotypes.xml и файл проекта -- myProject.vpp. Откроем проект (перед открытием Вы можете переименовать файл проекта). Чтобы использовать набор стереотипов технологии Unified Process, осуществим настройку. Меню Modeling -> Manage Stereotypes -> Import (или возможный вариант: вкладка меню Window -> Configuration -> Manage Stereotypes -> Import). Файл с описаниями стереотипов находится в workspace. Он называется stereotypes.xml. При импорте выберите способ разрешения конфликтов Overwrite All. Переключаемся в левом верхнем углу с закладки Diagram Navigator на закладку Model Explorer (или возможный вариант: закрываем Project Browser / клик на светло-серый крестик на сером заголовке окна; открываем Model Explorer и закрепляем его / Toggle auto-hide). После этого окно среды примет вид, показанный на рисунке 1.1. в интерфейсе Classic, или вид на рисунке 1.1.a в интерфейсе Sleek.


Рис. 1.1. Окно среды после создания модели

Рис. 1.1. Окно среды после создания модели (Classic).


Рис. 1.1.a. Окно среды после создания модели

Рис. 1.1.a. Окно среды после создания модели (Sleek).


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

      Согласно технологии Unified Process на верхнем уровне модель должна состоять из четырёх пакетов, называемых архитектурными представлениями. Каждый из них показывает будущую систему с определённой точки зрения. Представление вариантов использования (Use Case View) содержит модель требований к системе. Логическое представление (Logical View) содержит логическую структуру системы, её организацию в классы и пакеты. Представление реализации (Component View) описывает организацию компонент, из которых осуществляется сборка системы. Представление размещения (Deployment View) содержит модель вычислительной среды, в которой будет функционировать система.

      Выделим в браузере элемент Use Case View. Вызвав контекстное меню элемента Use Case View в браузере правым кликом, выберите пункт Open Use Case View Specification. Откроется полная спецификация элемента в виде отдельного окна с вкладками. На вкладке General указано имя элемента и его основные свойства. На вкладке Stereotypes -- его стереотипы. Видно, что к этому элементу применён стереотип «architectural view», указывающий, что пакет является архитектурным представлением.

      Вводные замечания даны, переходим к моделированию.

2. Система обработки заказов. Начальное описание


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

      Система должна обеспечивать следующие возможности: добавление сведений о новых заказов, изменение сведений о ранее введённых заказах, учёт хода выполнения заказов, учёт сведений об текущих остатках на складе. При получении сведений о новом заказе система должна также послать сообщение внешней программе -- бухгалтерской системе, которая выписывает счёт заказчику. Любой заказ может содержать одну или более товарных позиций. Для каждой позиции заказа указывается наименование товара и его количество. Заполненный заказ получает кладовщик, который начинает сборку заказа. Если для каждой позиции товара на складе находится товар в достаточном количестве, то товар резервируется, и заказ помечается выполненным. Если требуемого товара нет на складе, то заказ может быть отменён, либо выполнение заказа задерживается до поступления товара на склад.

3. Определение требований к создаваемой системе


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

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

      Требования оформляются в виде ряда документов и моделей. К основным документам, согласно технологии Unified Process, относятся: концепция, глоссарий предметной области, дополнительная спецификация. Концепция определяет глобальные цели проекта и основные особенности разрабатываемой системы. Существенной частью концепции является постановка задачи разработки, определяющая требования к функциям системы. Словарь предметной области (глоссарий) определяет общую терминологию для всех моделей и описаний требований к системе. Дополнительная спецификация (технические требования) содержит описание нефункциональных требований к системе, таких, как надёжность, удобство использования, производительность, сопровождаемость и др.

      Постановка задачи разработки системы обработки заказов:

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

      База данных системы будет поддерживаться реляционной СУБД. Система должна обеспечивать возможность продавцам вводить сведения о новых заказах и изменять сведения о заказах, хранящиеся в системе. Сведения о заказе могут быть изменены до тех пор пока ведётся работа на складе по его сборке. Собранные (выполненные) заказы поставляются заказчикам, внесение изменений в сведения о них запрещено. Дата окончания сборки заказа хранится в системе. По её наступлении заказ считается выполненным. Не выполненный заказ может быть отменен. Сведения об отменённых заказах изменению не подлежат.

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

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

      Заведующий складом использует систему, чтобы работать с данными об остатках -- описями, в которых указываются текущие (на момент составления описей) количества предметов мебели на складе. Остатки определяются системой по данным последней инвентаризации и данным о выполнении заказов. Например, если по данным инвентаризации было 10 стульев и 8 стульев отмечены как выполненные позиции заказов введённых после инвентаризации, (т. е. стулья переданы заказчикам или отложены в собираемые заказы), то текущий остаток -- 2 стула. При проведении инвентаризации для каждого предмета мебели со склада текущее его количество заносится в опись. Данные из описи вводятся в систему. Относительно этих данных будут рассчитываться остатки до ввода следующей описи.

      Кладовщики отмечают в системе ход выполнения заказов. Любой кладовщик может работать с любым заказом. Кладовщик может пометить какую-либо позицию заказа как выполненную. При этом соответствующее количество предметов мебели вычитается при расчёте текущих остатков. Если выполнены все позиции заказа, он также считается выполненным. Кладовщик может пометить невыполненный заказ как отменённый, если нужной для выполнения заказа мебели на складе нет. При этом снимается резерв с выполненных позиций отменённого заказа и, соответственно, увеличиваются остатки.

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

      Глоссарий:

Бухгалтерская система
(Accounting System)

Внешняя система, в которую передаются данные обо всех введённых заказах.

Заведующий складом
(Warehouseman)

Пользователь системы. Имеет возможность работать с данными об остатках (вносить данные новой описи, просматривать и распечатывать данные описей, введённых ранее, удалять неактуальные данные описей, узнать остатки, рассчитанные по данным описей и принятых заказов).

Заказ
(Order)

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

Заказчик
(Client)

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

Инвентаризационная опись
(Inventory)

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

Кладовщик
(Stockman)

Пользователь системы. Работник склада, отвечающий за сборку заказов. Может помечать позиции заказов как выполненные, а невыполненные заказы -- как отменённые.

Остатки
(Balance)

Данные о количестве предметов мебели на складе, рассчитываемые по сведениям из последней описи и данным о выполненных позициях заказов.

Позиция заказа
(Order Item)

Один или более одинаковых предметов мебели, указанных в заказе. Позиция характеризуется наименованием, количеством, номером по порядку и статусом (выполнена или нет)

Предмет мебели
(Article of furniture)

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

Продавец
(Salesperson)

Пользователь системы. Автор произвольного количества заказов. Может вводить заказы и изменять введённые им ранее заказы.

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

  1. Функциональные возможности
    Система должна обеспечивать многопользовательский режим работы. Несколько кладовщиков и/или продавцов могут одновременно использовать систему.
    Система должна обеспечивать выполнение следующих правил:

    • В заказе должна быть хотя бы одна позиция. Пустые заказы не сохраняются в системе.

    • Количество предметов мебели в любой позиции заказа -- натуральное число.

    • Если в заказе все позиции помечаются как выполненные, то он считается собранным, т. е. готовым к отправке заказчику.

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

    • Дата поставки заказа не может предшествовать дате его создания.

    • И т. п.

  2. Требования по реализации
    Система должна быть совместима с Windows.

  3. Надёжность
    Система должна быть в работоспособном состоянии 24 часа в день 7 дней в неделю, время простоя -- не более 10%.

  4. Производительность
    Система должна поддерживать до 30 одновременно работающих пользователей.

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

  6. Проектные ограничения
    Система должна поддерживать протокол обмена данных с бухгалтерской системой.

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

      В контексте процесса управления требованиями варианты использования трактуются следующим образом:

  • вариант использования фиксирует соглашение между участниками проекта относительно поведения системы;

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

  • основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели (если вариант использования имеет уровень «цель пользователя»). Система отвечает, соблюдая интересы всех действующих лиц.

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

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

  • Продавец -- вводит заказ, изменяет заказ, удаляет заказ;

  • Кладовщик -- выполняет заказ, помечает заказ как отменённый;

  • Заведующий складом -- создаёт, просматривает, удаляет сведения об остатках;

  • Бухгалтерская система -- получает данные о введённых заказах.

Упражнение 3.1. Создание действующих лиц
(общее для всех вариантов)


      1. В Model Explorer найдите пакет Use Case View, а внутри него модель Use Case Model. В модели находится диаграмма вариантов использования Main. Откройте её двойным кликом. Диаграмма пуста. Заполним её. Если Вы работаете на FullHD-дисплее или с ещё большим разрешением, то желательно установить увеличение 130% или выше (Ctrl+), чтобы Ваши диаграммы были обозримы на обычном дисплее. С таким увеличением все элементы диаграммы и все связи между ними должны помещаться на экране. В палитре найдите элемент System. Нажмите на него. Затем поместите курсор на диаграмму и кликните. Система появится на диаграмме. Назовите добавленный элемент "Система обработки заказов". Этим элементом в модели представляется рамка моделируемой программной системы. С помощью контекстного меню добавьте системе стереотип «subject». В палитре редактора выберите элемент Actor и добавьте действующее лицо на диаграмму. Введите имя актора: Продавец. Повторите те же действия и добавьте оставшихся действующих лиц: заведующего складом, кладовщика, бухгалтерскую систему. Увеличьте размеры элемента System, чтобы он вместил варианты использования системы. Получившаяся диаграмма примет вид, показанный на рисунке 3.1.1.

Рис. 3.1.1. Диаграмма вариантов использования после добавления действующих лиц

Рис. 3.1.1. Диаграмма вариантов использования после добавления действующих лиц

      Исходя из потребностей действующих лиц, системный аналитик может предложить следующие варианты использования: CRUD данных о заказах, CRUD данных об остатках, Выполнить заказ, Отменить заказ. Все эти варианты использования относятся к «уровню моря», т. е. соответствуют цели одного из пользователей системы. Такую цель пользователь может достичь в течение одного сеанса работы с системой. CRUD рашифровывается как Create, Read, Update, Delete (или как Create, Retrieve, Update, Destroy). Предполагается, что вариант использования «CRUD данных о заказах» описывает все функции системы, предоставляемые продавцу для управления сведениями о заказах. «CRUD данных об остатках» описывает все функции системы, предоставляемые заведующему складом для управления сведениями об остатках.

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

Упражнение 3.2. Создание вариантов использования
(общее для всех вариантов)


Рис. 3.2.1. Начальная версия диаграммы вариантов использования (красным отмечены ошибочные связи)

Рис. 3.2.1. Начальная версия диаграммы вариантов использования (красным отмечены ошибочные связи)

      1. В палитре редактора выберем элемент Use Case и добавим вариант использования на диаграмму (внутрь System). Введём название: «CRUD данных о заказах». Повторим те же действия для добавления оставшихся вариантов использования: CRUD данных об остатках, Выполнить заказ, Отменить заказ, Войти в систему. Каждый вариант использования пометим стереотипом, указывающим его уровень. Для этого вызываем контекстное меню правым кликом, выбираем пункт Stereotypes и нужный стереотип в списке. Размещаем варианты примерно так, как показано на рисунке 3.2.1.

      2. В палитре редактора выберем ассоциацию Association и проведём её от действующего лица Продавец к варианту использования »CRUD данных о заказах». Чтобы было видно направление связи, вызовем контекстное меню у левого конца ассоциации и выберем пункт Navigable. Установим флажок на значении Unspecified. По умолчанию связь была двунаправленная, теперь же она явно указывает, направление от действующего лица к варианту использования.

      3. Повторим те же действия для добавления связей других действующих лиц и вариантов использования. Получившаяся диаграмма изображена на рис. 3.2.1. Направления связей между действующими лицами и вариантами использования показывают, какое лицо является основным, а какое второстепенным. Для варианта использования CRUD данных о заказах Продавец -- основное действующее лицо (он инициирует запуск варианта использования), а Бухгалтерская система -- второстепенное (сведения о заказах пересылаются в бухгалтерскую систему).

      4. Добавим связь расширения (Extend) от варианта использования «Отменить заказ» к варианту использования «Выполнить заказ». Связь расширения показывает, что в ходе выполнения варианта использования «Выполнить заказ» могут возникнуть условия, при которых реализуется особый сценарий, описываемый вариантом использования «Отменить заказ». Заметим, что переключение происходит не всегда. Обратите внимание, что рисовать связь следует, указав сначала расширяемый вариант использования (в который входит стрелка), а затем -- расширяющий (из которого исходит связь). Переименовать точку расширения можно, открыв спецификацию расширяемого варианта использования через контекстное меню (контекстное меню -> Open specification), и перейдя на вкладку Extension Points.

      5. Созданная диаграмма имеет недостаток в том, что у варианта использования «Войти в систему» несколько основных действующих лиц. Стандартное её прочтение предполагает, что при входе в систему с ней взаимодействуют одновременно три экземпляра действующего лица -- один продавец, один кладовщик и один заведующий. Полагая поведение системы одинаковым при входе любого пользователя, полагая что вход в систему каждый пользователь производит сам по себе, введём абстрактное действующее лицо Пользователь, подвидами которого будут лица Продавец, Заведующий складом, Кладовщик. Указать, что действующее лицо является абстрактным, нужно в спецификации (контекстное меню -> Open specification) на вкладке General, поставив флаг в поле Abstract. Другой вариант: контекстное меню -> Model Element Properties -> Abstract. Для добавления связей обобщения используйте связь обобщения (Generalization). Лишние ассоциации удалите из модели, выделяя их в Model Explorer и нажимая Del. Чтобы связи отображались в Model Explorer, осуществите его настройку: вызовите контекстное меню на белом поле Model Explorer и отметьте флажками Show Relationships. Обратите внимание, что лишний элемент (или связь) следует удалить из модели (выделяя их в Model Explorer и нажимая Del). Если необходимо сохранить элемент (или связь) в модели и всего лишь убрать с диаграммы, на которую он случайно попал по какой-то причине, выделите элемент или связь на диаграмме и используйте пункт контекстного меню Delete -> Delete View Only. Следует чётко понимать, удаляете ли Вы текущий элемент из модели или всего лишь убираете с диаграммы, оставляя в модели (маскируете). Удаление вместо маскирования (как и обратное) может быть нежелательным. Случайно удалённый элемент можно попытаться восстановить, нажав Ctrl+z. Маскированный по ошибке элемент можно снова поместить на диаграмму, перетаскивая его из Model Explorer. Маскированную по ошибке связь можно снова поместить на диаграмму с помощью контекстного меню одного из связываемых ей элементов (Related Elements -> Visualize Related Model Element, флаг Visualize, кнопка Visualize). Работать с моделью следует аккуратно, не оставляя в ней «мусора» -- случайно созданных элементов и/или связей, не видимых на диаграммах.


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

Рис. 3.2.2. Итоговая диаграмма вариантов использования после исправления ошибки

Рис. 3.2.2. Итоговая диаграмма вариантов использования после исправления ошибки

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

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

      Для каждого варианта использования составляется описание. Выполняют эту работу use case писатели.

Упражнение 3.3. Добавление описаний вариантов использования
(общее для всех вариантов)


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

      Каждый поток событий задаётся перенумерованным набором шагов. Используются шаги трёх типов: действие системы (например, «Система запрашивает имя пользователя и пароль»); реакция действующего лица («Пользователь вводит имя и пароль»); управление потоком («Выполнение переходит на начало основного потока»). Структура предложений, описывающих шаги, одинакова: подлежащее, сказуемое и прочее. От неё отходят лишь при описании циклов и ветвлений.

      Цикл задаётся составным описанием, в начале которого указывается условие цикла («Для каждого незафиксированного курса в плане-графике выполняется») или количество повторений. Далее следует тело цикла -- последовательность вложенных шагов (см. подчинённый поток «8Г. Утвердить график» варианта использования «Зарегистрироваться на курсы»).

      Ветвление в тривиальных случаях, когда альтернативная ветвь пуста, допускается описывать предложением с союзом если («Система помечает курс как закрытый, если в списке студентов содержится 10 записей»). Чаще ветвление описывают с помощью альтернативных потоков. В основном потоке варианта использования «Войти в систему» 3-ий шаг указывает основное продолжение потока, а альтернативный поток «3А. Неправильное имя/пароль» содержит второй вариант развития событий. Почти всегда действия по проверке условия ветвления не описывают. Вместо этого указывается шаг на котором система (или действующее лицо) подтверждает, что условие выполнено, в основном потоке, или обнаруживает, что условие нарушено, в альтернативном потоке.

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

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

      Вариант использования «Войти в систему»:

Краткое описание
Данный вариант использования описывает вход пользователя в систему обработки заказов.
Основной поток событий
1. Пользователь запускает приложение.
2. Система запрашивает имя пользователя и пароль.
3. Пользователь вводит имя и пароль.
4. Система подтверждает правильность имени и пароля.
5. Система определяет тип пользователя (продавец, кладовщик или завскладом) и выводит главное меню, дающее доступ к её функциям в соответствии с типом пользователя.
Альтернативные потоки
4А. Неправильное имя/пароль
1. Система обнаруживает, что комбинация имени и пароля не верна.
2. Система сообщает об ошибке.
3. Вариант использования завершается неуспешно.
Предусловия
Отсутствуют.
Постусловия
Гарантии успеха: Если вариант использования выполнен успешно, система предоставляет доступ к главному меню пользователю, сообщившему верную комбинацию имени и пароля.
Минимальные гарантии: В любом случае система гарантирует, что пользователю, не сообщившему верную комбинацию имени и пароля, доступ к меню не будет предоставлен.


      Обратите внимание на номер альтернативного потока. Цифра указывает номер шага основного потока, на котором может произойти переключение на альтернативный поток, буква позволяет различить несколько альтернативных потоков, на которые можно переключиться на одном и том же шаге. Если переход на альтернативный поток может происходить в течение нескольких подряд идущих шагов, указывают их номера через дефис (например, 1-3Б). Если поток вызывается из разных шагов, он может иметь несколько номеров, перечисленных через запятую.

      Вариант использования «CRUD данных о заказах»:

Краткое описание
Данный вариант использования позволяет продавцу ввести данные о новом заказе, изменить ранее введённые данные о заказе или удалить данные о заказе. Сведения о заказе включают в себя данные о заказчике, дату поставки заказа и перечень позиций в заказе. При вводе заказа система присваивает ему дату создания. Новые сведения о заказе (изменения в заказе или сведения об удалении заказа) передаются системой в бухгалтерскую систему.
Основной поток событий
1. Продавец сообщает системе о желании работать с заказом.
2. Система принимает сообщение от продавца и запрашивает у него требуемое действие (ввести заказ, изменить заказ, удалить заказ).
3. Продавец сообщает системе свой выбор.
4. Согласно выбору продавца выполняется один из подчинённых потоков (ввести, изменить или удалить заказ).
5. Бухгалтерская система принимает сообщение от системы, обрабатывает его и отправляет в систему ответ.
6. Система принимает ответное сообщение бухгалтерской системы.
7. Система подтверждает, что в ответе бухгалтерской системы сказано об успехе.
Подчинённые потоки:
4.А. Ввести заказ
1. Система запрашивает у продавца данные о заказе.
2. Продавец вводит данные о заказчике и дате поставки заказа.
3. Система принимает данные о заказчике и дате поставки заказа.
4. Для каждой позиции нового заказа выполняется:
4.1. Продавец вводит наименование и количество.
4.2. Система принимает данные о введённой позиции заказа.
5. Продавец сообщает системе о необходимости сохранить заказ.
6. Система сохраняет принятые от продавца данные о заказе.
7. Система передаёт бухгалтерской системе сообщение с данными нового заказа.
8. Управление передаётся на шаг 5 основного потока событий
4.Б. Изменить заказ
1. Система выводит список заказов, созданных продавцом.
2. Продавец выбирает заказ из списка.
3. Система выводит все сведения о выбранном заказе.
4. Продавец изменяет сведения о заказе и сообщает системе о необходимости сохранить заказ.
5. Система сохраняет обновлённые данные о заказе.
6. Система передаёт бухгалтерской системе сообщение с измененными данными заказа.
7. Управление передаётся на шаг 5 основного потока событий
4.В. Удалить заказ
1. Система выводит список заказов, созданных продавцом.
2. Продавец выбирает заказ из списка.
3. Система выводит все сведения о выбранном заказе и запрашивает подтверждение удаления заказа.
4. Продавец подтверждает удаление заказа.
5. Система удаляет все данные о заказе.
6. Система передаёт бухгалтерской системе сообщение об удалении заказа.
7. Управление передаётся на шаг 5 основного потока событий
Альтернативные потоки
4.А.5.А, 4.Б.4.А, 4.В.4.А. Отмена действия с заказом
1. Продавец сообщает системе об отмене операции с заказом.
2. Система сообщает продавцу, что операция с заказом отменена.
3. Вариант использования завершается неуспешно.
7.А. Бухгалтерская система не сообщила об успешной обработке
1. Система обнаруживает, что в ответе бухгалтерской системы сказано о неуспехе.
2. Система выдаёт продавцу сообщение об ошибке.
3. Вариант использования завершается неуспешно.
Предусловия
Перед началом выполнения данного варианта использования продавец должен войти в систему.
Постусловия
Гарантии успеха: Если вариант использования завершится успешно, то операция с данными о заказе, требуемая продавцом, будет осуществлена, изменения в данных о заказах будут внесены в систему обработки заказов и переданы в бухгалтерскую систему.
Минимальные гарантии: В любом случае система гарантирует, что доступ к данным о заказе предоставляется только тому продавцу, который создал заказ, что операции в данными о заказе производятся только тогда, когда доступна бухгалтерская система, и что при отмене операции с заказом, не изменятся сведения о нём, хранящиеся в системе, что при неуспешной обработке данных в бухгалтерской системой сообщение об ошибке будет передано системой продавцу.

      Для остальных вариантов использования мы составим только краткие описания. В рамках работ по определению требований в ходе одной итерации допускается составлять полные описания лишь для нескольких приоритетных вариантов использования. Менее приоритетные варианты использования описываются кратко. Их полные описания могут быть составлены на последующих итерациях.

      Вариант использования «Обработать заказ»:

Точки расширения
Отмена

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

      Вариант использования «Отменить заказ»:

Краткое описание
Данный вариант использования позволяет кладовщику отменить заказ, собираемый на складе, если заказанных позиций нет в наличии. Выполнение варианта использования начинается в точке расширения «Отмена» расширяемого варианта использования «Обработать заказ». Кладовщик сообщает системе, что заказ следует отменить. Система помечает заказ как отменённый и сохраняет сведения об этом.

      Вариант использования «CRUD данных об остатках»:

Краткое описание
Данный вариант использования позволяет заведующему складом ввести данные о новой описи остатков на складе, изменить данные из ранее введённой описи или удалить данные об описи остатков. Сведения об описи включают в себя дату проведения описи и перечень позиций в описи. В каждой позиции описи указан каталожный номер предмета мебели, количество штук в наличии на складе, номер места хранения. Заведующий складом может пометить введённую опись как текущую. Система будет использовать сведения из неё для расчёта текущих остатков.

Упражнение 3.4. Построение диаграмм деятельности в модели вариантов использования
(общее для всех вариантов)


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

      1. В браузере вызываем контекстное меню варианта использования «Войти в систему» и выбираем Subdiagrams -> New diagram. В открывшемся окне указываем тип создаваемой диаграммы: Activity diagram.

      2. На появившейся в редакторе диаграмме создаём два раздела (Vertical Swimlane) -- Пользователь, Система регистрации на курсы -- каждый из которых обозначает область ответственности. Связываем каждый раздел с элементом модели, который он представляет, в окне спецификации на вкладке General в поле Represents (первый -- с актором Пользователь, второй с системой). Деятельности, соответствующие узлам, которые будут расположены в области ответственности пользователя, будут выполняться пользователем, остальные -- системой. Входной узел (Initial Node) помещаем в раздел Пользователь. Заметим, что если бы с вариантом использования были бы связаны два действующих лица, на диаграмме следовало бы создать три раздела (два для действующих лиц и один для системы).

      3. Согласно описаниям потоков событий варианта использования создаём узлы действий (Action): запустить приложение, запросить имя и пароль; ввести имя и пароль; проверить имя и пароль; сообщить об ошибке; определить тип пользователя и вывести главное меню. Узлы действий размещаем по разделам в соответствии с тем, кто выполняет действия.

      4. Добавляем узел логического ветвления (Decision Node). Соединяем узлы рёбрами потоков управления (Control Flow). Задать сторожевые условия можно, открыв спецификацию потока, на вкладке General в поле Guard (или выбрав пункт Guard в контекстном меню при потоке). Не следует указывать сторожевые условия в названиях потоков управления.

      5. Добавляем два узла завершения деятельности (Activity Final Node) с именами, указывающими на успешное и безуспешное завершение варианта использования. Вид получившейся диаграммы представлен на рис. 3.4.1.

Рис. 3.4.1. Диаграмма деятельности для варианта использования «Войти в систему»

Рис. 3.4.1. Диаграмма деятельности для варианта использования «Войти в систему»

      Диаграмма деятельности пути передачи управления между узлами. Изначально курсор управления порождается во входном узле. Оттуда он передаётся по ребру на вход узла действия (запустить приложение). Узел действия ждёт, когда курсоры управления придут на все входящие ребра, после чего запускается действие, а по окончании действия курсоры управления подаются на все исходящие из узла действия ребра. Когда курсор попадает в узел логического ветвления, проверяются сторожевые условия на всех исходящих рёбрах этого узла. Исходящих рёбер может быть два и более. По одному из рёбер, на котором сторожевое условие истинно, курсор управления передаётся дальше. Если таких рёбер (с истинными сторожевыми условиями) несколько, то случайным образом выбирается одно. Если все сторожевые условия ложны, то курсор не может быть передан дальше. Поток управления заблокирован, а диаграмма нарушает правила стандарта языка. Во избежание ошибок следует внимательно формулировать сторожевые условия. Рекомендуется делать их взаимоисключающими и покрывающими все возможные случаи. Часто используется условие [else], способствующее выполнению этих требований.

      При попадании курсора управления в (любой) узел завершения деятельности вся деятельность прекращается. Уничтожаются все курсоры управления на всех рёбрах диаграммы. В случаях, когда требуется остановить один поток, оставив другие активными, применяется узел завершения потока (Flow Final Node), изображаемый кружком с крестиком.

      Самостоятельно постройте диаграмму для варианта использования «CRUD данных о заказах». Обратите внимание на то, что подчинённый поток может быть представлен на диаграмме в виде одного узла (см. узлы «Ввести заказ», «Изменить заказ», «Удалить заказ»). Тип этих узлов -- Call Behavior Action (узел вызова деятельности). С каждым из них связана деятельность, которая может быть промоделирована отдельной диаграммой деятельности. При создании диаграммы следует сначала создать внутри варианта использования три деятельности (Activity): Ввести заказ, Изменить заказ, Удалить заказ. Затем разместите на диаграмме деятельности три узла действия (Action). В окне спецификации каждого созданного узла на вкладке General в поле Type укажите тип узла: Call Behaviour Action, после чего нажмите на кнопку с многоточием. В открывшемся окне следует выбрать подходящую деятельность.



Рис. 3.4.2. Диаграмма деятельности варианта использования «CRUD данных о заказах»

Рис. 3.4.2. Диаграмма деятельности варианта использования «CRUD данных о заказах»

      Обратите внимание на то, что если деятельности созданы в корне проекта, то следует перетащить их внутрь варианта использования «CRUD данных о заказах» в браузере модели. Может оказаться, что какая-то диаграмма создана Вами в корне проекта, а не внутри элемента проекта. Перетащить диаграмму в нужное место Model Explorer не даёт. Тем не менее, переместить диаграмму из корня можно. Откройте спецификацию диаграммы. На закладке General второе сверху поле Parent model: <No parent model>. Нажмите "..." и укажите нужный элемент проекта как родительскую модель для диаграммы. В браузере модели поддерево проекта Use Case View (соответствующее архитектурному представлению вариантов использования из модели «4+1») должно иметь примерно такой вид, как указано на рисунке 3.4.3. Действующие лица должны находиться в корне Use Case Model; варианты использования -- внутри рамок системы; диаграммы деятельности -- внутри соответствующих вариантов использования; деятельности, которые моделируют подчинённые потоки варианта использования CRUD данных о заказах -- внутри этого варианта использования.

Рис. 3.4.3. Структура архитектурного представления Use Case View в браузере модели

Рис. 3.4.3. Структура архитектурного представления Use Case View в браузере модели

      Моделирование требований следовало бы продолжить дальше, описав все варианты использования и построив для них диаграммы деятельности. Однако, не имеет смысла сразу описывать все требования. Работа осуществляется последовательными итерациями, в ходе которых составляются описания отдельных вариантов использования в порядке их важности. Когда описания важных вариантов использования составлены, выполняются работы по анализу и проектированию частей системы, реализующих их. Use case писатели приступают к работе над менее приоритетными вариантами использования во время последующих итераций, или занимаются ими на той же итерации, если они мало загружены во время анализа и проектирования. Следует быть готовыми к пересмотру требований в ходе проекта. Изменчивость требований обусловлена тем, что заказчики и будущие пользователи системы не могут сразу точно указать свои пожелания, и тем, что по ходу проекта разработчики лучше узнают предметную область и контекст системы. Из-за изменения требований переделываются описания вариантом использования, исправляются диаграммы деятельности.

4. Анализ системы


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

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

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

  1. Утверждение общих соглашений моделирования и документирования системы.

  2. Формирование набора ключевых абстракций предметной области.

      Соглашения моделирования фиксируются в документе «Руководящие указания по проектированию» (Design Guidelines). Они определяют: перечень используемых диаграмм и элементов модели; правила применения диаграмм; соглашения по именованию элементов модели; организацию модели (пакеты).

      Будем придерживаться следующих соглашений моделирования:

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

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

  3. Имена классов (и типов данных) должны начинаться с заглавной буквы.

  4. Имена атрибутов и операций должны начинаться со строчной буквы.

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

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

  7. Модель анализа (Analysis Model -- аналитическая модель) представляет собой пакет внутри логического архитектурного представления (Logical View -- одного из представлений «4+1»). Внутри модели анализа помещается пакет Use Case Realizations, содержащий в себе все реализации вариантов использования. Также внутри модели анализа создаётся диаграмма классов -- ключевых абстракций -- Key Abstractions.

  8. Для каждого варианта использования должна быть создана кооперация (Collaboration), внутри которой будут размещены элементы модели, относящиеся к реализации этого варианта использования. Каждая такая кооперация содержит диаграммы взаимодействия, описывающие потоки событий варианта использования (базовый, альтернативные и подчинённые потоки). Также кооперация содержит диаграмму классов VOPC (View Of Participating Classes), изображающую классы, экземпляры которых участвуют в реализации этого варианта использования.

Упражнение 4.1. Создание структуры модели в соответствии с соглашениями моделирования
(общее для всех вариантов)


Рис. 4.1.1 Структура модели анализа в браузере проекта

Рис. 4.1.1. Структура модели анализа в браузере проекта

      1. В модели Analysis Model (модель анализа) создадим пакет Use Case Realizations. Для этого в браузере проекта вызовем контекстное меню меню пакета Analysis Model, Model Element -> Package (или Model Element -> New Model Element -> Model element type: Package).

      2. В пакет Use Case Realizations добавим две кооперации (Collaboration) Login и CRUDOrders (контекстное меню пакета -> Model Element -> New Model Element -> Model element type: Collaboration). Назначим каждой созданной кооперации стереотип «usecase realization». Каждая кооперация описывает сценарии одного из вариантов использования: Login -- Войти в систему, CRUDOrders -- CRUD данных о заказах. В пакете Use Case Realizations создадим диаграмму вариантов использования (Use Case Diagram), на которой покажем связи между вариантами использования и их реализациями. Перетащим кооперации и варианты использования из браузера модели на созданную диаграмму. Проведём от связи реализации (Realization, этот тип связи можно найти в палитре, если открыть выпадающий список у связи Generalization) между кооперациями и теми вариантами использования, которые они реализуют. Важно, чтобы стрелки у связей показывали в направлении от коопераций к реализуемым вариантам использования. Получившаяся диаграмма примет вид, показанный на рис. 4.1.2.

Рис. 4.1.2 Диаграмма Use Case Realizations

Рис. 4.1.2. Диаграмма Use Case Realizations

      3. Внутри каждой кооперации -- реализации варианта использования -- создадим диаграмму последовательности BasicFlow (LoginBasicFlow, CRUDOrdersBasicFlow) и диаграмму классов VOPC (LoginVOPC, CRUDOrdersVOPC). Воспользуйтесь контекстным меню кооперации -> Sub Diagrams -> New Diagram -> Sequence Diagram / Class Diagram. Диаграмма последовательности BasicFlow служит для моделирования реализации основного сценария варианта использования (и, возможно, его альтернативных сценариев). Назначение диаграмм классов VOPC (сокращение View Of Participating Classes) -- отображение классов, экземпляры которых участвуют в реализации варианта использования, и связей между этими классами.

      4. Если в заготовке проекта нет диаграммы классов Key Abstractions в корне пакета Analysis Model, то создадим её. Контекстное меню пакета Analysis Model-> Sub Diagrams -> New Diagram -> Class Diagram. Дополнительно в кооперацию CRUDOrders внутри взаимодействия CRUDOrdersBasicFlow (тип элемента модели -- Frame) добавьте три диаграммы последовательности, моделирующие реализации подчинённых потоков: CreateOrderSubflow, UpdateOrderSubflow, DeleteOrderSubflow (контекстное меню взаимодействия -> Sub Diagrams -> New Diagram -> Sequence Diagram). Моделирование каких-то вспомогательных взаимодействий на отдельных диаграммах оправдано, так как размер диаграмм остаётся приемлемым, чтобы использовать их как иллюстрации в отчётах, и чтобы видеть диаграмму целиком на экране.

      Структура модели анализа в браузере должна соответствовать рис. 4.1.1.

      5. В модели Analysis Model присутствует диаграмма классов Key Abstractions. На ней будут представлены классы, представляющие собой основные абстракции предметной области. Каждый из них является абстрактным типом данных, имеющим отношение к предметной области -- к обработке заказов мебельного магазина. Откроем диаграмму ключевых абстракций двойным щелчком в Model Explorer.

      Ключевые абстракции -- основные понятия предметной области -- архитектор выделяет, анализируя требования и пользуясь, глоссарием и моделью бизнес-анализа, если таковая была создана. Каждый термин из глоссария является кандидатом для того, чтобы быть трансформированным в класс ключевой абстракции (или в несколько классов, если структура данных, связанная с ним, слишком сложна для представления одним классом). Некоторые термины могут быть источником для атрибутов классов. В системе обработки заказов можно выделить следующие ключевые абстракции: Order (данные о заказе), OrderItem (данные о позиции заказа), ArticleOfFurniture (данные о предмете мебели), Client (данные о заказчике), User (учётная запись пользователя системы), Inventory (инвентаризационная опись), InventoryItem (позиция описи с данными об остатке мебели на складе). Ассоциации между абстракциями показывают типы соединений между экземплярами ключевых абстракций. Мощности у полюсов указывают ограничения на количество соединений у одного экземпляра. Ассоциация может быть рефлексивной, т. е. соединяющей класс с ним самим. Такая связь описывает соединения между разными экземплярами одного класса. Чтобы различать роли объектов, участвующих в таких соединениях, полюсам рефлексивных ассоциаций обязательно дают имена. Также поступают при наличии двух ассоциаций между одной парой классов. Иногда имена полюсов указывают, чтобы пояснить назначение конкретной ассоциации. На диаграмме классов помимо ассоциаций могут присутствовать и другие связи. Так, связь между классом User и перечислимым типом UserType, указывает, что описание класса зависит от описания типа (так как атрибут User::type имеет тип UserType). Ещё одна зависимость указывает на то, что в описании атрибута Order::status используется перечислимый тип OrderStatus.

Рис. 4.1.3 Диаграмма классов Key Abstractions (ключевых абстракций)

Рис. 4.1.3. Диаграмма классов Key Abstractions (ключевых абстракций)

      Предварительно настроим среду для более удобной работы. Меню Tools -> Project Options -> Diagramming (вариант: Window -> Project Options -> Diagramming). На вкладке Association отменим отображение уникальности (Show multiplicity constraints -- Unique). По умолчанию любая пара объектов, связывается не более чем одним соединением, являющимся экземпляром одной ассоциации. Если необходимо допустить повторные соединения, уникальность соединения следует отменить. Там же укажем необходимость явно выводить мощность полюса, равную 1 (снимите флажок Suppress implied "1" multiplicity). Перейдите к вкладке Class. Выберите вложенную вкладку Presentation. Снимите флажок отображения классов в виде пиктограмм стереотипов (Display as Robustness Analysis icon). Сохраняем настройки, закрываем окно настроек проекта. Снятие флажка Suppress implied "1" multiplicity может потребоваться дополнительно на каждой диаграмме классов. Вызовите контекстное меню на поле диаграммы классов, нужный флажок спрятан в Presentation Options. Также в Presentation Options диаграммы Key Abstractions найдите и установите флажок Attribute Display Options -> Show Property Modifiers.

      1. Откроем диаграмму Key Abstractions. Выберем в палитре инструмент Class. Добавим классы Order, OrderItem, ArticleOfFurniture, Client, User, Inventory, InventoryItem.

      2. Добавим перечислимые типы (Enumeration) UserType (Тип пользователя) и OrderStatus (Статус заказа). Внутри них расположим значения перечислимого типа (enumeration literal): SALESMAN, STOCKMAN, WAREHOUSEMAN; ARCHIVED, CANCELLED, DELIVERED, FILLED, INPROCESS.

      3. Выберем в палитре инструмент Association. Проведём ассоциации между классами. Укажем мощности у полюсов -- концов ассоциаций (контекстное меню полюса Multiplicity). Укажем, что связь между заказом и позицией заказа -- композиция (контекстное меню полюса, Association Kind -> Composited). Укажем на полюсах ассоциаций их имена (контекстное меню полюса, Edit Role Name...). Чтобы имя полюса отобразилось на диаграмме вызовем контекстное меню диаграммы, Presentation Options -> Association Display Options -> Show From Role Name и Show To Role Name. Также выводом имён ролей можно управлять через контекстное меню отдельной ассоциации.

      4. Добавим атрибуты (Attribute) классов: классу Order -- number:long, creation:Date, delivery:Date[0..1], filling:Date[0..1], status:OrderStatus; классу OrderItem -- quantity:byte, number:byte, filled:boolean; классу ArticleOfFurniture -- code:string, description:string, discontinued:boolean; классу Client -- name:string, address:string[3], phones:string[*]; классу User -- login:string, passwordHash:long[2]; type:UserType; классу Inventory -- number:long, date:Date, approved:boolean; классу InventoryItem -- quantity:int. Мощности атрибутов следует вводить при создании атрибута как часть его типа. Другим способом их ввода является указание мощности как модификатора типа в окне спецификации атрибута (открыть которое можно, выделив атрибут и вызвав его контекстное меню). Среда Visual Paradigm загромождает диаграмму лишними сведениями, если указывать мощность атрибута в предназначенном для этого поле и выводить её на диаграмме. Поэтому рекомендуется указывать мощности как модификаторы типов атрибутов. Значения атрибутов по умолчанию (Initial value) вводятся в окне спецификации атрибута. Признак того, что атрибут входит в состав идентификатора экземпляра класса, также указывается в окне спецификации атрибута.

      5. Проведём зависимости (Dependency) от класса User к перечислимому типу UserType; от класса Order к перечислимому типу OrderStatus.

      6. Добавим всем классам -- ключевым абстракциям -- стереотип «entity». Эта пометка означает, что каждый экземпляр класса-сущности имеет явно выраженную индивидуальность, и что обязанностью класса будет хранение данных об объектах предметной области. Для добавления стереотипа выделим нужный класс в браузере, вызовем контекстное меню, Stereotypes -> Edit Stereotypes... -> entity.

      7. Пометим, что класс InventoryItem является классом ассоциации (инструмент палитры Association Class). В итоге диаграмма должна соответствовать рисунку 4.1.3.

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

      Мы готовы перейти к выполнению анализа вариантов использования. В технологии Unified Process он выполняется разработчиками и включает в себя следующие технологические операции:

  1. Идентификацию классов, экземпляры которых участвуют в реализациях потоков событий (так называемых, классов анализа).

  2. Определение обязанностей классов анализа, уточнение их атрибутов и связей.

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

      Классы анализа отражают функциональные требования к системе и моделируют типы объектов. Совокупность классов анализа представляет собой начальную концептуальную модель системы. Эта модель проста и позволяет сосредоточиться на реализации функциональных требований, не отвлекаясь на детали реализации, обеспечение эффективности и надёжности. Для решения этих вопросов впоследствии модель анализа будет трансформирована в проектную модель. В ходе анализа вариантов использования в их потоках событий выявляются классы трёх типов:

  • граничные классы (boundary classes), являющиеся посредниками при взаимодействии системы с действующими лицами и с аппаратной базой;

  • классы-сущности (entity classes), отвечающие за хранение данных;

  • управляющие классы (control classes), реализующие бизнес-логику и обеспечивающие координацию поведения объектов в системе.

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

      Выполним анализ варианта использования CRUD данных о заказах.

Упражнение 4.2. Анализ варианта использования «CRUD данных о заказах»
(общее для всех вариантов)


      Идентифицируем классы анализа. Согласно диаграмме вариантов использования имеются два действующих лица (Продавец и Бухгалтерская система), связанных с нашим вариантом использования. Создадим в пакете Analysis Model граничные классы (контекстное меню пакета Analysis Model, Model Element -> Class): MainMenu -- форму главного меню, OrderForm -- форму заказа, ASAccess -- класс-посредник, реализующий протокол взаимодействия с Бухгалтерской системой. Первые два класса обеспечат взаимодействие системы с действующим лицом Продавец в рамках нашего варианта использования. Созданным трём классам назначим стереотип «boundary» (контекстное меню, Stereotypes -> Edit Stereotypes... -> boundary). Создадим управляющие классы OrderController, отвечающий за реализацию бизнес-логики, и DataAccess, отвечающий за передачу запросов к базе данных (действия аналогичны). Созданным двум классам назначим стереотип «control» (контекстное меню, Stereotypes -> Edit Stereotypes... -> control). Из описания варианта использования следует, что в потоках событий будут задействованы экземпляры классов User, Order, OrderItem, ArticleOfFurniture, Client. Без данных, которые хранятся в экземплярах этих классов, потоки событий не могут быть реализованы. Открываем в редакторе диаграмму классов CRUDOrdersVOPC. Перетаскиваем на неё вышеупомянутые классы из браузера.

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

Рис. 4.2.1 Начальная версия диаграммы классов CRUDOrdersVOPC. Работа над диаграммой не завершена!

Рис. 4.2.1. Начальная версия диаграммы классов CRUDOrdersVOPC. Работа над диаграммой не завершена!

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

Упражнение 4.2.A. Создание диаграммы последовательности «CRUDOrdersBasicFlow»
(общее для всех вариантов)


      Откроем диаграмму последовательности CRUDOrdersBasicFlow. Добавим на диаграмму 5 линий жизни (Lifeline). Ими будут являться взаимодействующие объекты: s : Продавец -- экземпляр действующего лица; m : MainMenu -- экземпляр граничного класса; oc : OrderController -- экземпляр управляющего класса; asa : ASAccess -- экземпляр граничного класса; a : Бухгалтерская система -- экземпляр действующего лица. Заметьте, что линии жизни объектов граничных классов следует располагать рядом линиями жизни, представляющими действующих лиц, за общение с которыми они отвечают. Линия жизни экземпляра класса-контроллера расположена в середине диаграммы.

      Выберем на палитре синхронное сообщение вызова (Call Message) и проведём его от линии жизни s : Продавец к линии жизни m : MainMenu. Оставим сообщение без имени. Вызовем контекстное меню сообщения и выберем в нём Select Operation -> Create Operation. Дадим имя операции crudOrders. Также поступим, добавляя второе синхронное сообщение с тем же именем, которым форма извещает контроллер о выборе продавца (также создаём одноимённую операцию). Каждое сообщение к экземпляру класса должно быть связано с операцией данного класса. Сообщения, получаемые экземплярами действующих лиц связывать с операциями не следует. На диаграмме классов CRUDOrdersVOPC можно видеть, что в классе MainMenu появилась операция crudOrders. Также можно видеть операцию crudOrders в классе-контроллере OrderController.

Рис. 4.2.2. Начальный вид диаграммы последовательности CRUDOrdersBasicFlow. Работа над диаграммой не завершена!

Рис. 4.2.2. Начальный вид диаграммы последовательности CRUDOrdersBasicFlow. Работа над диаграммой не завершена!

      Далее есть три варианта развития событий, в зависимости от того, что хочет сделать с заказом Продавец: создать новый заказ, изменить ранее введённый заказ, удалить заказ. Добавим на диаграмму альтернативный комбинированный фрагмент взаимодействия (Alt. Combined Fragment). Добавим третий операнд внутрь фрагмента (контекстное меню комбинированного фрагмента, Operand -> Add Operant). Добавим сторожевые условия каждому операнду (контекстное меню комбинированного фрагмента, Operand -> Manage Operands). В открывшемся окне в поле Guard укажем сторожевые условия операндов: создаётся заказ -- верхнему операнду, изменяется заказ -- среднему, удаляется заказ -- нижнему (см. диаграмму 4.2.3). Внутри каждого их трёх операндов комбинированного фрагмента будет происходить одно из взаимодействий, соответствующих трём подчинённым потокам варианта использования. Чтобы не загромождать диаграмму основного потока для каждого подчинённого потока создаётся отдельная диаграмма (ранее мы уже создали для этого пустые диаграммы CreateOrderSubflow, UpdateOrderSubflow, DeleteOrderSubflow). На основной диаграмме будут размещены лишь ссылки на используемые взаимодействия. Вернёмся к диаграмме последовательности CRUDOrdersBasicFlow. В созданный нами последним комбинированный фрагмент взаимодействия с тремя операндами добавим указанные на диаграмме сообщения, а также элементы Interaction Use. С помощью контекстного меню каждого Interaction Use укажем на какое взаимодействие он ссылается (Refers to). Ниже нарисуем два вложенных комбинированных фрагмента. Создать их нужно, поместив на диаграмму два Loop Combined Fragment и изменив в них оператор с loop на alt (контекстное меню фрагмента, Operator type -> opt). Добавьте сообщения: синхронне сообщение вызова от объекта-контроллера к экземпляру граничного класса; аcинхронное сообщение к экземпляру действующего лица Бухгалтерская система (тип сообщения установите в контекстом меню сообщения, Model element properties -> Asynchronous); два сообщения-возврата (Reply); синхронное сообщение к форме главного меню. Диаграмма примет вид, схожий с рисунком 4.2.3. Не забудьте создать операции и связать их с сообщениями. Для сообщения к экземпляру действующего лица создавать операцию не следует, достаточно только указать имя сообщения. То же справедливо для сообщений-возвратов, у них лишь указывается имя.

Рис. 4.2.3. Окончательный вид диаграммы CRUDOrdersBasicFlow

Рис. 4.2.3. Окончательный вид диаграммы последовательности CRUDOrdersBasicFlow

      Чтобы у взаимодействующих экземпляров классов была возможность обмениваться сообщениями, проведём на диаграмме классов CRUDOrdersVOPC две ассоциации: от MainMenu к OrderController и от OrderController к ASAccess. Так как сообщения-вызовы идут в одну сторону, то можно указать направление навигации. Диаграмма CRUDOrdersVOPC примет вид как на рис. 4.2.4.. Скриншот диаграммы сделан со включённым выводом операций классов, но с отключённым выводом атрибутов классов.

Рис. 4.2.4. Промежуточный вид диаграммы классов CRUDOrdersVOPC

Рис. 4.2.4. Промежуточный вид диаграммы классов CRUDOrdersVOPC. Работа над диаграммой не завершена!

      Моделировать потоки событий в реализациях вариантов использования можно не только с помощью диаграмм последовательности. Также для этой цели применяют коммуникационные диаграммы (communication diagram). Об этих диаграммах рассказывается на лекции. При выполнении упражнений мы создавать такие диаграммы не будем.

Упражнение 4.2.B. Создание диаграммы последовательности «CreateOrderSubflow»
(только для варианта 1)


      Смоделируем один из подчинённых потоков CreateOrderSubflow. Вид диаграммы последовательности, которая должна получиться, показан на рисунке 4.2.5.

      Создание заказа моделируется на диаграмме последовательности созданной внутри взаимодействия CRUDOrdersBasicFlow. Продавец посылает дату поставки и сведения о заказчике в форму of : OrderForm. Форма, получив эти данные, передаёт запрос о создании заказа OrderController'у. Тот с помощью экземпляра класса для доступа к базе данных DataAccess либо получает из базы данных сведения о ранее созданном заказчике, либо добавляет в базу данных запись со сведениями о новом заказчике. Затем создаётся экземпляр класса Order и добавляется в список заказов, заведённых текущим пользователем. Далее в цикле для каждой позиции заказа Продавец вводит данные. Данные из формы попадают к контроллеру. Он проверяет, что предмет мебели из введённой позиции заказа есть в базе данных через менеджера транзакций. Если проверка успешна, контроллер запрашивает у Order добавление новой позиции. Логично возложить эту обязанность на сам заказ, чтобы оградить контроллер от лишних знаний о внутреннем устройстве заказа. Как заказ работает с собственными позициями -- это его личное дело. Если данные от Продавца ошибочны, данные о такой позиции заказа в системе не сохраняются.

      Далее продавец нажимает кнопку Сохранить заказ в форме. Форма передаёт сообщение об этом контроллеру. Контроллер передаёт доступа к базе данных запрос на сохранение заказа в базе данных. Форма закрывается (об этом говорит значок-крестик на её линии жизни, его следует добавить через контекстное меню линии жизни, Model Element Properties -> Stopped). Для передачи в бухгалтерскую систему контроллер преобразует данные о заказе в формат JSON. Это преобразование происходит в нескольких подчинённых потоках, поэтому оно моделируется на отдельной диаграмме, а здесь располагается только элемент Interaction Use.

      На диаграмме использованы комбинированные фрагменты с оператором opt (Optional), представляющие ветвления с единственной содержательной альтернативой, а также комбинированный фрагмент с оператором loop, описывающий цикл, и элемент Interaction Use. Создавая цикл, следует задать в сторожевых условиях ограничения на количество итераций. Обратите внимание, что на рис. 4.2.5 есть сообщения new, которые имеют тип Creation Message. Не забудьте для всех сообщений-вызовов добавить соответствующие операции в классы и связать их вызовы с сообщениями. Действующему лицу создавать операции не следует. Операции-конструкторы вроде new в аналитической модели можно не заводить.

Рис. 4.2.5 Диаграмма последовательности CreateOrderSubflow

Рис. 4.2.5. Диаграмма последовательности CreateOrderSubflow (моделируется только в варианте 1)

      Каждое сообщение на диаграмме последовательности назначает экземплярам классов обязанности по отправке или приёму и обработке сообщений. Для приёма сообщения в классе объекта-приёмника должна быть одноимённая операция. Для отправки сообщения между экземплярами классов должно быть соединение. Возможность соединения проще всего обеспечить, проведя ассоциацию между классами, экземпляры которых обмениваются сообщениями. На диаграмме 4.2.5 форма OrderForm отправляет сообщение newOrderData() контроллеру OrderController. Значит, в классе OrderController должна быть одноимённая операция, которая обрабатывает сообщение от формы OrderForm, а между классом-формой и классом-контроллером должна быть ассоциация. Нарисуем ассоциацию на диаграмме CRUDOrdersVOPC. Мощности полюсов этой ассоциации указывать не будем, уточним их позже при проектировании. По схожим причинам проведём ассоциации: от OrderController к DataAccess; от OrderController к User; от OrderController к Order. Вид обновлённой диаграммы CRUDOrdersVOPC приведён на 4.2.6.

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

Рис. 4.2.6 Вид обновлённой диаграммы классов CRUDOrdersVOPC

Рис. 4.2.6. Вид обновлённой диаграммы классов CRUDOrdersVOPC после моделирования подпотока CreateOrderSubflow (в варианте 1)

Упражнение 4.2.C. Создание диаграммы последовательности «DeleteOrderSubflow»
(только для варианта 2)


      Если у Вас 2й вариант, то составьте диаграмму последовательности DeleteOrderSubflow. Вид диаграммы последовательности, которая должна получиться приведён на рис. 4.2.7, обновлённый вид диаграммы классов CRUDOrdersVOPC -- на рис. 4.2.8. Линиям жизни or[i] : Order и ol[j] : OrderItem следует отметить флажок Multi-object в их спецификации на вкладке General. Остановленные линии жизни (с крестиками на концах) следует пометить как Stopped (контекстное меню -> Model Element Properties -> Stopped). Сообщение с вызовом деструктора (destroy) лучше создавать как Destroy Message и просто давать им имя, не заводя операцию-деструктор в классе явно. На CRUDOrdersVOPC следует поместить новый класс-участник SelectOrderForm и соединить его ассоциацией с контроллером. Следует расширить размеры классов, чтобы были видны новые добавленные операции, необходимые для моделируемого взаимодействия.

Рис. 4.2.7. Диаграмма последовательности DeleteOrderSubflow

Рис. 4.2.7. Диаграмма последовательности DeleteOrderSubflow (моделируется только в варианте 2)

Рис. 4.2.8. Вид обновлённой диаграммы CRUDOrdersVOPC

Рис. 4.2.8. Вид обновлённой диаграммы классов CRUDOrdersVOPC после моделирования подпотока DeleteOrderSubflow (в варианте 2)

Упражнение 4.2.D. Создание диаграммы последовательности «Order2JSON»
(только для варианта 3)


      Если у Вас 3й вариант, то составьте диаграмму последовательности Order2JSON. Вид диаграммы последовательности, которая должна получиться приведён на рис. 4.2.9, обновлённый вид диаграммы классов CRUDOrdersVOPC -- на рис. 4.2.10. Первое сообщение является найденным (Found Message). Добавьте его на диаграмму, а затем откройте окно спецификации (контекстное меню, Open Specification...). Укажите тип сообщения Call в поле Action Type. Создайте операцию к классе Order и свяжите с сообщением. Линиям жизни ol[j] : OrderItem и a[j] : ArticleOfFurniture следует отметить флажок Multi-object в их спецификациях на вкладке General. Нижнее сообщение является потерянным (Lost Message). Добавьте его на диаграмму, а затем откройте окно спецификации (контекстное меню, Open Specification...). Укажите тип сообщения Reply в поле Action Type. На CRUDOrdersVOPC следует расширить размеры классов, чтобы были видны новые добавленные операции, необходимые для моделируемого взаимодействия. Заметим, что CRUDOrdersVOPC не является связным графом. Это означает, что работа над ней не завершена. Это так, поскольку мы смоделировали не всю реализацию варианта использования, в только вспомогательное взаимодействие Order2JSON.

Рис. 4.2.9 Диаграмма последовательности Order2JSON

Рис. 4.2.9. Диаграмма последовательности Order2JSON (моделируется только в варианте 3)

Рис. 4.2.10. Вид обновлённой диаграммы CRUDOrdersVOPC

Рис. 4.2.10. Вид обновлённой диаграммы классов CRUDOrdersVOPC после моделирования взаимодействия Order2JSON (в варианте 3) Работа над диаграммой не завершена!

Упражнение 4.3. Анализ варианта использования «Войти в систему»

(только для варианта 4)


      Если у Вас 4й вариант, то проведите анализ варианта использования «Войти в систему». Откроем диаграмму LoginVOPC внутри кооперации Login из пакета Use Case Realizations. Поместим на неё классы User, LoginForm, MainMenu, LoginController, DataAccess. Классы, пока отсутствующие в модели, лучше не создавать на диаграмме, а создавать в браузере через контекстное меню пакета Analisys Model, так чтобы все классы анализа оказались в корне этого пакета. Если Вы создали классы на диаграмме, то найдите их в браузере (внутри кооперации) и переместите (перетащите) в корень пакета Analisys Model. Назначьте стереотипы: «boundary» -- LoginForm и MainMenu, «control» -- LoginController и DataAccess. Удостоверьтесь, что классу User назначен стереотип «entity». Начальный вариант диаграммы классов LoginVOPC приведён на рисунке 4.3.1.


Рис. 4.3.1. Начальный вариант диаграммы классов LoginVOPC. Работа над диаграммой не завершена!

Рис. 4.3.1. Начальный вариант диаграммы классов LoginVOPC (моделируется только в варианте 4). Работа над диаграммой не завершена!

      Если у Вас 4й вариант, то анализ варианта использования «Войти в систему» надо продолжить. Откроем диаграмму последовательности LoginBasicFlow. Добавим на диаграмму 6 линий жизни (Lifeline): линию жизни действующего лица Пользователь; lf -- экземпляр формы LoginForm; m -- экземпляр формы MainMenu; c -- экземпляр LoginController; dao -- экземпляр класса DataAccess; cu -- экземпляр класса User. Проще всего добавлять линии жизни перенося действующее лицо и классы из браузера на диаграмму. При переносе класса укажем, что добавляется линия жизни. Добавим линиям жизни стереотипы. Заметим, что линию жизни объекта граничного класса следует расположить рядом с линией жизни, представляющей то действующее лицо, за общение с которыми отвечает граничный класс, а линии объектов контроллеров следует расположить в середине диаграммы. В правой части диаграммы располагают линии жизни объектов-сущностей.

      Добавим на диаграмму сообщения и комбинированные фрагменты согласно рисунку 4.3.2. Редактирование осуществите по аналогии с CRUDOrdersBasicFlow. Комбинированный фрагмент с оператором opt следует добавлять как элемент палитры Loop Combined Fragment с последующей заменой в спецификации фрагмента оператора на нужный (контекстное меню -> Operator Kind). Создадим рефлексивное сообщение (SelfMessage) к экземпляру класса User и укажем его тип (контекстное меню -> Type, Call), свяжем его новой создаваемой операцией. Остановленную линию жизни (с крестиком на конце) следует пометить как Stopped (контекстное меню -> Model Element Properties -> Stopped).


Рис. 4.3.2. Диаграмма последовательности LoginBasicFlow

Рис. 4.3.2. Диаграмма последовательности LoginBasicFlow (моделируется только в варианте 4)

      Если у Вас 4й вариант, то анализ варианта использования «Войти в систему» надо продолжить. Откроем диаграмму классов LoginVOPC. Добавим ассоциации, необходимые для того, чтобы взаимодействие, описанное диаграммой последовательности LoginBasicFlow, было осуществимо. Расставим мощности и имена ролей на полюсах ассоциаций. Укажем направления навигации (на противоположном полюсе с помощью контекстного меню укажите Navigable Unspecified). Итоговый вид диаграммы приведён на рисунке 4.3.3.


Рис. 4.3.3. Итоговая версия диаграммы классов LoginVOPC

Рис. 4.2.10. Итоговая версия диаграммы классов LoginVOPC (моделируется только в варианте 4)

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

      Созданную модель анализа следует сохранить отдельно. Если при проектировании модель анализа разрушится, можно будет использовать сохранённую отдельно её копию. При сдаче выполненных упражнений полезно иметь с собой два проекта: один, сохранённый на момент окончания анализа; второй, представляющий модель после выполнения всех упражнений. Закройте проект и сделайте копию файла проекта в workspace.

5. Проектирование системы


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

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

Упражнение 5.1. Проектирование архитектуры системы обработки заказов
(общее для всех вариантов)


      Система обработки заказов будет работать с собственной реляционной базой данных, в которой будут сохраняться сведения о заказах, клиентах, продаваемых предметах мебели, остатках и проч., следовательно, при проектировании мы будем использовать RDBMS (relational database management system) -- механизм обеспечения работы с устойчивыми данными (т. е. данными сохраняемыми и после завершения сеанса работы с системой). Система обработки заказов также взаимодействует с внешней программой -- бухгалтерской системой. Значит, мы будем использовать при проектировании RemoteInterchange -- механизм обмена запросами и/или данными с внешней системой . Существуют готовые каркасы, обеспечивающие доступ к реляционным БД. К таким относится JDBC (Java Database Connectivity). Каркас XML-RPC обеспечивает межсистемное взаимодействие. Проектные механизмы уже добавлены в нашу модель (они входят в состав заготовки проекта, с которой мы начали выполнять упражнения). См. пакеты Architectural Mechanisms и Middleware в составе Design Model внутри архитектурного представления Logical View.

      В Design Model создайте два пакета: Application и BusinessServices. На уровень приложения мы будем размещать элементы пользовательского интерфейса и элементы, реализующие логику сценариев вариантов использования. На уровень бизнес-служб -- элементы, специфические для предметной области. Уровень промежуточного ПО -- Middleware -- содержит элементы, обеспечивающие сервисы, независимые от платформы. Назначьте пакетам Application и BusinessServices стереотип «layer» -- архитектурный уровень. В Design Model откройте диаграмму пакетов Main, находящуюся в корне Design Model. Вытащите на неё все три архитектурных уровня и соедините их зависимостями (Dependency), как указано на рис. 5.1.1. Мы создали иерархию уровней системы, т. е. описали устройство системы с точки зрения самых крупных её блоков.

Рис. 5.1.1. Диаграмма пакетов Main

Рис. 5.1.1. Диаграмма пакетов Main

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

      При анализе мы не учли полностью все вопросы, связанные с обеспечением работы с устойчивыми данными. В потоке событий система предпринимала некоторые действия, чтобы введённые данные были доступны не только в текущем сеансе работы, но и в последующих. Для этого отправлялись сообщения объекту доступа к данным (DAO), но его действия по обработке этих сообщений не были промоделированы. В этом нет ошибки, во время анализа эти вопросы рассматривать рано, надо сосредоточиться на основных функциях системы. Начиная проектирование, мы обращаемся к этим вопросам и должны смоделировать то, что было пропущено при анализе. Реализация обязанностей, назначенных классу DataAccess, сложна. Поэтому при отображении в проектные классы мы переводим его в одноимённую подсистему обеспечения устойчивости DataAccess. Граничный класс ASAccess, обеспечивающий взаимодействие с бухгалтерской системой, также отображается в подсистему для того, чтобы возможные изменения во взаимодействии с внешней программой мало затрагивали остальные части системы и были локализованы в подсистеме. Остальные классы анализа переведём в проектные один в один.

      Чтобы не испортить модель анализа, скопируем её содержимое внутрь проектной модели. Для этого в браузере выделите пакет Analysis Model, вызовите его контекстное меню и выберите в нём пункт Duplicate Recursively. После этого будет осуществлено дублирование пакета и всех его элементов. Дубль пакета получит имя Analysis Model2. Создайте в пакете Application пакеты Login и CRUDOrders. В созданный пакет CRUDOrders переместите классы участники реализации варианта использования «CRUD данных о заказах»: MainMenu, OrderForm, OrderListForm, OrderController из корня Analysis Model2. Для этого воспользуйтесь контекстным меню элемента и пунктом Move... либо перетащите мышью. Создайте диаграмму классов в пакете CRUDOrders. Дайте ей имя -- CRUDOrders. Перетащите на неё все классы пакета. Прежние стереотипы классов («control», «boundary») удалите. Диаграмма примет вид, похожий на рис. 5.1.2. В зависимости от Вашего варианта класс OrderForm может отсутствовать. На рисунке 5.1.2 вывод операций классов отключён. Если на Вашей диаграмме операции присутстуют, то в этом нет ошибки.

Рис. 5.1.2. Диаграмма классов CRUDOrders

Рис. 5.1.2. Диаграмма классов CRUDOrders (для всех вариантов)

      Если Вы выполняли упражнение по моделированию реализации варианта использования «Войти в систему» (вариант 4), то в пакет Login переместите классы участники этой реализации: LoginForm, LoginController из корня Analysis Model2. Для этого воспользуйтесь контекстным меню элемента и пунктом Move... либо перетащите мышью. Создайте диаграмму классов в пакете Login. Дайте ей имя -- Login. Перетащите на неё все классы этого пакета. Прежние стереотипы классов («control», «boundary») удалите. Диаграмма примет вид, похожий на рис. 5.1.3. На рисунке 5.1.3 вывод операций классов отключён. Если на Вашей диаграмме операции присутстуют, то в этом нет ошибки.

Рис. 5.1.3. Диаграмма классов Login

Рис. 5.1.3. Диаграмма классов Login (только для варианта 4)

      Класс LoginController из пакета Login связан ассоциацией с классом MainMenu из пакета CRUDOrders. Раз так, то следует провести зависимость пакета Login от пакета CRUDOrders. Создадим в пакете Application диаграмму пакетов (контекстное меню пакета, Sub Diagrams -> New Diagram... -> Package Diagram). Назовём её Application по имени пакета. Перетащим пакеты Login и CRUDOrders на созданную диаграмму. Проведём зависимость от пакета Login в направлении пакета CRUDOrders.

Рис. 5.1.4. Диаграмма пакетов Application

Рис. 5.1.4. Диаграмма классов Application (для всех вариантов)

      В пакете BusinessServices создадим пакет WarehouseArtefacts (т. е. артефакты склада, в нем мы разместим классы-сущности предметной области, а также перечислимые типы UserType и OrderStatus). Прежние стереотипы классов («entity») удалим. Через контекстное меню откройем спецификацию диаграммы классов Key Abstractions2. Введём её новое имя в поле Diagram name: WarehouseArtefacts. Укажем новую родительскую модель Parent model: пакет WarehouseArtefacts. Применим изменения. В результате этих действий диаграмма вместе со всеми её элементами и связями переместится в пакет WarehouseArtefacts. В зависимости от Вашего варианта некоторые операции классов могут отсутствовать, в этом нет ошибки.

Рис. 5.1.5. Диаграмма классов WarehouseArtefacts

Рис. 5.1.5. Диаграмма классов WarehouseArtefacts (для всех вариантов)

      В пакете BusinessServices создаим пакет Interfaces (где будут находиться все интерфейсы системы). В пакет Interfaces перенесём классы DataAccess и ASAccess из Analysis Model2. Переименуем DataAccess в IDataAccess, ASAccess в IASAccess. (По соглашениям моделирования имена интерфейсов следует начинать с буквы I.) Назначим классам стереотипы «Interface». Прежние стереотипы («control», «boundary») удалим. Создадим диаграмму классов Interfaces и разместим на ней интерфейсы IDataAccess, IASAccess. Диаграмма примет вид, похожий на рис. 5.1.6. В зависимости от Вашего варианта некоторые операции интерфейса IDataAccess могут отсутствовать, в этом нет ошибки.

Рис. 5.1.6. Диаграмма классов Interfaces

Рис. 5.1.6. Диаграмма классов Interfaces (для всех вариантов)

      Пакет Use Case Realizations из Analysis Model2 перенесём в Design Model и переименуем его в Design Use Case Realizations. Пакет Analysis Model2 удалим (в браузере модели откроем его контекстное меню и выберем Delete). Переименуем кооперации и диаграммы из пакета Design Use Case Realizations (диаграмму вариантов использования Use Case Realizations2 -- в Design Use Case Realizations; кооперацию CRUDOrders2 -- в DesignCRUDOrders; кооперацию Login2 -- в DesignLogin; диаграмму классов CRUDOrdersVOPC2 -- в DesignCRUDOrdersVOPC; диаграмму классов LoginVOPC2 -- в DesignLoginVOPC; диаграмму последовательности CRUDOrdersBasicFlow2 в DesignCRUDOrdersBasicFlow; диаграмму последовательности LoginBasicFlow2 в DesignLoginBasicFlow; диаграмму последовательности CreateOrderSubflow2 в DesignCreateOrderSubflow; диаграмму последовательности UpdateOrderSubflow2 в DesignUpdateOrderSubflow; диаграмму последовательности DeleteOrderSubflow2 в DesignDeleteOrderSubflow; диаграмму последовательности Order2JSON2 в DesignOrder2JSON). В зависимости от Вашего варианта некоторые диаграммы могут отсутствовать в пакете Design Use Case Realizations, в этом нет ошибки.

Рис. 5.1.7. Диаграмма вариантов использования Design Use Case Realizations

Рис. 5.1.7. Диаграмма вариантов использования Design Use Case Realizations (для всех вариантов)

      При реализации подсистемы DataAccess будет задействован механизм RDBMS-JDBC из одноимённого пакета, расположенного в Design Model::Architectural Mechanisms::Persistency. При реализации подсистемы ASAccess будет задействован механизм XMLRPCInterchange из одноимённого пакета, расположенного в Design Model::Architectural Mechanisms::RemoteInterchange. Чтобы не повредить части модели, описывающие механизмы, скопируем их в подсистемы. Для этого продублируем (Duplicate Recursively) пакет RDBMS-JDBC и пакет XMLRPCInterchange, а затем переместим полученные дубли на уровень Business Services и переименуем их в DataAccess и ASAccess, соответственно. Назначим пакетам DataAccess и ASAccess стереотип «subsystem», уберём стереотип «mechanism», если он у них есть. Стереотипы анализа в проектной модели смысла не имеют, их лучше убрать (снять флажки в контекстном меню -> Stereotypes).

      Создадим диаграмму пакетов BusinessServices в пакете BusinessServices. Разместим на ней пакеты Interfaces и WarehouseArtefacts, а также подсистемы DataAccess и ASAccess. Укажем зависимости (Dependency). Элементы подсистем будут реализовывать интерфейсы из пакета Interfaces. В интерфейсе подсистемы DataAccess содержатся операции, обеспечивающие сохранение в БД, подкачку из БД экземпляров классов из WarehouseArtefacts. Это обуславливает смоделированные нами зависимости. Диаграмма примет вид, представленный на рис. 5.1.8.

Рис. 5.1.8. Диаграмма пакетов BusinessServices

Рис. 5.1.8. Диаграмма пакетов BusinessServices (для всех вариантов)

      Откроем диаграмму пакетов Main в корне пакета Design Model. Перетащим на неё пакеты Login и CRUDOrders, так, чтобы они оказались внутри своего архитектурного уровня (Application). Чтобы отобразить зависимость между этими пакетами, добавленную нами ранее в модель, зывовем контекстное меню пакета Login, выберем Related Elements -> Visualize Related Model Element... . Отметим флажком нужную зависимость и отобразим её. Аналогично поступим с пакетами Interfaces и WarehouseArtefacts внутри архитектурного уровня BusinessServices. Аналогично отобразим зависимость между ними. Классы LoginController и OrderController обращаются к DataAccess и к экземплярам классов WarehouseArtefacts. Добавим зависимости для того, чтобы это было осуществимо. Диаграмма примет вид, представленный на рис. 5.1.9.

Рис. 5.1.9. Диаграмма пакетов Main в корне пакета Design Model

Рис. 5.1.9. Диаграмма пакетов Main в корне пакета Design Model (для всех вариантов)

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

Рис. 5.1.10. Структура проектной модели

Рис. 5.1.10. Структура проектной модели в браузере (для всех вариантов)

      Моделирование структуры потоков управления системы в упражнения не включено. Этот вопрос будет рассматриваться только на лекциях. В системе можно выделить следующие процессы: WarehousemanApplication -- процесс, исполняемый на рабочем месте заведующего складом; SalespersonApplication -- процесс, исполняемый на рабочем месте продавца; StockmanApplication -- процесс, исполняемый на рабочем месте кладовщика; DataAccessProcess -- процесс, обеспечивающий доступ к БД системы.

      Смоделируем конфигурацию вычислительной среды нашей системы. Она состоит из трёх типов узлов -- сред выполнения (Execution Environment); компонентов-процессов (Component), которые могут быть размещены внутри сред выполнения; устройств (Device). Связи между узлами -- пути коммуникации (Communication Line) -- являются подвидом ассоциаций. Другой вид связей -- вложение (Containment) -- указывает, что компоненты должны быть инсталлированы на среде выполнения. Откройте диаграмму размещения Main внутри архитектурного представления Deployment View. Создайте на ней узлы и связи между узлами. Компоненты следует создавать, размещая их внутри родительского узла. Окончательный вид диаграммы приведён на рис. 5.1.11. По получившейся диаграмме можно судить, что в вычислительной среде могут быть узлы разных типов: принтер, коммутатор, бухгалтерская система, сервер магазина, рабочие станции трёх видов. Различные виды рабочих станций созданы для того, чтобы предоставлять разным типам пользователей разные функциональные возможности. Лишний функционал не будет включаться в сборку компонента, инсталируемого на рабочее место. На диаграмме указан тип узла, относящийся к внешнему окружению системы -- сервер бухгалтерской системы, подключённый к общей локальной сети магазина. СУБД развёрнута на сервере магазина. К коммутатору подключён принтер по USB интерфейсу. Каждая рабочая станция подключена к коммутатору.

Рис. 5.1.11. Диаграмма размещения Main

Рис. 5.1.11. Диаграмма размещения Main (для всех вариантов)

      Диаграмма Main задаёт перечень типов узлов и возможные конфигурации, составленные из узлов разных типов. Если есть необходимость, то рисуют диаграмму с конкретными узлами (не с типами узлов, а с их экземплярами) для того, чтобы, например, привести пример конкретной конфигурации системы. Создадим вторую диаграмму размещения внутри пакета Delpoyment Model. Назовём её Installation Example. Поместим на неё 8 экземпляров (Instance Specification): asys : Бухгалтерская система, pc01 : Рабочее место заведующего складом, pc02 : Рабочее место кладовщика, pc03 : Рабочее место продавца, pc04 : Рабочее место продавца, srv01 : Сервер магазина, prn : Принтер, switch : Коммутатор. При размещении на диаграмме экземпляр выглядит как обычный прямоугольник. Сразу после размещения дадим имя экземпляру. Затем укажем тип (Classifier), экземпляром которого он является. Вызовем контекстное меню экземпляра, выберем Add Classifier. В открывшемся окне добавляем тип узла. После того, как экземпляру добавлен классификатор -- тип узла, он изображается на диаграмме как прямоугольный параллепипед, т. е. как узел на диаграмме размещения. Между собой экземпляры следует связать соединениями (Link). Соединения выглядят также как ассоциации, но связывать экземпляры можно только ими, а не ассоциациями.

Рис. 5.1.12. Диаграмма размещения Installation Example

Рис. 5.1.12. Диаграмма размещения Installation Example (для всех вариантов)

      На этом проектирование архитектуры завершено, переходим к проектированию элементов системы.

Упражнение 5.2. Проектирование элементов системы обработки заказов
(содержит общую часть для всех вариантов и отдельные части для разных вариантов)


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

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

Упражнение 5.2.1. Уточнение основного сценария варианта использования «CRUD данных о заказах»
(для всех вариантов)


      Откроем диаграмму последовательности DesignCRUDOrdersBasicFlow из кооперации DesignCRUDOrders в пакете LogicalView::Design Model::Design Use Case Realizations. На диаграмме DesignCRUDOrdersBasicFlow следует изменить стереотип на линии жизни объекта asa : IASAccess. Удалим стереотип «boundary», добавим стереотип «interface». Тем самым мы показываем, что происходит обращение к экземпляру класса, реализующего интерфейсы подсистемы. Какой именно это будет класс -- это для реализации варианта использования неважно. Реализация варианта использования не определяет, как подсистема ASAccess должна обрабатывать вызовы операций из её интерфейса. Это будет определено при проектировании подсистемы. Внутреннее поведение подсистемы скрыто, чтобы обеспечить возможность лёгкой модификации её реализации. По этой причине следует удалить сообщение-вызов, идущее от asa : IASAccess к действующему лицу Бухгалтерская система. Также удалим со всех линий жизни стереотипы анализа, т. к. в проектной модели они неуместны. Скроем линию жизни действующего лица Бухгалтерская система, к которой теперь не отправляются сообщения, чтобы диаграмма DesignCRUDOrdersBasicFlow приняла вид, представленный на рисунке 5.2.1. В проектной реализации следует указать более полные сигнатуры вызываемых операций по сравнению с моделью анализа. При уточнении реализаций вариантов использования можно детализировать сигнатуры операций, т. е. добавить их параметры и типы результатов (в браузере раскройте класс, выберите операцию, откройте её спецификацию и введите сведения на вкладках General и Parameters). Но это необязательно, т. к. можно составить полные сигнатуры операций при проектировании классов. Если Вы будете выполнять уточнения сигнатур операций, убедитесь, что работаете с проектными классами, т. е. элементами Design Model. У сообщений new сигнатуры целиком указываются как имена сообщений. Перечислим сигнатуры операций с диаграммы DesignCRUDOrdersBasicFlow:
IASAccess::orderOperation(json:string[]):boolean
MainMenu::createOrder():void
MainMenu::crudOrders():void
MainMenu::deleteOrder():void
MainMenu::displayError(msg:string):void
MainMenu::updateOrder():void
OrderController::createOrder():void
OrderController::crudOrders(u:User):void;
OrderController::deleteOrder():void
OrderController::updateOrder():void

Рис. 5.2.1. Уточнённая диаграмма последовательности DesignCRUDOrdersBasicFlow

Рис. 5.2.1. Уточнённая диаграмма последовательности DesignCRUDOrdersBasicFlow (для всех вариантов)

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



Упражнение 5.2.2. Уточнение подчинённого потока «Создать заказ» варианта использования «CRUD данных о заказах»
(для варианта 1)


      Если у Вас 1й вариант, то откроем диаграмму последовательности DesignCreateOrderSubflow из кооперации DesignCRUDOrders в пакете LogicalView::Design Model::Design Use Case Realizations. На диаграмме DesignCreateOrderSubflow нам следует изменить стереотип на линии жизни объектов dao : IDataAccess. Удалим стереотип «control» и добавим стереотип «interface». Тем самым мы показываем, что происходит обращение к экземпляру класса, реализующего интерфейс подсистемы. Какой именно это будет класс -- это для реализации варианта использования неважно. Реализация варианта использования не определяет, как подсистема DataAccess должна обрабатывать вызовы операций своего интерфейса. Это будет определено при проектировании подсистемы. Внутреннее поведение подсистемы скрыто, чтобы обеспечить возможность лёгкой модификации её реализации. По этой причине следовало бы удалить сообщения-вызовы, идущие от линии жизни dao : IDataAccess к другим линиям жизни, если бы таковые были на диаграмме. Удалим со всех линий жизни стереотипы анализа, так как они неуместны в проектной модели. Убедимся, что диаграмма DesignCreateOrderSubflow приняла вид, представленный на рисунке 5.2.2. В проектной реализации следует указать более полные сигнатуры вызываемых операций по сравнению с моделью анализа. При уточнении реализаций вариантов использования можно детализировать сигнатуры операций, т. е. добавить их параметры и типы результатов (в браузере раскройте класс, выберите операцию, откройте её спецификацию и введите сведения на вкладках General и Parameters). Но это необязательно, т. к. можно составить полные сигнатуры операций при проектировании классов. Если Вы будете выполнять уточнения сигнатур операций, убедитесь, что работаете с проектными классами, т. е. элементами Design Model. У сообщений new сигнатуры целиком указываются как имена сообщений. Перечислим сигнатуры операций с диаграммы DesignCreateOrderSubflow:
IDataAccess::getAvailableArticle(code:string):ArticleOfFurniture
IDataAccess::getClient(clientName:string):Client
IDataAccess::newClient(clientName:string):Client
IDataAccess::newOrder(o:Order):boolean
Order::addItem(a:ArticleOfFurniture, qty:byte):boolean
OrderController::newItemData(code:string, qty:byte):void
OrderController::newOrderData(clientName:string, delivery:Date):void
OrderController::saveOrder():void
OrderForm::newItemData(code:string, qty:byte):void
OrderForm::newOrderData(clientName:string, delivery:Date):void
OrderForm::saveOrder():void
User::addOrder(o:Order):boolean

Рис. 5.2.2. Уточнённая диаграмма последовательности DesignCreateOrderSubflow

Рис. 5.2.2. Уточнённая диаграмма последовательности DesignCreateOrderSubflow (только для варианта 1)

Упражнение 5.2.3. Уточнение подчинённого потока «Удалить заказ» варианта использования «CRUD данных о заказах»
(для варианта 2)


      Если у Вас 2й вариант, то откроем диаграмму последовательности DesignDeleteOrderSubflow из кооперации DesignCRUDOrders в пакете LogicalView::Design Model::Design Use Case Realizations. На диаграмме DesignDeleteOrderSubflow нам следует изменить стереотип на линии жизни объектов dao : IDataAccess. Удалим стереотип «control» и добавим стереотип «interface». Тем самым мы показываем, что происходит обращение к экземпляру класса, реализующего интерфейс подсистемы. Какой именно это будет класс -- это для реализации варианта использования неважно. Реализация варианта использования не определяет, как подсистема DataAccess должна обрабатывать вызовы операций своего интерфейса. Это будет определено при проектировании подсистемы. Внутреннее поведение подсистемы скрыто, чтобы обеспечить возможность лёгкой модификации её реализации. По этой причине следовало бы удалить сообщения-вызовы, идущие от линии жизни dao : IDataAccess к другим линиям жизни, если бы таковые были на диаграмме. Удалим со всех линий жизни стереотипы анализа, так как они неуместны в проектной модели. Убедимся, что диаграмма DesignDeleteOrderSubflow приняла вид, представленный на рисунке 5.2.3. В проектной реализации следует указать более полные сигнатуры вызываемых операций по сравнению с моделью анализа. При уточнении реализаций вариантов использования можно детализировать сигнатуры операций, т. е. добавить их параметры и типы результатов (в браузере раскройте класс, выберите операцию, откройте её спецификацию и введите сведения на вкладках General и Parameters). Но это необязательно, т. к. можно составить полные сигнатуры операций при проектировании классов. Если Вы будете выполнять уточнения сигнатур операций, убедитесь, что работаете с проектными классами, т. е. элементами Design Model. У сообщений new сигнатуры целиком указываются как имена сообщений. Перечислим сигнатуры операций с диаграммы DesignDeleteOrderSubflow:
IDataAccess::deleteOrder(o:Order):boolean
OrderController::confirm2Delete():void
OrderController::select2Delete(i:int):void
OrderForm::cancel():void
OrderForm::confirm2Delete():void
OrderListForm::select2Delete(i:int):void
User::deleteOrder(o:Order):void
User::getOrderList():Order[]

Рис. 5.2.3. Уточнённая диаграмма последовательности DesignDeleteOrderSubflow

Рис. 5.2.3. Уточнённая диаграмма последовательности DesignDeleteOrderSubflow (только для варианта 2)

Упражнение 5.2.4. Уточнение диаграммы «DesignOrder2JSON» варианта использования «CRUD данных о заказах»
(для варианта 3)


      Если у Вас 3й вариант, то откроем диаграмму последовательности DesignOrder2JSON из кооперации DesignCRUDOrders в пакете LogicalView::Design Model::Design Use Case Realizations. На диаграмме DesignOrder2JSON нам следует удалить со всех линий жизни стереотипы анализа, так как они неуместны в проектной модели. Убедимся, что диаграмма DesignOrder2JSON приняла вид, представленный на рисунке 5.2.4. В проектной реализации следует указать более полные сигнатуры вызываемых операций по сравнению с моделью анализа. При уточнении реализаций вариантов использования можно детализировать сигнатуры операций, т. е. добавить их параметры и типы результатов (в браузере раскройте класс, выберите операцию, откройте её спецификацию и введите сведения на вкладках General и Parameters). Но это необязательно, т. к. можно составить полные сигнатуры операций при проектировании классов. Если Вы будете выполнять уточнения сигнатур операций, убедитесь, что работаете с проектными классами, т. е. элементами Design Model. У сообщений new сигнатуры целиком указываются как имена сообщений. Перечислим сигнатуры операций с диаграммы DesignOrder2JSON:
Order::toJSON():string[]
OrderItem::toJSON():string[]
Client::toJSON():string[]
ArticleOfFurniture::toJSON():string[]
User::toJSON():string[]

Рис. 5.2.4. Уточнённая диаграмма последовательности DesignOrder2JSON

Рис. 5.2.4. Уточнённая диаграмма последовательности DesignOrder2JSON (только для варианта 3)

Упражнение 5.2.5. Уточнение основного сценария варианта использования «Войти в систему»
(для варианта 4)


      Если у Вас 4й вариант, то откроем диаграмму последовательности DesignLoginBasicFlow из кооперации DesignLogin в пакете LogicalView::Design Model::Design Use Case Realizations. На диаграмме DesignLoginBasicFlow нам следует изменить стереотип на линии жизни объектов dao : IDataAccess. Удалим стереотип «control» и добавим стереотип «interface». Тем самым мы показываем, что происходит обращение к экземпляру класса, реализующего интерфейс подсистемы. Какой именно это будет класс -- это для реализации варианта использования неважно. Реализация варианта использования не определяет, как подсистема DataAccess должна обрабатывать вызовы операций своего интерфейса. Это будет определено при проектировании подсистемы. Внутреннее поведение подсистемы скрыто, чтобы обеспечить возможность лёгкой модификации её реализации. По этой причине следовало бы удалить сообщения-вызовы, идущие от линии жизни dao : IDataAccess к другим линиям жизни, если бы таковые были на диаграмме. Удалим со всех линий жизни стереотипы анализа, так как они неуместны в проектной модели. Убедимся, что диаграмма DesignLoginBasicFlow приняла вид, представленный на рисунке 5.2.5. В проектной реализации следует указать более полные сигнатуры вызываемых операций по сравнению с моделью анализа. При уточнении реализаций вариантов использования можно детализировать сигнатуры операций, т. е. добавить их параметры и типы результатов (в браузере раскройте класс, выберите операцию, откройте её спецификацию и введите сведения на вкладках General и Parameters). Но это необязательно, т. к. можно составить полные сигнатуры операций при проектировании классов. Если Вы будете выполнять уточнения сигнатур операций, убедитесь, что работаете с проектными классами, т. е. элементами Design Model. У сообщений new сигнатуры целиком указываются как имена сообщений. Перечислим сигнатуры операций с диаграммы DesignLoginBasicFlow:
IDataAccess::getUserByLogin(login:string):User
LoginController::login(login:string, psw:string):void
LoginForm::cancel():void
LoginForm::close():void
LoginForm::displayError(msg:string):void
LoginForm::login(login:string, psw:string):void
User::checkPassword(psw:string):boolean
User::getUserType():UserType
User::password2Hash(psw:string):long[2]

Рис. 5.2.5. Уточнённая диаграмма последовательности DesignLoginBasicFlow

Рис. 5.2.5. Уточнённая диаграмма последовательности DesignLoginBasicFlow (только для варианта 4)

Вводные замечания по проектированию подсистем
(общие для всех вариантов)


      Следующей технологической операцией является проектирование подсистем. В рассматриваемой модели в ходе этой операции нам предстоит на основе механизма JDBC спроектировать подсистему DataAccess, а на основе механизма XMLRPCInterchange спроектировать подсистему ASAccess. При этом механизм выполнит роль шаблона, описывающего с точки зрения структуры и поведения либо типовую организацию доступа к устойчивым данным, либо типовую организацию обмена данными с внешней системой. В шаблоне JDBC своего рода параметрами являются классы PersistentObject, PersistentObjectList и DBClass, а в шаблоне XMLRPCInterchange -- классы ObjectToSend, ObjectToReceive, CustomTypeFactory, CustomParser, CustomSerializer и XMLRPCConnector. Проектирование подсистемы, в основном, сводится к конкретизации шаблона, в ходе которой класс-параметр (например, PersistentObject) заменяется на конкретный класс из модели (например, на класс Client, сведения об экземплярах которого хранятся в БД, и другие подобные классы из пакета WarehouseArtefacts). Класс-параметр DBClass заменяется на прокси-класс подсистемы DataAccess. Класс-параметр XMLRPCConnector заменяется на прокси-класс подсистемы ASAccess, обеспечивающий передачу данных во внешнюю систему.


Упражнение 5.2.6. Проектирование подсистемы DataAccess на основе механизма JDBC
(общее для всех вариантов)


      Для начала убедимся, что интерфейс подсистемы IDataAccess верно представлен в нашей модели. В ходе предшествующих упражнений в интерфейс добавлены следующие операции: IDataAccess::deleteOrder(o:Order):boolean, IDataAccess::getAvailableArticle(code:string):ArticleOfFurniture, IDataAccess::getClient(clientName:string):Client, IDataAccess::getUserByLogin(login:string):User, IDataAccess::newClient(clientName:string):Client, IDataAccess::newOrder(o:Order):boolean. Если каких-то операций в модели нет, или если их сигнатуры не полны, то следует дополнить модель. Далее нам следует создать прокси-класс подсистемы DataAccess. Экземпляр этого класса будет принимать и обрабатывать все вызовы операций, входящие в подсистему. В браузере находим интерфейс IDataAccess, открываем его контекстное меню и создаём дубль интерфейса при помощи Duplicate (не Duplicate Recursively). Переименуем дубль из IDataAccess2 в DataAccess. Уберём стереотип «interface», добавим стереотип «subsystem proxy». Переместим прокси-класс в подсистему DataAccess. Переименуем внутри пакета DataAccess диаграмму классов RDBMS-JDBC2 в Main, диаграмму пакетов RDBMS-JDBC2 также в Main. Класс PersistentObject переименуем в класс Client и с помощью контекстного меню объединим класс Client из подсистемы DataAccess с одноимённым классом Client из пакета WarehouseArtefacts (Merge to Model Element..., так чтобы целевым был класс из пакета WarehouseArtefacts). Из класса Client удалим атрибут attribute и переименуем операции getAttribute в getName, setAttribute в setName. Класс PersistentObjectList переместим в пакет WarehouseArtefacts и переименуем его в ClientList. Откройем спецификацию класса ClientList. Найдём вкладку Relations. Изменим имя у отношения зависимости связывания (Binding) на < E->Client >. Ту же строку <E->Client> укажем в поле Template info. Тем самым мы укажем, что элементами этого списка будут экземпляры класса Client. Класс DBClass с помощью контекстного меню объединим c классом DataAccess (Merge to Model Element..., так чтобы целевым был класс DataAccess). Удалим из класса DataAccess шаблонные операции create, read, update, delete. Операции initialize и disconnect оставим. В подсистеме DataAccess переименуем кооперацию JDBC2 в IDataAccessRealization. Добавим ей стереотип «interface realization» и удалим стереотип «mechanism».

      Откроем диаграмму классов Main в подсистеме DataAccess. На ней указано, что при реализации доступа к БД используются элементы, описанные в пакетах java::lang и java::sql. Поэтому откроем диаграмму пакетов из пакета BusinessServices, перенесём на неё пакеты java::lang и java::sql с уровня Middleware из пакета java. Убедимся, что отобразились зависимости импорта (Dependency или Import) от подсистемы DataAccess к пакетам java::lang и java::sql. Если нет, то добавим их на диаграмму пакетов. При этом зависимости должны быть направлены от зависящего пакета в сторону пакетов, от которых он зависит.

      Внутри кооперации IDataAccessRealization диаграмму последовательности initialize2 переименуем в initialize, create2 -- в newClient, read2 -- в getClient, disconnect2 -- в disconnect, update2 -- в createOrder, delete2 -- в deleteOrder, диаграмму составной структуры Main2 в Main. Теперь откроем находящуюся внутри подсистемы DataAccess диаграмму классов Main. Поместим на неё классы Order, User, Article и проведём зависимости к этим классам от класса DataAccess. Скроем с диаграммы классы ArrayList и ClientList, так как подсистема не работает со списками и не возвращает их в результате вызовов своих операций. Добавим на диаграмму интерфейс IDataAccess и переключим его отображение на «леденцовую» нотацию (контекстное меню, Presentation Options -> Interface Ball). Проведём связь реализации между интерфейсом IDataAccess и классом DataAccess. В результате, диаграмма классов и структура подсистемы должны быть похожи на изображённые на рисунках 5.2.2 и 5.2.3. Благодаря использованию механизма мы затратили меньше сил на обдумывание и моделирование, чем если бы делали подсистему с чистого листа. Переходим к моделированию внутреннего поведения подсистемы.


Рис. 5.2.6. Диаграмма классов Main подсистемы DataAccess

Рис. 5.2.6. Диаграмма классов Main подсистемы DataAccess (для всех вариантов)

Рис. 5.2.7. Структура подсистемы DataAccess в браузере модели

Рис. 5.2.7. Структура подсистемы DataAccess в браузере модели (для всех вариантов)

      Внутри кооперации IDataAccess находятся 6 диаграмм последовательности: deleteOrder, disconnect, getClient, initialize, newClient, newOrder. Каждая из них описывает то, что делают объекты подсистемы при вызове соответствующей операции. Реализацию операций deleteOrder, getAvailableArticle, getUserByLogin и newOrder мы моделировать не будем, остальные четыре (disconnect, getClient, initialize, newClient) промоделируем.

      На диаграмме последовательности disconnect левая линия жизни должна представлять объект dao:DataAccess, входящее сообщение, принимаемое им, должно быть связано с операцией disconnect. Внесём необходимые изменения так, чтобы диаграмма приняла вид, изображённый на рисунке 5.2.8.

Рис. 5.2.8. Диаграмма последовательности, описывающая реализацию операции disconnect()

Рис. 5.2.8. Диаграмма последовательности, описывающая реализацию операции disconnect() (для всех вариантов)

      Аналогично, диаграмма последовательности initialize должна иметь вид, изображённый на рисунке 5.2.9.

Рис. 5.2.9. Диаграмма последовательности, описывающая реализацию операции initialize()

Рис. 5.2.9. Диаграмма последовательности, описывающая реализацию операции initialize() (для всех вариантов)

      На диаграмме последовательности getClient левая линия жизни должна представлять объект dao:DataAccess, а вторая слева -- obj:Client. Линия жизни объекта ClientList должна быть удалена. Свяжем найденное сообщение, принимаемое экземпляром DataAccess, с операцией getClient. Добавим классу Client новые операции setAddress(value:string[3]):void, setPhones(value:string[*]):void. Проще всего геттеры и сеттеры атрибута добавлять через его контекстное меню (откроем диаграмму классов WarehouseArtefacts в одноимённом пакете, выделим атрибут, вызовем контекстное меню -> Create Getter and Setter). Заменим на диаграмме последовательности оператор взаимодействия в комбинированном фрагменте с loop на opt. Добавим новое сообщение-вызов isAfterLast() до комбинированного фрагмента. Добавим новые сообщения внутрь фрагмента. Диаграмма должна иметь вид, изображённый на рисунке 5.2.10.

Рис. 5.2.10. Диаграмма последовательности, описывающая реализацию операции getClient(name:string):Client

Рис. 5.2.10. Диаграмма последовательности, описывающая реализацию операции getClient(name:string):Client (для всех вариантов)

      На диаграмме последовательности newClient левая линия жизни должна представлять экземпляр dao:DataAccess, самая правая -- объект Client. Свяжем найденное сообщение с операцией newClient. Свяжем второе сверху сообщение с вызовом операции initialize. Свяжем четвёртое сверху сообщение с вызовом операции setName. Диаграмма должна иметь вид, изображённый на рисунке 5.2.11.

Рис. 5.2.11. Диаграмма последовательности, описывающая реализацию операции newClient(clientName:string):Client

Рис. 5.2.11. Диаграмма последовательности, описывающая реализацию операции newClient(clientName:string):Client (для всех вариантов)

      Проектирование подсистемы DataAccess завершено. Переходим к проектированию подсистемы ASAccess.

Упражнение 5.2.7. Проектирование подсистемы ASAccess на основе механизма XMLRPCInterchange
(общее для всех вариантов)


      Выполним проектирование подсистемы ASAccess. Для начала убедимся, что интерфейс подсистемы IASAccess верно представлен в нашей модели. В ходе предшествующих упражнений в интерфейс добавлена единственная операция: IASAccess::orderoperation(json:string[]):boolean. Если такой операции интерфейса в модели нет, или если её сигнатура не полна, то следует дополнить модель. Далее нам следует создать прокси-класс подсистемы ASAccess. Экземпляр этого класса будет принимать и обрабатывать все вызовы операций, входящие в подсистему. В браузере находим интерфейс IASAccess, открываем его контекстное меню и создаём дубль интерфейса при помощи Duplicate (не Duplicate Recursively). Переименуем дубль из IASAccess2 в ASAccess. Уберём стереотип «interface», добавим стереотип «subsystem proxy». Переместим прокси-класс в подсистему ASAccess. Переименуем внутри пакета ASAccess диаграмму классов XMLRPCInterchange2 в Main, диаграмму пакетов XMLRPCInterchange2 также в Main. Так как единственная операция не содержит в своей сигнатуре параметров -- экземпляров нестандартных классов, и так как она возвращает булево значение, то в подсистеме не нужны классы ObjectToSend, ObjectToReceive, CustomTypeFactory, CustomParser и CustomSerializer. Удалим их из браузера модели. Класс XMLRPCConnector с помощью контекстного меню объединим c классом ASAccess (Merge to Model Element..., так чтобы целевым был класс ASAccess). Удалим из класса ASAccess шаблонную операцию sendRequest. В подсистеме ASAccess переименуем кооперацию XMLRPCInterchange2 в IASAccessRealization. Добавим ей стереотип «interface realization» и удалим стереотип «mechanism».

      Откроем диаграмму классов Main в подсистеме ASAccess. На ней указано, что при обмене данными с внешней подсистемой по протоколу XML-RPC используются элементы, описанные в пакетах java::net и org::apache::xmlrpc. Поэтому откроем диаграмму пакетов из пакета BusinessServices, перенесём на неё пакеты java::net и org::apache::xmlrpc с уровня Middleware из пакетов java и org::apache. Убедимся, что отобразились зависимости импорта (Dependency или Import) от подсистемы ASAccess к пакетам java::net и org::apache::xmlrpc. Если нет, то добавим их на диаграмму пакетов. При этом зависимости должны быть направлены от зависящего пакета в сторону пакетов, от которых он зависит.

      Внутри кооперации IASAccessRealization диаграмму последовательности init2 переименуем в init, sendRequest2 -- в orderOperation, диаграмму составной структуры XMLRPCInterchange Main2 в Main. Теперь откроем находящуюся внутри подсистемы ASAccess диаграмму классов Main. Скроем с диаграммы интерфейсы TypeSerializer и TypeParser, так как подсистема не работает с пользовательскими типами данных, а также ненужные классы Object и TypeFactoryImpl. Добавим на диаграмму интерфейс IASAccess и переключим его отображение на «леденцовую» нотацию (контекстное меню, Presentation Options -> Interface Ball). Проведём связь реализации между интерфейсом IASAccess и классом ASAccess. В результате, диаграмма классов и структура подсистемы должны быть похожи на изображённые на рисунках 5.2.12 и 5.2.13. Благодаря использованию механизма мы затратили меньше сил на обдумывание и моделирование, чем если бы делали подсистему с чистого листа. Переходим к моделированию внутреннего поведения подсистемы ASAccess.

Рис. 5.2.12. Диаграмма классов Main подсистемы ASAccess

Рис. 5.2.12. Диаграмма классов Main подсистемы ASAccess


Рис. 5.2.13. Структура подсистемы ASAccess в браузере модели

Рис. 5.2.13. Структура подсистемы ASAccess в браузере модели

Рис. 5.2.14. Диаграмма пакетов BusinessServices в пакете BusinessServices

Рис. 5.2.14. Диаграмма пакетов BusinessServices в пакете BusinessServices

      Внутри кооперации IASAccess находятся диаграммы последовательности init, orderOperation. Каждое взаимодействие будет описывать, что делают объекты подсистемы при вызове соответствующей операции.

      На диаграмме последовательности init вторая слева линия жизни должна представлять объект cn:ASAccess, входящее сообщение, принимаемое им, должно быть связано с операцией init. Так как обмен происходит данными только стандартных типов, то следует удалить линию жизни объекта-фабрики (вторую справа) и два нижних сообщения. Диаграмма примет вид, изображённый на рисунке 5.2.15. Взаимодействие описывает инициализацию подсистемы перед первым обменом данными с внешней системой.


Рис. 5.2.15. Диаграмма последовательности, описывающая реализацию операции init() в подсистеме ASAccess

Рис. 5.2.15. Диаграмма последовательности, описывающая реализацию операции init() в подсистеме ASAccess

      На диаграмме последовательности orderOperation левая линия жизни должна представлять cn:ASysAccess, а самая правая -- действующее лицо Бухгалтерская система (переименуйем XMLRPCServer). Шаблонная диаграмма описывает сложное взаимодействие, при котором не только пересылается объект данных во внешнюю систему, но и в ответ получается объект-результат. Моделируемая нами операция ничего такого не предусматривает, а значит, лишние линии жизни следует удалить из модели (из фрейма orderOperation): result, cp, cs, cf. Должны остаться только три линии жизни: cn:ASysAccess, client:XMLRpcClient и Бухгалтерская система. Свяжем найденное сообщение, принимаемое экземпляром ASAccess, с операцией orderOperation. Свяжем рефлексивное сообщение внутри opt-фрагмента с операцией init. Изменим второй аргумент в сообщении execute (контекстное меню, Open Specification, вкладка Argumets, второй аргумент должен быть json). Удалим примечания с диаграммы последовательности. Добавим нижнее потерянное сообщение (Lost Message) от объекта cn:ASysAccess и укажем его тип -- возврат (контекстное меню -> Type(Reply)). В спецификации сообщения в поле Name укажите, что возвращается. Диаграмма примет вид, изображённый на рисунке 5.2.16.


Рис. 5.2.16. Диаграмма последовательности, описывающая реализацию операции orderOperation() в подсистеме ASAccess

Рис. 5.2.16. Диаграмма последовательности, описывающая реализацию операции orderOperation() в подсистеме ASAccess

      Проектирование подсистемы ASAccess будем считать завершённым.



Упражнение 5.2.8. Проектирование классов системы
(общее для всех вариантов)


      Проектирование классов включает следующие действия: детализацию проектных классов; уточнение операций и атрибутов; моделирование состояний для экземпляров классов; уточнение связей между классами. При детализации проектный класс может быть разбит на несколько классов из соображений, связанных с его реализацией в коде. Класс может быть удалён из модели, если его экземпляры являются посредниками, не несущими содержательных обязанностей. Обязанности классов, определённые в процессе анализа и документированные в виде операций анализа, преобразуются в операции, которые будут реализованы в коде. При этом каждой операции присваивается краткое имя, характеризующее её, определяется полная сигнатура операции, создаётся краткое описание операции, содержащее смысл всех её параметров, определяется видимость операции, определяется область действия операции (операция экземпляра или операция класса). Если метод, реализующий операцию, реализует нетривиальный алгоритм, то он моделируется на диаграмме деятельности. Уточнение атрибутов классов заключается в следующем: задаются типы атрибутов, их множественность и значения по умолчанию (необязательно); задаётся видимость атрибутов; при необходимости определяются производные (вычисляемые) атрибуты, статические атрибуты.

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

      Затем производится уточнение связей между классами. Ассоциации, созданные на этапе анализа, которые соответствуют временным соединениям между объектами, заменяются на зависимости. Оставшиеся ассоциации заменяются на агрегации или композиции. Указываются мощности на полюсах, направления связей, типы множественных связей (set, ordered, bag, sequence), квалификаторы. Классы ассоциаций преобразуются в обычные с помощью материализации связей. Некоторые связи обобщения могут быть преобразованы применением метаморфозы подтипов.

      Рассмотрим проектирование классов на примере системы обработки заказов. Откроем в пакете WarehouseArtefacts диаграмму классов. Добавим и уточним атрибуты и операции классов, чтобы придать ему вид, схожий с рисунком 5.2.17. Статические (подчеркнутые) атрибуты и операции пометим, указав в их спецификации в поле Scope значение сlassifier. Аналогично поступим с выводимыми (начинающимися со слэша) атрибутами (отметим флажок Derived). Чтобы указать квалификатор, используем контекстное меню ассоциации.

Рис. 5.2.17. Диаграмма классов WarehouseArtefacts Class Diagram

Рис. 5.2.17. Диаграмма классов WarehouseArtefacts Class Diagram

      Экземпляры класса Order должны по-разному обрабатывать вызовы их операции в зависимости от состояния заказа. Например. если сборка заказа закончена, то в него нельзя добавлять новые позиции. Это признак сложного поведения и причина для создания диаграммы состояний. Добавим классу Order диаграмму состояний Lifeсycle. Создайте начальное псевдосостояние (Initial), финальное состояние (FinalState) и состояние Active (State). Внутри состояния Active разместим подсостояния In Process, Cancelled, Filled, Delivered и псевдосостояние выбора (Choice). Чтобы была возможность создавать подсостояния, предварительно добавим внутрь Active регион (контекстное меню -> Add Horizontal Region). Соединим состояния переходами, как указано на рисунке 5.2.18.

      

      Переходу может быть добавлено событие (триггер), указываемое до слэша; действие, указываемое после слэша; сторожевое условие, записываемое в прямоугольных скобках. События addItem, removeItem, delete, markDelivery, markFilledItem, cancel и when(numOfItems>0 && numOfItems == numOfFilledItems) добавим на вкладку Triggers спецификаций переходов. Типы всех событий, кроме последнего -- события вызова (Call Trigger). Тип последнего события -- событие изменения (Change Trigger). Событие removeItem приписано разным переходам. Не следует создавать дважды это событие. Привяжем одно и то же событие обоим переходам. Действия при переходах укажем в поле Effect, текст действия укажем в имени создаваемой деятельности. Значок "^" в записи действия обозначает отправку сообщения другому объекту. Чтобы добавить внутренние переходы (переходы без стрелок на диаграмме) в состоянии In Process добавим сначала ему внутренний регион с помощью контекстного меню (Add Horizontal Region).

      В итоге модель состояний должна соответствовать изображённому на рисунках 5.2.18, 5.2.19.

Рис. 5.2.18. Диаграмма состояний Lifecycle внутри класса Order

Рис. 5.2.18. Диаграмма состояний Lifecycle внутри класса Order

Рис. 5.2.19. Структура модели состояний в браузере

Рис. 5.2.19. Структура модели состояний в браузере

      К проектированию классов также относится моделирование нетривиальных реализаций операций (т. е. методов). Например, тривиальными являются операции-геттеры. Нетривиальная операция содержит в своём методе ветвления и/или циклы. В нашу модель внутрь проектного класса OrderController можно добавить диаграмму деятельности newOrderData (см. рис. 5.2.20), а также внутрь проектного класса Order -- диаграмму деятельности toJSON (см. рис. 5.2.21). По желанию Вы можете построить эти диаграммы.

Рис. 5.2.20. Диаграмма деятельности OrderController::newOrderData, моделирующая реализацию одноимённой операции

Рис. 5.2.20. Диаграмма деятельности OrderController::newOrderData, моделирующая реализацию одноимённой операции

Рис. 5.2.21. Диаграмма деятельности Order::toJSON, моделирующая реализацию одноимённой операции

Рис. 5.2.21. Диаграмма деятельности Order::toJSON, моделирующая реализацию одноимённой операции

      Уточним связи между классами на диаграмме DesignCRUDOrdersVOPC проектной реализации варианта использования CRUD данных о заказах. Откроем диаграмму (Design Model -> Use Case Realization -> DesignCRUDOrdersVOPC). Удалим из модели (в Model Explorer) лишние ассоциации между проектными классами. Добавим недостающую зависимость OrderController от Client (она есть, т. к. при создании заказа используется локальный объект -- экземпляр Client). Осуществим уточнение связей. OrderController использует интерфейс, для этого в нём хранится ссылка на экземпляр класса, реализующего этот интерфейс. На диаграмме этот факт отображается агрегацией, направленной к интерфейсу. OrderController также хранит ссылку на текущий заказ. Укажем направления ассоциаций и мощности при их полюсах. Ассоциации без явных стрелочек являются двунаправленными.

Рис. 5.2.22. Уточненная диаграмма классов DesignCRUDOrdersVOPC

Рис. 5.2.22. Уточненная диаграмма классов DesignCRUDOrdersVOPC

Упражнение 5.3. Проектирование схемы реляционной базы данных
(общее для всех вариантов)


      Если среди проектных классов есть устойчивые, чьи экземпляры должны сохраняться в периодах между запусками системы, следует обеспечить сохранение их в базе данных (например, реализовав подсистему обеспечения устойчивости на базе JDBC) и создать схему реляционной базы данных. Фактически, следует отобразить объектную модель в реляционную. Одна из стратегий при этом состоит в том, что для каждого устойчивого класса создаётся собственная таблица. Атрибуты класса переводятся в столбцы таблицы. Столбцы для хранения выводимых атрибутов не заводятся, т. к. эти значения вычисляются при выполнении запросов. Атрибуты с нескалярными значениями (массивами) переводятся в отдельные таблицы, чтобы не нарушать ограничений 1й нормальной формы. Атрибут-идентификатор (или набор атрибутов) переводится в первичный ключ. Ассоциации моделируются с помощью связей между таблицами (связывающими значения первичного ключа записей одной таблицы со значениями внешнего ключа другой таблицы). Заметим, что связи между таблицами обычно двунаправленные, по записям любой из связанных таблиц можно найти соответствующие записи другой таблицы. Связи между таблицами могут быть идентифицирующими и не идентифицирующими. Идентифицирующая связь указывает, что внешний ключ включает в себя часть первичного ключа, то есть ключ родительской записи является частью ключа дочерних записей. Связь отображается как композиция, если требуется указать на каскадированное удаление связанных записей из подчинённой таблицы. В некоторых случаях для ассоциации (например, с максимальными мощностями обоих полюсов *) требуется создавать дополнительную служебную таблицу, хранящую соединения между объектами. Для отображения обобщений используются разные способы. Один из них -- "отдельная таблица для каждого класса". В этом случае у всех получившихся таблиц будет один и тот же первичный ключ, который в таблицах подклассов будет также внешним ключом.

      Осуществим проектирование схемы реляционной базы данных. Продублируем рекурсивно пакет WarehouseArtefacts. Полученный дубль переименуем в Database Schema и переместим в корень Design Model. Назначим ему стереотип «schema». С помощью Model Explorer удалим всё лишнее из этого пакета: зависимости, перечислимые типы, класс ClientList, диаграмму состояний, диаграммы деятельности, все операции всех классов. Диаграмму WarehouseArtefacts Class Diagram2, находящуюся в пакете, переименуем в Database Schema. Добавим классам, находящимся на диаграмме стереотип «table» и уберём стереотип «entity». Переименуем классы, добавив к именам приставку Table. Добавим класс (таблицу) TableStatic для хранения значений статических атрибутов. Добавим класс (таблицу) TablePhone для хранения телефонов клиентов. См. рисунок 5.3.1. Эту схему можно использовать для хранения сведений о заказах, клиентах, пользователях, предметах мебели. Таблица с записями о заказах состоит из 7 столбцов, один из которых является первичным ключом («PK»), а два внешними ключами («FK») для связи с записями из таблиц клиентов и пользователей. Позиции заказа хранятся в отдельной таблице TableOrderItem. В этой таблице 6 столбцов, один из которых является первичным ключом («PK»), а два других -- внешними ключами («FK») для связи с таблицами артикулов и заказов. У таблицы есть составной альтернативный ключ («AK») из двух столбцов. Связь между таблицами TableOrder и TableOrderItem не идентифицирующая, так как никакая часть первичного ключа не является внешним ключом. Сведения о заказываемых предметах мебели хранятся в таблице TableArticleOfFurniture. В ней 4 столбца, один из которых является первичным ключом, а ещё один -- альтернативным ключом. Связь этой таблицы с таблицей TableOrderItem также не идентифицирующая. Заметим, что всякий раз внешний ключ для связи 1 к * добавляется в таблицу со стороны *. Рассмотрим таблицу TableClient. Значение атрибута address:string[3] хранится в трёх столбцах-строках. Значение атрибута phones:string[*] хранится в отдельной таблице TablePhone. Заметим как связана эта таблица с таблицей TableClient. Связь идентифицирующая, так как первичный ключ таблицы TablePhone состоит из двух столбцов, и один из них -- clientId -- также является внешним ключом. Связь промоделирована как композиция. Это означает, что при удалении записи о клиенте удаляются и все связанные записи о телефонах удаляемого клиента. Такое же каскадированное удаление записей о позициях заказа, происходящее при удалении записи о заказе, показано композицией между таблицами TableOrder и TableOrderItem.

      Согласно этой схеме одному объекту -- экземпляру класса Order -- будут соответствовать одна запись в таблице TableOrder и связанные с ней записи в таблице TableOrderItem. Во всех этих записях будет одно и то же значение номера заказа. Для любой записи в таблице TableOrderItem можно найти связанную с ней запись из таблицы TableOrder о заказе, к которому относится эта позиция. И наоборот, для любой записи из таблицы TableOrder можно найти связанные с ней записи из таблицы TableOrderItem о позициях этого заказа. Можно видеть, что связь между таблицами двунаправленная. Каждой записи в таблице TableOrderItem соответствует одна запись из таблицы TableArticleOfFurniture. Соответствие между объектами других классов-сущностей и записями других таблиц определите самостоятельно.

Рис. 5.3.1. Диаграмма классов Database Schema

Рис. 5.3.1. Диаграмма классов Database Schema

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

Предупреждение


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

  

© Кафедра системного программирования ВМК МГУ.

Обновлено: 5.XI.2020