Разработка требований к системе
На этапе формирования требований, прежде всего, необходимо определить область действия разрабатываемой системы и получить точное представление о желаемых возможностях системы.
Основой разработки требований является модель системных прецедентов, отражающая выполнение конкретных обязанностей внутренними и внешними исполнителями с использованием ИС.
Источником данных для создания модели системных прецедентов являются разработанные на предыдущем этапе бизнес-модели. Однако при создании модели полезно предварительно составить детальные описания прецедентов, содержащие определения используемых данных и точную последовательность их выполнения. Описание осуществляется в соответствии с принятым в организации шаблоном, который обычно включает следующие разделы:
заголовок (название прецедента, ответственный за исполнение, дата создания шаблона/внесения изменений);
краткое описание прецедента;
ограничения;
предусловия (необходимое состояние системы или условия, при которых должен выполняться прецедент);
постусловия (возможные состояния системы после выполнения прецедента);
предположения;
основная последовательность действий;
альтернативные последовательности действий и условия, их инициирующие;
точки расширения и включения прецедентов.
В процессе создания модели системных прецедентов осуществляется преобразование и перенос компонентов бизнес-моделей на новые диаграммы. Типовые преобразования по технологии 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. Диаграмма классов "Защита доступа"
Таким образом, в результате этого этапа проектирования появляется достаточно подробное описание состава и функций проектируемой системы, а также информации, которую необходимо использовать в базе данных и в приложениях.
Поскольку диаграммы классов строятся на основе разработанных ранее бизнес-моделей, появляется уверенность в том, что разрабатываемая система будет действительно удовлетворять исходным требованиям заказчика.
В то же время, благодаря своему синтаксису, диаграммы классов оказываются хорошим средством структурирования и представления требований к функциональности, интерфейсам и данным для элементов проектируемой системы.
Разработка моделей базы данных и приложений
На этом этапе осуществляется отображение элементов полученных ранее моделей классов в элементы моделей базы данных и приложений:
классы отображаются в таблицы;
атрибуты – в столбцы;
типы – в типы данных используемой СУБД;
ассоциации – в связи между таблицами (ассоциации "многие-ко-многим" преобразуются в ассоциации "один-ко-многим" посредством создания дополнительных таблиц связей);
приложения – в отдельные классы с окончательно определенными и связанными с данными в базе методами и атрибутами.
Поскольку модели базы данных и приложений строятся на основе единой логической модели, автоматически обеспечивается связность этих проектов (рис. 12.12).
Рис. 12.12. Связь между проектами базы данных и приложений
В модель базы данных отображаются только перманентные классы, из которых удаляются атрибуты, не отображаемые в столбцах (например, атрибут типа " Общий объем продаж ", который получается суммированием содержимого множества полей базы данных). Некоторые атрибуты (например, АДРЕС ) могут отображаться в множество столбцов ( СТРАНА, ГОРОД, УЛИЦА, ДОМ, ПОЧТОВЫЙ ИНДЕКС ).
Для каждого простого класса в модели базы данных формируется отдельная таблица, включающая столбцы, соответствующие атрибутам класса.
Отображение классов подтипов в таблицы осуществляется одним из стандартных способов:
одна таблица на класс;
одна таблица на суперкласс;
одна таблица на иерархию.
В первом случае для каждого из классов создается отдельная таблица, между которыми затем устанавливаются необходимые связи. Во втором случае создается таблица для суперкласса, а затем в каждую таблицу подклассов включаются столбцы для каждого из атрибутов суперкласса. В третьем – создается единая таблица, содержащая атрибуты как суперкласса, так и всех подклассов (рис. 12.13). При этом для выделения исходных таблиц подклассов в результирующую таблицу добавляется один или более дополнительных столбцов (на рисунке показан курсивом).
Рис. 12.13. Преобразование иерархии в таблицу
Разработка проекта базы данных осуществляется с использованием специального UML-профиля (Profile for Database Design), который включает следующие основные компоненты диаграмм:
таблица – набор записей базы данных по определенному объекту;
столбец – элемент таблицы, содержащий значения одного из атрибутов таблицы;
первичный ключ (РК) – атрибут, однозначно идентифицирующий строку таблицы;
внешний ключ (FK) – один или группа атрибутов одной таблицы, которые могут использоваться как первичный ключ другой таблицы;
обязательная связь – связь между двумя таблицами, при которой дочерняя таблица существует только вместе с родительской;
необязательная связь – связь между таблицами, при которой каждая из таблиц может существовать независимо от другой;
представление – виртуальная таблица, которая обладает всеми свойствами обычной таблицы, но не хранится постоянно в базе данных;
хранимая процедура – функция обработки данных, выполняемая на сервере;
домен – множество допустимых значений для столбца таблицы.
На рис. 12.14 представлен фрагмент модели базы данных — две таблицы, соответствующие классам " пациент " (рис. 12.3, рис. 12.6) и " минимальный набор данных " (рис. 12.8). Связь между ними обязательная, поскольку " минимальный набор данных " не может существовать без " пациента ".
Рис. 12.14. Фрагмент модели базы данных
На диаграммах указываются дополнительные характеристики таблиц и столбцов:
ограничения – определяют допустимые значения данных в столбце или операции над данными (ключ (PK,FK) – ограничение, определяющее тип ключа и его столбец; проверка (Check) – ограничение, определяющее правило контроля данных; уникальность (Unique) – ограничение, определяющее, что в столбце содержатся неповторяющиеся данные);
триггер – программа, выполняющая при определенных условиях предписанные действия с базой данных;
тип данных и пр.
Результатом этапа является детальное описание проекта базы данных и приложений системы.
Проектирование физической реализации системы
На этом этапе проектирования модели баз данных и приложений дополняются обозначениями их размещения на технических средствах разрабатываемой системы. На рис. 12.15 приведено изображение разделения таблицы " пациент " на три экстента ( <> ) в соответствии с первой буквой фамилии пациента.
Рис. 12.15. Экстенты таблицы "Пациент"
Основными понятиями UML, которые используются на данном этапе, являются следующие:
компонент – самостоятельный физический модуль системы;
зависимость – связь между двумя элементами, при которой изменения в одном элементе вызывают изменения другого элемента;
устройство – узел, не обрабатывающий данные;
процессор – узел, выполняющий обработку данных;
соединение – связь между устройствами и процессорами.
Диаграммы развертывания позволяют отобразить на единой схеме различные компоненты системы (программные и информационные) и их распределение по комплексу технических средств (рис. 12.16).
Рис. 12.16. Фрагмент диаграммы развертывания ИС
Таким образом, при проектировании сложной ИС она разделяется на части, и каждая из них затем исследуется и создается отдельно. В настоящее время используются два различных способа такого разбиения ИС на подсистемы: структурное (или функциональное) разбиение и объектная (компонентная) декомпозиция.
С позиций проектирования ИС суть функционального разбиения может быть выражена известной формулой: " Программа = Данные + Алгоритмы ". При функциональной декомпозиции программной системы ее структура описывается блок-схемами, узлы которых представляют собой "обрабатывающие центры" (функции), а связи между узлами описывают движение данных.
При объектном разбиении в системе выделяются "активные сущности" – объекты (или компоненты), которые взаимодействуют друг с другом, обмениваясь сообщениями и выполняя соответствующие функции (методы) объекта.
Если при проектировании ИС разбивается на объекты, то для ее визуального моделирования следует использовать UML. Если в основу проектирования положена функциональная декомпозиция ИС, то UML не нужен и следует использовать рассмотренные ранее структурные нотации.
В то же время, при выборе подхода к разработке ИС следует учитывать, что визуальные модели все более широко используются в существующих технологиях управления проектированием систем, сложность, масштабы и функциональность которых постоянно возрастают. Они хорошо приспособлены для решения таких часто возникающих при создании систем задач как: физическое перераспределение вычислений и данных, обеспечение параллелизма вычислений, репликация БД, обеспечение безопасности доступа к ИС, оптимизация балансировки нагрузки ИС, устойчивость к сбоям и т.п. Визуализированные средствами UML модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Они обеспечивают ясность представления выбранных архитектурных решений и позволяют понять разрабатываемую систему во всей ее полноте.
13. Практикум: Учебный проект: "Разработка ИС предприятия оптовой торговли лекарственными препаратами"
|
|
Порядок выполнения практического задания
В процессе выполнения практического задания проводится анализ и оформление результатов обследования деятельности гипотетического предприятия "МЕД", и на его основе разрабатываются документы, необходимые для настройки типовой ИС.
По итогам проведения обследования обычно формируются следующие документы:
Предварительная информация.
Видение выполнения проекта и границы проекта.
Отчет об обследовании.
Предварительная информация
Предполагается, что в начале обследования проведен предварительный сбор информации о компании, по итогам которого получены следующие данные:
Краткая информация о компании (профиль клиента).
Цели проекта.
Подразделения и пользователи системы.
На основе предварительной информации сформировано и согласовано с заказчиком общее представление о проекте:
Видение выполнения проекта и границы проекта - документ, который кратко описывает, в каких подразделениях и в какой функциональности будет внедряться ИС.
Затем выполняется детальное обследование предприятия, результаты которого оформляются в виде отдельного документа - отчета об обследовании.
Отчет об обследовании содержит следующие разделы:
Анализ существующего уровня автоматизации.
Составляется список программного обеспечения, используемого в компании, и приводятся данные об использовании этих пакетов в каждом из подразделений организации.
Общие требования к ИС
Формулируются общие требования к функциональности разрабатываемой системы.
Формы документов
Устанавливается перечень и структура документов, которые должны формироваться системой.
Описание системы учета
Описание системы учета включает в себя следующие документы:
Учетная политика компании
План счетов и используемых аналитик
Список типовых хозяйственных операций и их отражение в проводках
Описание справочников
По каждому справочнику, проектируемому в системе, дается описание необходимой иерархической структуры.
Организационная диаграмма
Организационная диаграмма используется для отражения организационной структуры подразделений предприятия и их зон ответственности.
Описание состава автоматизируемых бизнес-процессов
Все бизнес-процессы компании должны быть перечислены в общем списке и каждый должен иметь свой уникальный номер.
Диаграммы прецедентов
Для выделения автоматизируемых бизнес-процессов и их основных исполнителей используются диаграммы прецедентов.
Физическая диаграмма
Физическая диаграмма служит для того, чтобы описать взаимодействие организации на верхнем уровне с внешними контрагентами.
Описания бизнес-процессов (книга бизнес-процессов).
Далее в отчет об обследовании включается книга бизнес-процессов, содержащая подробное описание автоматизируемых бизнес-процессов. Модели бизнес-процессов позволяют выделить отдельные операции, выполнение которых должно поддерживаться разрабатываемой ИС.
На последнем этапе осуществляется отображение модели предметной области на функциональность типовой системы - выбираются модули системы для поддержки выделенных операций, определяются особенности их настройки, выявляется необходимость разработки дополнительных программных элементов.
|
