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

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

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

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

      Topcased (topcased.org) -- среда объектно-ориентированного проектирования с открытым кодом. Среда создана на основе Eclipse. Для установки следует загрузить jar-архив версии 5.2.0 со страницы загрузки и запустить его. Поскольку практикум в компьютерных классах проходит под операционной системой Windows, описывается работа в ней. При установке укажите путь, например, C:\Program Files. Для запуска среды вызывается исполняемый файл eclipse.exe из директории C:\Program Files\Topcased-5.2.0. Для его работы необходимо установить Java SE Runtime Environment 6 с сайта www.java.com. Следует убедиться, что в переменной среды Path прописан путь к файлу java.exe из JRE (что-то вроде C:\Program Files\Java\jre6\bin). Запуск может быть неудачен при сравнительно небольшой памяти. В этом случае следует открыть файл eclipse.ini и исправить ключ -Xmx1024m на -Xmx512m.

      Запустив среду Topcased, указываем путь к рабочей области (workspace), в которой будут находиться файлы нашего проекта. Открываем так называемый, ракурс (Perspective) UML/SysML -- выберите в меню Window -> Open Perspective -> Other... . В появившемся списке выберите ракурс UML/SysML. В главном меню выбираем File -> New -> Other... . В открывшемся окне выбираем Topcased -> Topcased Project. Даем имя проекту (например, MyProject). Вызываем контекстное меню папки Models, появившейся в навигаторе, выбираем New -> Papyrus Model. Даем имя модели (например, MyModel.di). Выбираем язык моделирования: UML. Также указываем шаблон для создаваемой модели Model with UML Basic Types. В этом шаблоне есть стандартные типы UML, и нам не придётся их добавлять. После создания модели окно примет вид, показанный на рисунке 1.1.

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

      В левой верхней части находится навигатор, показывающий файловую структуру проекта и модели. Данные модели хранятся в трёх файлах (MyModel.di, MyModel.uml, MyModel.notation). На вкладке Model Explorer, которая находится под навигатором, представлена структура модели. Туда мы будем добавлять диаграммы, пакеты, и другие составляющие модели. Контекстное меню вкладки Model Explorer позволяет добавлять пакеты и диаграммы в модель. При работе следует использовать эту вкладку, а не навигатор. Правая часть окна состоит из редактора (вверху) и находящегося внизу окна с закладками Свойства (Properties), Документация (Documentation), Задачи (Problems).

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

      Добавим архитектурные представления в модель. На вкладке Model Explorer вызовем контекстное меню элемента Model, выберем New Child -> Create a new Package. Назовём новый пакет UseCase View. Аналогично создадим пакеты Logical View, Component View, Deployment View. После создания пакетов окно примет вид, показанный на рисунке 1.2.

      Рис. 1.2. Окно Topcased после создания архитектурных представлений.

      Перед тем как приступить к моделированию, добавим в нашу модель стереотипы. Модель, содержащая профиль с необходимыми стереотипами, можно скачать отсюда. Скачав архив, следует добавить файлы в проект. Для этого в навигаторе выберите проект и вызовите контекстное меню. Import -> General -> Archive File. Укажите полное имя архива (C:\Temp\stereotypes.zip), и выделите все файлы, содержащиеся в нём. В качестве целевого каталога укажите MyProject/Models. По окончании импорта в проект добавятся файлы модели 4prak.profile.di, 4prak.profile.uml, 4prak.profile.notation описывающие UML-профиль со стереотипами. Далее в Model Explorer кликом выделите корневой элемент Model. В разделе Properties выберите закладку Profile. Добавьте профиль 4prak в список Profile Application. После добавления профиля окно должно иметь вид, показанный на рисунке 1.3.

      Рис. 1.3. Окно Topcased после добавления профиля.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Глоссарий:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      1. На вкладке Model Explorer находим пакет UseCase View. Правым щелчком вызываем контекстное меню. New Child -> Create a new Model. Вложенной модели дадим имя UseCase Model (модель вариантов использования). Выделим UseCase Model и вызовем контекстное меню New Diagram -> Create a new UseCase Diagram. В Properties на закладке UML дадим имя Main диаграмме. Диаграмма открылась в окне редактора и появилась палитра с элементами диаграмм. Вид окна представлен на рисунке 3.1.1.

      Рис. 3.1.1. Окно Topcased после создания диаграммы вариантов использования.

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

      3. С помощью элемента Subject обозначим границы проектируемой системы. Дадим ему имя «Система учёта заказов». Получившаяся диаграмма примет вид, показанный на рисунке 3.1.2.

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

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

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

      Рис. 3.2.1. Диаграмма вариантов использования для системы обработки заказов.

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

      2. В палитре редактора выберем связь Association и свяжем действующее лицо Продавец с вариантом использования CRUD данных о заказах. В свойствах (закладка UML, правое поле Member End, кнопка выбора Navigable) укажем направление, пометив значение true.

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

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

      5. Созданная диаграмма имеет недостаток в том, что у варианта использования «Войти в систему» несколько основных действующих лиц. Полагая поведение системы одинаковым при входе любого пользователя, введем абстрактное действующее лицо Пользователь, подвидами которого будут лица Продавец, Заведующий складом, Кладовщик. Диаграмма примет вид, изображенный на рисунке 3.2.2. Для добавления связей обобщения используйте связь Generalization. Лишние ассоциации удалите из модели Сtrl+Del. Обратите внимание, что нажатие на Del лишь скроет связи с диаграммы, в модели они останутся, что может привести к ошибкам. Поэтому в окне редактора диаграммы удаление следует осуществлять с помощью Ctrl+Del. Однако, если Вы работаете с элементами в Model Explorer, то в нём удаление элементов осуществляется с помощью Del. У действующего лица Пользователь на в окне свойств на закладке UML пометьте флаг Is abstract. Выделите действующее лицо Пользователь на диаграмме и вызовите его контекстное меню. Format -> Font. Установите курсивное начертание.

      Рис. 3.2.2. Модифицированная диаграмма вариантов использования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      При желании можно настроить редактор. Для этого в главном меню выберите Window -> Preferences -> Papyrus -> Diagrams -> PapyrusActivityDiagram -> ControlFlow Link. Установите Routing Styles значение Rectilinear, чтобы ребра потоко управления отображались прямоугольными ломаными.

      1. На вкладке Model Explorer вызываем контекстное меню варианта использования Войти в систему и выбираем New diagram -> Create a new Activity diagram.

      2. На появившейся в редакторе диаграмме переименовываем деятельность в «Войти в систему». Cоздаем два раздела (Activity Partition) -- Пользователь и Система -- каждый из которых обозначает область ответственности. Деятельности, соответствующие узлам, которые будут расположены в области ответственности пользователя, будут выполняться пользователем, остальные -- системой. Входной узел (Initial Node) помещаем в раздел Система.

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

      4. Добавляем узлы разветвления (Decision Node). Соединяем узлы ребрами потоков управления (Control Flow). Задать нетривиальные сторожевые условия можно в Proterties на закладке UML в поле Guard. Следует удалить тривиальное сторожевое условие true. Затем добавляется условие типа <LiteralString>, текст условия задается в поле Value. Скрыть тривиальные сторожевые условия можно, выделив их на диаграмме и нажав на Del. Если по ошибке скрыто нетривиальное условие, следует скрыть ребро с диаграммы, а затем отобразить его обратно, перетащив с Model Explorer в окно редактора.

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

      Рис. 3.4.2. Диаграмма деятельности с ошибкой

      Диаграмма деятельности задает потоки управления между узлами. Изначально курсор управления порождается во входном узле. Оттуда он передается по ребру на вход узла действия (Запрос имени и пароля). Узел действия ждет, когда курсоры управления придут на все входящие ребра, после чего запускается действие, а по окончании действия курсоры управления подаются на все исходящие ребра. Очевидно, наша диаграмма содержит ошибку. По второму ребру курсор управления придет не раньше, чем узел действия выдаст его на выход. Тупик. Чтобы исправить ошибку, добавим узел объединения (Merge Node), чтобы в узел действия входило одно ребро (и чтобы для выполнения действия требовался один входящий курсор). Узел объединения принимает курсор с любого входящего ребра и сразу передает его на исходящее ребро, которое у него одно. Исправленная диаграмма показана на рисунке 3.4.2.

      Рис. 3.4.2. Исправленная диаграмма

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

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

      Самостоятельно постройте диаграмму для варианта использования «CRUD данных о заказах». Обратите внимание, что подчиненный поток может быть представлен на диаграмме в виде одного узла (см. узлы «Ввести заказ», «Изменить заказ», «Удалить заказ»). Тип этих узлов -- Call Behavior Action (узел вызова действия). С каждым из них связана деятельность, которая может быть промоделирована отдельной диаграммой деятельности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Модель анализа (Analysis Model) представляет собой пакет внутри логического архитектурного представления (Logical View). Внутри модели анализа помещается пакет UseCase Realizations, содержащий в себе все реализации вариантов использования. Также внутри модели создается диаграмма классов -- ключевых абстракций -- Key Abstractions.

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

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

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

      1. Создадим модель Analysis Model (модель анализа). Вкладка Model Explorer, контекстное меню пакета Logical View, New child -> Create a new Model. Аналогично создадим проектную модель (Design Model).

      2. Создадим пакет UseCase Realizations. Вкладка Model Explorer, контекстное меню пакета Analysis Model, New child -> Create a new Package.

      3. Создадим реализацию варианта использования ход в систему (Login). Вкладка Model Explorer, контекстное меню пакета UseCase Realizations, New child -> Create a new Collaboration. В свойствах кооперации на вкладке Profile укажем стереотип <<use case realization>>. Кооперации дадим имя Login в соответствии с соглашениями моделирования. Аналогичным образом создадим реализацию варианта использования CRUD данных о заказах (CRUDorders).

      4. Создадим диаграммы классов VOPC. Вкладка Model Explorer, контекстное меню пакета UseCase Realizations, New diagram -> Create a new Class Diagram.

      5. Создадим диаграмму классов Key Abstractions диаграмму классов Realizations. Вкладка Model Explorer, контекстное меню пакета Analysis Model, New diagram -> Create a new Class Diagram.

      Структура модели в папке Model Explorer должна соответствовать рис. 4.1.1.

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

      Рис. 4.1.2. Диаграмма ключевых абстракций

      Предварительно настроим редактор для более удобной работы. Меню Window -> Preferences. В открывшемся окне в дереве настроек найдем диаграмму классов: Papyrus -> Diagrams -> PapyrusUMLClassDiagram Diagrem. Отменим отображение дополнительной области у классов (Class Node -> NestedClassifierCompartment). У ассоциации (AssociationLink Link) начертание линии (Routing) заменим на прямоугольное (Rectilinear), а среди меток оставим видимыми лишь SourceMultiplicity и TargetMultiplicity.

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

      2. Добавим перечислимый тип (Enumeration) TypeOfUser (Тип пользователя). Внутри него расположим три значения перечислимого типа (enumeration literal): salesman, warehouseman, stockman.

      2. Выберем в палитре инструмент Association. Проведем связи между классами. Уберём направления связей по умолчанию (поля Navigable в закладке UML в областях Member End). Укажем мощности у полюсов -- концов ассоциаций (поля Multiplicity в закладке UML в областях Member End). Если мощность не указана, она равна 1. Укажем имя полюса type (поле Name в Member End) ассоциации между классом User и типом TypeOfUser. Отобразим имя полюса на диаграмме (выделить ассоциацию, вызвать контекстное меню, Filters -> Manage Connector Labels, пометить SorceRole или TargetRole). Связь между классом User и TypeOfUser указывает, кто из пользователей к какому типу (продавец, заведующий, кладовщик) относится.

      4. Добавим атрибуты (Property) классов. Укажем, что все атрибуты закрытые (выделите с нажатым Ctrl все атрибуты, закладке свойств UML найдите поле Visibility, занесите в него private). Установим мощность у атрибута phones класса Customer. В итоге диаграмма должна соответствовать рисунку 4.1.2.

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

      В пакете UseCase Realizations мы создали диаграмму классов Realizations, на которой сейчас укажем связи между вариантами использования и их реализациями. Перетащите из Model Explorer варианты использования Войти в систему, CRUD данных о заказах. На диаграмме классов они отображаются как классификаторы (в виде прямоугольников). Чтобы явно указать, что они являются вариантами использования включите отображение пиктограмм (окно свойств, закладка Appearance, флажок Element Icons). Совершите те же действия с кооперациями Login, CRUDorders. Выберите на палитре связь Realization и проведите её от кооперации Login к варианту использования Войти в систему. Добавьте вторую реализацию между CRUDOrders и CRUD данных о заказе. Подписи к связям скройте на диаграмме с помощью Del. Вид готовой диаграммы приведён на рис. 4.1.3.

      Рис. 4.1.3 Диаграмма классов Realizations

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

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

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

3. Унификацию классов анализа.

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

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

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

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

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

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

      Идентифицируем классы анализа. Согласно диаграмме вариантов использования имеются два действующих лица (Продавец и Бухгалтерская система), связанных с нашим вариантом использования. Создадим в пакете Analysis Model граничные классы: MainMenuForm -- форму главного меню, OrderForm -- форму заказа, AccountingSystem -- класс-посредник, реализующий протокол взаимодействия с Бухгалтерской системой. Вкладка Outline, контекстное меню пакета Analysis Model, New child -> Create a new Class. Не забудьте указать стереотип <<boundary>> этим классам. Создадим управляющий класс OrderController, отвечающий за реализацию бизнес-логики (действия аналогичны, стереотип <<control>>). Классам -- ключевым абстракциям -- назначим стереотип <<entity>>. Из описания варианта использования следует, что в потоках событий будут задействованы экземпляры классов Order, OrderItem, ArticleOfFurniture, Customer. Открываем в редакторе диаграмму классов VOPC CRUDorders. Перетаскиваем на нее вышеупомянутые классы (граничные, управляющие и сущности) и связи между ними. Чтобы вместе с классами перетаскивались атрибуты, следует пенеосить их с нажатым Ctrl. Вид диаграммы изображен на рис. 4.2.1.

      Рис. 4.2.1. Диаграмма VOPC CRUDorders

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

      Создадим внутри кооперации CRUDorders элемент внутреннего поведения BasicFlow (основной поток). Create child -> Create a new Interaction. Внутри созданного взаимодействия создадим одноименную диаграмму последовательности (контекстное меню New Diagram -> Create a new Sequence Diagram).

       Прежде чем рисовать диаграмму последовательности, добавим кооперации атрибуты. Ими будут являться взаимодействующие объекты: s -- экземпляр действующего лица Продавец; m -- экземпляр формы MainMenuForm; f -- экземпляр формы OrderForm; c: экземпляр класса OrderController; asys -- экземпляр граничного класса AccountingSystem и a -- экземпляр действующего лица Бухгалтерская система. В Model Explorer выделите кооперацию CRUDorders, вызовите его контекстное меню, New child -> Create a new Property. В окне свойств на закладке UML заполните поля Name и Type.

      Добавим объекты с линиями жизни (Lifeline). Левый представляет собой экземпляр действующего лица Продавец (свойства, вкладка UML, поле Represents). Чтобы внести нужное значение, нажмите кнопку ..., в открывшемся окне выбелите Model -> Logical View -> Analysis Model -> UseCase Realizations -> CRUDorders -> ownedAttribute -> s.Правая линия жизни -- экземпляр действующего лица Бухгалтерская система (Model -> Logical View -> Analysis Model -> UseCase Realizations -> CRUDorders -> ownedAttribute -> a). В середине экземпляр класса MainMenuForm (Model -> Logical View -> Analysis Model -> UseCase Realizations -> CRUDorders -> ownedAttribute -> m), экземпляр класса OrderForm (Model -> Logical View -> Analysis Model -> UseCase Realizations -> CRUDorders -> ownedAttribute -> f), объект класса OrderController (Model -> Logical View -> Analysis Model -> UseCase Realizations -> CRUDorders -> ownedAttribute -> c) и экземпляр AccountingSystem (Model -> Logical View -> Analysis Model -> UseCase Realizations -> CRUDorders -> ownedAttribute -> asys). Заметьте, что экземпляры граничных классов находятся рядом с экземплярами тех действующих лиц, за общение с которыми они отвечают, а экземпляр контроллера расположен в середине диаграммы.

      Добавим активацию (Execution) а линию жизни Продавца. Затем выберем на палитре синхронное сообщение (Message Synch) и проведем его от первой линии жизни ко второй. При создании сообщения свяжем его с новой операцией (во всплывающем окне выберите Create a new element). Дадим имя операции //crudOrders. Два слэша указывают, что это предварительное имя сообщения, которое в дальнейшем будет уточнено. Аналогично добавим второе сообщение //crudOrders, и другие. Обратите внимание, что на диаграмме есть рефлексивное сообщение, которое объект посылает сам себе. также присутствует сообщение open, имеющее тип Create Message, обозначенное пунктирной стрелкой.

      Рис. 4.2.2. Диаграмма BasicFlow

      Рассмотрим дальнейшее взаимодействие объектов на диаграмме. В форму MainMenu Продавец сообщает о желании работать с заказами (например, нажимая на кнопку). Форма информирует об этом контроллер. Контроллер при посредничестве граничного объекта устанавливает связь с бухгалтерской системой. Если связи нет, выдаётся сообщение об ошибке. Иначе есть три альтернативных варианта продолжения, каждый из которых моделируется на отдельной диаграмме. На вспомогательные диаграммы поставлены ссылки с помощью блоков InteractionUse. На диаграмму добавлены комбинированные фрагменты взаимодействия (Combined Fragment). Их тип -- Alternative (свойства, закладка UML, в поле Interaction Operator внесите alt). В объемлющем фрагменте два операнда взаимодействия (выделите на палитре Interaction Operand и добавьте внутрь фрагмента). Во вложенном -- три. По умолчанию операнды получают сторожевые условия, не совпадающие с нужными нам. На Model Explorer найдём первый операнд взаимодействия (Interaction Operand), вложенный в комбинированный фрагмент. Раскроем его и выделим значение сторожевого условия (Analysis Model -> UseCase Realizations -> usecase realization RegisterForCourses -> ownedBehavior (1) -> BasicFlow -> fragment -> CombinedFragment -> operand (2) -> InteractionOperand -> guard (1)). В окне свойств на вкладке UML есть поле Specification, в которое следует ввести новое значение типа LiteralString, величиной которого является строка "есть связь". Аналогичным образом указывается сторожевое условие второго операнда взаимодействия. Достаточно удалить его значение по умолчанию, редактор сам высветит сторожевое условие [else]. Перед использованием блоков Interaction Use следует создать внутри кооперации взаимодействия CreateOrder, UpdateOrder, DeleteOrder.

      Создание заказа моделируется на диаграмме последовательности созданной внутри взаимодействия CreateOrder. Продавец посылает дату поставки и сведения о заказчике в форму. Форма, получив эти данные, передает запрос о создании заказа OrderController'у. Он создает экземпляр класса Order и проверяет, есть ли в системе данные о заказчике. Если их нет, выполняется взаимодействие описанное комбинированным фрагментом взаимодействия (Combined Fragment), являющимся Optional блоком. Ниже блока находится сообщение от OrderController, записывающее в заказ дату его поставки и ссылку на его заказчика. Ниже расположен блок loop. Создание его аналогично. Сначала создается блок и указывается его тип -- Loop. Во вложенном в блок операнде взаимодействия создается сторожевое условие, удаляются значения по умолчанию из границ диапазона числа итераций. Блок описывает, что для каждой позиции заказа Продавец вводит данные. Данные из формы попадают к контроллеру. Он проверяет, что введённая позиция есть в перечне предметов мебели. По результатам проверки есть два варианта действий. Если проверка успешна, контроллер запрашивает у Order добавление новой позиции. Логично возложить эту обязанность на сам заказ, чтобы оградить контроллер от лишних знаний о внутреннем устройстве заказа. Как заказ работает с собственными позициями -- это его личное дело. Если данные от Продавца ошибочны, данные в системе не сохраняются.

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

      Рис. 4.2.3. Диаграмма Rest of BasicFlow

      Каждое сообщение на диаграмме последовательности дает экземплярам классов обязанности по отправке и приему сообщения. Эти операции созданы нами при создании сообщений. Следует перенести их из Model Explorer на диаграмму VOPC CRUDorders. Если экземпляры классов обмениваются сообщениями, то на диаграмме VOPC следует провести ассоциации между классами анализа. Диаграмма VOPC RegisterForCourses примет вид, показанный на рисунке 4.2.4.

      Рис. 4.2.4. Диаграмма VOPC CRUDorders с заготовками операций и ассоциациями, добавленными по диаграммам последовательности

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

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

      Система регистрации работает с реляционной базой -- каталогом курсов, следовательно при проектировании мы будем использовать механизм обеспечения устойчивости RDBMS (relational database management system). Существуют готовые каркасы, обеспечивающие доступ к реляционным БД. К таким относится JDBC (Java Database Connectivity). Добавим в нашу модель проектный механизм. Для этого следует скачать архив с моделью. Вызовите контекстное меню в Project Explorer Import -> General -> Archive File. Укажите jdbc.zip. Поместите файлы из архива в папку Models. Далее в Model Explorer Вашей модели выберите пакет Logical View, вызовите его контекстное меню. Import -> Import Package from Workspace. Выберите файл jdbc.uml. Пометьте галкой пакет Design Model. В Logical View появится Package Import. Раскройте его, найдите Design Model внутри Package Import. Скопируйте пакеты Architectural Mechanisms и Middleware в Logical View внутри Design Model. Для этого выберите пакет Logical View::<PackageImport>Design Model::ImportedPackage::Design Model::Middleware, нажмите Ctrl+C (или контекстное меню Copy). Выберите пакет Logical View, нажмите Ctrl+V (Paste). Повторите копирование для пакета Architectural Mechanisms. Переименуйте копии пакетов, уберите префиксы CopyOf_. Добавление проектного механизма закончено.

      В Design Model создадим еще два пакета: Application и BusinessServices. На уровень приложения мы будем размещать элементы пользовательского интерфейса. На уровень бизнес-служб -- элементы, относящиеся к предметной области. Уровень промежуточного ПО содержит элементы, обеспечивающие сервисы, независимые от платформы. В Design Model создадим диаграмму пакетов Main. Вытащим на нее все три архитектурных уровня и соединим их зависимостями, как указано на рис. 5.1.1. Подписи внутри пакетов на диаграмме можно убрать, выделив пакеты и нажав Ctrl+F5. Назначим пакетам стереотип <<layer>> -- архитектурный уровень. Мы создали иерархию уровней системы, т. е. её устройство с точки зрения самых крупных блоков.

      Рис. 5.1.1. Диаграмма Main

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

      При анализе мы не учли вопросы, связанные с обеспечением устойчивости данных. В потоке событий система не предпринимала никаких действий, чтобы введённые данные были доступны не только в текущем сеансе работы, но и в последующих. В этом нет ошибки, во время анализа эти вопросы рассматривать рано, надо сосредоточиться на основных функциях системы. Начиная проектирование мы обращаемся к этим вопросам и должны предложить класс, ответственный за общение с базой данных системы. Таким классом может быть OrderController, так как он связан со всеми классами, данные об экземплярах которых надо будет сохранять, и манипулирует этими экземплярами -- создает заказы, удаляет и т. п. Добавление обязанностей классу OrderController делает его сложным. Поэтому при отображении в проектные классы мы переводим его в два проектных элемента -- одноимённый проектный класс OrderController и подсистему обеспечения устойчивости DBAccess. Остальные классы анализа переведем в проектные один в один. Заметим, что можно было бы отобразить класс AccountingSystem в подсистему для того, чтобы возможные изменения во взаимодействии с бухгалтерской системой мало затрагивали остальные части системы и были локализованы в подсистеме. Так как цель наших упражнений -- знакомство со средой Topcased/Papyrus и процессом разработки, мы этого делать не будем.

      Чтобы не испортить модель анализа, скопируем ее, чтобы из копии перенести классы в проектную модель. Model Explorer, контекстное меню Analysis Model -> Copy, контекстное меню Logical View -> Paste. Появился пакет CopyOf_Analysis Model_1. Создадим в пакете Application пакет CRUDofOrders (классы не могут быть вложены непосредственно в слой, дочерними элементами слоя являются только пакеты). В созданный пакет перетащим из копии модели анализа классы MainMenuForm, CreateOrderForm, OrderController, AccountingSystem и их связи. Ассоциации, соединяющее эти классы с другими можете найти в пакете UseCase Realizations, если их нет в корне CopyOf_Analysis Model_1. Заметим, что стереотипы анализа в проектной модели смысла не имеют, их нужно убрать. В пакете BusinessServices создадим пакеты WarehouseArtefacts (т. е. артефакты склада, в нем разместим классы-сущности предметной области и их связи), пакет Interfaces (где будут находиться все интерфейсы), пакет DBAccess со стереотипом <<subsystem>> (в нем создадим одноименный класс). Классу DBAccess назначим стереотип <<subsystem proxy>> -- это означает, что он принимает все сообщения, идущие внутрь подсистемы. Перенесем пакет UseCase Realizations из Copy Of Analysis Model в Design Model. Диаграмму классов Key Abstractions перенесем в пакет WarehouseArtefacts. Удалим опустевший CopyOf_Analysis Model_1. В пакете Interfaces создадим интерфейс IDBAccess. Структура проектной модели в Model Explorer примет вид похожий на рис. 5.1.2.

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

      Создадим диаграмму пакетов Main в пакете BusinessServices. Разместим на ней пакеты этого архитектурного уровня, укажем их зависимости (PackageImport). Чтобы убрать надпись внутри пакетов, используйте Ctrl+F5. Подсистема реализует интерфейс, отсюда верхняя зависимость. Для описаний в верхних пакетах понадобятся классы-артефакты, отсюда две другие зависимости. Диаграмма примет вид, представленный на рис. 5.1.3.

      Рис. 5.1.3. Структура уровня BusinessServices

      Моделировать структуру потоков управления системы не будем. Этот вопрос будет рассматриваться на лекции. Перечислим лишь виды процессов в нашей системе: WarehousemanApplication -- пользовательский процесс рабочего места заведующего складом; SalespersonApplication -- пользовательский процесс рабочего места продавца; StockmanApplication -- пользовательский процесс рабочего места кладовщика; OrderProcess -- общий процесс, управляющий обработкой заказов; AccountingSystemAccess -- процесс обеспечивающий связь с бухгалтерской системой; DBAccessProcess -- процесс, обеспечивающий связь с реляционной СУБД. Последние два нужны для обеспечения эффективности, т. е. поддержки кэшей данных. Перейдем к моделированию конфигурации вычислительной среды. Вычислительная среда состоит из двух типов узлов -- процессоров (ExecutionEnvironment) и устройств (Device). На процессорах можно разместить части системы -- артефакты, соответствующие рассмотренным нами процессам. Связи между узлами описывают пути коммуникации (CommunicationPath). Создадим диаграмму размещения DeploymentView внутри одноименной модели. Артефакты следует создавать, размещая их внутри узла. Окончательный вид диаграммы приведен на рис. 5.1.4. На ней показано, что в среде есть сервер обработки заказов, к которому подключен принтер и три типа рабочих станций. Для соединения рабочих станций с сервером используется локальная сеть склада. Также на диаграмме указан узел, относящийся к окружению системы -- узел бухгалтерской системы, подключенный к серверу обработки заказов. СУБД развёрнута на сервере обработки заказов.

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

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

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

      Проектные реализации вариантов использования являются более полными, чем реализации, созданные в ходе анализа. В них вместо экземпляров классов анализа должны присутствовать экземпляры проектных классов и интерфейсов, т. е. должны быть учтены трансформации классов анализа в проектные элементы. Проведем уточнение реализаций вариантов использования. Откроем диаграмму последовательности CreateOrder из кооперации CRUDorders в пакете LogicalView::Design Model::UseCase Realizations. Классы у объектов должны быть проектными. Убедитесь в этом (см. поле Represents в окне Properties, закладка Model). Убедитесь, что все сообщения, получаемые этими объектами, связаны с операциями проектных классов. При необходимости исправьте выявленные несоответствия.

      На диаграмме CreateOrder следует учесть, что экземпляры классов Customer, ArticleOfFurniture являются устойчивыми, следовательно их надо запрашивать из базы данных. На диаграмму BasicFlow следует добавить линию жизни экземпляра интерфейса IDBAccess и направить к нему сообщения для поиска заказчика (findCustomer(cName:String):Customer вместо сообщения find к объекту Customer), создания записи о новом заказчике (createCustomer(addr:String, name:String, phones:String):Customer вместо new к Customer) и проверки предмета мебели, введённого в позиции заказа (checkArticle(description:String, qty:Int):Boolean вместо find к ArticleOfFurniture). Тем самым мы показываем, что происходит обращение к экземпляру класса, реализующему интерфейс подсистемы, отвечающей за доступ к базе данных. Какой именно это будет класс -- это для реализации варианта использования неважно. Реализация варианта использования не определяет, как подсистема DBAccess должна обрабатывать такие вызовы. Эта часть относится к проектированию подсистемы и может варьироваться в зависимости от реализации подсистемы. Внутреннее поведение подсистемы скрыто, чтобы обеспечить возможность легкой модификации ее реализации. Следует также сообщение от экземпляра класса OrderController createOrder(o:Order) к экземпляру интерфейса после сообщения saveOrder, полученного объектом-контроллером. Диаграмма CreateOrder примет вид, представленный на рисунке 5.2.1. Не забудьте создать операции в интерфейсе и связать с ними сообщения на диаграмме. Дополнительно создайте в интерфейсе операции init() и close(), управляющие соединением системы с СУБД.

      Рис. 5.2.1. Уточненная диаграмма CreateOrder

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

      Подсистема DBAccess пока содержит один класс со стереотипом <<subsystem proxy>>. Класс отвечает за реализацию интерфейса подсистемы. Объекты этого класса будут принимать и обрабатывать все входящие сообщения. Класс создается для удобства тестирования сопряжений при сборке системы. При реализации подсистемы мы воспользуемся механизмом RDBMS-JDBC. При использовании механизма следует создать элемент модели CollaborationUse (использование кооперации), и для каждой роли в составе механизма Persistency JDBC указать проектный класс, выполняющий эту роль. Мы собираемся подставить экземпляр класса DBAccess вместо роли dbObject, экземпляр Order -- вместо persistentObject, экземпляр Customer -- также вместо persistentObject.

      Создадим в подсистеме DBAccess кооперацию IDBAccess со стереотипом «interface realization». Создадим внутри подсистемы диаграмму составной структуры (Composite Structure Diagram) с названим Interface Realization. Поместим кооперацию на диаграмму составной структуры. Добавим на диаграмме три атрибута (Property) в кооперацию: db:DBAccess, o:Order, c:Customer. Добавим на диаграмме в кооперацию элемент CollaborationUse. Укажем тип используемой кооперации: механизм Persistency JDBC. Соединим CollaborationUse с атрибутами db, o, c связями RoleBinding. Укажем выполяемые роли, как изображено на диаграмме 5.2.2.

      Рис. 5.2.2. Диаграмма составной структуры Interface Realization

      Откройте диаграмму пакетов в пакете RDBMS-JDBC. На ней указано, что для механизма нужны пакеты java.lang и java.sql. Поэтому откройте диаграмму пакетов из пакета Business Services, перенесите на неё пакеты java.lang и java.sql с уровня Middleware, добавьте связи импорта (PackageImport) от подсистемы DBAccess к пакетам java.lang и java.sql. Теперь создайте внутри подсистемы DBAccess диаграмму классов DBAccess. Поместите на неё интерфейс IDBAccess из пакета Interfaces. Поместите прокси-класс DBAccess. Проведите связь реализации (InterfaceRealization) от прокси-класса к интерфейсу. Остальные связи прокси-класса следует восстановить по диаграмме составной структуры Main из пакета RDBMS-JDBC и диаграммам последовательности кооперации-механизма Persistency JDBC. Прокси-класс DBAccess играет роль dbObject, следовательно, этому классу надо добавить все зависимости этой роли. Перенесите на диаграмму классов DBAccess классы Order и Customert, играющие роли persistentObject. Проведите зависимости от прокси-класса к этим двум классам. Также поступите с классом DriverManager, интерфейсами Connection, Statement, ResultSet из пакета java.sql. Скопируйте в прокси-класс операции из интерфейса. Перенесите их на диаграмму. В результате, диаграмма классов и структура подсистемы должны быть похожи на изображенные на рисунках.

      Рис. 5.2.3. Диаграмма классов подсистемы DBAccess

      Рис. 5.2.4. Структура подсистемы DBAccess в Model Explorer

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

      Внутрь кооперации IDBAccess скопируйте четыре взаимодействия из механизма: Initialize (переименуйте в Init), Add (переименуйте в CreateCustomer), Disconnect (переименуйте в Close) и Read (переименуйте в FindCustomer). Каждое взаимодействие будет описывать, что делают объекты подсистемы при вызове соответствующей операции. Реализацию оставшихся операций createOrder и checkArticle мы моделировать не будем. На диаграмме последовательности внутри взаимодействия Init замените тип у экземпляра dbObject на db:DBAccess. Входящее сообщение, принимаемое им, свяжите с операцией init. Диаграмма примет вид, изображенный на рисунке 5.2.5.

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

      Схожим образом приведите диаграмму Close в вид, изображенный на рисунке 5.2.6.

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

      На диаграмме последовательности CreateCustomer (бывшей Create) замените типы объектов: у экземпляра dbObject -- на DBAccess, у экземпляра persistentObject -- на Customer. Входящее сообщение, принимаемое последним, свяжите с операцией createCustomer. Добавьте классу Customer новую операцию:setData(addr:String, name:String, phone:String). Свяжите с ней сообщение на диаграмме последовательности. Диаграмма примет вид, изображенный на рисунке 5.2.7.

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

      Реализация операции createOrder будет отличаться от createCustomer тем, что не надо будет создавать экземпляры классов Order и OrderItem, так как они созданы в ходе потока CreateOrder варианта использования CRUD данных о заказах, но для составления запроса или группы запросов к БД надо будет запросить сведения и у объекта Order и у его составных частей -- экземпляров OrderItem.

      На диаграмме последовательности FindCustomer (бывшей Read) замените типы объектов: у экземпляра dbObject -- на DBAccess, у экземпляра persistentObject -- на c:Customer. Свяжите найденное сообщение с операцией findCustomer. Удалите линию жизни persistentObjectList. Исправьте тип внешнего блока на opt. Диаграмма примет вид, изображенный на рисунке 5.2.8.

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

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

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

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

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

      Рассмотрим проектирование классов на примере системы обработки заказов. Создайте в пакете WarehouseArtefacts диаграмму классов Order. Поместите классы Order, OrderItem и ассоциацию между ними на диаграмму. Чтобы содержимое классов отобразилось на диаграмме, перетаскивайте их из Model Explorer с нажатым Ctrl. Добавьте и уточните его атрибуты и операции, чтобы придать ему вид, схожий с рисунком 5.2.9. Статические (подчеркнутые) и выводимые (начинающиеся со слэша) атрибуты и операции пометьте специальным флажком. Типы int, boolean и String используйте из пакета java.lang, Date -- из java.util.

      Рис. 5.2.9. Диаграмма классов Order

      Экземпляры класса Order должны по-разному обрабатывать вызовы их операции в зависимости от состояния заказа. Например. если сборка заказа закончена, то в него нельзя добавлять новые позиции. Это признак сложного поведения и причина для создания диаграммы состояний.Добавьте классу диаграмму состояний LifeCycle (контекстное меню, New diagram -> Create a new StateMachine Diagram). Создайте начальное состояние (Initial), финальное состояние (FinalState) и суперсостояние Active (Composite State). Внутри состояния Active разместите подсостояния InProcess, Canceled, Filled, Delivered и псевдосостояние выбора (Choice). Соедините состояния переходами, как указано на рисунке 5.2.10. Для добавления переходу события-триггера в окне Properties на вкладке UML в поле Trigger создайте триггер. Введите имя создаваемого триггера и создайте событие. При создании события выберите его тип (CallEvent) и пакет, в котором оно будет размещаться (контейнером всех событий должен быть пакет WarehouseArtifacts. Обратите внимание, что событие when(numOfItems==numOfFilledItems) является событием изменения (ChangeEvent). Действия на переходах создаются в поле Effect. Тип действий Opaque Behavior. При создании действия следует задать его язык (Natural Language) и его тело. Сторожевые условия создаются в поле Guard. Тип всех условий Constraint. Содержимое условия следует задавать с помощью окна Outline. Раскройте переход, выделите условие. В окне Properties на вкладке Specification создайте Literal String и введите текст условия в поле Value. Обратите внимание, что один переход является внутренним в состоянии InProcess. Его следует добавлять в окне Properties (при выделенном состоянии InProcess в Outline) на закладке Internal Transition. Тригер, сторожевое условие добавляются к внутреннему переходу также, как к обычному. Работа с действием имеет отличия. Действие на внутреннем переходе создаётся на вкладке Effect. Тип действия Opaque Behavior. Во всплывающем окне задайте спецификацию в поле Specification. Тип значения Literal String. Введите текст условия в поле Value. Обратите внимание, что один переход является внутренним в состоянии InProcess. Его следует добавлять как обычный переход из состояния в само себя, а затем указать тип перехода internal. Тригер, сторожевое условие и эффект добавляются к внутреннему переходу также, как к обычному.

      Постройте модель состояний в соответствии с рисунками 5.2.10, 5.2.11. Учтите что, если одно и то же событие присутствует на разных переходах (removeItem), то создать его надо только в первый раз, а во второй следует лишь связывать событие с триггером. Имена переходов в Вашей модели могут не совпадать с рис. 5.2.11.

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

      Рис. 5.2.11. Структура модели состояний в Model Explorer

      Уточним связи между классами на диаграме VOPC CRUDOrders проектной реализации варианта использования CRUD данных о заказах. Откроем диаграмму (из Design Model). Удалите с диаграммы (но не из модели!) класс ArticleOfFurniture. Перетащите с Ctrl интерфейс IDBAccess и его зависимости. Уточните связи. Зависимость (пунктирная стрелка) указывает на то, что связи между экземплярами временные, а не постоянные как в случае ассоциации. OrderController хранит ссылку на текущий заказ (агрегации -- AssotiationType: shared). Укажите направления ассоциаций (флажок Navigable) и типы.

      Рис. 5.2.12. Уточненная диаграмма классов VOPC CRUDOrders

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

      Осуществим проектирование базы данных. В корне Design Model создайте диаграмму классов DataBase Schema. Создайте 2 класса со стереотипом <<table>>. См. рисунок 5.2.13. Эту схему можно использовать для хранения экземпляров класса Order и их составных частей. Каждая запись о заказе состоит из 6 столбцов, один из которых является первичным ключом (<<PK>>). Столбцы для хранения выводимых атрибутов можно не заводить. Как "операция" таблицы TableOrder моделируется ограничение первичного ключа. Позиции заказа хранятся в отдельной таблице TableOrderItem. В этой таблице 5 столбцов, один из которых является частью первичного ключа (<<PK>>), а другой -- внешним ключом (<<FK>>) и частью первичного ключа. В таблицу добавлены ограничения первичного и внешнего ключа и ограничение индекса. Связь между таблицами идентифицирующая, так как часть первичного ключа входит во внешний ключ.

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

      Рис. 5.2.13. Диаграмма классов DataBase Schema

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

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