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. Диаграмма классов "Защита доступа"

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

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

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


 

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

81885. Внешняя среда организации 41.32 KB
  Подвижность среды это скорость с которой происходят изменения в окружении организации. Среда прямого воздействия включает факторы которые непосредственно влияют на операции организации и испытывают на себе прямое влияние операций организации. Зависимость между организацией и сетью поставщиков обеспечивающих ввод указанных ресурсов один из наиболее ярких примеров прямого воздействия среды на операции и успешность деятельности организации.
81886. Понятие и классификация структур управления 34.87 KB
  В рамках структуры управления протекает весь управленческий процесс в котором участвуют менеджеры всех уровней категорий и профессиональной специализации. Структура управления простая совокупность способов посредством которых процесс труда сначала разделяется на отдельные рабочие задачи а затем достигается координация действий по решению задачи. Типы организационных структур: Иерархический тип структура которая характеризуется высокой степенью разделения труда иерархией управления многочисленными нормами и правилами поведения.
81887. Основные элементы структуры управления 39.32 KB
  Под структурой управления организацией понимается упорядоченная совокупность взаимосвязанных элементов находящихся между собой в устойчивых отношениях обеспечивающих их развитие и функционирование как единого целого. Элементами структуры управления являются. Структура управления характеризуется наличием связей между её элементами.
81888. Иерархические структуры управления 38.72 KB
  Соблюдение этого принципа должно обеспечивать единство управления. Такая организационная структура образуется в результате построения аппарата управления из взаимоподчинённых органов в виде иерархической лестницы т. Функциональная организационная структура основана на создании подразделений для выполнения определённых функций на всех уровнях управления.
81889. Принципы «рациональной бюрократии» Макса Вебера как основа иерархических структур управления 38.18 KB
  Бюрократия рассматривалась им как некий идеальный образ наиболее эффективный инструмент управления социальными структурами и отдельными структурными единицами. Бюрократию как рациональную машину управления характеризуют: жесткая ответственность за каждый участок работы: координация во имя достижения организационных целей; оптимальное действие безличных правил; четкая иерархическая зависимость. Однако позже Вебер стал различать бюрократию в позитивном смысле западная рациональная система управления и в негативном смысле восточная...
81890. Достоинства и недостатки линейной структуры управления 36.39 KB
  Другими словами все функции управления и подчинения сосредотачиваются у руководителя создается вертикальная линия управления и прямой путь воздействия на подчиненных Преимущества линейной структуры управления: Создает реальные условия для единоначалия обеспечивает единство распоряжения в системе управления ориентирует руководителей в основном на решение оперативных задач. Простота управления один канал связи. Недостатки линейной структуры управления: Высокие требования к руководителю который должен быть подготовлен всесторонне.
81891. Достоинства и недостатки линейно-функциональной системы управления 35.61 KB
  Преимущества линейнофункциональной структуры управления: Обеспечивает соблюдение принципа единоначалия и в то же время предполагает рациональную специализацию управленческих звеньев. Недостатки линейнофункциональной структуры управления: Отсутствие тесных взаимосвязей и взаимодействия на горизонтальном уровне между производственными отделениями.
81892. Органические структуры управления 39.41 KB
  При такой организации руководитель проекта взаимодействует с двумя группами подчиненных: с постоянными членами проектной группы и с другими работниками функциональных отделов которые подчиняются ему временно и по ограниченному кругу вопросов. Проектные структуры это структуры управления комплексными видами деятельности которые изза их решающего значения для организации требуют обеспечения непрерывного координирующего и интегрирующего воздействия при жестких ограничениях по затратам срокам и качеству работ. Сетевые организации ...
81893. Достоинства и недостатки матричной структуры управления 38.04 KB
  Достоинства: Одновременное использование нескольких видов деятельности в рамках осуществляемых программ. В рамках системы нет четкого распределения прав каждого участника потому наблюдается тенденция к анархии. Очень часто начинается борьба за власть в рамках внедрения этой системы потому что руководствующие полномочия четко не распределены.