А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 17

К основным документам, регламентируемымтехнологией Rational Unified Process, относятся:• Концепция - определяет глобальные цели проекта и основныеособенности разрабатываемой системы. Существенной частьюконцепции является постановка задачи разработки, определяющаятребования к выполняемым системой функциям.• Словарь предметной области (глоссарий) - определяет общуютерминологию для всех моделей и описаний требований к системе.Глоссарий предназначен для описания терминологии предметнойобласти и может быть использован как словарь данных системы.• Дополнительные спецификации (технические требования) содержит описание нефункциональных требований к системе,таких,какнадежность,удобствоиспользования,производительность, сопровождаемость и др.Функциональные требованияк системемоделируютсяидокументируются с помощью вариантов использования (use case), которыев контексте процесса управления требованиями трактуются следующимобразом [7]:• вариант использования фиксирует соглашение между участникамипроекта относительно поведения системы;• вариант использования описывает поведение системы приразличных условиях, когда система отвечает на запрос одного изучастников, называемого основным действующим лицом;• основное действующее лицо инициирует взаимодействие ссистемой, чтобы добиться некоторой цели.

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

В итерационном циклесоздания системы не следует пытаться за один прием подробно описатьвсе требования, их нужно постепенно уточнять, повышая уровеньточности. Выбор первоочередных вариантов использования для уточненияопределяется их приоритетами. Факторами ранжирования вариантовиспользования (и вообще всех требований) по приоритетам являются:• существенное влияние на архитектуру системы;• рискованные, сложные для реализации или срочные функции;• применение новой, неапробированной технологии;• значимость в экономических процессах.Методика моделирования вариантов использования в технологииRational Unified Process предусматривает специальное соглашение,связанное с группировкой структурных элементов и диаграмм модели.

Этосоглашение включает следующие правила:• Все действующие лица, варианты использования и диаграммывариантов использования помещаются в пакет с именем Use CaseModel.• Если моделируется сложная многофункциональная система, тосовокупность всех действующих лиц и вариантов использованияможет разделяться на пакеты. В качестве принципов разделениямогут использоваться:o структуризации модели в соответствии с типамипользователей (действующих лиц);o функциональная декомпозиция;o разделение модели на пакеты между группами разработчиков(в качестве объектов управления конфигурацией).Спецификация требований в технологии Rational Unified Process нетребует обязательного моделирования бизнес-процессов организации, длякоторых создается ПО, однако, наличие бизнес-моделей существенноупрощает построение системной модели вариантов использования. Припереходе от бизнес-модели к начальной версии модели вариантовиспользования применяются следующие правила:• Для каждого исполнителя в модели бизнес-анализа, который вперспективе станет пользователем новой системы, в моделивариантов использования создается действующее лицо с таким женаименованием.

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

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

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

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

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

Если курс окажется заполненным в процессе регистрации,студент должен быть извещен об этом до окончательного формированияего личного учебного плана.В конце семестра студенты должны иметь доступ к системе дляпросмотра своих электронных табелей успеваемости. Поскольку этаинформация конфиденциальная, система должна обеспечивать ее защитуот несанкционированного доступа.2.5.2 Глоссарий проектаТерминЗначениеУчебный курс, предлагаемый университетомКурсКонкретный курс Конкретное чтение данного курса в конкретномсеместре (один и тот же курс может вестись внескольких параллельных сессиях). Включает точныедни недели и время.Полный каталог всех курсов, предлагаемыхКаталог курсовуниверситетом.Система обработки информации об оплате за курсы.РасчетнаясистемаОценка, полученная студентом за конкретный курс.ОценкаПреподаватель университета.ПрофессорВсе оценки за все курсы, полученные студентом вТабельданном семестре.успеваемостиСписок всех студентов, записавшихся на конкретныйСписок курсакурс.Личность, проходящая обучение в университете.СтудентУчебный график Курсы, выбранные студентом в текущем семестре.2.5.3.

Описание дополнительных спецификацийФункциональные возможности:• Система должна обеспечивать многопользовательский режимработы.• Если конкретный курс оказывается заполненным в то время, когдастудент формирует свой учебный график, включающий данныйкурс, то система должна известить его об этом.Удобство использования:91• Пользовательский интерфейс должен быть Windows-совместимым.Надежность:• Система должна быть в работоспособном состоянии 24 часа в день7 дней в неделю, время простоя - не более 10%.Производительность:• Система должна поддерживать до 2000 одновременно работающихс центральной базой данных пользователей, и до 500пользователей, одновременно работающих с локальнымисерверами.Безопасность:• Система не должна позволять студентам изменять любые учебныеграфики, кроме своих собственных, а также не должна позволятьпрофессорам модифицировать конкретные курсы, выбранныедругими профессорами.• Только профессора имеют право ставить студентам оценки.• Только регистратор может изменять любую информацию остудентах.Проектные ограничения:• Система должна быть интегрирована с существующей системойкаталога курсов, функционирующей на основе реляционной СУБД.2.5.4.

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

2.10. Начальная версия диаграммы вариантов использования932.5.5. Модификация модели вариантов использованияСогласно постановке задачи, в состав пользователей системы следуетввести студентов и профессоров. При этом в описание действующих лиц ивариантов использования вносятся изменения. Модифицированная версиядиаграммы вариантов использования показана на рис. 2.11.