На этапе формирования требований, прежде всего, необходимо определить область действия разрабатываемой системы и получить точное представление о желаемых возможностях системы.
Основой разработки требований является модель системных прецедентов, отражающая выполнение конкретных обязанностей внутренними и внешними исполнителями с использованием ИС.
Источником данных для создания модели системных прецедентов являются разработанные на предыдущем этапе бизнес-модели. Однако при создании модели полезно предварительно составить детальные описания прецедентов, содержащие определения используемых данных и точную последовательность их выполнения. Описание осуществляется в соответствии с принятым в организации шаблоном, который обычно включает следующие разделы:
В процессе создания модели системных прецедентов осуществляется преобразование и перенос компонентов бизнес-моделей на новые диаграммы. Типовые преобразования по технологии Rational Unified Process приведены в таблица 12.1.
Таблица 12.1.
Элементы бизнес-модели | Элементы модели системных прецедентов |
Бизнес-прецеденты | Подсистемы |
Внешние исполнители | Исполнители |
Внутренние исполнители | Исполнители или прецеденты |
Процессы, выполняемые внутренними исполнителями | Прецеденты |
На рис. 12.9 представлена модель системных прецедентов для бизнес-прецедента Оказание медицинской помощи. Исходя из цели создания системы, в модели системных прецедентовотражены только те действия исполнителей, которые связаны с предоставлением доступа и обновлением клинических записей.
Рис. 12.9. Модель системных прецедентов
Описываемые моделью функции характерны только для одного вида деятельности – оказания медицинской помощи, и в основном не используются в других видах деятельности Центра. Это позволяет объединить выделенные функции в некую единую подсистему проектируемой ИС.
Внутренний исполнитель Персонал центра (см. рис. 12.4, рис. 12.7) и выполняемый им ручной процесс преобразован в системный прецедент Предоставление доступа к клиническим записям.
Внешние исполнители (например, Производитель медицинского оборудования) непосредственно взаимодействуют с проектируемой системой, т.е. превращаются в исполнителей.
В модели отражены два специальных типа связи между прецедентами (на рис. 12.9 соответствующие прецеденты выделены тенью):
Прецедент Проверка прав доступа впервые появился на диаграммах и реализуется средствами разрабатываемой ИС. Поэтому для него приходится разрабатывать диаграмму последовательностей, описывающую его исполнение (рис. 12.10). В результате в проектируемой ИС появляются два новых объекта – программный модуль Менеджер защиты и информационный блок Набор прав.
Рис. 12.10. Диаграмма последовательностей для прецедента Проверка прав
Таким образом, результатом разработки модели системных прецедентов является не только исчерпывающий перечень функций, которые должны быть реализованы в проектируемой системе, но и подробное описание необходимой реализации этих функций.
^
Основные задачи этапа:
Основным инструментом на данном этапе являются диаграммы классов системы, которые строятся на основе разработанной модели системных прецедентов. Одновременно на этом этапе уточняются диаграммы последовательностей выполнения отдельных прецедентов, что приводит к изменениям в составе объектов и диаграммах классов. Это естественное отражение средствами UML итеративного процесса разработки системы.
Диаграммы классов системы заполняются объектами из модели системных прецедентов. Они содержат описание этих объектов в виде классов и описание взаимодействия между классами.
Диаграмма классов, описывающая процедуры защиты доступа к данным, приведена на рис. 12.11.
Рис. 12.11. Диаграмма классов Защита доступа
Таким образом, в результате этого этапа проектирования появляется достаточно подробное описание состава и функций проектируемой системы, а также информации, которую необходимо использовать в базе данных и в приложениях.
Поскольку диаграммы классов строятся на основе разработанных ранее бизнес-моделей, появляется уверенность в том, что разрабатываемая система будет действительно удовлетворять исходным требованиям заказчика.
В то же время, благодаря своему синтаксису, диаграммы классов оказываются хорошим средством структурирования и представления требований к функциональности, интерфейсам и данным для элементов проектируемой системы.
Друзья! Приглашаем вас к обсуждению. Если у вас есть своё мнение, напишите нам в комментарии.