70606

Разработка требований к системе

Лекция

Информатика, кибернетика и программирование

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

Русский

2014-10-23

185.11 KB

3 чел.

Лекция 43

Разработка требований к системе

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

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

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

  1.  заголовок (название прецедента, ответственный за исполнение, дата создания шаблона/внесения изменений);
  2.  краткое описание прецедента;
  3.  ограничения;
  4.  предусловия (необходимое состояние системы или условия, при которых должен выполняться прецедент);
  5.  постусловия (возможные состояния системы после выполнения прецедента);
  6.  предположения;
  7.  основная последовательность действий;
  8.  альтернативные последовательности действий и условия, их инициирующие;
  9.  точки расширения и включения прецедентов.

В процессе создания модели системных прецедентов осуществляется преобразование и перенос компонентов бизнес-моделей на новые диаграммы. Типовые преобразования по технологии Rational Unified Process приведены в таблица 12.1.

Таблица 12.1.

Элементы бизнес-модели

Элементы модели системных прецедентов

Бизнес-прецеденты

Подсистемы

Внешние исполнители

Исполнители

Внутренние исполнители

Исполнители или прецеденты

Процессы, выполняемые внутренними исполнителями

Прецеденты

На рис. 12.9 представлена модель системных прецедентов для бизнес-прецедента " Оказание медицинской помощи ". Исходя из цели создания системы, в модели системных прецедентов отражены только те действия исполнителей, которые связаны с предоставлением доступа и обновлением клинических записей.


Рис. 12.9. Модель системных прецедентов

Описываемые моделью функции характерны только для одного вида деятельности – оказания медицинской помощи, и в основном не используются в других видах деятельности Центра. Это позволяет объединить выделенные функции в некую единую подсистему проектируемой ИС.

Внутренний исполнитель " Персонал центра " (см. рис. 12.4, рис. 12.7) и выполняемый им ручной процесс преобразован в системный прецедент " Предоставление доступа к клиническим записям ".

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

В модели отражены два специальных типа связи между прецедентами (на рис. 12.9 соответствующие прецеденты выделены тенью):

  1.  " включает " — один прецедент в процессе своего исполнения обязательно выполняет некий блок действий, составляющих другой прецедент;
  2.  " расширяет " — когда прецеденты подобны по своим действиям, но один несет несколько большую функциональную нагрузку.

Прецедент " Проверка прав доступа " впервые появился на диаграммах и реализуется средствами разрабатываемой ИС. Поэтому для него приходится разрабатывать диаграмму последовательностей, описывающую его исполнение ( рис. 12.10). В результате в проектируемой ИС появляются два новых объекта – программный модуль " Менеджер защиты " и информационный блок " Набор прав ".


Рис. 12.10. Диаграмма последовательностей для прецедента "Проверка прав"

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

Анализ требований и предварительное проектирование системы.

Основные задачи этапа:

  1.  определить проект системы, который будет отвечать всем бизнес-требованиям;
  2.  разработать общий предварительный проект для всех команд разработчиков (проектировщиков баз данных, разработчиков приложений, системных архитекторов и пр.)

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

Диаграммы классов системы заполняются объектами из модели системных прецедентов. Они содержат описание этих объектов в виде классов и описание взаимодействия между классами.

Диаграмма классов, описывающая процедуры защиты доступа к данным, приведена на рис. 12.11.

Разработка моделей базы данных и приложений

На этом этапе осуществляется отображение элементов полученных ранее моделей классов в элементы моделей базы данных и приложений:

  1.  классы отображаются в таблицы;
  2.  атрибуты – в столбцы;
  3.  типы – в типы данных используемой СУБД;
  4.  ассоциации – в связи между таблицами (ассоциации "многие-ко-многим" преобразуются в ассоциации "один-ко-многим" посредством создания дополнительных таблиц связей);
  5.  приложения – в отдельные классы с окончательно определенными и связанными с данными в базе методами и атрибутами.

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


Рис. 12.12. Связь между проектами базы данных и приложений

В модель базы данных отображаются только перманентные классы, из которых удаляются атрибуты, не отображаемые в столбцах (например, атрибут типа " Общий объем продаж ", который получается суммированием содержимого множества полей базы данных). Некоторые атрибуты (например, АДРЕС ) могут отображаться в множество столбцов ( СТРАНА, ГОРОД, УЛИЦА, ДОМ, ПОЧТОВЫЙ ИНДЕКС ).

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

Отображение классов подтипов в таблицы осуществляется одним из стандартных способов:

  1.  одна таблица на класс;
  2.  одна таблица на суперкласс;
  3.  одна таблица на иерархию.

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


Рис. 12.13. Преобразование иерархии в таблицу

Разработка проекта базы данных осуществляется с использованием специального UML-профиля (Profile for Database Design), который включает следующие основные компоненты диаграмм:

  1.  таблица – набор записей базы данных по определенному объекту;
  2.  столбец – элемент таблицы, содержащий значения одного из атрибутов таблицы;
  3.  первичный ключ (РК) – атрибут, однозначно идентифицирующий строку таблицы;
  4.  внешний ключ (FK) – один или группа атрибутов одной таблицы, которые могут использоваться как первичный ключ другой таблицы;
  5.  обязательная связь – связь между двумя таблицами, при которой дочерняя таблица существует только вместе с родительской;
  6.  необязательная связь – связь между таблицами, при которой каждая из таблиц может существовать независимо от другой;
  7.  представление – виртуальная таблица, которая обладает всеми свойствами обычной таблицы, но не хранится постоянно в базе данных;
  8.  хранимая процедура – функция обработки данных, выполняемая на сервере;
  9.  домен – множество допустимых значений для столбца таблицы.

На рис. 12.14 представлен фрагмент модели базы данных — две таблицы, соответствующие классам " пациент " ( рис. 12.3, рис. 12.6) и " минимальный набор данных " ( рис. 12.8). Связь между ними обязательная, поскольку " минимальный набор данных " не может существовать без " пациента ".


Рис. 12.14. Фрагмент модели базы данных

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

  1.  ограничения – определяют допустимые значения данных в столбце или операции над данными (ключ (PK,FK) – ограничение, определяющее тип ключа и его столбец; проверка (Check) – ограничение, определяющее правило контроля данных; уникальность (Unique) – ограничение, определяющее, что в столбце содержатся неповторяющиеся данные);
  2.  триггер – программа, выполняющая при определенных условиях предписанные действия с базой данных;
  3.  тип данных и пр.

Результатом этапа является детальное описание проекта базы данных и приложений системы.

Проектирование физической реализации системы

На этом этапе проектирования модели баз данных и приложений дополняются обозначениями их размещения на технических средствах разрабатываемой системы. На рис. 12.15 приведено изображение разделения таблицы " пациент " на три экстента ( <<Tablespace>> ) в соответствии с первой буквой фамилии пациента.


Рис. 12.15. Экстенты таблицы "Пациент"

Основными понятиями UML, которые используются на данном этапе, являются следующие:

  1.  компонент – самостоятельный физический модуль системы;
  2.  зависимость – связь между двумя элементами, при которой изменения в одном элементе вызывают изменения другого элемента;
  3.  устройство – узел, не обрабатывающий данные;
  4.  процессор – узел, выполняющий обработку данных;
  5.  соединение – связь между устройствами и процессорами.

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


Рис. 12.16. Фрагмент диаграммы развертывания ИС

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

С позиций проектирования ИС суть функционального разбиения может быть выражена известной формулой: " Программа = Данные + Алгоритмы ". При функциональной декомпозиции программной системы ее структура описывается блок-схемами, узлы которых представляют собой "обрабатывающие центры" (функции), а связи между узлами описывают движение данных.

При объектном разбиении в системе выделяются "активные сущности" – объекты (или компоненты), которые взаимодействуют друг с другом, обмениваясь сообщениями и выполняя соответствующие функции (методы) объекта.

Если при проектировании ИС разбивается на объекты, то для ее визуального моделирования следует использовать UML. Если в основу проектирования положена функциональная декомпозиция ИС, то UML не нужен и следует использовать рассмотренные ранее структурные нотации.

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


Рис. 12.11. Диаграмма классов "Защита доступа"

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

7483. Поняття про основні галузі господарства і технології, які в них застосовуються. Правила внутрішнього розпорядку і правила безпечної роботи в шкільних майстернях 24.45 KB
  Мета: ознайомити учнів із програмою й обєктами праці, основними галузями виробництва, із прикладами технологій, які в них застосовуються; повторити правила внутрішнього розпорядку і безпечної роботи в шкільних майстернях, навчити характе-ризувати основні галузі виробництва і види технологій
7484. Мифы народов мира, мифологическая энциклопедия в двух томах. Анализ 59.54 KB
  Мифы народов мира, мифологическая энциклопедия в двух томах, под ред. С.А. Токарева, М.: Советская энциклопедия, 1980 том I, стр. 321-335 Сущность греческой мифологии становится понятной только при учете особенностей первобытнообщинного строя...
7485. Древнегреческая мифология и религия 20.89 KB
  Древнегреческая мифология и религия - религия и мифология древних греков (эллинов).  По мнению авторитетного исследователя античной мифологии А.Ф. Лосева, сущность греческой мифологии определяется особенностями первобытнообщинного строя греков,...
7486. Христианская мифология 79.5 KB
  Христианская мифология, комплекс представлений, образов, наглядных символов, связанных с религиозной доктриной христианства и развивающихся во взаимодействии этой доктрины с фольклорными традициями народов. Соотношение между христианской доктриной и...
7487. Психология. Понятие о психологии 235.5 KB
  Психология. Тема 1.1. Понятие о психологии. Научное определение психологии, и ее аспекты, этапы становления. Общая психология в современном представлении. Отрасли психологии. 1 Психология - это наука о психике человека и...
7488. Педагогическая психология. Предмет, задачи, методы педагогической психологии 60 KB
  Педагогическая психология. Тема 2.1. Предмет, задачи, методы педагогической психологии. Современная педагогическая психология и предмет ее изучения. Проблемы и задачи современной педагогической психологии. Методы педагогической пси...
7489. Педагогика. Предмет и основные категории педагогики 88.5 KB
  Педагогика. Тема 3.1. Предмет педагогики. Предмет и основные категории педагогики. История и классовый характер воспитания. Связь педагогики с другими науками. 1. Предмет и основные категории педагогики. К числу основных понятий пе...
7490. Приёмы игры на гитаре 26.44 KB
  План школьного открытого урока Приёмы игры на гитаре Добрый день, уважаемые преподаватели. Тема моего открытого урока: Приёмы игры на гитаре Сегодня открытый урок я проведу с учеником 4-го класса Иваном Мотузом...
7491. Возникновение и развитие философии марксизма 34 KB
  Возникновение и развитие философии марксизма Основателем этой философии были Карл Маркс (1818 - 1883) и Фридрих Энгельс (1820 - 1895). К. Маркс учился на юридическом факультете, его выпускная диссертация была на тему Различия натуралистического...