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

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

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

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

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

      Запустив среду Topcased, выбираем в левом верхнем углу закладку Topcased Navigator. Если такой закладки нет, значит, не открыт, так называемый, ракурс (Perspective) Topcased Modeling. Чтобы открыть ракурс, выберите в меню Window -> Open Perspective -> Other... . В появившемся списке выберите ракурс Topcased Modeling. Выберите появившуюся в левом верхнем углу закладку Topcased Navigator. Правым щелчком открываем контекстное меню, New -> Project. В открывшемся окне выбираем Topcased Project. Даем имя проекту (например, MyProject). Вызываем контекстное меню папки Models, появившейся в навигаторе, выбираем New -> UML Model with TOPCASED. Даем имя модели (например, MyModel). Также указываем шаблон для создаваемой модели Common approach. В этом шаблоне есть готовая структура модели, нам не придется создавать ее вручную. После создания модели окно примет вид, показанный на рисунке 1.1.

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

      В левой верхней части находится навигатор, показывающий файловую структуру проекта и модели. Данные модели хранятся в файле с расширением uml (MyModel.uml). Модель состоит из 4 пакетов -- 4 архитектурных представлений. Данные диаграмм хранятся в файле с расширением umldi (MyModel.umldi). В модели 4 диаграммы -- по одной для каждого архитектурного представления. Более удобен вид, представленный во вкладке Outline (схеме), которая находится под навигатором. Там показаны и диаграммы, и пакеты, то есть, все составляющие модели. Контекстное меню вкладки Outline позволяет добавлять пакеты и диаграммы в модель. При работе рекомендуется использовать эту вкладку, а не навигатор. Правая часть окна состоит из редактора (вверху) и находящихся внизу окон Свойства (Properties) и Документация (Documentation). В левой части редактора содержится панель инструментов (палитра), на которой представлены элементы и связи, помещаемые на диаграммы. Правую часть окна занимает область редактирования диаграммы.

      Перед тем как приступить к моделированию, добавим в нашу модель стереотипы. Модель, содержащая профиль с необходимыми стереотипами, можно скачать отсюда. Скачав архив, следует добавить файлы в проект. Для этого в навигаторе выберите проект и вызовите контекстное меню. Import -> General -> Archive File. Укажите полное имя архива (C:\Temp\oldstereotypes.zip), и выделите оба файла, содержащихся в нём. В качестве целевого каталога укажите MyProject/Models. По окончании импорта в проект добавятся файлы модели 4prak.uml, 4prak.umldi, описывающий UML-профиль со стереотипами. Для отображения стереотипов в виде пиктограмм следует скачать архив с пиктограммами. Точно также, как описано выше добавьте в каталог Plugin_Resources каталог icons из архива вместе со всем его содержимым. Далее в Outline вызовите контекстное меню модели MyModel. Load Resourse... -> Browse Workspace... Выберите файл модели 4prak.uml. После загрузки ресурсов двойным кликом выделите MyModel в Outline. В разделе Properties выберите закладку Profiles. Добавьте профиль 4prak в список Applied Profiles. Если все проделано успешно, под пакетами в Outline появится ссылка на профиль (<Profile Application>). Для отображения пиктограмм на диаграммах вызовите в меню Window -> Preferences выберите пункт Topcased -> Editors -> UML/SysML -> All Diagram -> Stereotype и установите значение As Icon...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Глоссарий:

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

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

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

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

   • На процесс регистрации отводится две недели.

   • Курс считается отмененным по окончании регистрации, если на него записалось менее 3 студентов. И т. п.

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

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

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

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

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

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

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

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

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

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

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

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

• Студент -- регистрируется на курсы, смотрит свой табель;
  

• Профессор -- выбирает курсы для преподавания, ставит оценки;
  

• Регистратор -- управляет процессом регистрации, ведёт (т. е. вводит, изменяет, удаляет) данные о профессорах и студентах;
  

• Расчетная система -- получает данные, нужные для формирования счетов за обучение;
  

• Каталог курсов -- поставляет данные об университетских курсах.

      1. На вкладке Outline находим пакет UseCaseView. Правым щелчком вызываем контекстное меню. Create child -> Nested Package -> Model. Вложенной модели дадим имя UseCase Model (модель вариантов использования). Перемещаем на вкладке Outline диаграмму UseCaseView внутрь созданной модели. Двойным щелчком открываем диаграмму UseCaseView в редакторе.

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

      3. С помощью инструмента Boundary Box обозначим границы проектируемой системы. Получившаяся диаграмма примет вид, показанный на рисунке 3.1.

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

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

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

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

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

      2. В палитре редактора выберем инструмент Associations и свяжем действующее лицо Студент с вариантом использования Зарегистрироваться на курсы. В свойствах (закладка Second end) укажем направление с помощью флажка isNavigable. В свойствах (закладка Graphics) скрываем имя связи, перемещая элемент NameEdgeObject в список скрытых.

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

      4. Созданная диаграмма имеет недостаток в том, что у варианта использования Войти в систему несколько основных действующих лиц. Полагая поведение системы одинаковым при входе любого пользователя, введем абстрактное действующее лицо Пользователь, подвидами которого будут лица Студент, Профессор, Регистратор. Диаграмма примет вид, изображенный на рисунке 3.2.2. Для добавления связей обобщения используйте инструмент палитры Generalization. Лишние ассоциации удалите из модели Shift+Del. Нажатие на Del удалит связи только с диаграммы, в модели они останутся, что может привести к ошибкам.

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

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

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

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

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

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

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

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

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

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

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

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

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

      Вариант использования «Зарегистрироваться на курсы»:

Краткое описание
Данный вариант использования позволяет студенту зарегистрироваться на конкретные курсы в текущем семестре. Студент может изменить свой выбор (обновить или удалить курсы), если изменение выполняется в установленное время в начале семестра. Система каталога курсов предоставляет список всех конкретных курсов текущего семестра.
Основной поток событий
1. Студент сообщает о желании зарегистрироваться на курсы.
2. Система подтверждает, что регистрация на курсы в текущем семестре открыта.
3. Система запрашивает связь с каталогом курсов.
4. Каталог курсов подтверждает, что связь установлена.
5. Система запрашивает требуемое действие (создать график, обновить график, удалить график, утвердить график).
6. Студент сообщает системе свой выбор.
7. Система подтверждает, что требуемое действие можно выполнить.
8. Согласно выбору студента выполняется один из подчиненных потоков (создать, обновить, удалить или утвердить график).
9. Система заканчивает сеанс связи с каталогом курсов.
10. Каталог курсов подтверждает, что сеанс закончен.
Подчиненные потоки событий:
8А. Создать график
1. Система выполняет поиск в каталоге курсов доступных конкретных курсов и выводит их список.
2. Студент выбирает из списка 4 основных курса и 2 альтернативных курса.
3. Система создает график студента и заносит в него выбранные курсы, помечая их как незафиксированные.
4. Система сообщает, что создание графика завершено.
5. Выполнение переходит на шаг 9 основного потока.
8Б. Обновить график
1. Система выводит текущий график студента.
2. Система выполняет поиск в каталоге курсов доступных конкретных курсов и выводит их список.
3. Студент обновляет свой выбор курсов, удаляя или добавляя конкретные курсы.
4. Система обновляет график в соответствии с пожеланиями студента. Для каждого зафиксированного курса, удаленного из графика, система удаляет студента из списка студентов, записавшихся на курс. Каждый добавленный курс система помечает как незафиксированный.
5. Система сообщает, что обновление графика завершено.
6. Выполнение переходит на шаг 9 основного потока.
8В. Удалить график
1. Система выводит текущий график студента.
2. Система запрашивает у студента подтверждения удаления графика.
3. Студент подтверждает удаление.
4. Система удаляет график. Для каждого зафиксированного курса из удаляемого графика, система удаляет студента из списка студентов, записавшихся на курс.
5. Выполнение переходит на шаг 9 основного потока.
8Г. Утвердить график
1. Для каждого незафиксированного курса в графике выполняется:
1.1. Система подтверждает выполнение студентом предварительных требований (прохождение определенных курсов), и подтверждает, что курс открыт для регистрации, и отсутствуют конфликты (в графике не должно быть зафиксированного курса, читаемого в тот же день и на той же паре, что и проверяемый курс).
1.2. Система добавляет студента в список записавшихся на курс.
1.3. Система помечает курс в графике как зафиксированный.
1.4. Система помечает курс как закрытый, если в списке студентов содержится 10 записей.
2. Система сообщает студенту результаты утверждения графика.
3. Выполнение переходит на шаг 9 основного потока.
Альтернативные потоки
2А. Регистрация на курсы закрыта
1. Система обнаруживает, что регистрация на курсы в текущем семестре закрыта.
2. Система выдает сообщение об ошибке.
3. Вариант использования завершается.
3А. Каталог курсов недоступен
1. Система обнаруживает, что невозможно установить связь с каталогом курсов.
2. Система выдаёт сообщение об ошибке.
3. Вариант использования завершается.
8Г.1.1А. Не выполнены предварительные требования, курс заполнен, или имеют место конфликты графика
1. Система обнаруживает, что студент не выполнил необходимые предварительные требования, или выбранный им конкретный курс заполнен, или имеют место конфликты графика.
2. Система выдаёт сообщение об ошибке.
3. Система переходит к следующему незафиксированному курсу и продолжает выполнение потока «Утвердить график»
7А. График не найден
1. Система обнаруживает, что требуемое действие (обновить, удалить или утвердить график) нельзя выполнить, так как график студента на текущий семестр отсутствует.
2. Система выдает сообщение об ошибке.
3. Выполнение переходит на шаг 5 основного потока.
7Б. График найден
1. Система обнаруживает, что требуемое действие (создать график) нельзя выполнить, так как график студента на текущий семестр создан ранее.
2. Система выдает сообщение об ошибке.
3. Выполнение переходит на шаг 5 основного потока.
8В.3А. Удаление отменено
1. Студент отменяет удаление графика.
2. Выполнение переходит на шаг 5 основного потока.
Предусловия
Перед началом выполнения данного варианта использования студент должен войти в систему.
Постусловия
Если вариант использования завершится успешно, система создаст, обновит, удалит или утвердит график студента в соответствии с выбором пользователя. В противном случае гарантируется что: при закрытой регистрации изменения в графики студентов не производятся; при недоступном каталоге курсов изменения в графики студентов не производятся; при утверждении графика студента игнорируются курсы, для которых не выполнены предварительные требования, или которые закрыты, или которые вызывают конфликты в графике; при отсутствии графика на текущий семестр его обновление, удаление или утверждение не производятся; при наличии графика на текущий семестр добавление еще одного графика не производится.

      Вариант использования «Закрыть регистрацию»:

Краткое описание
Данный вариант использования позволяет регистратору закрывать процесс регистрации. Конкретные курсы, на которые не записалось достаточного количества студентов (менее трех), отменяются. В расчетную систему передается информация о каждом студенте по каждому конкретному курсу, чтобы студенты могли внести оплату за курсы.
Основной поток событий
1. Регистратор запрашивает прекращение регистрации.
2. Система подтверждает возможность закрыть регистрацию и фиксирует, что регистрация закрыта.
3. Для каждого предлагаемого курса, который открыт для регистрации, выполняется:
3.1. Система подтверждает, что курс взялся провести какой-либо профессор, и что на курс записалось не менее трех студентов.
3.2. Для каждого графика студента, в котором курс помечен основным и не зафиксированным, выполняется подчиненный поток «Зафиксировать курс в графике».
4. Для каждого студенческого графика система проверяет наличие в нём 4 зафиксированных курсов; если их недостаточно, система дополняет график альтернативными курсами по схеме, описанной в шаге 3 основного потока.
5. Для каждого открытого предлагаемого курса выполняется:
5.1. Система подтверждает, что в списке неменее трёх студентов.
5.2. Система помечает курс как закрытый.
6. Система запрашивает связь с расчётной системой.
7. Расчётная система подтверждает готовность к приёму данных.
8. Система передает в расчётную систему графики студентов.
9. Расчётная система подтверждает приём графиков студентов.
Подчинённые потоки:
3.2. Зафиксировать курс в графике
1. Система подтверждает, что курс открыт для регистрации.
2. Система добавляет студента в список записавшихся на курс.
3. Система помечает курс в графике как зафиксированный.
4. Система помечает курс как закрытый, если в списке студентов содержится 10 записей.
Альтернативные потоки:
2А. Регистрация не может быть прекращена
1. Система обнаруживает, что процесс регистрации нельзя прекратить немедленно.
2. Система выдает сообщение регистратору и предлагает выбрать повтор или отмену закрытия регистрации.
3. Регистратор сообщает свой выбор.
4. Система в соответствии с выбором либо продолжает выполнение шага 2 основного потока, либо завершает выполнение варианта использования.
3.1А. Курс никто не ведет
1. Система помечает курс как отмененный.
2. Система исключает данный курс из каждого содержащего его графика и удаляет студентов из списка записавшихся на курс.
3. Система выбирает следующий курс и продолжает выполнение шага 3 основного потока.
3.1Б. На курс записалось мало студентов
1. Система выбирает следующий курс и продолжает выполнение шага 3 основного потока.
3.2.1А Регистрация на курс закрыта
1. Выполнение подчиненного потока «Зафиксировать курс в графике» завершается.
5.1А. Менее трёх студентов на курсе
1. Пока в списке меньше 3 студентов и есть графики, в которых меньше 4 зафиксированных курсов выполняется подчиненный поток «Зафиксировать курс в графике»
2. Система подтверждает, что на курсе 3 или более студентов.
3. Продолжается выполнение основного потока с шага 5.2.
5.1А.2А. Невозможно добавить студентов на курс
1. Система обнаруживает, что на курсе 2 или менее студентов.
2. Система помечает курс как отмененный.
3. Система вычеркивает его из всех графиков и переходит к следующему открытому курсу.
3. Продолжается выполнение основного потока с шага 5.
7А. Расчётная система недоступна
1. Система ожидает некоторое установленное время.
2. Выполнение передается на шаг 6 основного потока.
Предусловия
Перед началом выполнения данного варианта использования регистратор должен войти в систему.
Постусловия
Если вариант использования завершится успешно, регистрация закрывается, графики студентов передаются в расчётную систему. В противном случае регистрация остаётся открытой.

      Все потоки событий одного варианта использования, сценарии двух и более взаимосвязанных вариантов использования или отдельный поток событий могут быть смоделированы на диаграммах деятельности. Построим диаграмму деятельности для варианта использования «Войти в систему». Предварительно настроим редактор для более удобной работы. Меню Window -> Preferences. В открывшемся окне в поле фильтра вводим Control, в дереве настроек находим Control Flow. Скрываем стереотип ребра, имя ребра и вес ребра.

      Рис. 3.4.1. Окно настроек

      1. На вкладке Outline вызываем контекстное меню варианта использования Войти в систему и выбираем Add diagram -> Activity diagram.

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

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

      4. Добавляем узлы разветвления (Decision Node). Соединяем узлы ребрами потоков управления (Control Flow). Скрыть имена ребер и тривиальные сторожевые условия можно с помощью окна Свойства (закладка Graphics). Задать нетривиальные сторожевые условия можно на закладке Guard. Тип создаваемого условия <Literal String>, текст условия задается в поле Value.

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

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

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

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

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

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

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

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

      Моделирование требований следовало бы продолжить дальше, описав все варианты использования и построив для них диаграммы деятельности. Однако, не имеет смысла сразу описывать все требования. Работа осуществляется последовательными итерациями, в ходе которых составляются описания отдельных вариантов использования в порядке их важности. Когда описания важных вариантов использования составлены, выполняются работы по анализу и проектированию частей системы, реализующих их. 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. Вкладка Outline, контекстное меню пакета Logical View, Create child -> Packaged Element -> Model. Аналогично создадим проектную модель (Design Model).

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

      3. Создадим реализацию варианта использования ход в систему (Login). Вкладка Outline, контекстное меню пакета UseCase Realizations, Create child -> Packaged Element -> Collaboration. В свойствах кооперации на вкладке Stereotypes укажем стереотип <<use case realization>>. На вкладке Advanced укажем Use Case Войти в систему. Кооперации дадим имя Login в соответствии с соглашениями моделирования. Аналогичным образом создадим реализацию варианта использования Зарегистрироваться на курсы (RegisterForCourses).

      4. Создадим диаграммы классов VOPC. Вкладка Outline, контекстное меню пакета UseCase Realizations, Add diagram -> Class Diagram.

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

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

      Ключевые абстракции -- основные понятия предметной области -- архитектор выделяет, анализируя требования и пользуясь, глоссарием и моделью бизнес-анализа, если таковая была создана. Каждый термин из глоссария является кандидатом для того, чтобы быть трансформированным в класс ключевой абстракции (или в несколько классов, если структура данных, связанная с ним, слишком сложна для представления одним классом). Некоторые термины могут быть источником для атрибутов классов. В системе регистрации можно выделить следующие ключевые абстракции: Student (данные об учащемся), Schedule (план-график студента, которых у него может быть несколько разных в разных семестрах), CourseOffering (данные о курсе, читаемом в некотором семестре), Professor (данные о лекторе), Course (данные о курсе из учебного плана, полученные из каталога курсов). Ассоциации между абстракциями описывают типичные соединения между экземплярами ключевых абстракций. Мощности у полюсов указывают ограничения на количество соединений у одного экземпляра. Обратите внимание на рефлексивную ассоциацию (см. рис. 4.1.2) класса Course, используемую для указания на курсы, которые следует прослушать до какого-либо курса. В обратную сторону связь может трактоваться как список курсов, которые можно прослушать после сдачи какого-либо курса. Полюсам рефлексивных связей следует давать имена, чтобы различать их роли. Также поступают при наличии двух ассоциаций между одной парой классов.

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

      Предварительно настроим редактор для более удобной работы. Меню Window -> Preferences. В открывшемся окне в дереве настроек найдем диаграмму классов: Topcased -> Editors -> UML/SysML -> Class Diagram. Изменим фон класса на белый. У ассоциации оставим видимыми лишь srcCountEdgeObject и targetCountEdgeObject. Начертание линии (Router) заменим на прямоугольное.

      1. Откроем в редакторе диаграмму Key Abstractions. Выберем в палитре инструмент Class. Добавим классы Course, CourseOffering, Professor, Schedule, Student.

      2. Выберем в палитре инструмент Association. Проведем связи между классами. Укажем мощности у полюсов (поля Lower Bound и Upper Bound в закладках First End, Second End). Дадим имена полюсам (поле Role в закладках First End, Second End). Отобразим имена полюсов на диаграмме (закладка Graphics, элементы srcNameEdgeObject и targetNameEdgeObject).

      3. Добавим атрибуты (Property) классов: : классу Student -- address, name; классу Schedule -- semester; классу CourseOffering -- number; классу Professor -- name, academicDegree; классу Course -- description, duration. Укажем, что все атрибуты закрытые (поле Visibility в закладке Model). В итоге диаграмма должна соответствовать рисунку 4.1.2.

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

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

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

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

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

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

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

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

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

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

      Выполним анализ варианта использования «Зарегистрироваться на курсы».

      Идентифицируем классы анализа. Согласно диаграмме вариантов использования имеются два действующих лица (Студент и Каталог курсов), связанных с нашим вариантом использования. Создадим граничные классы: RegisterForCoursesForm -- экранную форму, отвечающую за взаимодействие со Студентом, CourseCatalogSystem -- класс-посредник, реализующий протокол взаимодействия с Каталогом курсов. Вкладка Outline, контекстное меню пакета Analysis Model, Create child -> Packaged Element -> Class. Не забудьте указать стереотип <<boundary>>. Создадим управляющий класс RegistrationController, отвечающий за реализацию бизнес-логики (действия аналогичны, стереотип <<control>>). Классам -- ключевым абстракциям -- назначим стереотип <<entity>>. Из описания варианта использования следует, что в потоках событий будут задействованы экземпляры классов Student, CourseOffering, Schedule. Открываем в редакторе диаграмму классов VOPC RegisterForCourses. Перетаскиваем на нее вышеупомянутые классы (граничные, управляющие и сущности). Вид диаграммы изображен на рис. 4.2.1.

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

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

      Создадим внутри кооперации RegisterForCourses элемент внутреннего поведения BasicFlow (основной поток). Create child -> Owned Behavior -> Interaction. Внутри созданного взаимодействия создадим одноименную диаграмму последовательности (Sequence Diagram). Откроем ее в редакторе. Чтобы увеличить ширину диаграммы изменим её ориентацию на листе с "портретной" на "пейзажную" (Properties, вкладка Graphics, поле Opientation).

      Добавим пять объектов с линиями жизни (Lifeline). Левый представляет собой экземпляр действующего лица Студент (свойства, вкладка Model, поле Represents), правый -- экземпляр действующего лица Каталог курсов. В середине экземпляр класса RegisterForCoursesForm, объект класса RegistrationController и экземпляр CourseCatalogSystem. Все объекты анонимны. Как правило, имена дают в том случае, если на диаграмме есть несколько объектов одного типа, чтобы их различать. Заметьте, что экземпляры граничных классов находятся рядом с экземплярами тех действующих лиц, за общение с которыми они отвечают, а экземпляр контроллера расположен в середине диаграммы.

      Добавим активацию (Execution) а линию жизни Студента. Затем выберем на палитре синхронное сообщение (Call synch.) и проведем его от первой линии жизни ко второй. Дадим имя сообщению //register for courses. Два слэша указывают, что это предварительное имя сообщения, которое в дальнейшем будет уточнено. Аналогично добавим второе сообщение с тем же именем, которым форма извещает контроллер о выборе студента. Экземпляр контроллера должен проверить, можно ли выполнить запрошенное действие. Для этого он посылает сам себе рефлексивное сообщение //is registration open?.

      Рис. 4.2.2. Начальный вид диаграммы BasicFlow

      Далее есть два варианта развития событий. Либо регистрация закрыта, и экземпляр формы выводит сообщение об ошибке, посылая самому себе сообщение //display error (см. внизу диаграммы), либо регистрация открыта и происходит содержательное взаимодействие. Добавим на диаграмму комбинированный фрагмент взаимодействия (Combined Fragment), иначе называемый блоком. Укажем его тип -- Alternative (свойства, закладка Model, поле Interaction Operator). Добавим в блок второй операнд взаимодействия (Interaction Operand). По умолчанию он получает сторожевое условие [else]. На Outline выделим первый операнд взаимодействия (Interaction Operand), вложенный в комбинированный фрагмент. С помощью контекстного меню добавим сторожевое условие [регистрация открыта] (Create child -> Guard -> Interaction Constraint). Указать значение и тип сторожевого условия (Literal String) можно в окне свойств на закладке Specification. Добавим активацию на линию жизни экземпляра контроллера. Создадим сообщения //connect with catalog и //start session. В зависимости от того, удаётся установить связь или нет, возникают альтернативные продолжения. Помещаем на диаграмму вложенный комбинированный фрагмент аналогично предыдущему. Если связь установлена, от экземпляра Каталог курсов приходит сообщение-возврат. Происходят возвраты в ответ на сообщения //connect with catalog и //is registration open?. Явно возвраты указывать не обязательно, здесь они приведены для наглядности, далее мы их будет опускать.

      Рис. 4.2.3. Диаграмма BasicFlow в ходе редактирования

      Получив возврат, форма высвечивает доступные студенту действия с помощью рефлексивного сообщения //display possible operations. Для моделирования вариантов продолжения потока событий создадим внутри операнда взаимодействия вложенный комбинированный фрагмент. Укажем его тип (Alternative). Добавим еще три операнда взаимодействия внутрь созданного комбинированного фрагмента. Добавим операндам сторожевые условия. К сожалению текущая версия Topcased не поддерживает должным образом элемент interaction use, который мы могли бы использовать для ссылки на взаимодействия, моделирующие подчиненные потоки варианта использования. Поэтому мы воспользуемся примечаниями (comment). Чтобы поместить примечание внутрь операнда взаимодействия, создадим его справа от правой границы фрагмента, затем сдвинем левую и правую границы примечания внутрь фрагмента. Внутри примечаний (Body) укажем подчиненные потоки. Добавим сообщения для вывода предупреждений об ошибках. Диаграмма примет вид, показанный на рисунке 4.2.4.

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

      Для моделирования подчиненных потоков создадим внутри взаимодействия BasicFlow дочерние взаимодействия CreateScheduleSubflow, UpdateScheduleSubflow, DeleteScheduleSubflow и SubmitScheduleSubflow. Внутри каждого взаимодействия создадим одноименные диаграммы последовательности. Из них промоделируем поток CreateScheduleSubflow. Вид диаграммы, которая должна получиться, показан на рисунке 4.2.5. На диаграмме использован блок Optional -- ветвление с единственной содержательной альтернативой, а также блоки Loop -- циклы. Обратите внимание, что на рис. 4.2.5 есть сообщение //create with offerings, имеет тип Create Message. Возможность передвинуть экземпляр Schedule вниз диаграммы появится после добавления Create Message. Topcased не позволяет сразу расположить экземпляр в нужном месте, следует сдвинуть нижнюю границу блока, чтобы освободить место, затем поместить туда объект и сдвинуть границу блока обратно.

      Рис. 4.2.5. Диаграмма CreateScheduleSubflow

      Каждое сообщение на диаграмме последовательности дает экземплярам классов обязанности по отправке и приему сообщения. Для приема сообщения в классе объекта-приемника должна быть одноименная операция. Для отправки сообщения между экземплярами классов должно быть соединение, т. е. между классами должна быть ассоциация. Рассмотрим пример. На диаграмме 4.2.4. BasicFlow форма отправляет сообщение контроллеру. Найдем в Outline класс RegistrationController. Добавим операцию //isRegistrationOpen? (контекстное меню, Add child -> Owned Operation -> Operation). Поскольку профиль операции до конца не определен, она -- лишь заготовка будущей операции (операция анализа). На диаграмме последовательности следует связать сообщение и операцию. Для этого выделите сообщение в редакторе, в окне Свойства откройте закладку Model, заполните поле Operation. На диаграмме VOPC RegisterForCourses проведем ассоциацию между классом-формой и классом-контроллером, чтобы их экземпляры могли взаимодействовать. Самостоятельно создайте остальные операции анализа, свяжите с ними сообщения, проведите ассоциации между классами анализа. Диаграмма VOPC RegisterForCourses примет вид, показанный на рисунке 4.2.6.

      Рис. 4.2.6. Диаграмма VOPC RegisterForCourses

      Действуя аналогично, добавьте новые атрибуты классам (контекстное меню, Add child -> Owned Attribute -> Property): классу Student -- id; классу CourseOffering -- numStudents, day, pair. Отметьте атрибут CourseOffering:numStudents как выводимый (в окне свойств отметьте флажок isDerived), поскольку его значение равно количеству планов-графиков, связанных с предлагаемым курсом. Так как студенты учатся на дневном и вечернем отделениях добавьте в пакет Analysis Model классы FullTimeStudent и PartTimeStudent -- наследники класса Student. Проведите на диаграмме связи обобщения (Generalization). Добавьте атрибуты классам наследникам (указываются только собственные атрибуты, унаследованные добавлять не следует). Укажите, что связь студента с планом-графиком -- композиция (в Свойствах для одного из концов укажите Assotiation Type = composite). Диаграмма должна выглядеть как на рис. 4.2.7.

      Рис. 4.2.7. Диаграмма VOPC RegisterForCourses по окончании анализа

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

      Рис. 4.2.8. Диаграмма BasicFlow после связывания сообщений и операций

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

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

      Система регистрации работает с реляционной базой -- каталогом курсов, следовательно при проектировании мы будем использовать механизм обеспечения устойчивости RDBMS (relational database management system). Существуют готовые каркасы, обеспечивающие доступ к реляционным БД. К таким относится JDBC (Java Database Connectivity). Добавим в нашу модель проектный механизм. Для этого следует скачать архив с моделью. Вызовите контекстное меню в навигаторе Topcased Import -> General -> Archive File. Укажите persistency.zip. Поместите файлы Persistency.uml и Persistency.umldi в папку Models. Далее в Outline Вашей модели выберите пакет Logical View, вызовите его контекстное меню. Import From Model... -> Persistency.uml -> Design Model. Лишний (пустой) пакет Design Model удалите. В появившейся проектной модели есть два пакета: первый с описанием механизма JDBC, второй с библиотечными пакетами java. Добавление проектного механизма закончено.

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

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

      Следующие наши действия нацелены на трансформацию классов анализа в проектные элементы (классы, интерфейсы и подсистемы) и распределение проектных элементов по уровням системы. При трансформации простые классы анализа преобразуются в проектные классы один в один. Сложный класс анализа может преобразовываться в несколько связанных проектных классов или в подсистему. Сложным у нас является класс CatalogSystem -- преобразуем его в подсистему. Остальные классы анализа переведем в проектные один в один. Чтобы не испортить модель анализа, скопируем ее, чтобы из копии перенести классы в проектную модель. Outline, контекстное меню Analysis Model -> Duplicate subtree. Появился пакет Copy Of Analysis Model. Создадим в пакете Application пакет Registration (классы не могут быть вложены непосредственно в слой, дочерними элементами слоя являются только пакеты). В созданный пакет перетащим классы RegisterForCoursesForm и RegistrationController и их связи. Ассоциации, соединяющее эти классы с другими можете найти в пакете UseCase Realizations. Заметим, что стереотипы анализа в проектной модели смысла не имеют, их нужно убрать. В пакете BusinessServices создадим пакеты UniversityArtefacts (т. е. артефакты университета, в нем разместим классы-сущности предметной области и их связи), пакет Interfaces (где будут находиться все интерфейсы), пакет CourseCatalogSystem со стереотипом <<subsystem>> (в него поместим одноименный класс). Классу CourseCatalogSystem назначим стереотип <<subsystem proxy>> -- это означает, что он принимает все сообщения, идущие внутрь подсистемы. Перенесем пакет UseCase Realizations из Copy Of Analysis Model в Design Model. Диаграмму классов Copy of Key Abstractions перенесем в пакет UniversityArtefacts. Удалим опустевший Copy Of Analysis Model. В пакете Interfaces создадим интерфейс ICourseCatalogSystem. Структура проектной модели в Outline примет вид похожий на рис. 5.1.2.

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

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

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

      Моделировать структуру потоков управления системы не будем. Этот вопрос будет рассматриваться на лекции. Перечислим лишь виды процессов в нашей системе: StudentApplication -- пользовательский процесс рабочего места студента; ProfessorApplication -- пользовательский процесс рабочего места лектора; RegistrarApplication -- пользовательский процесс рабочего места регистратора; RegistrationProcess -- общий процесс, управляющий ходом регистрации; BillingAccess -- процесс обеспечивающий связь с расчетной системой; CourseCatalogAccess -- процесс, обеспечивающий связь с каталогом курсов. Последние два нужны для обеспечения эффективности, т. е. поддержки кэшей данных. Перейдем к моделированию конфигурации на вычислительной среде. Вычислительная среда состоит из двух типов узлов -- процессоров (ExecutionEnvironment) и устройств. На процессорах можно разместить части системы -- артефакты, соответствующие рассмотренным нами процессам. Связи между узлами описывают пути коммуникации (CommunicationPath). Откроем в редакторе диаграмму размещения DeploymentView из одноименного пакета. Артефакты следует создавать, размещая их внутри узла. Окончательный вид диаграммы приведен на рис. 5.1.4. На ней показано, что в среде есть сервер регистрации, к которому подключен принтер и три типа рабочих станций. Для соединения рабочих станций с сервером используется локальная сеть университетского кампуса. Также на диаграмме указаны два унаследованных узла -- узел каталога курсов и узел расчётной системы, подключённые к серверу регистрации.

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

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

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

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

      На диаграммах BasicFlow и CreateScheduleSubflow следует объекту класса CourseCatalogSystem изменить тип на интерфейс ICourseCatalogSystem. Тем самым мы показываем, что здесь происходит обращение к экземпляру класса, реализующему интерфейс подсистемы. Какой именно это будет класс -- это для реализации варианта использования неважно. Реализация не определяет, как подсистема CourseCatalogSystem должна обрабатывать такой вызов. Эта часть относится к проектированию подсистемы и может варьироваться в зависимости от реализации подсистемы. Внутреннее поведение подсистемы скрыто, чтобы обеспечить возможность легкой модификации ее реализации. Исходя из сказанного, уберем из модели экземпляр действующего лица Каталог курcов. Убедимся, что сообщения, принимаемые объектом, реализующим интерфейс ICourseCatalogSystem, связаны с операциями интерфейса ICourseCatalogSystem::getCourseOfferings(), ICourseCatalogSystem::connectWithCatalog() и ICourseCatalogSystem::disconnectWithCatalog(). Поскольку операции отсутствуют, на Outline перенесите их из класса CourseCatalogSystem в интерфейс. Диаграмма BasicFlow примет вид, представленный на рисунке 5.2.1. На диаграмме CreateScheduleSubflow произойдут схожие изменения (см. рис. 5.2.2).

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

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

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

      Подсистема пока содержит один класс со стереотипом <<subsystem proxy>>. Класс отвечает за реализацию интерфейса подсистемы. Объекты этого класса будут принимать и обрабатывать все входящие сообщения. Класс создается для удобства тестирования сопряжений при сборке системы. При реализации подсистемы мы воспользуемся механизмом RDBMS-JDBC. При использовании механизма классы-роли следует заменить на проектные классы системы. Среда Topcased пока не поддерживает автоматическое создание экземпляра механизма и постановку проектных классов вместо ролей. Придется вручную создать экземпляр механизма RDBMS-JDBC с подстановкой класса DBCourseOffering вместо роли DBClass, CourseOffering – вместо PersistentClass, CourseOfferingList – вместо PersistentClassList, CourseCatalogSystem вместо PersistencyClient.

      Продублируем на Outline пакет RDBMS-JDBC (контекстное меню, Duplicate subtree). Копию перемещаем в пакет CourseCatalogSystem и переименовываем в Interface Realization. Кооперацию внутри пакета Interface Realization переименовываем в ICourseCatalogSystem и указываем ей стереотип <<interface realization>> вместо <<mechanism>>. В интерфейсе ICourseCatalogSystem должны быть три операции ICourseCatalogSystem::getCourseOfferings(semester:String):CourseOfferingList, ICourseCatalogSystem::connectWithCatalog() и ICourseCatalogSystem::disconnectWithCatalog(). Уберите слэши из имён операций. Вызовы этих операций мы встречали на диаграммах последовательности.
Диаграмму классов Copy of RDBMS-JDBC из пакета Interface Realization перенесите в пакет CourseCatalogSystem и переименуйте в CourseCatalogSystem. Также поступите со всеми классами и связями из пакета Interface Realization. Переименуйте классы: DBClass -- в DBCourseOffering, PersistentClassList -- в CourseOfferingList. Удалите стереотипы <<role>> у этих двух классов. Поместите классы CourseCatalogSystem и CourseOffering на диаграмму классов CourseCatalogSystem. Создайте для них те же связи, что имеют соответствующие им классы-роли: PersistencyClient и PersistentClass. Удалите PersistencyClient и PersistentClass. Класс CourseOfferingList перенесите в пакет UniversityArtefacts. Туда же переместите зависимость между классами CourseOfferingList и CourseOffering. Добавьте на диаграмму интерфейс ICourseCatalogSystem. Укажите связью реализации, что класс CourseCatalogSystem реализует интерфейс подсистемы. Удалите из класса DBCourseOffering лишние операции: create, update, delete (взаимодействие с каталогом курсов идет только в режиме чтения). Диаграмма классов и структура подсистемы должны быть похожи на изображенные на рисунках. Обратите внимание, что связи импорта, ассоциация и зависимости находятся в корне подсистемы. Исправьте свою модель, перенеся связи в корень подсистемы.

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

      Рис. 5.2.4. Структура подсистемы CourseCatalogSystem в Outline

      Не забудьте исправить профили операций DBCourseOffering::read и CourseOfferingList::add. Зависимость между классами CourseOfferingList и CourseOffering следует переместить в пакет UniversityArtefacts, где находятся оба этих класса. Структура подсистемы создана. Благодаря использованию механизма мы затратили меньше сил на обдумывание и моделирование, чем если бы делали подсистему с чистого листа. Переходим к моделированию внутреннего поведения подсистемы.

      Внутри кооперации ICourseCatalogSystem оставьте только три взаимодействия Initialize, Read и disconnect. Взаимодействие Initialize переименуйте в ConnectWithCatalog, взаимодействие Read -- в GetCourseOfferings, disconnect -- в DisconnectWithCatalog. Каждое взаимодействие будет описывать, что делают объекты подсистемы при обработке вызова соответствующей операции, реализуемой подсистемой. На диаграмме последовательности внутри взаимодействия ConnectWithCatalog добавьте экземпляр класса CourseCatalogSystem, входящее сообщение connectWithCatalog, принимаемое им, и сообщение init от него к объекту DBCourseOffering. Удалите лишнее входящее сообщение. Диаграмма примет вид, изображенный на рисунке 5.2.5.

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

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

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

      На диаграмме последовательности GetCourseOfferings (бывшей Read) замените типы объектов: у левой линии жизни укажите тип CourseCatalogSystem, у правой линии жизни -- CourseOffering. Добавьте входящее сообщение getCourseOffering, принимаемое экземпляром CourseCatalogSystem. Добавьте классу CourseOffering новые операции new() и setData(number:String, day:String, pair:String):Boolean. Свяжите с ними сообщения на диаграмме последовательности. Диаграмма примет вид, изображенный на рисунке 5.2.7.

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

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

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

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

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

      Рассмотрим проектирование классов на примере системы регистрации. Создайте в пакете UniversityArtefacts диаграмму классов Student. Поместите класс Student на диаграмму. Уточните его атрибуты и операции, чтобы придать ему вид, схожий с рисунком 5.2.8. Статические (подчеркнутые) атрибуты и операции пометьте специальным флажком. Типы Int, Boolean и String используйте из пакета java.lang, Date -- из java.sql.

      Рис. 5.2.8. Диаграмма классов Student

      Экземпляры класса CourseOffering должны по-разному обрабатывать вызовы операции addStudent в зависимости от того, отменен курс или нет, и от количества уже зарегистрировавшихся студентов. Это признак сложного поведения и причина для создания диаграммы состояний. Добавьте классу диаграмму состояний LifeCycle (контекстное меню, Add diagram -> State Machine Diagram). Откройте диаграмму в редакторе. Создайте начальное состояние (Initial), финальное состояние (FinalState), состояния Open, Closed, Canceled и псевдосостояние выбора (Choice). Соедините состояния переходами, как указано на рисунке 5.2.9. Для добавления переходу события в окне Properties на вкладке Triggers создайте триггер. Выделив созданный триггер, создайте событие, укажите его имя и тип (CallEvent). Обратите внимание, что событие when(numStudents=10) является событием изменения (ChangeEvent). Контейнером всех событий является пакет UniversityArtifacts. Некоторые события, такие как cancel и del запускают переходы из разных состояний. Их не следует создавать дважды. Указывая тригер для второго перехода просто сошлитесь на уже созданное событие (кнопка «...»). Действия на переходах создаются на вкладке Effect. Тип действий Opaque Behavior. Выделив действие в окне Outline, следует задать его тело. Особенность среды Topcased в том, что для переходов между состояниями тело действия следует указывать, в поле Name на вкладке Model окна Properties. Чтобы заставить Topcased перерисовать диаграмму состояний и отобразить внесенные Вами изменения в Outline дважды щелкните по любой другой диаграмме (например, Key Abstractions) а затем снова откройте диаграмму состояний. Сторожевые условия создаются на закладке Guard. Тип всех условий Constraint. Содержимое условия следует задавать с помощью окна Outline. Раскройте переход, выделите условие. В окне Properties на вкладке Specification создайте Literal String и введите текст условия в поле Value. Обратите внимание, что два перехода являются внутренними в состоянии Open. Их следует добавлять в окне Properties (при выделенном состоянии Open в Outline) на закладке Internal Transition. Тригер, сторожевое условие добавляются к внутреннему переходу также, как к обычному. Работа с действием имеет отличия. Действие на внутреннем переходе создаётся на вкладке Effect. Тип действия Opaque Behavior. Выделив действие в окне Outline, следует задать его тело. Перейдите на вкладку Advanced окна Properties. Выделите свойство Body, откройте вспомогательное окно кнопкой «...». Введите текст тела в левое поле и переместите его в поле Feature кнопкой «Add». Таким же способом задаётся тело действия при входе в состояние Canceled.

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

      Рис. 5.2.9. Диаграмма состояний класса CourseOffering

      Рис. 5.2.10. Структура модели состояний в Outline

      Согласно построенной диаграмме, следует добавить в класс CourseOffering операции, соответствующие событиям вызова: addStudent(sch: Schedule), removeStudent(sch: Schedule), cancel(), close(), del().

      Уточним связи между классами на диаграмме VOPC RegisterForCourses проектной реализации варианта использования Зарегистрироваться на курсы. Откроем диаграмму (из Design Model). Чтобы на диаграмме отобразились изменения, внесённые в ходе проектирования, удалим классы с диаграммы, но не из модели (выделите все и нажмите Del) и заново поместим их на диаграмму. Перетащите классы RegisterForCoursesForm, RegistrationController, Student, Schedule, CourseOffering и интерфейс ICourseCatalogSystem из Outline на диаграмму (см. рис. 5.2.10). Уточните связи. Зависимость (пунктирные стрелки) указывает на то, что класс RegistrationController использует интерфейс. RegistrationController хранит ссылку на объект с данными регистрирующегося студента и на текущее расписание (две агрегации -- AssotiationType: shared). Укажите направления ассоциаций (флажок isNavigable) и типы. Обратите внимание на двунаправленные ассоциации (со стрелкам на обоих концах). В плане-графике хранятся ссылки на курсы, включенные в него, и каждый курс хранит массив ссылок на планы-графики, в которые он включен.

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

      Рассмотрим уточнение обобщения (метаморфозу подтипов). При анализе мы определили, что бывают студенты дневного отделения и студенты вечернего отделения, создав иерархию наследования. Рассмотрим хороша ли такая модель, в случае перевода студента с одного отделения на другое. При переводе требуется создать студента нового типа, скопировать в него данные (значения атрибутов класса Student), а затем исходный объект удалить. Эффективнее было бы общую для дневных и вечерних студентов часть не трогать, а менять только то, что зависит от отделения. Выделим эту часть в абстрактный класс Classification, унаследуем от него FullTimeClassification и PartTimeClassification -- переименованные бывшие классы FulltimeStudent и PartTimeStudent. Результат -- обновленная диаграмма классов Student представлена на рис. 5.2.12.

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

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

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

      Согласно этой схеме одному объекту -- экземпляру класса Student -- будут соответствовать три записи: запись в таблице TableStudent, связанная с ней запись в таблице TableClassification и запись в одной из двух оставшихся таблиц. Во всех этих записях будет одно и то же значение id. Обратите внимание, что в схемах БД все связи между таблицами двунаправленные, так как по записи любой из связанных таблиц можно найти связанные записи из второй таблицы.

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

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

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