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

Моделирование системы регистрации на курсы. Выполнение учебного проекта в среде Modelio


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

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

Содержание


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

1. Сведения о работе в среде Modelio


      Modelio (www.modelio.org) -- среда объектно-ориентированного проектирования на языке UML. Для установки следует загрузить архив версии 3.0 RC2a со страницы загрузки и разархивировать его. Поскольку практикум в компьютерных классах проходит под операционной системой Windows, описывается работа в ней. При разархивировании укажите путь, например, C:\Program Files\Modelio. Для запуска среды вызывается исполняемый файл modelio.exe из директории C:\Program Files\Modelio. Для работы среды необходимо установить Java SE Runtime Environment 7 с сайта www.java.com. Следует убедиться, что в переменной среды Path прописан путь к файлу java.exe из JRE (что-то вроде C:\Program Files\Java\jre7\bin). Запуск может быть неудачен, если в качестве рабочей директории используется папка, в которую нет права записи у текущего пользователя. Следует запускать среду, используя директорию, на которую достаточно прав.

      Запустив среду, указываем путь к рабочей области (workspace), в которой будут находиться файлы нашего проекта (меню File -> Switch workspace). Для простоты воспользуемся шаблоном проекта, в котором уже создана основная структура модели, добавлены стереотипы и проектный механизм JDBC. Загружаем шаблон с веб-странички курса. Импортируем проект в рабочую область (меню File -> Import project). В рабочей области появился проект MyProject. Откроем его (Ctrl+O). После этого окно примет вид, показанный на рисунке 1.1.

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

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

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

      По содержимому вкладки Element можно узнать, что текущий элемент, выделенный в браузере, является пакетом Use Case View. К этому элементу применён стереотип <<architectural view>>, указывающий, что пакет является архитектурным представлением.

      В составе модели уже есть одна диаграмма -- overview diagram. Откроем её, выделив в браузере и сделав двойной клик. В редакторе диаграмм слева появится палитра элементов, остальную часть окна редактора займёт диаграмма. Окно примет вид, показанный на рисунке 1.2.

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

      Выделим в редакторе Use Case View. Откроем вкладку Symbol. Мы можем изменить отображение Use Case View на диаграмме. Например, можно выбрать режим отображения стереотипов Text+icon, чтобы стереотип был показан пиктограммой и дополнительно был подписан строчкой текста. Стереотип можно рассматривать как пометку элемента модели, сообщающую пользователю дополнительные сведения. Пакет, помеченный <<architectural view>> отличается от обычного пакета. У него специальное назначение -- группировать элементы модели, представляющие систему с определённой точки зрения. Стереотипы бывают полезны при обработке моделей программами. При трансформации модели в текст (код или документ) или в другую модель стереотипы указывают на способы обработки элементов модели.

      Запишем сделанные изменения (Ctrl+S). Чтобы сохранить промежуточную копию, к которой можно будет вернуться, если что-то пойдёт не так, закроем проект (меню File -> Close project). Наведём курсор на MyProject в браузере и вызовем правым кликом контекстное меню. Выберем пункт Export the project. Укажем в появившемся окне расположение и имя архива с проектом. Этот архив можно скопировать в надёжное место (например, на флешку) и при необходимости импортировать сохранённый проект в рабочую область, как мы это делали в начале работы.

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

2. Система регистрации для вуза. Описание


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

      Глоссарий:

Каталог курсов
(Course Catalog)

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

Курс
(Course)

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

Оценка
(Mark)

Количество баллов (от 2 до 5), полученных студентом за конкретный курс.

План-график
(Schedule)

Набор предлагаемых курсов, выбранных студентом в некотором семестре. План-график включает в себя 4 основных и 2 альтернативных курса.

Предлагаемый курс
(Course Offering)

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

Профессор
(Professor)

Пользователь системы регистрации. Лектор произвольного количества курсов в течение семестра. Отмечает в системе читаемые им курсы, ставит оценки.

Расчётная система
(Billing System)

Внешняя система, в которую передаются сведения для формирования счетов за обучение.

Регистратор
(Registrar)

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

Регистрация на курсы
(Registration)

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

Список курса
(Roster)

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

Студент
(Student)

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

Табель успеваемости
(Report Card)

Все оценки за все курсы, полученные студентом в некотором семестре.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


      1. В браузере находим пакет Use Case View, а внутри него модель Use Case Model. Правым щелчком вызываем контекстное меню Use Case Model. Create element -> Class. Созданный класс назовём "Система регистрации на курсы". Для этого выделим его в браузере и нажмём F2. Назначим классу стереотип <<subject>> (контекстное меню Add stereotype). Этим классом мы представим в модели рамки моделируемой программной системы. Выделим UseCase Model и вызовем контекстное меню Create diagram -> Create a Use Case diagram. Дадим имя Main диаграмме. Диаграмма открылась в окне редактора и появилась палитра с элементами диаграмм. Перетащим из браузера систему на диаграмму. На вкладке Symbol изменим параметры её отображения. Отменим отображение атрибутов (Class - Attributes Show) и операций (Class - Operations Show), установим отображение вложенных элементов (Class - Inner elements Display mode = Diagram). Вид окна с получившейся диаграммой представлен на рисунке 3.1.1.

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

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

      3. Увеличим размеры элемента Subject, чтобы он вместил варианты использования системы. Получившаяся диаграмма примет вид, показанный на рисунке 3.1.2.

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

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

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

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


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

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

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

      2. В палитре редактора выберем связь Communication Link и проведём связь от действующего лица Студент к варианту использования Зарегистрироваться на курсы. В свойствах отображения (вкладка Symbol, Association Show navigability) зададим отображение направление, поставив галку. Также можно указать тип линии (Line path style): прямая (Direct), ломанная (Bendpoint), прямоугольная ломанная (Orthogonal). Можно управлять выводом мощностей связи (Association Show cardinality). Если мощность выводится, следует её отключить. Для управления отображения всех элементов некоторого типа воспользуйтесь меню Configuration -> Diagram styles.

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

      4. Созданная диаграмма имеет недостаток в том, что у варианта использования «Войти в систему» несколько основных действующих лиц. Полагая поведение системы одинаковым при входе любого пользователя, введём действующее лицо Пользователь, подвидами которого будут лица Студент, Профессор, Регистратор. Диаграмма примет вид, изображённый на рисунке 3.2.2. Для добавления связей обобщения используйте связь Generalization. Лишние ассоциации удалите из модели (Del). Обратите внимание, что нажатие на Del удаляет элемент и с диаграммы и из модели. Если необходимо сохранить элемент в модели и всего лишь убрать его с диаграммы, на которую он случайно попал по какой-то причине, нажимайте Ctrl+M или используйте пункт контекстного меню Mask Selection. Следует чётко понимать удаляете ли Вы текущий элемент или всего лишь маскируете. Удаление вместо маскирования (как и обратное) может быть нежелательным. Случайно удалённый элемент можно попытаться восстановить, нажав Ctrl+Z. Маскированный по ошибке элемент можно снова поместить на диаграмму, перетаскивая его из браузера.
Рис. 3.2.2 Модифицированная диаграмма вариантов использования

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

    Краткое описание
    Данный вариант использования позволяет студенту зарегистрироваться на конкретные курсы в текущем семестре. Студент может изменить свой выбор (обновить или удалить курсы), если изменение выполняется в установленное время в начале семестра. Система каталога курсов предоставляет список всех конкретных курсов текущего семестра.
    Основной поток событий
    1. Студент сообщает о желании зарегистрироваться на курсы.
    2. Система подтверждает, что регистрация на курсы в текущем семестре открыта.
    3. Система запрашивает связь с каталогом курсов.
    4. Каталог курсов подтверждает, что связь установлена.
    5. Система запрашивает требуемое действие (создать график, обновить график, удалить график, утвердить график).
    6. Студент сообщает системе свой выбор.
    7. Система подтверждает, что требуемое действие можно выполнить.
    8. Согласно выбору студента выполняется один из подчинённых потоков (создать, обновить, удалить или утвердить график).
    9. Система заканчивает сеанс связи с каталогом курсов.
    10. Каталог курсов подтверждает, что сеанс закончен.
    Подчинённые потоки событий:
    8А. Создать график
    1. Система запрашивает у каталога курсов список доступных конкретных курсов.
    2. Каталог курсов передаёт системе запрашиваемый список.
    3. Система выводит список курсов и пустой план-график.
    4. Студент выбирает из списка 4 основных курса и 2 альтернативных курса.
    5. Система создаёт график студента и заносит в него выбранные курсы, помечая их как незафиксированные.
    6. Система сообщает, что создание графика завершено.
    7. Выполнение переходит на шаг 9 основного потока.
    8Б. Обновить график
    1. Система выводит текущий график студента.
    2. Система запрашивает у каталога курсов список доступных конкретных курсов.
    3. Каталог курсов передаёт системе запрашиваемый список.
    4. Система выводит список курсов.
    5. Студент обновляет свой выбор курсов, удаляя или добавляя конкретные курсы.
    6. Система обновляет график в соответствии с пожеланиями студента. Для каждого зафиксированного курса, удалённого из графика, система удаляет студента из списка студентов, записавшихся на курс. Каждый добавленный курс система помечает как незафиксированный.
    7. Система сообщает, что обновление графика завершено.
    8. Выполнение переходит на шаг 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 основного потока.
    Предусловия
    Перед началом выполнения данного варианта использования регистратор должен войти в систему.
    Постусловия
    Если вариант использования завершится успешно, регистрация закрывается, графики студентов передаются в расчётную систему. В противном случае регистрация остаётся открытой.

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


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

      При желании можно настроить редактор. Для этого в главном меню выберите Configuration -> Diagram styles -> ControlFlow -> Line path style = Orthogonal.

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

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

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

      4. Добавляем узлы логического ветвления (Decision). Соединяем узлы рёбрами потоков управления (Control Flow). Задать нетривиальные сторожевые условия можно на вкладке Element в поле Guard.

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

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

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

      Диаграмма деятельности задаёт потоки управления между узлами. Изначально курсор управления порождается во входном узле. Оттуда он передаётся по ребру на вход узла действия (Запрос имени и пароля). Узел действия ждёт, когда курсоры управления придут на все входящие ребра, после чего запускается действие, а по окончании действия курсоры управления подаются на все исходящие ребра. Очевидно, наша диаграмма содержит ошибку. По второму ребру курсор управления придёт не раньше, чем узел действия выдаст его на выход. Тупик. Чтобы исправить ошибку, добавим узел объединения (Merge), чтобы в узел действия входило одно ребро (и чтобы для выполнения действия требовался один входящий курсор). Узел объединения принимает курсор с любого входящего ребра и сразу передаёт его на исходящее ребро, которое у него одно. Дополнительно укажем действующих лиц, которых представляют собой разделы диаграммы. Для этого выберите раздел на диаграмме. Во вкладке Element поместите курсор ввода в поле Represented by. Затем выберите в браузере нужное действующее лицо (при расположении курсора рядом с действующим лицом появится пиктограмма горящей лампочки). Можно заполнять поле Represented by при помощи клавиатуры. Начните вводить имя элемента, а затем нажмите Ctrl+Space. Среда подскажет подходящие значения поля. Исправленная диаграмма показана на рисунке 3.4.2.

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

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

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

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

      Самостоятельно постройте диаграмму для варианта использования «Зарегистрироваться на курсы». Обратите внимание, что подчинённый поток может быть представлен на диаграмме в виде одного узла (см. узлы «c1:call Создать график», «c2:call Обновить график», «c3:call Удалить график», «c4: Утвердить график»). Тип этих узлов -- Call Behavior (узел вызова действия). С каждым из них связана деятельность, которая может быть промоделирована отдельной диаграммой деятельности. При создании диаграммы следует сначала создать внутри варианта использования четыре деятельности (Activity): Создать график, Обновить график, Удалить график, Утвердить график. Затем создайте узлы вызова действия и в каждом из них укажите вызываемую деятельность на вкладке Element в поле Called element. Заполнять это поле следует так, как было описано при сопоставлении разделов диаграммы с действующими лицами.

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

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

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

      Перейдём к анализу.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

      2. В пакет Use Case Realizations добавим три диаграммы последовательности (контекстное меню пакета Use Case Realizations -> Create diagram -> Create a Sequence diagram). Среда сама создаёт взаимодействия и размещает внутри взаимодействий диаграммы последовательности. Переименуем созданные взаимодействия в Login, RegisterForCourses и CloseRegistration. Диаграммы внутри взаимодействий переименуем в Basic flow. Каждое взаимодействие описывает сценарии одного из вариантов использования: Login -- Войти в систему, RegisterForCourses -- Зарегистрироваться на курсы, CloseRegistration -- Закрыть регистрацию. Диаграммы Basic flow служат для моделирования реализации основных сценариев.

      3. Создадим диаграммы классов VOPC (VOPC Login, VOPC RegisterForCourses, VOPC CloseRegistration). Контекстное меню пакета UseCase Realizations, Create diagram -> Create a Class Diagram. VOPC это сокращение View Of Participating Classes. Назначение этих диаграмм -- отображение классов, участвующих в реализации варианта использования и связей между этими классами.

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

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

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

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

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

      Предварительно настроим среду для более удобной работы. Меню Configuration -> Preferences. В открывшемся окне укажем тип атрибутов по умолчанию: undefined, видимость атрибутов по умолчанию: private, тип параметров операций по умолчанию undefined, тип результата операций по умолчанию undefined. Меню Configuration -> Diagram styles. В открывшемся окне в дереве настроек найдём Class. Укажем отображение стереотипов (Stereotypes display mode): Text + Icon. Установим метку Class Attributes ->Show для отображения атрибутов. Также отметим Show visibility. Class - Inner elements -> Display mode: Hidden. Class - Internal structure -> Display mode: Hidden. Отметим Class - Operations -> Show, и там же -- Display signatures, Show visibility. Можно аналогичные настройки сразу же установить для Interface. Сохраняем настройки, закрываем редактор стилей.

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

      2. Выберем в палитре инструмент Association. Проведём связи между классами. Уберём направления связей по умолчанию (поля Navigable в закладке Element). Укажем мощности у полюсов -- концов ассоциаций (поля Multiplicity min и Multiplicity max в закладке Element). Укажем роли у полюсов (поле Role). Укажем, что связь между студентом и графиком -- композиция (в поле Association type со стороны Schedule занести Composition).

      3. Добавим атрибуты (Attribute) классов: классу Student -- address, name; классу Schedule -- semester; классу CourseOffering -- number; классу Professor -- name, academicDegree; классу Course -- description, duration.

      4. Добавим всем классам-сущностям стереотип <<entity>>. Для этого выделим нужный класс в браузере, вызовем контекстное меню, Add stereotype -> <<entity>>. В итоге диаграмма должна соответствовать рисунку 4.1.2.

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

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

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

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

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

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

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

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

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

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

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

Упражнение 4.2. Анализ варианта использования «Зарегистрироваться на курсы»


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

      Назначим классам стереотипы. Выделите в браузере класс RegistrationController. С помощью контекстного меню добавьте стереотип <<control>>. Аналогично добавьте стереотип <<boundary>> граничным классам RegisterForCoursesForm, CourseCatalogSystem. Классам-сущностям Student, CourseOffering, Schedule назначьте стереотип <<entity>>, если не сделали этого ранее.

      Вид диаграммы, которая должна получиться, изображён на рис. 4.2.1.

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

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

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

      Откроем внутри взаимодействия RegisterForCourses диаграмму последовательности Basic Flow (основной поток). В браузере видно, внутри взаимодействия помимо диаграммы создана кооперация (Collaboration) locals. Внутри этой кооперации добавим роли. Ими будут являться взаимодействующие объекты: st -- экземпляр действующего лица Студент; menu -- экземпляр формы RegisterForCoursesForm; control: экземпляр класса RegistrationController; catsys -- экземпляр граничного класса CourseCatalogSystem и catalog -- экземпляр действующего лица Каталог курсов. В браузере выделите кооперацию RegisterForCourses, вызовите её контекстное меню, Create element -> Role. На закладке Element заполните поля Name и Base. Поле Base легче заполнять, помещая в него курсор ввода и затем указывая нужный элемент модели (класс или действующее лицо) в браузере.

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

      Добавим спецификацию выполнения (Execution Specification) на линию жизни Студента. Затем выберем на палитре синхронное сообщение (Synchronous Message) и проведём его от спецификации выполнения к линии жизни menu:RegisterForCoursesForm. Дадим имя сообщению registerForCourses. Удалим автоматически созданное ответное сообщение (пунктирную стрелку в обратном направлении следует выделить и нажать на Del). После удаления ответного сообщения длину спецификации выполнения можно менять, выделив её и сдвинув нижнюю её границу. Длину спецификации выполнения, от которой исходит возвратное сообщение, можно менять, сдвигая возвратное сообщение. Добавим второе синхронное сообщение с тем же именем, которым форма извещает контроллер о выборе студента (возврат не удаляем). Экземпляр контроллера должен проверить, можно ли выполнить запрошенное действие. Для этого он посылает сам себе рефлексивное сообщение //isRegistrationOpened, тип которого Inner Synchronous Message. Каждое сообщение экземпляру класса должно быть связано с операцией данного класса. Сообщения, получаемые экземплярами действующих лиц связывать с операциями не следует. Создадим в классе RegisterForCoursesForm операцию //registerForCourses. Два слэша указывают, что это предварительное имя, которое в дальнейшем будет уточнено. Аналогично создадим операции //registerForCourses и //isRegistrationOpened в классе-контроллере. Свяжем сообщения с операциями, заполнив поле Invoked на вкладке Element.

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

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

      Далее есть два варианта развития событий. Либо регистрация закрыта, и экземпляр формы выводит сообщение об ошибке, посылая самому себе сообщение //displayError, либо регистрация открыта и происходит содержательное взаимодействие. Добавим на диаграмму комбинированный фрагмент взаимодействия (Combined Fragment). Укажем его тип -- Alt (вкладка Element, поле Operator). Добавим во фрагмент второй операнд взаимодействия (выделите на палитре Interaction Operand и добавьте к фрагменту снизу). По умолчанию операнды получают пустые сторожевые условия. Ввести нужные условия следует, выделив операнд взаимодействия на диаграмме и заполнив поле Guard на вкладке Element. Добавим сообщения от контроллера к CourseCatalogSystem и от него к Каталогу курсов. Нарисуем в нижнем операнде взаимодействия возврат (Reply Message) и рефлексивное сообщение для вывода предупреждения об ошибке. Диаграмма примет вид, схожий с рисунком 4.2.3. Не забудьте создать операции //connectWithCatalog() и //displayError() и связать их с сообщениями. Для startSession создавать операцию не следует, достаточно только указать имя сообщения.

Рис. 4.2.3. Диаграмма Basic flow с добавленным фрагментом взаимодействия

      Рис. 4.2.3. Диаграмма Basic flow с добавленным фрагментом взаимодействия

      Сообщения-возвраты (Reply Message) от каталога курсов, граничного объекта, обеспечивающего связь с ним, и объекта-контроллера изображены на диаграмме явно. Для экономии места на диаграммах возвраты можно не указывать, однако, их подразумевают для всех синхронных сообщений. Далее возвраты мы будет удалять с диаграмм.

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

      Если связь установлена, форма высвечивает доступные студенту действия с помощью рефлексивного сообщения //displayPossibleOperations. Для моделирования вариантов продолжения потока событий создадим внутри операнда взаимодействия вложенный комбинированный фрагмент. Укажем его тип (Alternative). Добавим ещё три операнда взаимодействия в созданный комбинированный фрагмент. Добавим операндам сторожевые условия.

      По окончании работы открытую сессию связи с каталогом курсов следует закрыть. Добавим внутри верхнего операнда взаимодействия второго по порядку комбинированного фрагмента спецификацию выполнения на линию жизни RegistrationController. Поместим сообщение //disconnectWithCatalog от контроллера экземпляру CourseCatalogSystem, создадим соответствующую операцию и свяжем сообщение с её вызовом. Добавим сообщение closeSession от экземпляра CourseCatalogSystem к экземпляру действующего лица Каталог курсов. Создавать операцию closeSession действующему лицу не нужно, достаточно просто ввести имя сообщения. Получившаяся диаграмма представлена на рисунке 4.2.4.

Рис. 4.2.4. Диаграмма Basic flow в ходе редактирования

      Рис. 4.2.4. Диаграмма Basic flow в ходе редактирования

      Внутри каждого их четырёх операндов комбинированного фрагмента будет происходить одно из взаимодействий, соответствующих четырём подчинённым потокам варианта использования. Чтобы не загромождать диаграмму основного потока для каждого подчинённого потока создаётся отдельная диаграмма. На основной диаграмме будут размещены лишь ссылки на используемые взаимодействия. Выделим в браузере кооперацию locals внутри взаимодействия RegisterForCourses. Добавим кооперации новые элементы-взаимодействия (Interaction): Create Schedule subflow, Update Schedule subflow, Delete Schedule subflow, Submit Schedule subflow. В созданный нами последним комбинированный фрагмент взаимодействия с четырьмя операндами добавим по одному элементу Interaction Use в каждый операнд. Во вкладке Element для каждого Interaction Use заполним поле Refers to. Диаграмма примет окончательный вид, показанный на рисунке 4.2.5.

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

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

      Смоделируем один из подчинённых потоков Create Schedule subflow. Вид диаграммы, которая должна получиться, показан на рисунке 4.2.6. На диаграмме есть линии жизни экземпляра класса Student и экземпляра класса Schedule. Следует добавить новые роли -- currentStudent (экземпляр класса Student) и currentSchedule (экземпляр класса Schedule) в кооперацию locals внутри взаимодействия RegisterForCourses. На диаграмме использован комбинированный фрагмент с оператором opt (Optional), представляющий ветвление с единственной содержательной альтернативой, а также комбинированные фрагменты с оператором loop, описывающие циклы. Создавая циклы, следует задать в сторожевых условиях ограничения на количество итераций. Обратите внимание, что на рис. 4.2.6 есть сообщение //createScheduleWithOfferings, которое имеет тип Creation Message. Не забудьте добавить соответствующую операцию в класс Schedule и связать её вызов с сообщением. Если при создании сообщения Creation Message возникает ошибка, попробуйте удалить линию жизни, создать линию жизни при помощи элемента палитры Lifeline, добавить сообщение и лишь затем указать линии жизни роль, которую она представляет (currentSchedule:Schedule). Свяжите сообщение с операцией Schedule:://createScheduleWithOfferings().

Рис. 4.2.6 Диаграмма Create Schedule subflow

      Рис. 4.2.6. Диаграмма Create Schedule subflow

      Каждое сообщение на диаграмме последовательности назначает экземплярам классов обязанности по отправке или приёму и обработке сообщения. Для приёма сообщения в классе объекта-приёмника должна быть одноимённая операция. Для отправки сообщения между экземплярами классов должно быть соединение, т. е. между классами, экземпляры которых обмениваются сообщениями, должна быть ассоциация. На диаграмме 4.2.5. Basic flow форма отправляет сообщение //registerForCourses контроллеру. Значит, в классе RegistrationController должна быть одноимённая операция, которая обрабатывает сообщение от формы, а между классом-формой и классом контроллером должна быть ассоциация. Нарисуем её на диаграмме VOPC RegisterForCourses. Мощности полюсов этой ассоциации 1 к 1. Объект-контроллер посылает сообщения объекту граничного класса CourseCatalogSystem (см. рис. 4.2.5), экземпляру класса Student и экземпляру класса Schedule (см. рис. 4.2.6), следовательно, нужны ещё ассоциации между классами. Добавьте три ассоциации, соединяющие класс RegistrationController c CourseCatalogSystem (0..1 к 1), Student (0..1 к 0..1) и Schedule (0..1 к 0..1).

      Проверьте, что для каждого сообщения, принимаемого экземпляром любого класса (не действующего лица), существует связанная операция. Заметьте, что не следует дважды создавать операцию формы //displayError. Второе сообщение следует связать с ранее созданной операцией формы. На диаграмме VOPC RegisterForCourses отобразятся созданные операции. В результате классы должны выглядеть, как показано на рисунке 4.2.7.

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

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

      Добавьте новый атрибут классу CourseOffering -- numStudents. Отметьте атрибут CourseOffering:numStudents как выводимый (во вкладке Element отметьте Derived), поскольку его значение равно количеству планов-графиков, связанных с предлагаемым курсом. Так как студенты учатся на дневном и вечернем отделениях добавьте в пакет Analysis Model классы FullTimeStudent (студент очного отделения) и PartTimeStudent (студент вечернего отделения) -- наследники класса Student. Чтобы убедиться, что классы будут созданы в пакете Analysis Model следует создать их с помощью контекстного меню пакета Analysis Model в браузере. Если их создать с помощью палитры на диаграмме, классы будут помещены в пакет Use Case Realizations, являющийся родительским для диаграммы. Если классы созданы в неверном пакете, перетащите их в нужный пакет в браузере. Проведите на диаграмме связи обобщения (Generalization). Добавьте атрибуты классам наследникам (указываются только собственные атрибуты, унаследованные добавлять не следует). Так как мы моделируем классы анализа, типы атрибутов следует выбирать из набора стандартных типов UML (date, string). Диаграмма должна выглядеть как на рис. 4.2.7.

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

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

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

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


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

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

Упражнение 5.1. Проектирование архитектуры системы регистрации


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

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

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

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

      Следующие наши действия нацелены на трансформацию классов анализа в проектные элементы (классы, интерфейсы и подсистемы) и распределение проектных элементов по уровням системы. При трансформации простые классы анализа преобразуются в проектные классы один в один. Сложный класс анализа может преобразовываться в несколько связанных проектных классов или в подсистему. Сложным у нас является класс CatalogSystem -- преобразуем его в подсистему. Остальные классы анализа переведём в проектные один в один. Чтобы не испортить модель анализа, скопируем её содержимое внутрь проектной модели. В браузере выделите всё содержимое Analysis Model от пакета Use Case Realization до диаграммы Key Abstractions включительно (но не сам пакет). Нажмите Ctrl+C (или выберите в контекстном меню Copy Element). Выделите Design Model, нажмите Ctrl+V (Paste Element). Создайте в Design Model пакет Registration. В созданный пакет перетащите классы RegisterForCoursesForm и RegistrationController из корня проектной модели. Заметим, что стереотипы анализа в проектной модели смысла не имеют, их можно убрать. В пакете BusinessServices создайте пакеты UniversityArtefacts (т. е. артефакты университета, в нем разместим классы-сущности предметной области и их связи), пакет Interfaces (где будут находиться все интерфейсы), пакет CourseCatalogSystem со стереотипом <<subsystem>> (в него поместите одноименный класс). Классу CourseCatalogSystem назначьте стереотип <<subsystem proxy>> -- это означает, что он принимает все сообщения, идущие внутрь подсистемы. Диаграмму классов Key Abstractions перенесите в пакет UniversityArtefacts. В пакете Interfaces создайте интерфейс ICourseCatalogSystem и перенесите в него операции из класса CourseCatalogSystem. Структура проектной модели в браузере примет вид похожий на рис. 5.1.2.

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

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

      Создайте диаграмму классов Dependencies в пакете Registration. Разместите на ней пакеты Registration, Interfaces и UniversityArtefacts, укажите их зависимости (Package Import). Элементы пакета Registration используют классы-артефакты и интерфейс подсистемы, отсюда две зависимости. Диаграмма примет вид, представленный на рис. 5.1.3.

Рис. 5.1.3. Связи пакета Registration

      Рис. 5.1.3. Связи пакета Registration

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

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

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

      Моделировать структуру потоков управления системы не будем. Этот вопрос будет рассматриваться на лекции. Перечислим лишь виды процессов в нашей системе: StudentApplication -- пользовательский процесс рабочего места студента; ProfessorApplication -- пользовательский процесс рабочего места лектора; RegistrarApplication -- пользовательский процесс рабочего места регистратора; RegistrationProcess -- общий процесс, управляющий ходом регистрации; BillingAccess -- процесс обеспечивающий связь с расчётной системой; CourseCatalogAccess -- процесс, обеспечивающий связь с каталогом курсов. Последние два нужны для обеспечения эффективности, т. е. поддержки кэшей данных. Перейдём к моделированию конфигурации вычислительной среды. Вычислительная среда состоит из трёх типов узлов -- сред выполнения (Execution Environment) или процессоров, на которых могут быть размещены вложенные узлы-процессы (Process), и устройств (Device). Связи между узлами -- пути коммуникации -- являются подвидами ассоциации. Создайте диаграмму размещения Deployment View внутри одноимённого архитектурного представления. Узлы-процессы следует создавать, размещая их внутри родительского узла. Окончательный вид диаграммы приведён на рис. 5.1.5. Добавьте стереотипы, настройте отображение узлов (Node) в стилях диаграмм. Отметьте отображение внутренних элементов в виде диаграммы и отображение стереотипов в виде текста или текста с пиктограммой. По получившейся диаграмме можно судить, что в среде есть сервер регистрации, к которому подключён принтер и рабочие станции трёх типов. Также на диаграмме указаны два унаследованных узла -- узел каталога курсов и узел расчётной системы, подключённые к серверу регистрации.

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

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

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

Упражнение 5.2. Проектирование элементов системы регистрации


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

      Проектные реализации вариантов использования являются более полными, чем реализации, созданные в ходе анализа. В них вместо экземпляров классов анализа должны присутствовать экземпляры проектных классов и интерфейсов, т. е. должны быть учтены трансформации классов анализа в проектные элементы. Проведём уточнение реализаций вариантов использования. Откроем диаграмму последовательности Basic flow из взаимодействия RegisterForCourses в пакете Logical View::Design Model::Use Case Realizations.

      На диаграммах Basic flow и Create Schedule subflow следует объект класса CourseCatalogSystem заменить на объект, реализующий интерфейс ICourseCatalogSystem. Для этого измените у кооперации внутри взаимодействия RegisterForCourses из проектной модели тип роли catsys:CourseCatalogSystem на ICourseCatalogSystem (вкладка Element, поле Base). Тем самым мы показываем, что здесь происходит обращение к экземпляру класса, реализующему интерфейс подсистемы. Какой именно это будет класс -- это для реализации варианта использования неважно. Реализация не определяет, как подсистема CourseCatalogSystem должна обрабатывать такой вызов. Эта часть относится к проектированию подсистемы и может варьироваться в зависимости от реализации подсистемы. Внутреннее поведение подсистемы скрыто, чтобы обеспечить возможность лёгкой модификации её реализации. Исходя из сказанного, уберём с диаграммы и из модели экземпляр действующего лица Каталог курсов и сообщения, идущие к нему. Сообщения, принимаемые объектом, реализующим интерфейс ICourseCatalogSystem, должны быть связаны с операциями интерфейса ICourseCatalogSystem:://getCourseOfferings(), ICourseCatalogSystem:://connectWithCatalog() и ICourseCatalogSystem:://disconnectWithCatalog(). Если в Вашей модели эти операции отсутствуют, в браузере скопируйте их из класса CourseCatalogSystem в интерфейс. Диаграмма Basic flow примет вид, представленный на рисунке 5.2.1. На диаграмме Create Schedule subflow произойдут схожие изменения (см. рис. 5.2.2).

Рис. 5.2.1. Уточнённая диаграмма Basic flow

      Рис. 5.2.1. Уточнённая диаграмма Basic flow

Рис. 5.2.2. Уточнённая диаграмма Create Schedule subflow

      Рис. 5.2.2. Уточнённая диаграмма Create Schedule subflow

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

      Подсистема пока содержит один класс со стереотипом <<subsystem proxy>>. Класс отвечает за реализацию интерфейса подсистемы. Объекты этого класса будут принимать и обрабатывать все входящие сообщения. Класс создаётся для удобства тестирования сопряжений при сборке системы. При реализации подсистемы мы воспользуемся механизмом RDBMS-JDBC из одноимённого пакета. При использовании механизма следует создать элемент модели Collaboration (кооперацию) с именем ICCSystem внутри подсистемы. Эта кооперация будет построена по шаблону проектного механизма, который является параметризованной кооперацией. Для каждого параметра шаблона RDBMS-JDBC нам понадобится указать соответствующий проектный класс. Мы собираемся подставить класс CourseCatalogSystem вместо DBClass, CourseOffering -- PersistentClass, CourseOfferingList -- PersistentClassList.

      Создайте интерфейс CourseOfferingList в пакете UniversityArtefacts. Внутри него создайте вложенный элемент -- конкретизацию шаблона (Template Instanciation). Укажите конкретизируемый шаблон -- интерфейс List<E> из пакета java.util (вкладка Element, поле Instanciated template). В качестве параметра E укажите класс CourseOffering из пакета UniversityArtefacts. Создайте в подсистеме CourseCatalogSystem кооперацию IССSystem со стереотипом «interface realization». Если стереотип отсутствует в проекте, создайте его с помощью контекстного меню. Внутри кооперации IССSystem создайте вложенный элемент -- конкретизацию шаблона RDBMS-JDBC. Укажите подставляемые параметры CourseCatalogSystem вместо DBClass, CourseOffering -- PersistentClass, CourseOfferingList -- PersistentClassList. Создайте внутри кооперации диаграмму составной структуры (Composite Structure diagram) Main. Перетащите на неё кооперацию IССSystem и кооперацию RDBMS-JDBC, также перетащите конкретизацию шаблона. Получившаяся диаграмма изображена на рис. 5.2.3.

Рис. 5.2.3. Диаграмма составной структуры Main

      Рис. 5.2.3. Диаграмма составной структуры Main

       Внутрь кооперации-реализации интерфейса ICourseCatalogSystem скопируйте из механизма роли drMan:DriverManager и l:PersistentClassList, а также три взаимодействия Initialize, Read и Disconnect. Взаимодействие Initialize (и диаграмму внутри него) переименуйте в connectWithCatalog, Read -- в getCourseOfferings, Disconnect -- в disconnectWithCatalog. Замените классы у всех ролей. Вместо DBClass укажите CourseCatalogSystem, вместо PersistentClass -- CourseOffering, вместо PersistentClassList -- CourseOfferingList. Теперь создайте внутри подсистемы CourseCatalogSystem диаграмму классов CourseCatalogSystem. Поместите на неё интерфейс ICourseCatalogSystem из пакета Interfaces. Поместите прокси-класс CourseCatalogSystem. Проведите связь реализации (InterfaceRealization) от прокси-класса к интерфейсу. Перенесите на диаграмму классов CourseCatalogSystem классы CourseOffering и CourseOfferingList. Также поступите с классом DriverManager, интерфейсами Connection, Statement, ResultSet из пакета java.sql, со связями между ними и с интерфейсом List из пакета java.util. Удалите слэши из названий операций интерфейса. Добавьте операции getCourseOfferings параметр-результат типа CourseOfferingList. Скопируйте все операции интерфейса в класс CourseCatalogSystem. Поскольку на диаграмме последовательности Read из механизма роль l:PersistentClassList получает сообщение add(obj), добавьте интерфейсу CourseOfferingList операцию add(e:CourseOffering) (её можно скопировать из интерфейса List и заменить класс у параметра). Добавьте зависимости от CourseCatalogSystem ко всем элементам диаграммы, кроме интерфейса подсистемы. Наличие этих зависимостей следует из взаимодействий, описанных диаграммами последовательности из кооперации-механизма RDBMS-JDBC. В результате, диаграмма классов и структура подсистемы должны быть похожи на изображённые на рисунках.

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

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

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

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

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

      На диаграмме последовательности внутри взаимодействия сonnectWithCatalog левая линия жизни должна представлять объект db:CourseCatalogSystem, входящее сообщение принимаемое им свяжите с операцией connectWithCatalog. Диаграмма примет вид, изображённый на рисунке 5.2.6.

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

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

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

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

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

      На диаграмме последовательности getCourseOfferings (бывшей Read) левая линия жизни должна представлять объект CourseCatalogSystem, самая правая линия жизни -- объект CourseOfferingList, а вторая справа -- CourseOffering. Свяжите найденное сообщение, принимаемое экземпляром CourseCatalogSystem, с операцией getCourseOffering. Добавьте классу CourseOffering новую операцию setData(number:int, day:byte, pair:byte). Свяжите с ней второе снизу сообщение на диаграмме последовательности. Самое нижнее сообщение свяжите с операцией add(e:CourseOffering). Удалите вложенный цикл. Замените сообщение getString на getInt, добавьте два сообщения getByte. Аргументы вызова задаются на вкладке Element в поле Argument. Диаграмма примет вид, изображённый на рисунке 5.2.8.

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

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

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

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

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

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

      Рассмотрим проектирование классов на примере системы регистрации. Создайте в пакете UniversityArtefacts диаграмму классов Student. Поместите классы Student, FullTimeStudent и PartTimeStudent, а также связи обобщения между ними на диаграмму. Добавьте и уточните его атрибуты и операции, чтобы придать ему вид, схожий с рисунком 5.2.9. Статические (подчёркнутые) атрибуты и операции пометьте специальным флажком (вкладка Element, поле Class). Типы long, int, boolean и String используйте из пакета java.lang, Date -- из java.util.

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

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

      Экземпляры класса CourseOffering должны по-разному обрабатывать вызовы операции addStudent в зависимости от того, отменен курс или нет, и в зависимости от количества уже зарегистрировавшихся студентов. Это признак сложного поведения и причина для создания диаграммы состояний. Добавьте классу CourseOffering диаграмму состояний LifeCycle (контекстное меню, Create diagram -> Create a State Machine Diagram). Создайте на диаграмме начальное состояние (Initial State), финальное состояние (Final State), состояния Open, Closed, Canceled и псевдосостояние выбора (Choice). Соедините состояния переходами, как указано на рисунке 5.2.10.

      Создайте в элементе State Machine, автоматически созданном при добавлении диаграммы состояний, события addStudent, removeStudent, delete, close, cancel и when(numStudents==10). Укажите типы событий (вкладка Element, поле Kind). Типы всех событий, кроме последнего -- события вызова (Call). Тип последнего события -- событие изменения (Change). Создайте в классе CourseOffering операции: addStudent(sch: Schedule), removeStudent(sch: Schedule), cancel(), close(), delete(). Свяжите одноимённые операции и события вызова (вкладка Element, поле Called element). У события изменения укажите выражение, при наступлении истинности которого возникает событие: numStudents==10.

      Переходу может быть добавлено событие, указываемое до слэша, действие, указываемое после слэша, но перед "^", сторожевое условие, записываемое в прямоугольных скобках, и отправка сообщения, указываемая после "^". Для добавления переходу события-триггера во вкладке Element в поле Received event укажите подходящее событие. Некоторые события, такие как cancel и delete запускают переходы из разных состояний. Их не следует создавать дважды. Действия на переходах создаются в поле Expression of the action. Просто введите в поле нужный текст (тот, который идёт после слэша в надписи рядом с переходом). Обратите внимание, что в состоянии Canceled есть действие по выходу. Оно создаётся при помощи элемента палитры Internal Transition (внутренний переход). Укажите внутреннему переходу событие EXIT. Добавьте отправляемое событие вызова -- текст после "^" -- в поле Sent signal/events. Этим событием является вызов операции delete() у объекта roster -- экземпляра контейнера, хранящего графики студентов, которые записались на курс.

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

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

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

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

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

      Уточним связи между классами на диаграмме VOPC RegisterForCourses проектной реализации варианта использования Зарегистрироваться на курсы. Откройте диаграмму (Design Model -> Use Case Realization). Проверьте, изображены на диаграмме проектные классы или классы анализа. Присутствующие на диаграмме классы анализа следует замаскировать (Ctrl+M), а отсутствующие проектные классы и их связи переместить из браузера. Удалите из модели ассоциацию между проектными классами RegistrationController и CourseCatalogSystem. В проектной модели они напрямую не связаны, их разделяет/соединяет интерфейс ICourseCatalogSystem. Добавьте интерфейс ICourseCatalogSystem из браузера на диаграмму (см. рис. 5.2.12). Проведите уточнение связей. Зависимость (пунктирная стрелка) указывает на то, что класс RegistrationController использует интерфейс. RegistrationController хранит ссылку на объект с данными регистрирующегося студента и на текущее расписание (две агрегации -- Association type = Aggregation). Укажите направления ассоциаций (поле Navigable). Обратите внимание на двунаправленные ассоциации (со стрелкам на обоих концах). В плане-графике хранятся ссылки на курсы, включённые в него, и каждый курс хранит массив ссылок на планы-графики, в которые он включён.

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

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

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

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

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

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

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

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

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

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

      Если возникают трудности с добавлением стереотипа <<identifying>> связи между таблицами, попытайтесь применить следующие советы. Если стереотип присутствует в модели, но при его назначении связи возникает ошибка, удалите стереотип. Узнать, присутствует ли стереотип, можно, настроив браузер. В верхней строке браузера расположены пиктограммы (стрелки, домик, ...). Найдите пиктограмму со всплывающей подсказкой View Menu (треугольник с вершиной вниз). Нажмите её, Show Options -> Show MDA Model. В дереве проекта станет виден модуль LocalModule с профилем внутри. Откройте профиль для просмотра списка стереотипов. Если стереотипа в модели нет, с помощью пункта контекстного меню проекта (корневого элемента дерева проекта) Create stereotype создайте стереотип <<identifying>> для метакласса Feature. После этого может получиться добавить стереотип связи. Если не получилось, экспортируйте проект в архив и вышлите на электронную почту по адресу, указанному внизу страницы.

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

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


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

  

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

Обновлено: 6.12.2013