|
Дополнительная спецификация определяет нефункциональные требования к системе, такие,
как надежность, удобство использования, производительность, сопровождаемость, а также ряд функциональных требований, являющихся общими для нескольких вариантов использования. Назначение дополнительных спецификаций -- определить требования к системе регистрации курсов, которые не отражены в других документах и моделях. Вместе они образуют полный набор требований к системе. Рассмотрим дополнительную спецификацию:
Функциональные возможности
Система должна обеспечивать многопользовательский режим работы. Если конкретный курс оказывается заполненным в то время, когда студент формирует свой план-график, включающий данный курс, то система должна известить его об этом.
Система должна обеспечивать выполнение следующих правил:
Студент может регистрироваться на курс только в том случае, если им выполнены требования к предварительному уровню подготовки.
На каждый курс может записаться не более 10 и не менее 3 студентов.
На процесс регистрации отводится две недели.
Курс считается отменённым по окончании регистрации, если на него записалось менее 3 студентов. И т. п.
Требования по реализации
Система должна быть совместима с Windows.
Надёжность
Система должна быть в работоспособном состоянии 24 часа в день 7 дней в неделю, время простоя -- не более 10%.
Производительность
Система должна поддерживать до 2000 одновременно работающих пользователей.
Безопасность
Система не должна позволять студентам изменять какие-либо планы-графики,
кроме своих собственных (за текущий семестр), а также не должна позволять профессорам
выбирать для чтения предлагаемые курсы лекций, уже выбранные другими профессорами.
Только профессора имеют право ставить студентам оценки только за те курсы, которые они читают.
Только регистратор может изменять любую информацию о студентах, профессорах, учебных курсах.
Проектные ограничения
Система должна поддерживать протокол обмена данных с расчётной системой.
Функциональные требования к системе моделируются и документируются с помощью вариантов использования (use case). Вариант использования (use case) -- связный элемент функциональности, предоставляемый системой при взаимодействии с действующими лицами, и соответствующий цели некоторого действующего лица. Действующее лицо (actor) -- роль, обобщение элементов внешнего окружения системы, ведущих себя по отношению к системе одинаковым образом.
В контексте процесса управления требованиями варианты использования трактуются следующим образом:
вариант использования фиксирует соглашение между участниками проекта относительно поведения системы;
вариант использования описывает поведение системы при различных условиях, когда система отвечает на запрос одного из участников, называемого основным действующим лицом;
основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели. Система отвечает, соблюдая интересы всех действующих лиц.
Модель вариантов использования состоит из диаграмм вариантов использования, текстовых описаний вариантов использования и диаграмм деятельности, моделирующих потоки событий вариантов использования. Диаграмма вариантов использования составляется системным аналитиком, который сначала выявляет элементы модели, а затем устанавливает связи между ними. Элементами диаграмм вариантов использования являются варианты использования и действующие лица, соединённые разного рода связями.
Из постановки задачи разработки и глоссария системный аналитик может выделить список действующих лиц и их интересов:
Студент -- регистрируется на курсы, смотрит свой табель;
Профессор -- выбирает курсы для преподавания, ставит оценки;
Регистратор -- управляет процессом регистрации, ведёт (т. е. вводит, изменяет, удаляет) данные о профессорах и студентах;
Расчётная система -- получает данные, нужные для формирования счетов за обучение.
|
|
Упражнение 3.1. Создание действующих лиц
|
1. В Model Explorer найдите пакет Use Case View, а внутри него модель Use Case Model. В модели находится диаграмма вариантов использования Main. Откройте её двойным кликом. Диаграмма пуста. Заполним её. В палитре найдите элемент System. Нажмите на него. Затем поместите курсор на диаграмму и кликните. Система появится на диаграмме. Назовите добавленный элемент "Система регистрации на курсы". Этим элементом в модели представляется рамка моделируемой программной системы. С помощью контекстного меню добавьте системе стереотип <<subject>>. В палитре редактора выберите элемент Actor и добавьте действующее лицо на диаграмму. Введите имя актора: Студент. Повторите те же действия и добавьте оставшихся действующих лиц: профессора, регистратора и расчётную систему. Увеличьте размеры элемента System, чтобы в дальнейшем он вместил варианты использования системы. Получившаяся диаграмма примет вид, показанный на рисунке 3.1.1.
Рис. 3.1.1. Окно среды после создания диаграммы вариантов использования.
Исходя из потребностей действующих лиц, системный аналитик может предложить следующие варианты использования: Войти в систему, Зарегистрироваться на курсы, Просмотреть табель, Выбрать читаемые курсы, Поставить оценки, Открыть регистрацию, Закрыть регистрацию, CRUD данных о профессорах, CRUD данных о студентах. CRUD рашифровывается как Create, Read, Update, Delete (или как Create, Retrieve, Update, Destroy). Предполагается, что вариант использования «CRUD данных о профессорах» описывает все функции системы, предоставляемые регистратору для управления сведениями о профессорах.
Вариант использования «Войти в систему» не соответствует какой-либо явной цели какого-нибудь действующего лица. Он описывает функциональные требования к системе по обеспечению защиты данных. Про каждого своего пользователя система должна знать, какую роль по отношению к ней он выполняет: студента, профессора или регистратора, к каким функциям и данным ему можно предоставлять доступ.
|
|
Упражнение 3.2. Создание вариантов использования
|
Рис. 3.2.1. Диаграмма вариантов использования для системы регистрации.
1. В палитре редактора выберем элемент Use Case и добавим вариант использования на диаграмму (внутрь System). Введём название: «Зарегистрироваться на курсы». Повторим те же действия для добавления оставшихся вариантов использования: Войти в систему, Просмотреть табель, Выбрать читаемые курсы, Поставить оценки, CRUD данных о профессорах, CRUD данных о студентах, CRUD данных о курсах, Открыть регистрацию, Закрыть регистрацию. Размещаем варианты примерно так, как показано на рисунке 3.2.1.
2. В палитре редактора выберем ассоциацию Association и проведём её от действующего лица Студент к варианту использования »Зарегистрироваться на курсы». Чтобы было видно направление связи, вызовем контекстное меню у левого конца ассоциации и выберем пункт Navigable. Установим флажок на значении Unspecified. По умолчанию связь была двунаправленная, теперь же она явно указывает, направление от действующего лица к варианту использования.
3. Повторим те же действия для добавления связей других действующих лиц и вариантов использования. Получившаяся диаграмма изображена на рис. 3.2.1. Направления связей между действующими лицами и вариантами использования показывают, какое лицо является основным, а какое второстепенным. Для варианта использования Закрыть регистрацию актор Регистратор -- основное действующее лицо (он инициирует запуск варианта использования), а Расчётная система -- второстепенное действующее лицо (в ходе работы в неё передаются данные для формирования счетов за обучение студентов).
4. Созданная диаграмма имеет недостаток в том, что у варианта использования «Войти в систему» несколько основных действующих лиц. Полагая поведение системы одинаковым при входе любого пользователя, введём абстрактное действующее лицо Пользователь, подвидами которого будут лица Студент, Профессор, Регистратор. Указать, что действующее лицо абстрактное, нужно в спецификации (контекстное меню -> Open specification) на вкладке General, поставив флаг в поле Abstract. Диаграмма примет вид, изображённый на рисунке 3.2.2. Для добавления связей обобщения используйте связь обобщения (Generalization). Лишние ассоциации удалите из модели (Del). Обратите внимание, что следует удалить элемент и с диаграммы и из модели. Если необходимо сохранить элемент в модели и всего лишь убрать его с диаграммы, на которую он случайно попал по какой-то причине, используйте пункт контекстного меню Delete -> Delete View Only. Следует чётко понимать удаляете ли Вы текущий элемент или всего лишь убираете с диаграммы, оставляя в модели (маскируете). Удаление вместо маскирования (как и обратное) может быть нежелательным. Случайно удалённый элемент можно попытаться восстановить, нажав Ctrl+Z. Маскированный по ошибке элемент можно снова поместить на диаграмму, перетаскивая его из Model Explorer. Чтобы связи отображались в Model Explorer, осуществите его настройку: вызовите контекстное меню на белом поле Model Explorer и отметьте флажками Show Relationships.
Рис. 3.2.2. Модифицированная диаграмма вариантов использования
Теперь на нашей диаграмме каждый вариант использования связан ровно с одним действующим лицом, которое для него является основным, и с произвольным количеством дополнительных действующих лиц. Каждое действующее лицо связано хотя бы с одним вариантом использования. Никакие два варианта использования между собой не связаны ассоциацией. Связи между вариантами использования допускаются, если они имеют тип, отличный от ассоциации. Это могут быть связи обобщения, включения и расширения. О них рассказывается на лекциях. Системный аналитик с их помощью производит структурирование модели вариантов использования. Модель с большим количеством вариантов использования может быть разбита им на части -- пакеты. Никакие действующие лица не связаны между собой ассоциацией. Между ними допускаются лишь связи обобщения. Самостоятельно создавая диаграммы вариантов использования, старайтесь, чтобы их элементы и связи удовлетворяли таким же ограничениям. Также рекомендуется основных действующих лиц размещать в левой части диаграммы, а второстепенных -- на правой.
Получившаяся диаграмма является примерным оглавлением проекта. Мы видим, какие функции и кому предоставляет система. По ней архитектор проекта может составить оценку трудоёмкости всего проекта, основанную на прогнозируемой трудоёмкости реализации каждого из вариантов использования. Также архитектор ранжирует варианты использования по приоритету. Отмеченные им более важные варианты использования будут реализованы в первую очередь.
Для каждого варианта использования составляется описание. Выполняют эту работу use case писатели.
|
|
Упражнение 3.3. Добавление описаний вариантов использования
|
Функциональные требования подробно фиксируются в описаниях вариантов использования. Описания составляются специальным образом, чтобы уменьшить вероятность неверного толкования и облегчить восприятие текста. Каждое описание включает в себя:
а) краткое описание, являющееся сжатым обзором варианта использования;
б) основной поток событий, описывающий взаимодействие системы и действующих лиц, при котором достигается цель основного действующего лица;
в) альтернативные потоки, описывающие обработку ошибок и исключительных ситуаций;
г) подчинённые потоки, которые облегчают описание основного и альтернативных потоков;
д) предусловия (которые могут отсутствовать) и постусловия (которые всегда есть).
Каждый поток событий задаётся перенумерованным набором шагов. Используются шаги трёх типов: действие системы (например, «Система запрашивает имя пользователя и пароль»); реакция действующего лица («Пользователь вводит имя и пароль»); управление потоком («Выполнение переходит на начало основного потока»). Структура предложений, описывающих шаги, одинакова: подлежащее, сказуемое и прочее. От неё отходят лишь при описании циклов и ветвлений.
Цикл задаётся составным описанием, в начале которого указывается условие цикла («Для каждого незафиксированного курса в плане-графике выполняется») или количество повторений. Далее следует тело цикла -- последовательность вложенных шагов (см. подчинённый поток «8Г. Утвердить график» варианта использования «Зарегистрироваться на курсы»).
Ветвление в тривиальных случаях, когда альтернативная ветвь пуста, допускается описывать предложением с союзом если («Система помечает курс как закрытый, если в списке студентов содержится 10 записей»). Чаще ветвление описывают с помощью альтернативных потоков. В основном потоке варианта использования «Войти в систему» 3-ий шаг указывает основное продолжение потока, а альтернативный поток «3А. Неправильное имя/пароль» содержит второй вариант развития событий. Почти всегда действия по проверке условия ветвления не описывают. Вместо этого указывается шаг на котором система (или действующее лицо) подтверждает, что условие выполнено, в основном потоке, или обнаруживает, что условие нарушено, в альтернативном потоке.
Добавьте в модель описания, приведённые ниже. Для этого скопируйте текст описания, выделите нужный вариант использования, откройте его спецификацию и на вкладке General вставьте текст в поле Description. Обратите внимание, что в описании любого варианта использования должен присутствовать хотя бы один шаг для каждого действующего лица, связанного с ним. Постусловие в описании не может отсутствовать, так как по нему тестировщики составляют тестовые сценарии. Постусловие состоит из двух частей: гарантии успеха и минимальных гарантий. Первая часть описывает, что должно быть истинно при успешном завершении варианта использования. Вторая часть -- это гарантии системы в случаях неуспеха. Например, при успешном входе в систему гарантируется доступ пользователя к главному меню, при неуспешном -- гарантируется, что такой доступ не будет предоставлен. Пустое постусловие допускало бы произвольное поведение системы и было бы не пригодно для тестирования.
В реальном рабочем процессе описания составляются для всех вариантов использования. Выполняя упражнения, мы создадим лишь три описания.
Вариант использования «Войти в систему»:
Краткое описание
Данный вариант использования описывает вход пользователя в систему регистрации курсов.
Основной поток событий
1. Пользователь запускает приложение.
2. Система запрашивает имя пользователя и пароль.
3. Пользователь вводит имя и пароль.
4. Система подтверждает правильность имени и пароля.
5. Система определяет тип пользователя (студент, профессор или регистратор) и выводит главное меню, дающее доступ к её функциям в соответствии с типом пользователя.
Альтернативные потоки
4А. Неправильное имя/пароль
1. Система обнаруживает, что комбинация имени и пароля не верна.
2. Система сообщает об ошибке и предлагает пользователю либо заново ввести имя и пароль, либо отказаться
от входа в систему.
3. Пользователь сообщает системе свой выбор.
4. В соответствии с выбором пользователя либо выполнение переходит шаг 2 основного потока, либо вариант использования завершается.
Предусловия
Отсутствуют.
Постусловия
Если вариант использования выполнен успешно, система предоставляет доступ к главному меню пользователю, сообщившему верную комбинацию имени и пароля. В противном случае система гарантирует, что пользователю, сообщившему неверную комбинацию имени и пароля, доступ к меню не будет предоставлен.
Обратите внимание на номера альтернативных потоков. Цифра указывает номер шага основного потока, на котором может произойти переключение на альтернативный поток, буква позволяет различить несколько альтернативных потоков, на которые можно переключиться на одном и том же шаге. Если переход на альтернативный поток может происходить в течение нескольких подряд идущих шагов, указывают их номера через дефис (например, 1-3Б). Если поток вызывается из разных шагов, он может иметь несколько номеров, перечисленных через запятую.
Вариант использования «Зарегистрироваться на курсы»:
Краткое описание
Данный вариант использования позволяет студенту зарегистрироваться на
конкретные курсы в текущем семестре. Студент может изменить свой выбор
(обновить список курсов в своём плане-графике или удалить курсы из плана-графика), если изменение выполняется в установленное
время в начале семестра.
Основной поток событий
1. Студент сообщает о желании зарегистрироваться на курсы.
2. Система подтверждает, что регистрация на курсы в текущем семестре открыта.
3. Система выводит перечень доступных действий и предлагает студенту выбрать одно из них.
4. Студент сообщает системе свой выбор.
5. Согласно выбору студента выполняется один из подчинённых потоков (создать, обновить, удалить или утвердить график).
6. Вариант использования завершается.
Подчинённые потоки событий:
5А. Создать график
1. Система подтверждает, что у студента отсутствует план-график на текущий семестр.
2. Система выводит пустой план-график.
3. Студент запрашивает список предлагаемых курсов.
4. Система выводит список предлагаемых курсов.
5. Студент выбирает из списка четыре основных курса и два альтернативных курса.
6. Система создаёт график студента и заносит в него выбранные курсы, помечая их как незафиксированные.
7. Система сообщает, что создание графика завершено.
5Б. Обновить график
1. Система подтверждает наличие текущего плана-графика студента и выводит его.
2. Студент запрашивает список предлагаемых курсов.
3. Система выводит список предлагаемых курсов.
4. Студент обновляет свой выбор курсов, удаляя или добавляя конкретные курсы.
5. Система обновляет график в соответствии с пожеланиями студента. Для каждого зафиксированного курса, удалённого из графика, система удаляет студента из списка студентов, записавшихся на курс. Каждый добавленный курс система помечает как незафиксированный.
6. Система сообщает, что обновление графика завершено.
5В. Удалить график
1. Система подтверждает наличие текущего плана-графика студента и выводит его.
2. Система запрашивает у студента подтверждения удаления графика.
3. Студент подтверждает удаление.
4. Система удаляет график. Для каждого зафиксированного курса из удаляемого графика, система удаляет студента из списка студентов, записавшихся на курс.
5. Система сообщает, что удаление графика завершено.
5Г. Утвердить график
1. Система подтверждает наличие текущего плана-графика студента.
2. Для каждого незафиксированного курса в графике выполняется:
2.1. Система подтверждает выполнение студентом предварительных требований (прохождение определённых курсов), и подтверждает, что курс открыт для регистрации, и отсутствуют конфликты (в графике не должно быть зафиксированного курса, читаемого в тот же день и на той же паре, что и проверяемый курс).
2.2. Система добавляет студента в список записавшихся на курс.
2.3. Система помечает курс в графике как зафиксированный.
2.4. Система помечает курс как закрытый, если в списке студентов содержится 10 записей.
3. Система сообщает студенту результаты утверждения графика.
Альтернативные потоки
2А. Регистрация на курсы закрыта
1. Система обнаруживает, что регистрация на курсы в текущем семестре закрыта.
2. Система выдаёт сообщение об ошибке.
3. Вариант использования завершается.
5Г.2.1А. Не выполнены предварительные требования, курс заполнен, или имеют место конфликты графика
1. Система обнаруживает, что студент не выполнил необходимые предварительные
требования, или выбранный им конкретный курс заполнен, или имеют место
конфликты графика.
2. Система выдаёт сообщение об ошибке.
3. Система переходит к следующему незафиксированному курсу и продолжает выполнение потока «Утвердить график»
5Б.1А, 5В.1А, 5Г.1А. График не найден
1. Система обнаруживает, что требуемое действие (обновить, удалить или утвердить график) нельзя выполнить, так как график студента на текущий семестр отсутствует.
2. Система выдаёт сообщение об ошибке.
3. Вариант использования завершается.
5А.1А. График найден
1. Система обнаруживает, что требуемое действие (создать график) нельзя выполнить, так как график студента на текущий семестр создан ранее.
2. Система выдаёт сообщение об ошибке.
3. Вариант использования завершается.
5В.3А. Удаление отменено
1. Студент отменяет удаление графика.
2. Вариант использования завершается.
Предусловия
Перед началом выполнения данного варианта использования студент должен войти в систему.
Постусловия
Если вариант использования завершится успешно, система
создаст, обновит, удалит или утвердит график студента в соответствии с выбором пользователя. В противном случае гарантируется что: при закрытой регистрации изменения в графики студентов не производятся; при утверждении графика студента игнорируются курсы, для которых не выполнены предварительные требования, а также закрытые курсы, и курсы, вызывающие конфликты в графике; при отсутствии графика на текущий семестр его обновление, удаление или утверждение не производится; при наличии графика на текущий семестр добавление ещё одного графика не производится.
Вариант использования «Закрыть регистрацию»:
Краткое описание
Данный вариант использования позволяет регистратору закрывать процесс
регистрации. Конкретные курсы, на которые не записалось достаточного
количества студентов (менее трёх), отменяются. В расчётную систему
передаётся информация о каждом студенте по каждому конкретному курсу,
чтобы студенты могли внести оплату за курсы.
Основной поток событий
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. Система вычёркивает его из всех графиков и переходит к следующему открытому курсу.
4. Продолжается выполнение основного потока с шага 5.
7А. Расчётная система недоступна
1. Система ожидает некоторое установленное время.
2. Выполнение передаётся на шаг 6 основного потока.
Предусловия
Перед началом выполнения данного варианта использования регистратор должен войти в систему.
Постусловия
Если вариант использования завершится успешно, регистрация закрывается, графики студентов передаются в расчётную систему. В противном случае регистрация остаётся открытой.
|
|
Упражнение 3.4. Построение диаграмм деятельности в модели вариантов использования
|
Все потоки событий одного варианта использования, взаимосвязанные сценарии двух и более вариантов использования или отдельный поток событий могут быть смоделированы на диаграммах деятельности. Построим диаграмму деятельности для варианта использования «Войти в систему».
1. В браузере вызываем контекстное меню варианта использования «Войти в систему» и выбираем Subdiagrams -> New diagram. В открывшемся окне указываем тип создаваемой диаграммы: Activity diagram.
2. На появившейся в редакторе диаграмме создаём два раздела (Vertical Swimlane) -- Пользователь, Система регистрации на курсы -- каждый из которых обозначает область ответственности. Связываем каждый раздел с элементом модели, который он представляет, в окне спецификации на вкладке General в поле Represents (первый -- с актором Пользователь, второй с системой). Деятельности, соответствующие узлам, которые будут расположены в области ответственности пользователя, будут выполняться пользователем, остальные -- системой. Входной узел (Initial Node) помещаем в раздел Пользователь. Заметим, что если бы с вариантом использования были бы связаны два действующих лица, на диаграмме следовало бы создать три раздела (два для действующих лиц и один для системы).
3. Согласно описаниям потоков событий варианта использования создаём узлы действий (Action): Запустить приложение, Запросить логин и пароль; Ввести логин и пароль; Проверить логин и пароль; Сообщить об ошибке; Выбрать действие, Вывести меню. Узлы действий размещаем по разделам в соответствии с тем, кто выполняет действия.
4. Добавляем узлы логического ветвления (Decision Node). Соединяем узлы рёбрами потоков управления (Control Flow). Задать нетривиальные сторожевые условия можно, открыв спецификацию потока, на вкладке General в поле Guard.
5. Добавляем два финальных узла (Activity Final Node) с именами, указывающими на успешное и безуспешное окончание потоков событий. Вид получившейся диаграммы представлен на рис. 3.4.1.
Рис. 3.4.1. Диаграмма деятельности с ошибкой
Диаграмма деятельности задаёт потоки управления между узлами. Изначально курсор управления порождается во входном узле. Оттуда он передаётся по ребру на вход узла действия (Запустить приложение). Узел действия ждёт, когда курсоры управления придут на все входящие ребра, после чего запускается действие, а по окончании действия курсоры управления подаются на все исходящие ребра. Очевидно, наша диаграмма содержит ошибку. По второму ребру, входящему в узел действия Запросить логин и пароль, курсор управления придёт не раньше, чем этот же узел действия выдаст его на выход. Тупик. Чтобы исправить ошибку, добавим узел логического соединения (Merge Node), чтобы в узел действия входило одно ребро (и чтобы для выполнения действия требовался один входящий курсор). Узел логического соединения принимает курсор с любого входящего ребра и сразу передаёт его на исходящее ребро, которое у него одно. Исправленная диаграмма показана на рисунке 3.4.2.
Рис. 3.4.2. Исправленная диаграмма
Когда курсор попадает в узел логического ветвления, проверяются сторожевые условия на исходящих рёбрах этого узла. Исходящих рёбер может быть два и более. По одному из рёбер, на котором сторожевое условие истинно, курсор управления передаётся дальше. Если таких рёбер несколько -- произвольным образом выбирается одно. Если все сторожевые условия ложны, курсор не может быть передан дальше, поток управления заходит в тупик. Ситуация тупика считается ошибочной. Во избежание ошибок следует внимательно формулировать сторожевые условия. Рекомендуется делать их взаимоисключающими и покрывающими все возможные случаи. Часто используется условие [else], способствующее выполнению этих требований.
При попадании курсора управления в финальный узел (любой, по любому входящему потоку) вся деятельность прекращается. Уничтожаются все курсоры управления на всех рёбрах диаграммы. В случаях, когда требуется остановить один поток, оставив другие активными, применяется узел завершения потока (Flow Final Node), изображаемый кружком с крестиком.
Самостоятельно постройте диаграмму для варианта использования «Зарегистрироваться на курсы». Обратите внимание, что подчинённый поток может быть представлен на диаграмме в виде одного узла (см. узлы «Создать график», «Обновить график», «Удалить график», «Утвердить график»). Тип этих узлов -- Call Behavior Action (узел вызова действия). С каждым из них связана деятельность, которая может быть промоделирована отдельной диаграммой деятельности. При создании диаграммы следует сначала создать внутри варианта использования четыре деятельности (Activity): Создать график, Обновить график, Удалить график, Утвердить график. Затем разместите на диаграмме деятельности четыре узла действия (Action). В окне спецификации каждого созданного узла на вкладке General в поле Type укажите тип узла: Call Behaviour Action, после чего нажмите на кнопку с многоточием. В открывшемся окне следует выбрать подходящую деятельность. Обратите внимание, что если деятельности созданы в корне проекта, то следует перетащить их внутрь варианта использования «Зарегистрироваться на курсы» в браузере модели.
Рис. 3.4.3. Диаграмма деятельности варианта использования «Зарегистрироваться на курсы».
Моделирование требований следовало бы продолжить дальше, описав все варианты использования и построив для них диаграммы деятельности. Однако, не имеет смысла сразу описывать все требования. Работа осуществляется последовательными итерациями, в ходе которых составляются описания отдельных вариантов использования в порядке их важности. Когда описания важных вариантов использования составлены, выполняются работы по анализу и проектированию частей системы, реализующих их. Use case писатели приступают к работе над менее приоритетными вариантами использования во время последующих итераций, или занимаются ими на той же итерации, если они мало загружены во время анализа и проектирования. Следует быть готовыми к пересмотру требований в ходе проекта. Изменчивость требований обусловлена тем, что заказчики и будущие пользователи системы не могут сразу точно указать свои пожелания, и тем, что по ходу проекта разработчики лучше узнают предметную область и контекст системы. Из-за изменения требований переделываются описания вариантом использования, исправляются диаграммы деятельности.
Перейдём к анализу.
|
|
4. Анализ системы
|
При анализе системы производится трансформация требований в системный проект, создание эскизной архитектуры, соответствующей функциональным требованиям. Эскизная архитектура включает в себя набор ключевых абстракций, набор классов анализа, перечень механизмов анализа, иерархию уровней системы, реализации вариантов использования. В ходе жизненного цикла эскизная архитектура подлежит уточнению, на её основе создаётся проектная архитектура, учитывающая нефункциональные требования и подлежащая реализации в коде. Анализ нацелен на прояснение проблемы, решаемой в проекте, построение её решения, простого насколько это возможно, но удовлетворяющего функциональным требованиям.
Анализ разбивается на несколько итераций, в ходе которых выполняется анализ части вариантов использования. Работа ведётся в соответствии с приоритетом вариантов использования, самые важные анализируются в первую очередь. Результаты каждой итерации интегрируются в общую модель. При анализе последовательно выполняются два вида работ: архитектурный анализ и анализ вариантов использования. Исполнителями процесса анализа являются архитектор, разработчик. Обязанности архитектора состоят в координации и руководстве процессом, определении структуры каждого архитектурного представления, осуществлении архитектурного анализа. Обязанности разработчика включают анализ вариантов использования, определение обязанностей, поведения, свойств классов и связей между классами.
Архитектурный анализ выполняется архитектором и включает в себя следующие технологические операции:
Утверждение общих соглашений моделирования и документирования системы.
Формирование набора ключевых абстракций предметной области.
Соглашения моделирования фиксируются в документе «Руководящие указания по проектированию» (Design Guidelines). Они определяют: перечень используемых диаграмм и элементов модели; правила применения диаграмм; соглашения по именованию элементов модели; организацию модели (пакеты).
Будем придерживаться следующих соглашений:
Используются английские имена (поскольку на основе моделей могут быть получены заготовки кода, которые при использовании русских имён будут бесполезны).
Имена классов должны быть существительными, соответствующими, по возможности, понятиям предметной области.
Имена классов должны начинаться с заглавной буквы.
Имена атрибутов и операций должны начинаться со строчной буквы.
Составные имена должны быть сплошными, без подчёркиваний, каждое отдельное слово должно начинаться с заглавной буквы.
Модель анализа (Analysis Model) представляет собой пакет внутри логического архитектурного представления (Logical View). Внутри модели анализа помещается пакет Use Case Realizations, содержащий в себе все реализации вариантов использования. Также внутри модели создаётся диаграмма классов -- ключевых абстракций -- Key Abstractions.
Для реализации каждого варианта использования в модели должен быть создан отдельный пакет. В этом пакете должна быть создана кооперация, моделирующая реализацию варианта использования. Помимо кооперации пакет должен содержать диаграммы взаимодействия, описывающие базовый поток событий, а также альтернативные и подчинённые потоки событий. Кооперация -- это группа экземпляров классов или экземпляров интерфейсов, которые взаимодействуют, обеспечивая общее поведение (в нашем случае -- реализацию варианта использования). Кооперации должен быть назначен стереотип <<usecase realization>>.
Для каждого варианта использования должна быть создана диаграмма классов VOPC (View Of Participating Classes) внутри пакета с его реализацией его, изображающая классы, экземпляры которых участвуют в реализации.
|
|
Упражнение 4.1. Создание структуры модели в соответствии с соглашениями моделирования
|
Рис. 4.1.1. Структура модели анализа
1. В модели Analysis Model (модель анализа) создадим пакет Use Case Realizations. Для этого в браузере проекта вызовем контекстное меню меню пакета Analysis Model, Model Element -> Package (или Model Element -> New Model Element -> Model element type: Package).
2. В пакет Use Case Realizations добавим три вложенных пакета (Package) Login Realizations, RegisterForCourses Realization и CloseRegistration Realization (контекстное меню пакета Use Case Realizations -> Model Element -> New Model Element -> Model element type: Package). Внутри созданных пакетов создайте кооперации (Collaboration) Login, RegisterForCourses и CloseRegistration (контекстное меню пакета -> Model Element -> New Model Element -> Model element type: Collaboration). Назначим каждой созданной кооперации стереотип <<usecase realization>>. Каждая кооперация описывает сценарии одного из вариантов использования: Login -- Войти в систему, RegisterForCourses -- Зарегистрироваться на курсы, CloseRegistration -- Закрыть регистрацию. В пакете Use Case Realizations создадим диаграмму составной структуры (Composite Structure Diagram), на которой покажем связи между вариантами использования и их реализациями. Перетащим кооперации и варианты использования из браузера модели на диаграмму. Проведём от коопераций связи реализации к тем вариантам использования, которые они реализуют. Получившаяся диаграмма примет вид, показанный на рис. 4.1.2.
3. Внутри каждого пакета с реализацией создадим диаграмму последовательности Basic Flow (Basic Flow Login, Basic Flow RegisterForCourses, Basic Flow CloseRegistration) и диаграмму классов VOPC (VOPC Login, VOPC RegisterForCourses, VOPC CloseRegistration). Воспользуйтесь контекстным меню пакета -> Sub Diagrams -> New Diagram. Диаграммы Basic flow служат для моделирования реализации основных сценариев. VOPC это сокращение View Of Participating Classes. Назначение диаграмм VOPC -- отображение классов, участвующих в реализации варианта использования и связей между этими классами.
4. Создадим диаграмму классов Key Abstractions. Контекстное меню пакета Analysis Model-> Sub Diagrams -> New Diagram.
5. Дополнительно в пакет RegisterForCourses добавьте пять диаграмм последовательности, моделирующих подчинённые потоки: Create Schedule Subflow, DisplayCourseOfferings, Update Schedule Subflow, Delete Schedule Subflow, Submit Schedule Subflow.
Структура модели в браузере должна соответствовать рис. 4.1.1.
Рис. 4.1.2. Диаграмма составной структуры Use Case Realizations
Ключевые абстракции -- основные понятия предметной области -- архитектор выделяет, анализируя требования и пользуясь, глоссарием и моделью бизнес-анализа, если таковая была создана. Каждый термин из глоссария является кандидатом для того, чтобы быть трансформированным в класс ключевой абстракции (или в несколько классов, если структура данных, связанная с ним, слишком сложна для представления одним классом). Некоторые термины могут быть источником для атрибутов классов. В системе регистрации можно выделить следующие ключевые абстракции: Student (данные об учащемся), Schedule (план-график студента, которых у него может быть несколько разных в разных семестрах), CourseOffering (данные о курсе, читаемом в некотором семестре), Professor (данные о лекторе), Course (данные о курсе из учебного плана -- общие сведения об учебной дисциплине). Ассоциации между абстракциями описывают типичные соединения между экземплярами ключевых абстракций. Мощности у полюсов указывают ограничения на количество соединений у одного экземпляра. Обратите внимание на рефлексивную ассоциацию (см. рис. 4.1.3) класса Course, используемую для указания на курсы, которые следует прослушать до какого-либо курса. В обратную сторону связь может трактоваться как список курсов, которые можно прослушать после сдачи какого-либо курса. Полюсам рефлексивных связей следует давать имена, чтобы различать их роли. Также поступают при наличии двух ассоциаций между одной парой классов.
Рис. 4.1.3. Диаграмма ключевых абстракций
Предварительно настроим среду для более удобной работы. Меню Tools -> Project Options -> Diagraming. На вкладке Association отменим отображение уникальности (Show multiplicity constraints -- Unique). По умолчанию любая пара объектов, связывается не более чем одним соединением, являющимся экземпляром одной ассоциации. Если необходимо допустить повторные соединения, уникальность соединения следует отменить. Там же укажем необходимость явно выводить мощность полюса, равную 1 (снимите флажок Suppress implied "1" multiplicity). Перейдите к вкладке Class. Выберите вложенную вкладку Presentation. Снимите флажок отображения классов в виде пиктограмм стереотипов (Display as Robustness Analysis icon). Сохраняем настройки, закрываем окно настроек проекта.
1. Откроем диаграмму Key Abstractions. Выберем в палитре инструмент Class. Добавим классы Course, CourseOffering, Professor, Schedule, Student.
2. Добавим перечислимый тип DayOfWeek, используя Enumeration в выпадающем списке элемента палитры Class. Внутри DayOfWeek расположим значения перечислимого типа (enumeration literal): sunday, ..., saturday.
3. Выберем в палитре инструмент Association. Проведём ассоциации между классами. Укажем мощности у полюсов -- концов ассоциаций (контекстное меню полюса Multiplicity). Укажем, что связь между классами Student и Schedule -- композиция (контекстное меню полюса, Aggregation kind -> Composited).
4. Добавим атрибуты (Attribute) классов: классу Student -- address: string, name: string, phones: string[0..2]; классу Schedule -- semester; классу CourseOffering -- number, day: DayOfWeek; pair: byte; классу Professor -- name: string, academicDegree, phones: string[0..2]; классу Course -- description: string, duration.
5. Проведём зависимость (Dependency) от класса CourseOffering к перечислимому типу DayOfWeek. Эта связь указывает, что изменения в описании перечислимого типа могут отразиться на описании класса CourseOffering, так как один из его атрибутов имеет этот перечислимый тип.
6. Добавим всем классам-сущностям стереотип <<entity>>. Для этого выделим нужный класс в браузере, вызовем контекстное меню класса, Stereotype -> <<entity>>. В итоге диаграмма должна соответствовать рисунку 4.1.3.
Мы не указали типы всех атрибутов, не описали операции, направления всех связей. Дело в том, что нет необходимости сразу указывать все детали ключевых абстракций. Важно определить начальный набор классов, установить между ними связи, вытекающие из свойств предметной области, указать основные данные, хранимые в объектах. В ходе проекта возможности уточнить набор ключевых абстракций ещё представятся.
Мы готовы перейти к выполнению анализа вариантов использования. В технологии RUP он выполняется разработчиками и включает в себя следующие технологические операции:
Идентификацию классов, экземпляры которых участвуют в реализациях потоков событий (так называемых, классов анализа).
Определение обязанностей классов анализа, уточнение их атрибутов и связей.
Унификацию классов анализа, в ходе которой делается попытка упростить модель, исключая лишние классы, объединяя классы с общими обязанностями в один.
Классы анализа отражают функциональные требования к системе и моделируют типы объектов. Совокупность классов анализа представляет собой начальную концептуальную модель системы. Эта модель проста и позволяет сосредоточиться на реализации функциональных требований, не отвлекаясь на детали реализации, обеспечение эффективности и надёжности. Для решения этих вопросов впоследствии модель анализа будет трансформирована в проектную модель. В ходе анализа вариантов использования в их потоках событий выявляются классы трёх типов:
граничные классы (boundary classes), являющиеся посредниками при взаимодействии системы с действующими лицами и с аппаратной базой;
классы-сущности (entity classes), отвечающие за хранение данных;
управляющие классы (control classes), реализующие бизнес-логику и обеспечивающие координацию поведения объектов в системе.
Правило выделения граничных классов: для каждой связи между действующим лицом и вариантом использования создаётся или назначается граничный класс, отвечающий за данное взаимодействие. Правило выделения классов-сущностей: классы-сущности -- это, обычно, классы, представляющие ключевые абстракции системы.
Правило выделения управляющих классов: для каждого варианта использования создаётся ответственный за его реализацию класс управления.
Выполним анализ варианта использования «Зарегистрироваться на курсы».
|
|
Упражнение 4.2. Анализ варианта использования «Зарегистрироваться на курсы»
|
Выделим классы анализа. Согласно диаграмме вариантов использования имеется одно действующее лицо (Студент), связанное с нашим вариантом использования. Создадим граничный класс RegisterForCoursesForm -- экранную форму, отвечающую за взаимодействие со Студентом. В браузере вызовем контекстное меню пакета Analysis Model, Model Element -> Class. Дадим имя классу -- RegisterForCoursesForm. Тем же образом создадим управляющий класс RegistrationController, отвечающий за реализацию бизнес-логики (действия аналогичны). Добавим управляющий класс TransactionManager, отвечающий за сохранение данных об устойчивых объектах в базе данных нашей системы. Из описания варианта использования следует, что в потоках событий будут задействованы экземпляры классов Student, CourseOffering, Schedule. Открываем в редакторе диаграмму классов VOPC RegisterForCourses. Перетаскиваем на неё вышеупомянутые классы из браузера. Также перетаскиваем на диаграмму связи между классами-сущностями, участвующими в реализации варианта использования.
Назначим классам стереотипы. Выделите в браузере класс RegistrationController. С помощью контекстного меню добавьте стереотип <<control>>. Аналогично добавьте стереотип <<boundary>> граничному классу RegisterForCoursesForm, и стереотип <<control>> -- классу TransactionManager. Классам-сущностям Student, CourseOffering, Schedule назначьте стереотип <<entity>>, если не сделали этого ранее.
Вид диаграммы, которая должна получиться, изображён на рис. 4.2.1.
Рис. 4.2.1. Диаграмма VOPC RegisterForCourses
Распределение поведения, предусматриваемого вариантом использования, между классами анализа реализуется при построении диаграмм взаимодействия. На основе описания варианта использования для потоков событий (основного, альтернативных, подчинённых) строятся диаграммы взаимодействия -- диаграммы последовательности или коммуникативные диаграммы. Перейдём к моделированию потоков событий с помощью диаграмм последовательности.
Предварительно настроим среду для более удобной работы. Меню Tools -> Project Options -> Diagraming. На вкладке Interaction установите настройку Mark target lifeline stopped ... -- Yes и оставьте помеченными пункты: Show sequence number in Communication Diagram; Show message operation signature...; Show stereotype of message... . У остальных пунктов отметку уберите.
Откроем внутри пакета RegisterForCourses Realization диаграмму последовательности Basic Flow RegisterForCourses (основной поток варианта использования Зарегистрироваться на курсы). Добавим на диаграмму 4 линии жизни (Lifeline): линию жизни действующего лица Студент; menu -- экземпляр формы RegisterForCoursesForm; control: экземпляр класса RegistrationController; tm -- экземпляр класса TransactionManager. Проще всего добавлять линии жизни перенося действующее лицо и классы из браузера на диаграмму. При переносе класса укажем, что добавляется линия жизни. Добавим линиям жизни стереотипы. Заметим, что линию жизни объекта граничного класса следует расположить рядом с линией жизни, представляющей то действующее лицо, за общение с которыми отвечает граничный класс, а линии объектов контроллеров следует расположить в середине диаграммы. В правой части диаграммы располагают линии объектов-сущностей.
Выберем на палитре синхронное сообщение (Call Message) и проведём его от линии жизни актора Студент к линии жизни menu:RegisterForCoursesForm. Дадим имя сообщению registerForCourses. Создадим вызываемую операцию (контекстное меню сообщения -> Select Operation -> Create Operation "registerForCourses"). Добавим второе синхронное сообщение с тем же именем, которым форма извещает контроллер о выборе студента. Экземпляр контроллера должен проверить, можно ли выполнить запрошенное действие. Для этого он посылает сам себе рефлексивное сообщение (Self Message) isRegistrationOpened. Каждое сообщение экземпляру класса должно быть связано с операцией данного класса. Сообщения, получаемые экземплярами действующих лиц, связывать с операциями не следует. Всякий раз, добавляя сообщение, вызывающее новую операцию будем добавлять операцию в модель.
Далее есть два варианта развития событий. Либо регистрация закрыта, и экземпляр контроллера возвращает неудачу, а экземпляр формы выводит сообщение об ошибке, посылая самому себе сообщение displayError, либо регистрация открыта и происходит содержательное взаимодействие. Сообщение-возврат (Reply Message), изображённое пунктирной стрелкой, не связывают с операцией. Добавим на диаграмму альтернативный комбинированный фрагмент взаимодействия (Alt. Combined Fragment). По умолчанию во фрагменте два операнда
с пустыми сторожевыми условиями. Ввести нужные условия следует, выделив фрагмент на диаграмме и вызвав контекстное меню -> Operand -> Manage Operands. Добавим сообщения от экземпляра контроллера к менеджеру транзакций. Нарисуем в нижнем операнде взаимодействия возвраты (Reply Message) и рефлексивное сообщение для вывода предупреждения об ошибке. Диаграмма примет вид, схожий с рисунком 4.2.2. Не забудьте создать операции getCourseOfferings(), displayError(), displayPossibleOperations() и связать их с сообщениями.
Рис. 4.2.2. Начальный вид диаграммы Basic Flow RegisterForCourses
Сообщения-возвраты (Reply Message) от менеджера транзакций и объекта-контроллера изображены на диаграмме явно. Для экономии места на диаграммах возвраты можно не указывать, однако, их подразумевают для всех синхронных сообщений. Далее возвраты мы будем изображать только при необходимости.
Помещаем на диаграмму вложенный комбинированный фрагмент аналогично предыдущему. Добавим ещё два операнда взаимодействия в созданный комбинированный фрагмент (чтобы общее их количество стало равно четырём). Добавим операндам сторожевые условия.
Рис. 4.2.3. Диаграмма последовательности Basic Flow RegisterForCourses с добавленным вложенным фрагментом взаимодействия
Внутри каждого их четырёх операндов комбинированного фрагмента будет происходить одно из взаимодействий, соответствующих четырём подчинённым потокам варианта использования. Чтобы не загромождать диаграмму основного потока для каждого подчинённого потока создаётся отдельная диаграмма. На основной диаграмме будут размещены лишь ссылки на используемые взаимодействия. В созданный нами последним комбинированный фрагмент взаимодействия с четырьмя операндами добавим по одному элементу Interaction Use в каждый операнд. Во вкладке General в спецификации каждого Interaction Use заполним поле Refers to. Диаграмма примет окончательный вид, показанный на рисунке 4.2.4.
Рис. 4.2.4. Окончательный вид диаграммы Basic Flow RegisterForCourses
Смоделируем один из подчинённых потоков Create Schedule Subflow. Вид диаграммы, которая должна получиться, показан на рисунке 4.2.5. На диаграмме помимо ранее использованных линий жизни есть линии экземпляра класса Student и экземпляра класса Schedule. На диаграмме использован комбинированный фрагмент с оператором opt (Optional), представляющий ветвление с единственной содержательной альтернативой, а также комбинированные фрагменты с оператором loop, описывающие циклы. Создавая циклы, следует задать в сторожевых условиях ограничение на количество итераций -- их минимальное количество. Когда указывается только минимальное количество итераций, а максимальное количество опущено, считается что цикл должен исполняться ровно столько раз, сколько указано. Обратите внимание, что на рис. 4.2.5 есть сообщение new, которое имеет тип Create Message. Не забудьте добавить соответствующую операцию в класс Schedule, но связывать её вызов с сообщением не следует.
Рис. 4.2.5. Диаграмма последовательности Create Schedule subflow
Фрагмент Interaction Use (с оператором взаимодействия ref) ссылается на диаграмму последовательности Display Course Offerings. Поскольку вывод списка предлагаемых курсов возникает в нескольких подчинённых потоках, есть смысл смоделировать его однажды, и многажды ставить ссылку на взаимодействие, моделирующее его.
Рис. 4.2.6. Диаграмма последовательности Display Course Offerings
Каждое сообщение на диаграмме последовательности назначает экземплярам классов обязанности по отправке или приёму и обработке сообщения. Для приёма сообщения в классе объекта-приёмника должна быть одноимённая операция. Для отправки сообщения между экземплярами классов должно быть соединение, т. е. между классами, экземпляры которых обмениваются сообщениями, должна быть ассоциация. На диаграмме 4.2.4. Basic Flow RegisterForCourses форма отправляет сообщение registerForCourses контроллеру регистрации. Значит, в классе RegistrationController должна быть одноимённая операция, которая обрабатывает сообщение от формы, а между классом-формой и классом-контроллером должна быть ассоциация. Нарисуем её на диаграмме VOPC RegisterForCourses. Мощности полюсов этой ассоциации 1 к 1. Объект-контроллер посылает сообщения объекту класса TransactionManager (см. рис. 4.2.4, 4.2.5) и экземпляру класса Student, следовательно, нужны ещё ассоциации между классами. Добавьте ассоциации, соединяющие классы RegistrationController, TransactionManager, Student, CourseOffering. Ассоциации от менеджера транзакций мы добавляем, предполагая, что в ответ на полученные запросы он возвращает объекты-студенты и объекты-курсы, подкачанные из БД, следовательно между классами должны быть связи. Конкретный тип связей будет выбран позднее. На этапе анализа можно считать, что эти связи -- ассоциации.
Проверьте, что для каждого сообщения, принимаемого экземпляром любого класса (не действующего лица), существует связанная операция. Заметьте, что не следует дважды создавать операцию, обрабатывающую приём двух одноимённых сообщений. Второе сообщение следует связать с ранее созданной операцией. На диаграмме VOPC RegisterForCourses отобразятся созданные операции. В результате классы должны выглядеть, как показано на рисунке 4.2.7.
Рис. 4.2.7. Диаграмма VOPC RegisterForCourses по окончании анализа
Добавьте новый атрибут классу CourseOffering -- numStudents. Отметьте атрибут CourseOffering::numStudents как выводимый (в окне спецификации атрибута на вкладке General отметьте Derived), поскольку его значение равно количеству планов-графиков, связанных с предлагаемым курсом. Так как студенты учатся на дневном и вечернем отделениях добавьте в пакет Analysis Model классы FullTimeStudent (студент очного отделения) и PartTimeStudent (студент вечернего отделения) -- наследники класса Student. Чтобы убедиться, что классы будут созданы в пакете Analysis Model следует создать их с помощью контекстного меню пакета Analysis Model в браузере. Если их создать с помощью палитры на диаграмме, классы будут помещены в пакет Use Case Realizations, являющийся родительским для диаграммы. Если классы созданы в неверном пакете, перетащите их в нужный пакет в браузере. Проведите на диаграмме связи обобщения (Generalization). Добавьте атрибуты классам наследникам (указываются только собственные атрибуты, унаследованные добавлять не следует). Так как мы моделируем классы анализа, типы атрибутов следует выбирать из набора стандартных типов UML. Создайте атрибуты CourseOffering::semester, Student::id. Диаграмма должна выглядеть как на рис. 4.2.7.
Моделировать потоки событий в реализациях вариантов использования можно не только с помощью диаграмм последовательности. Также для этой цели применяют коммуникационные диаграммы (communication diagram). Об этих диаграммах рассказывается на лекции. Пример такого рода диаграммы, моделирующей подчинённый поток Delete Schedule Subflow, приведён на рисунке 4.2.8. По желанию, создайте коммуникационную диаграмму в своём проекте.
Рис. 4.2.8. Коммуникационная диаграмма Delete Schedule Subflow
Упражнения по анализу закончены. Предполагается, что реализация всех вариантов использования выполняется не за один раз. Часть вариантов использования могут быть реализована не на первой итерации, а на последующих. Мы не будем моделировать остальные подчинённые потоки варианта использования Зарегистрироваться на курсы, чтобы не терять время на рутину.
Созданную модель анализа следует сохранить отдельно. Если при проектировании модель анализа разрушится, можно будет использовать сохранённую отдельно её копию. При сдаче выполненных упражнений полезно иметь с собой два проекта: один, сохранённый на момент окончания анализа; второй, представляющий модель после выполнения всех упражнений. Закройте проект и сделайте копию файла проекта в 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. Вытащите на неё все три архитектурных уровня и соедините их зависимостями (Package Import), как указано на рис. 5.1.1. Вы создали иерархию уровней системы, т. е. её устройство с точки зрения самых крупных блоков.
Рис. 5.1.1. Диаграмма пакетов Main
Следующие действия нацелены на трансформацию классов анализа в проектные элементы (классы, интерфейсы и подсистемы) и распределение проектных элементов по уровням системы.
При анализе не были полностью учтены все вопросы, связанные с обеспечением устойчивости данных. В потоке событий система предпринимала некоторые действия, чтобы введённые данные были доступны не только в текущем сеансе работы, но и в последующих. Для этого отправлялись сообщения менеджеру транзакций, но действия менеджера по обработке этих сообщений не были промоделированы. В этом нет ошибки, во время анализа эти вопросы рассматривать рано, надо сосредоточиться на основных функциях системы. Начиная проектирование, следует вернуться к этим вопросам и смоделировать то, что было пропущено при анализе. Реализация обязанностей, назначенных классу TransactionManager, сложна. Поэтому при отображении в проектные классы следует перевести его в подсистему обеспечения устойчивости DBAccess (сокращённо от DataBase Access). Остальные классы анализа перейдут в проектные один в один. Заметим, что можно было бы отобразить граничный класс BillingSystem, обеспечивающий взаимодействие с расчётной системой, в подсистему для того, чтобы возможные изменения во взаимодействии с расчётной системой мало затрагивали остальные части системы и были локализованы в подсистеме. Так как цель наших упражнений -- знакомство со средой Visual Paradigm и процессом разработки, реализация варианта использования Закрыть регистрацию, при котором происходит взаимодействие с расчётной системой, не моделируется. Так что, подсистема в нашей модели пока будет одна.
Итак, все классы анализа, кроме TransactionManager, отобразятся в проектные один в один. Чтобы не испортить модель анализа, скопируйте её содержимое внутрь проектной модели. Для этого в браузере выделите пакет Analysis Model, вызовите его контекстное меню и выберите в нём пункт Duplicate Recursively. После этого будет осуществлено дублирование пакета и всех его элементов. Дубль пакета получит имя Analysis Model2. Создайте в пакете Application пакет Registration. В созданный пакет переместите классы RegisterForCoursesForm и RegistrationController из корня Analysis Model2. Для этого воспользуйтесь контекстным меню элемента и пунктом Move... . В пакете BusinessServices создайте пакет UniversityArtefacts (т. е. артефакты университета, в нем разместите классы-сущности предметной области, а также перечислимый тип DayOfWeek). Там же создайте пакет Interfaces (где будут находиться все интерфейсы). Диаграмму классов Key Abstractions2 удалите. В пакет Interfaces перенесите класс TransactionManager из Analysis Model2. Переименуйте TransactionManager в IDBAccess и назначьте ему стереотип <<Interface>>. Пакет Use Case Realizations из Analysis Model2 перенесите в Design Model и переименуйюе в Design Use Case Realizations. Пустой пакет Analysis Model2 удалите.
При реализации подсистемы следует воспользоваться механизмом RDBMS-JDBC из одноимённого пакета, расположенного в Design Model::Architectural Mechanisms::Persistency. Чтобы не повредить часть модели, описывающей механизм, скопируйте её в подсистему. Для этого продублируйте (Duplicate Recursively) пакет RDBMS-JDBC, а затем переместим полученный дубль на уровень Business Services и переименуйте его в DBAccess. Назначьте пакету DBAccess стереотип <<subsystem>>. Структура проектной модели в браузере должна иметь вид похожий на рис. 5.1.2. Убедитесь, что Вы верно распределили элементы модели по пакетам. Обратите внимание, что стереотипы анализа в проектной модели смысла не имеют, их можно убрать.
Рис. 5.1.2. Структура проектной модели
Переименуйте подпакеты, кооперации и диаграммы внутри пакета Design Model :: Design Use Case Realizations, убрав цифру в окончании и добавив приставку Design (см. рис. 5.1.2). Диаграмма составной структуры внутри этого пакета примет вид, представленный на рис. 5.1.3.
Рис. 5.1.3. Диаграмма составной структуры Design Use Case Realizations
Создайте диаграмму пакетов Dependencies в пакете Registration. Разместите на ней пакеты Registration, Interfaces и UniversityArtefacts, укажите их зависимости (Package Import). Элементы пакета Registration используют классы-артефакты и интерфейс подсистемы, отсюда две зависимости. Диаграмма примет вид, представленный на рис. 5.1.4.
Рис. 5.1.4. Связи пакета Registration
Создайте диаграмму пакетов BusinessServices в пакете BusinessServices. Разместите на ней пакеты этого архитектурного уровня, укажите их зависимости (Dependency). Подсистема реализует интерфейс, отсюда верхняя зависимость. Для описаний в верхних пакетах понадобятся классы-артефакты, отсюда две другие зависимости. Диаграмма примет вид, представленный на рис. 5.1.5.
Рис. 5.1.5. Структура уровня BusinessServices
Моделирование структуры потоков управления системы в упражнение не включено. Этот вопрос рассматривается только на лекциях. В системе можно выделить следующие процессы: StudentApplication.exe -- пользовательский процесс рабочего места студента; ProfessorApplication.exe -- пользовательский процесс рабочего места лектора; RegistrarApplication.exe -- пользовательский процесс рабочего места регистратора; RegistrationProcess -- процесс, управляющий ходом регистрации; BillingSystemAccessProcess -- процесс, обеспечивающий связь с расчётной системой; DBAccessProcess -- процесс, обеспечивающий доступ к БД системы.
Промоделируйте конфигурацию вычислительной среды. Она состоит из трёх типов узлов -- сред выполнения (Execution Environment) или процессоров, на которых могут быть размещены вложенные компоненты-процессы, и устройств (Device). Связи между узлами -- пути коммуникации -- являются подвидами ассоциации. Откройте диаграмму размещения Main внутри архитектурного представления Deployment View. Создайте на ней узлы и связи между узлами. Компоненты следует создавать, размещая их внутри родительского узла. Окончательный вид диаграммы приведён на рис. 5.1.6. По получившейся диаграмме можно судить, что в среде есть сервер регистрации, к которому подключён принтер и рабочие станции трёх типов. Также на диаграмме указан узел расчётной системы, подключённый к серверу регистрации. Коммуникации осуществляются через локальную сеть кампуса. Принтер подключён по USB интерфейсу.
Рис. 5.1.6. Диаграмма размещения
На этом проектирование архитектуры завершено, переходим к проектированию элементов системы.
|
|
Упражнение 5.2. Проектирование элементов системы регистрации
|
Проектирование элементов системы включает в себя следующие виды работ: уточнение реализаций вариантов использования; проектирование подсистем; проектирование классов и проектирование баз данных.
Проектные реализации вариантов использования являются более полными, чем реализации, созданные в ходе анализа. В них вместо экземпляров классов анализа должны присутствовать экземпляры проектных классов, т. е. должны быть учтены трансформации классов анализа в проектные элементы. Для этого следует уточнить реализации вариантов использования.
Переименуйте диаграммы из Design Model: диаграмму классов VOPC RegisterForCourses2 в Design VOPC RegisterForCourses, диаграмму классов VOPC Login в Design VOPC Login, диаграмму последовательности Create Schedule Subflow2 в Design Create Schedule Subflow, диаграмму последовательности Delete Schedule Subflow2 в Design Delete Schedule Subflow, диаграмму последовательности Update Schedule Subflow2 в Design Update Schedule Subflow, диаграмму последовательности Submit Schedule Subflow2 в Design Submit Schedule Subflow, диаграмму последовательности Display Course Offerings в Design Display Course Offerings, диаграмму последовательности Basic Flow Login2 в Design Basic Flow Login. По такому же принципу все элементы модели с именами, оканчивающимися на 2, следует переименовать.
Откройте диаграмму последовательности Design Basic Flow RegisterForCourses из пакета Design RegisterForCourses Realization в пакете Logical View :: Design Model :: Design Use Case Realizations. Измените самую правую линию жизни -- бывший экземпляр TransactionManager. Она должна представлять "экземпляр интерфейса" IDBAccess. На диаграмме Design Create Schedule subflow измените стереотип на линии жизни объекта tm : IDBAccess. Удалите стереотип <<control>>, добавьте стереотип <<interface>>. Этот элемент показывает, что происходит обращение к экземпляру класса, реализующему интерфейс подсистемы. Какой именно это будет класс -- это для реализации варианта использования неважно. Реализация не определяет, как подсистема DBAccess должна обрабатывать такой вызов. Эта часть относится к проектированию подсистемы и может варьироваться в зависимости от реализации подсистемы. Внутреннее поведение подсистемы скрыто, чтобы обеспечить возможность лёгкой модификации её реализации. Сообщения, принимаемые объектом, реализующим интерфейс IDBAccess, должны быть связаны с операциями интерфейса IDBAccess::getCourseOfferings(), IDBAccess::getStudent() и IDBAccess::updateStudent(). Если в Вашей модели эти операции отсутствуют, добавьте их в интерфейс. Дополнительно создайте в интерфейсе IDBAccess операции init() и close(), управляющие соединением системы с СУБД. Проектные версии диаграмм Basic flow, Create Schedule, Display Course Offerings примут вид, представленный на рисунках 5.2.1, 5.2.2 и 5.2.3. Необязательно при уточнении реализаций вариантов использования детализировать сигнатуры операций (см. добавленные параметры и типы результатов на диаграммах 5.2.1-3). Составить полные сигнатуры операций лучше при проектировании классов.
Рис. 5.2.1. Уточнённая диаграмма Design Basic flow RegisterForCourses
Рис. 5.2.2. Уточнённая диаграмма Design Create Schedule subflow
Рис. 5.2.3. Уточнённая диаграмма Design Display Course Offerings
Обычно при проектировании граничные классы, отвечающие за взаимодействие с пользователем, трансформируются не в один класс, а в группу классов GUI, но упражнения по проектированию пользовательского интерфейса в рамках нашего курса не рассматриваются. Уточнение реализаций вариантов использования закончено. Следующей технологической операцией является проектирование подсистем. В рассматриваемой модели в ходе этой операции следует на основе механизма JDBC спроектировать подсистему DBAccess. При этом механизм выполняет роль шаблона, описывающего типовую организацию доступа к устойчивым данным с точки зрения структуры и поведения. В этом шаблоне своего рода параметрами являются классы PersistentObject, PersistentObjectList и DBClass. Проектирование системы в основном сводится к конкретизации шаблона, в ходе которой класс PersistentObject заменяется на классы-сущности, данные которых хранятся в БД (например, CourseOffering), класс PersistentObjectList -- на соответствующие классы-контейнеры (например, CourseOfferingList), класс DBClass -- на прокси-класс подсистемы DBAccess.
Переименуйте класс DBClass внутри пакета DBAccess в DBAccess и назначьте ему стереотип <<subsystem proxy>> -- тем самым будет указано, что экземпляр этого класса будет принимать все сообщения, идущие внутрь подсистемы. Класс PersistentObjectList переместите в пакет UniversityArtefacts, переименуйте его в CourseOfferingList. Откройте спецификацию класса CourseOfferingList. Найдите вкладку Relations. Если её не видно, воспользуйтесь чёрной треугольной стрелкой в правом верхнем углу окна спецификации класса и добавьте вкладку. Измените имя у отношения реализации (Realization) на < E->courseOffering >. Тем самым Вы укажете, что элементами этого списка будут экземпляры класса CourseOffering. У связи зависимости, ведущей к классу PersistentObject, измените конец, указав вместо PersistentObject класс CourseOffering. Класс PersistentObject переименуйте в класс CourseOffering и с помощью контекстного меню объедините класс CourseOffering из подсистемы DBAccess с классом CourseOffering из пакета UniversityArtefacts (Merge to Model Element...). В подсистеме DBAccess переименуйте кооперацию JDBC в IDBAccess. Добавьте ей стереотип «interface realization» и удалите стереотип «mechanism».
Откройте диаграмму классов в пакете RDBMS-JDBC. На ней указано, что при реализации доступа к БД используются элементы, описанные в пакетах java.lang и java.sql. Поэтому откройте диаграмму пакетов из пакета Business Services, перенесите на неё пакеты lang и sql с уровня Middleware из пакета java, добавьте зависимости (Dependency) от подсистемы DBAccess к пакетам java.lang и java.sql. Не забудьте, что зависимости проводятся от зависящего пакета к пакетам, от которых он зависит.
Диаграмму последовательности initialize2 переименуйте в init, read2 -- в getCourseOfferings, disconnect2 -- в close, update2 -- в updateStudent. Теперь откройте находящуюся внутри подсистемы DBAccess диаграмму классов DBAccess. Поместите на неё классы CourseOffering, Student, Schedule и проведите зависимости от класса DBAccess. Добавьте на диаграмму интерфейс IDBAccess. Проведите связь реализации от класса DBAccess к интерфейсу IDBAccess. Переименуйте операции класса DBAccess: read(criteria:string):CourseOfferingList в getCourseOfferings(semester:byte):CourseOfferingList, update(obj:CourseOffering):void в updateStudent(obj:Student):void, initialize в init, disconnect в close. Добавьте в DBAccess операцию getStudent(id:long):Student. Затем продублируйте операции и перенесите их копии в интерфейс IDBAccess. Удалите операции анализа из интерфейса IDBAccess. Проведите недостающие зависимости. В результате, диаграмма классов и структура подсистемы должны быть похожи на изображённые на рисунках 5.2.4 и 5.2.5. Уточнение связей между классами вне подсистемы лучше проводить при проектировании классов, поэтому добавить квалификатор на композицию между Student и Schedule следует потом.
Рис. 5.2.4. Диаграмма классов подсистемы DBAccess
Рис. 5.2.5. Структура подсистемы DBAccess
Так как мы вносили изменения в интерфейс IDAccess, следует перейти на диаграмму Design Create Schedule subflow и заново связать сообщения, получаемые интерфейсом с его операциями. Ранее сообщения были связаны с операциями, которые были удалены. Найдите на диаграмме сообщения без операций и привяжите к ним подходящие операции (или убедитесь, что все сообщения по-прежнему связаны с операциями).
Благодаря использованию механизма мы затратили меньше сил на обдумывание и моделирование, чем если бы делали подсистему с чистого листа. Переходим к моделированию внутреннего поведения подсистемы.
Внутри кооперации IDBAccess находятся диаграммы последовательности, среди которых интересны: init (бывшая initialize), close (бывшая disconnect), getCourseOfferings, updateStudent. Каждое взаимодействие будет описывать, что делают объекты подсистемы при вызове соответствующей операции. Реализацию операций не перечисленных выше мы моделировать не будем, а указанные четыре промоделируем.
На диаграмме последовательности init левая линия жизни должна представлять объект db:DBAccess, входящее сообщение, принимаемое им, должно быть связано с операцией init. Диаграмма примет вид, изображённый на рисунке 5.2.6. Взаимодействие описывает установление соединения с БД.
Рис. 5.2.6. Диаграмма последовательности, описывающая реализацию операции init()
Диаграмма close должна иметь вид, изображённый на рисунке 5.2.7.
Рис. 5.2.7. Диаграмма последовательности, описывающая реализацию операции close()
На диаграмме последовательности getCourseOfferings левая линия жизни должна представлять объект DBAccess, а самая правая -- obj:CouseOffering. Вторая справа линия жизни -- объект CourseOfferingList. Свяжите найденное сообщение, принимаемое экземпляром DBAccess, с операцией getCourseOfferings. Добавьте классу CourseOffering новые операции-сеттеры setDay(day:DayOfWeek), setPair, setNumber, setSemester. Удалите вложенный цикл с диаграммы последовательности. Добавьте соответствующие сообщения от объекта db:DBAccess к obj:CourseOffering и от db:DBAccess к rs:ResultSet на диаграмму последовательности. Самое нижнее сообщение свяжите с операцией add(e:CourseOffering). Диаграмма примет вид, изображённый на рисунке 5.2.8.
Рис. 5.2.8. Диаграмма последовательности, описывающая реализацию операции getCourseOfferings()
На диаграмме последовательности updateStudent левая линия жизни должна представлять экземпляр DBAccess, две правые -- объект Student и объект Schedule (эту линию жизни следует создать на диаграмме). Свяжите найденное сообщение с операцией updateStudent. Свяжите третье сверху сообщение с вызовом операции getId, добавьте недостающие сообщения. Диаграмма должна иметь вид, изображённый на рисунке 5.2.9.
Рис. 5.2.9. Диаграмма последовательности, описывающая реализацию операции updateStudent()
Проектирование подсистемы завершено. Переходим к проектированию классов.
Проектирование классов включает следующие действия: детализацию проектных классов; уточнение операций и атрибутов; моделирование состояний для экземпляров классов; уточнение связей между классами. При детализации проектный класс может быть разбит на несколько классов из соображений, связанных с его реализацией в коде. Класс может быть удалён из модели, если его экземпляры являются посредниками, не несущими содержательных обязанностей. Обязанности классов, определённые в процессе анализа и документированные в виде операций анализа, преобразуются в операции, которые будут реализованы в коде. При этом каждой операции присваивается краткое имя, характеризующее её, определяется полная сигнатура операции, создаётся краткое описание операции, содержащее смысл всех её параметров, определяется видимость операции, определяется область действия операции (операция экземпляра или операция класса). Если метод, реализующий операцию, реализует нетривиальный алгоритм, то он моделируется на диаграмме деятельности. Уточнение атрибутов классов заключается в следующем: задаются типы атрибутов, их множественность и значения по умолчанию (необязательно); задаётся видимость атрибутов; при необходимости определяются производные (вычисляемые или выводимые) атрибуты, статические атрибуты.
Если экземпляры некоторого класса реализуют сложное поведение, меняют своё поведение в зависимости от состояния, то для этого класса строят диаграмму состояний. При построении диаграммы уточняются операции, так как они могут быть связаны с событиями, вызывающими смену состояний, и с действиями на переходах и внутри состояний. Уточняются атрибуты, так как текущее состояние экземпляра определяется совокупностью значений его атрибутов.
Затем производится уточнение связей между классами. Ассоциации, созданные на этапе анализа, которые соответствуют временным соединениям между объектами, заменяются на зависимости. Оставшиеся ассоциации заменяются на агрегации или композиции. Указываются мощности на полюсах, направления связей, типы множественных связей (set = unordered + unique, ordered = ordered + unique, bag = unordered + nonunique, sequence = ordered + nonunique), квалификаторы. Классы ассоциаций преобразуются в обычные с помощью материализации связей. Некоторые связи обобщения могут быть преобразованы путём метаморфозы подтипов.
Рассмотрим проектирование классов на примере системы регистрации. Создайте в пакете UniversityArtefacts диаграмму классов Student. Поместите классы Student, FullTimeStudent и PartTimeStudent, а также связи обобщения между ними на диаграмму. Чтобы составить набор из двух обобщений, выделите обе связи обобщения (с помощью Ctrl-клик) и вызовите контекстное меню (Generalization Set). Добавьте и уточните его атрибуты и операции, чтобы придать ему вид, схожий с рисунком 5.2.10. Геттеры и сеттеры удобно создавать, выделив атрибут и вызвав контекстное меню. Статические (подчёркнутые) атрибуты и операции задаются указанием области действия classifier (вкладка General, поле scope). Также можно задать необходимые свойства элемента модели в контекстном меню. Типы long, int, boolean и String используйте из набора стандартных типов UML, Date -- из java.util.
Рис. 5.2.10. Диаграмма классов Student
Постройте модель состояний в соответствии с рисунком 5.2.11.
Экземпляры класса CourseOffering должны по-разному обрабатывать вызовы операции addStudent в зависимости от того, отменен курс или нет, и в зависимости от количества уже зарегистрировавшихся студентов. Это признак сложного поведения и причина для создания диаграммы состояний. Добавьте классу CourseOffering диаграмму состояний LifeCycle (контекстное меню, Sub diagram -> New diagram -> State Machine Diagram). Начальное состояние (Initial) создаётся автоматически. Создайте финальное состояние (FinalState), состояния Open, Closed, Canceled и псевдосостояние выбора (Choice). Соедините состояния переходами, как указано на рисунке 5.2.11.
Переходу может быть добавлено событие (триггер), указываемое до слэша, действие, указываемое после слэша, сторожевое условие, записываемое в прямоугольных скобках. События addStudent, removeStudent, delete, close, cancel и when(numStudents==10) добавляйте на вкладку Triggers спецификаций переходов. Типы всех событий, кроме последнего -- события вызова (Call Trigger). Тип последнего события when(numStudents==10) -- событие изменения (Change Trigger). Событие cancel приписано двум разным переходам, аналогично событие delete. Не следует создавать дважды одно и то же событие. Привяжите одно созданное событие обоим переходам. Действия при переходах указывайте в поле Effect, текст действия указывайте в имени создаваемой деятельности. Значок "^" в записи действия указывает на отправку сообщение другому объекту. Чтобы добавить действие по выходу в состоянии Canceled, откройте спецификацию состояния, перейдите на вкладку General и создайте действие в поле Exit.
Рис. 5.2.11. Диаграмма состояний класса CourseOffering
Уточним связи между классами на диаграмме Design VOPC RegisterForCourses проектной реализации варианта использования Зарегистрироваться на курсы. Добавьте на диаграмму отсутствующие элементы и связи. Проведите уточнение ассоциаций, указав, где нужно, что они являются агрегациями или композициями. Укажите направления ассоциаций. Обратите внимание на двунаправленные ассоциации (со стрелкам на обоих концах). В плане-графике хранятся ссылки на курсы, включённые в него, и каждый курс хранит массив ссылок на планы-графики, в которые он включён. Укажите начальное значение атрибуту numStudents класса CourseOffering. Уточните обобщения (осуществите метаморфозу подтипов). При анализе мы определили, что бывают студенты дневного отделения и студенты вечернего отделения, и создали иерархию наследования. Хороша ли такая модель, в случае перевода студента с одного отделения на другое? При переводе требуется создать студента нового типа, скопировать в него данные (значения слотов атрибутов класса Student), а затем исходный объект удалить. Эффективнее было бы общую для дневных и вечерних студентов часть не трогать, а менять только то, что зависит от отделения. Выделим эту меняющуюся часть в абстрактный класс Classification, унаследуем от него FullTimeClassification и PartTimeClassification -- переименованные бывшие классы FulltimeStudent и PartTimeStudent. Результат на уточнённой диаграмме классов Design VOPC RegisterForCourses (рис. 5.2.12).
Рис. 5.2.12. Уточнённая диаграмма классов Design VOPC RegisterForCourses
|
|
Упражнение 5.3. Проектирование базы данных
|
Если среди проектных классов есть устойчивые, чьи экземпляры должны сохраняться в периодах между запусками системы, следует обеспечить сохранение их в базе данных (например, реализовав подсистему обеспечения устойчивости на базе JDBC) и создать схему базы данных. Фактически, следует отобразить объектную модель в реляционную. Одна из стратегий при этом состоит в том, что для каждого устойчивого класса создаётся собственная таблица. Атрибуты класса переводятся в столбцы таблицы. Атрибут-идентификатор становится первичным ключом. Ассоциации моделируются с помощью связей между таблицами (связывающими значения первичного ключа записей одной таблицы со значениями внешнего ключа другой таблицы). Заметим, что связи между таблицами всегда двунаправленные, по записям любой из связанных таблиц можно найти соответствующие записи другой таблицы. Связи между таблицами могут быть идентифицирующими и не идентифицирующими. Идентифицирующая связь указывает, что внешний ключ включает в себя часть первичного ключа, то есть ключ родительской записи является частью ключа дочерних записей. Связь отображается как композиция, если требуется указать на зависимость по существованию. Так, при удалении родительской записи (например, из таблицы TableCourse) должны быть удалены дочерние записи (из таблицы TableCoursePreq). В некоторых случаях для ассоциации (например, * к *) требуется создавать дополнительную таблицу, хранящую соединения между объектами, (например TablePrimaryCourse). Для отображения обобщений используются разные способы. Один из них -- "отдельная таблица для каждого класса". В этом случае у всех получившихся таблиц будет один и тот же первичный ключ, который в таблицах подклассов будет также внешним ключом. Другой способ -- "одна таблица для всей иерархии наследования". В этом случае создаётся таблица, хранящая записи об экземплярах всех неабстрактных классов, входящих в иерархию. Такая таблица получается "разреженной", так как в записях некоторые поля остаются не заполненными (так как они относятся к экземплярам других подклассов).
Осуществим проектирование базы данных. Продублируйте рекурсивно пакет UniversityArtefacts. Полученный дубль переименуйте в Database Schema и переместите в корень Design Model. Назначьте ему стереотип <<schema>>. Диаграмму классов Student2, находящуюся в пакете, переименуйте в DataBase Schema. Вынесите на диаграмму классы Student, Schedule, CourseOffering, Course. Добавьте классам, находящимся на диаграмме, стереотип <<table>> и уберите стереотип <<entity>>. Переименуйте классы, добавив к именам приставку Table. Добавьте класс (таблицу) TableStaticVariables для хранения значений статических атрибутов. Добавьте классы (таблицы) TablePrimaryCourse и TableCoursePrereq для хранения соединений * к *. Добавьте недостающие атрибуты и стереотипы. Уберите квалификатор и исправьте мощность 0..1 на ассоциации между Student и CourseOffering. Новое значение мощности -- *. См. рисунок 5.3.1. Эту схему можно использовать для хранения сведений о студентах, планах-графиках, читаемых курсах, дисциплинах. Столбцы для хранения выводимых атрибутов можно не заводить. При отображении обобщения в реляционную модель применена стратегия "Одна таблица для всей иерархии наследования". Согласно ей для трёх классов Classification, FullTimeClassification и PartTimeClassification заводится одна таблица. Одновременно можно слить эту единую таблицу с таблицей TableStudent. Получится, что данные обоих типов студентов хранятся в одной таблице, просто некоторые поля в каждой записи не заполнены в зависимости от типа студента. Использованные стратегии упрощают схему, позволяют обойтись сравнительно малым количеством таблиц и связей.
Рис. 5.3.1. Диаграмма классов DataBase Schema
Упражнения по анализу и проектированию системы регистрации на этом закончены. Остались не реализованными остальные варианты использования, но мы не ставили целью полностью спроектировать систему, лишь рассмотрели работы, выполняемые в рамках разных процессов жизненного цикла. Перед тем как сдавать полученную модель, попробуйте ответить на вопросы из списка.
|
|
Предупреждение
|
Размещение на других ресурсах, а также коммерческое использование материалов, опубликованных в данном разделе, возможно только с разрешения авторов. По всем вопросам пишите:
|
|
© Кафедра системного программирования ВМК МГУ.
Обновлено: 12.10.2016
|
