Проектирование АИС. С аратовский госуниверситет м еханико математический факультет проектирование информационных систем Составил
 Скачать 3.17 Mb.
|
|
10.3 Разработка концептуальной модели данных Затем на основе информации, выявленной на этапах бизнес-моделирования, выполняется разработ- ка концептуальной модели данных, которые будут использоваться в разрабатываемой системе. На Рис. 10.8: Концептуальная модель данных рис. 10.8 представлена в виде диаграммы классов модель данных для объекта "Клинические записи". Модель показывает, что клинические записи включают (агрегируют) ряд блоков. При этом "ми- нимальный набор данных"и "план лечения"могут быть включены в каждую клиническую запись в единственном экземпляре, а блоки "результаты анализов "предписания врача "ход лечения"могут повторяться неограниченное число раз. Архив состоит из множества клинических записей (агрегирует клинические записи), но может быть и пустым. Поскольку пациент может предварительно проходить лечение в других учреждениях, или несколь- ко раз проходить лечение в центре, появляются дополнительные разновидности (подклассы) клини- ческих записей: внешние, старые внутренние, новые внутренние. Этот этап завершает процедуры бизнес-моделирования и позволяет представить команде проек- тировщиков в едином формате ту информацию, которая будет необходима для создания системы. Разработанные диаграммы являются отправной точкой в процессах проектирования баз данных и приложений системы, обеспечивают согласованность действий бизнес-аналитиков и разработчиков в процессе дальнейшей работы над системой. Эти диаграммы, конечно же, будут претерпевать из- менения в процессе последующего проектирования, однако эти изменения будут фиксироваться в формате, уже привычном для всей команды разработчиков, и будут автоматически отражаться в последующих моделях. 10.4 Разработка требований к системе На этапе формирования требований, прежде всего, необходимо определить область действия разра- батываемой системы и получить точное представление о желаемых возможностях системы. Основой разработки требований является модель системных прецедентов, отражающая выполне- ние конкретных обязанностей внутренними и внешними исполнителями с использованием ИС. Источником данных для создания модели системных прецедентов являются разработанные на предыдущем этапе бизнес-модели. Однако при создании модели полезно предварительно составить детальные описания прецедентов, содержащие определения используемых данных и точную после- довательность их выполнения. Описание осуществляется в соответствии с принятым в организации шаблоном, который обычно включает следующие разделы: • заголовок (название прецедента, ответственный за исполнение, дата создания шаблона/внесе- ния изменений); • краткое описание прецедента; • ограничения; • предусловия (необходимое состояние системы или условия, при которых должен выполняться прецедент); • постусловия (возможные состояния системы после выполнения прецедента); • предположения; • основная последовательность действий; • альтернативные последовательности действий и условия, их инициирующие; • точки расширения и включения прецедентов. В процессе создания модели системных прецедентов осуществляется преобразование и перенос компонентов бизнес-моделей на новые диаграммы. Типовые преобразования по технологии Rational Unified Process приведены в таблица 10.1 На рис. 10.9 представлена модель системных прецедентов для бизнес-прецедента "Оказание ме- дицинской помощи". Исходя из цели создания системы, в модели системных прецедентов отражены только те действия исполнителей, которые связаны с предоставлением доступа и обновлением кли- нических записей. Э л е м е нты б из н ес-м о д е ли Э л е м е нты м о д е ли с и сте мных п ре ц ед е нто в Б и зн ес-п ре ц ед енты П од си сте мы Вн ешни е и сп о лнители И сп о лнители Внутре нни е и сп о лнители И сп о лнители или п ре ц ед енты П ро ц ес сы, в ып о лня емы е в нутре нними и сп о лнителями П ре ц ед енты Таблица 10.1: Рис. 10.9: Модель системных прецедентов Описываемые моделью функции характерны только для одного вида деятельности – оказания медицинской помощи, и в основном не используются в других видах деятельности Центра. Это позволяет объединить выделенные функции в некую единую подсистему проектируемой ИС. Внутренний исполнитель "Персонал центра"(см. рис. 10.4 , рис. 10.7 ) и выполняемый им ручной процесс преобразован в системный прецедент "Предоставление доступа к клиническим записям". Внешние исполнители (например, "Производитель медицинского оборудования") непосредственно взаимодействуют с проектируемой системой, т.е. превращаются в исполнителей. В модели отражены два специальных типа связи между прецедентами (на рис. 10.9 соответству- ющие прецеденты выделены тенью): • "включает"— один прецедент в процессе своего исполнения обязательно выполняет некий блок действий, составляющих другой прецедент; • "расширяет"— когда прецеденты подобны по своим действиям, но один несет несколько боль- шую функциональную нагрузку. Прецедент "Проверка прав доступа"впервые появился на диаграммах и реализуется средствами разрабатываемой ИС. Поэтому для него приходится разрабатывать диаграмму последовательностей, описывающую его исполнение (рис. 10.10 ). В результате в проектируемой ИС появляются два новых объекта – программный модуль "Менеджер защиты"и информационный блок "Набор прав". Таким образом, результатом разработки модели системных прецедентов является не только исчер- пывающий перечень функций, которые должны быть реализованы в проектируемой системе, но и подробное описание необходимой реализации этих функций. Анализ требований и предварительное проектирование системы. Основные задачи этапа: Рис. 10.10: Диаграмма последовательностей для прецедента “Проверка прав” • определить проект системы, который будет отвечать всем бизнес-требованиям; • разработать общий предварительный проект для всех команд разработчиков (проектировщиков баз данных, разработчиков приложений, системных архитекторов и пр.) Основным инструментом на данном этапе являются диаграммы классов системы, которые строятся на основе разработанной модели системных прецедентов. Одновременно на этом этапе уточняются диаграммы последовательностей выполнения отдельных прецедентов, что приводит к изменениям в составе объектов и диаграммах классов. Это естественное отражение средствами UML итеративного процесса разработки системы. Диаграммы классов системы заполняются объектами из модели системных прецедентов. Они со- держат описание этих объектов в виде классов и описание взаимодействия между классами. Диаграмма классов, описывающая процедуры защиты доступа к данным, приведена на рис. 10.11 Таким образом, в результате этого этапа проектирования появляется достаточно подробное описа- ние состава и функций проектируемой системы, а также информации, которую необходимо исполь- зовать в базе данных и в приложениях. Поскольку диаграммы классов строятся на основе разработанных ранее бизнес-моделей, появля- ется уверенность в том, что разрабатываемая система будет действительно удовлетворять исходным требованиям заказчика. В то же время, благодаря своему синтаксису, диаграммы классов оказываются хорошим средством структурирования и представления требований к функциональности, интерфейсам и данным для элементов проектируемой системы. Рис. 10.11: Диаграмма классов “Защита доступа” 10.5 Разработка моделей базы данных и приложений На этом этапе осуществляется отображение элементов полученных ранее моделей классов в элемен- ты моделей базы данных и приложений: • классы отображаются в таблицы; • атрибуты – в столбцы; • типы – в типы данных используемой СУБД; • ассоциации – в связи между таблицами (ассоциации "многие-ко-многим"преобразуются в ас- социации "один-ко-многим"посредством создания дополнительных таблиц связей); • приложения – в отдельные классы с окончательно определенными и связанными с данными в базе методами и атрибутами. Поскольку модели базы данных и приложений строятся на основе единой логической модели, автоматически обеспечивается связность этих проектов (рис. 10.12 ). В модель базы данных отображаются только перманентные классы, из которых удаляются атрибу- ты, не отображаемые в столбцах (например, атрибут типа "Общий объем продаж который получается суммированием содержимого множества полей базы данных). Некоторые атрибуты (например, АД- РЕС) могут отображаться в множество столбцов (СТРАНА, ГОРОД, УЛИЦА, ДОМ, ПОЧТОВЫЙ ИНДЕКС). Для каждого простого класса в модели базы данных формируется отдельная таблица, включающая столбцы, соответствующие атрибутам класса. Отображение классов подтипов в таблицы осуществляется одним из стандартных способов: Рис. 10.12: Связь между проектами базы данных и приложений • одна таблица на класс; • одна таблица на суперкласс; • одна таблица на иерархию. В первом случае для каждого из классов создается отдельная таблица, между которыми затем устанавливаются необходимые связи. Во втором случае создается таблица для суперкласса, а за- тем в каждую таблицу подклассов включаются столбцы для каждого из атрибутов суперкласса. В третьем – создается единая таблица, содержащая атрибуты как суперкласса, так и всех подклас- сов (рис. 10.13 ). При этом для выделения исходных таблиц подклассов в результирующую таблицу добавляется один или более дополнительных столбцов (на рисунке показан курсивом). Разработка проекта базы данных осуществляется с использованием специального UML-профиля (Profile for Database Design), который включает следующие основные компоненты диаграмм: • таблица – набор записей базы данных по определенному объекту; Рис. 10.13: Преобразование иерархии в таблицу • столбец – элемент таблицы, содержащий значения одного из атрибутов таблицы; • первичный ключ (РК) – атрибут, однозначно идентифицирующий строку таблицы; • внешний ключ (FK) – один или группа атрибутов одной таблицы, которые могут использоваться как первичный ключ другой таблицы; • обязательная связь – связь между двумя таблицами, при которой дочерняя таблица существует только вместе с родительской; • необязательная связь – связь между таблицами, при которой каждая из таблиц может суще- ствовать независимо от другой; • представление – виртуальная таблица, которая обладает всеми свойствами обычной таблицы, но не хранится постоянно в базе данных; • хранимая процедура – функция обработки данных, выполняемая на сервере; • домен – множество допустимых значений для столбца таблицы. На рис. 10.14 представлен фрагмент модели базы данных — две таблицы, соответствующие клас- сам "пациент"(рис. 10.3 , рис. 10.6 ) и "минимальный набор данных"(рис. 10.8 ). Связь между ними обязательная, поскольку "минимальный набор данных"не может существовать без "пациента". На диаграммах указываются дополнительные характеристики таблиц и столбцов: • ограничения – определяют допустимые значения данных в столбце или операции над данными (ключ (PK,FK) – ограничение, определяющее тип ключа и его столбец; проверка (Check) – ограничение, определяющее правило контроля данных; уникальность (Unique) – ограничение, определяющее, что в столбце содержатся неповторяющиеся данные); Рис. 10.14: Фрагмент модели базы данных • триггер – программа, выполняющая при определенных условиях предписанные действия с ба- зой данных; • тип данных и пр. Результатом этапа является детальное описание проекта базы данных и приложений системы. 10.6 Проектирование физической реализации системы На этом этапе проектирования модели баз данных и приложений дополняются обозначениями их размещения на технических средствах разрабатываемой системы. На рис. 10.15 приведено изобра- жение разделения таблицы "пациент"на три экстента («Tablespace») в соответствии с первой буквой фамилии пациента. Основными понятиями UML, которые используются на данном этапе, являются следующие: • компонент – самостоятельный физический модуль системы; • зависимость – связь между двумя элементами, при которой изменения в одном элементе вы- зывают изменения другого элемента; • устройство – узел, не обрабатывающий данные; • процессор – узел, выполняющий обработку данных; • соединение – связь между устройствами и процессорами. Рис. 10.15: Экстенты таблицы Пациент Рис. 10.16: Фрагмент диаграммы развертывания ИС Диаграммы развертывания позволяют отобразить на единой схеме различные компоненты си- стемы (программные и информационные) и их распределение по комплексу технических средств (рис. 10.16 ). Таким образом, при проектировании сложной ИС она разделяется на части, и каждая из них затем исследуется и создается отдельно. В настоящее время используются два различных способа такого разбиения ИС на подсистемы: структурное (или функциональное) разбиение и объектная (компонентная) декомпозиция. С позиций проектирования ИС суть функционального разбиения может быть выражена известной формулой: "Программа = Данные + Алгоритмы". При функциональной декомпозиции программной системы ее структура описывается блок-схемами, узлы которых представляют собой "обрабатываю- щие центры"(функции), а связи между узлами описывают движение данных. При объектном разбиении в системе выделяются "активные сущности"– объекты (или компонен- ты), которые взаимодействуют друг с другом, обмениваясь сообщениями и выполняя соответствую- щие функции (методы) объекта. Если при проектировании ИС разбивается на объекты, то для ее визуального моделирования следует использовать UML. Если в основу проектирования положена функциональная декомпозиция ИС, то UML не нужен и следует использовать рассмотренные ранее структурные нотации. В то же время, при выборе подхода к разработке ИС следует учитывать, что визуальные мо- дели все более широко используются в существующих технологиях управления проектированием систем, сложность, масштабы и функциональность которых постоянно возрастают. Они хорошо при- способлены для решения таких часто возникающих при создании систем задач как: физическое перераспределение вычислений и данных, обеспечение параллелизма вычислений, репликация БД, обеспечение безопасности доступа к ИС, оптимизация балансировки нагрузки ИС, устойчивость к сбоям и т.п. Визуализированные средствами UML модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Они обеспечивают ясность представления выбранных архитектурных решений и позволяют понять разрабатываемую систему во всей ее полноте. Контрольные вопросы 1. Какие диаграммы используются на этапе описания бизнес-деятельности? Диаграммы деятельности Диаграммы взаимодействия Диаграммы прецедентов Диаграммы последовательностей Диаграммы компонентов 2. Какие диаграммы используются на этапе описания логической модели ИС? Диаграммы развертывания Диаграммы видов деятельности Диаграммы состояний Диаграммы последовательности Диаграммы классов Диаграммы прецедентов 3. Какие диаграммы используются на этапе создания физической модели ИС? Диаграммы прецедентов Диаграммы классов Диаграммы развертывания Диаграммы компонентов Диаграммы деятельности Диаграммы последовательностей 4. Дайте определение понятию актер в UML Разработчик проекта ИС Личность, организация или система, взаимодействующая с ИС Описание совокупности однородных объектов с их атрибутами, операциями, отношениями и семантикой 5. Дайте определение понятию прецедент UML Законченная последовательность действий, инициированная внешним объектом (личностью или системой) Описание совокупности однородных объектов с их атрибутами, операциями, отношениями и семантикой Разработанный ранее прототип ИС 6. Укажите правильные свойства прецедентов Описывает ПОРЯДОК выполнения действий Описывает, ЧТО нужно делать Описывает действия с точки зрения ИСПОЛНИТЕЛЯ Возвращает исполнителю некоторое СООБЩЕНИЕ Может описывать фрагмент действий 7. Укажите основные элементы диаграммы вида деятельности Обозначение класса Обозначение момента синхронизации действий Обозначение действующего лица Обозначение состояния Обозначение действия 8. Укажите основные компоненты модели бизнес-объектов Обозначение действия Обозначение момента синхронизации действий Обозначения внешних и внутренних исполнителей Обозначения бизнес-сущностей, отображающие все, что используют внутренние исполнители для реализации бизнес-процессов 9. Что отражает модель системных прецедентов? Выполнение конкретных обязанностей внутренними и внешними исполнителями с использо- ванием ИС Структуру базы данных ИС Архитектуру ИС Набрано баллов Литература [1] ISO/IEC 12207:1995. [2] Автоматизированные Системы Стадии создания. ГОСТ 34.601-90. — 1997. [3] Бек, К. Экстремальное программирование / К. Бек. — СПб: “Питер”, 2002. [4] Вендров, А. М. Проектирование программного обеспечения экономических информационных систем / А. М. Вендров. — М: “Финансы и статистика”, 2000. [5] Гамма, Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. — СПб: “Питер”, 2007. [6] Грекул, В.И. Проектирование информационных систем / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. — Интернет-университет информационных технологий - ИНТУИТ.ру, 2005. [7] Данилин, А. Архитектура и стратегия. “Инь” и “янь” информационных технологий / А. Да- нилин, А. Слюсаренко. — Интернет-университет информационных технологий - ИНТУИТ.ру, 2005. [8] Козленко, Л. Проектирование информационных систем / Л. Козленко // КомпьютерПресс. — 2001. — Т. 9. 3 [9] Колтунова, Е. Требования к информационной системе и модели жизненного цикла. http: //www.carabisolutions.sp.ru [10] Сузи, Р. А. Язык программирования Python / Р. А. Сузи. — Интернет-университет информаци- онных технологий - ИНТУИТ.ру, БИНОМ. Лаборатория знаний, 2006. — С. 328. Изучается язык программирования Python, его основные библиотеки и некоторые приложения. Реко- мендовано для студентов высших учебных заведений, обучающихся по специальностям в области ин- формационных технологий. Курс посвящен одному из бурно развивающихся и популярных в настоящее время сценарных языков программирования - Python. Язык Python позволяет быстро создавать как про- тотипы программных систем, так и сами программные системы, помогает в интеграции программного обеспечения для решения производственных задач. Python имеет богатую стандартную библиотеку и большое количество модулей расширения практически для всех нужд отрасли информационных техно- логий. Благодаря ясному синтаксису изучение языка не составляет большой проблемы. Написанные на нем программы получаются структурированными по форме, и в них легко проследить логику работы. На примере языка Python рассматриваются такие важные понятия как: объектно-ориентированное програм- мирование, функциональное программирование, событийно-управляемые программы (GUI-приложения), форматы представления данных (Unicode, XML и т.п.). Возможность диалогового режима работы интер- претатора Python позволяет существенно сократить время изучения самого языка и перейти к решению задач в соответствующих предметных областях. Python свободно доступен для многих платформ, а напи- санные на нем программы обычно переносимы между платформами без изменений. Это обстоятельство позволяет применять для изучения языка любую имеющуюся аппаратную платформу. Список иллюстраций 2.1 Каскадная модель ЖЦ ИС 2.2 Поэтапная модель с промежуточным контролем 2.3 Спиральная модель ЖЦ ИС 4.1 Обобщенная схема организационного бизнес- моделирования 4.2 Основные этапы процессно-целевого описания компании 4.3 Полная бизнес-модель компании 4.4 Шаблон разработки миссии (матрица проекций) 4.5 Шаблон разработки миссии 4.6 Шаблон формирования бизнесов 4.7 Шаблон формирования бизнесов (матрица проекций) 4.8 Шаблон формирования основных бизнес-функций 4.9 Шаблон формирования основных функций менеджмента 4.10 Шаблон распределения функций по организационным звеньям 4.11 Потоковая процессная модель 4.12 Функциональная схема компании 4.13 Схема создания Положения об организационно-функциональной структуре компании 4.14 Распределение функций по подразделениям производственного предприятия 5 4.15 Распределение функций по подразделениям торгового предприятия 5.1 Схема управления деятельностью компании 5.2 Упрощенная модель деятельности компании 5.3 Двухуровневая модель деятельности предприятия 5.4 Упрощенная матрица-генератор обеспечивающих бизнес-функций 5.5 Матрица-генератор обеспечивающих бизнес-функций 6.1 Функциональный блок 7.1 Иерархическая классификационная схема 7.2 Организационная структура подразделения предприятия-цеха отгрузки 7.3 Классификатор материальных ресурсов для обеспечения производства 7.4 Схема признаков фасетной классификации 7.5 Элементы электронного документа 8.1 Независимые от идентификации сущности 8.2 Зависимые от идентификации сущности 8.3 Графическое изображение мощности связи 8.4 Неидентифицирующая связь 8.5 Пример характеристической сущности “Хобби” 8.6 Иерархия наследования. Неполная категория 8.7 Иерархия наследования. Полная категория 8.8 Определение первичного ключа для сущности “Сотрудник” 9.1 Изображение класса в UML 9.2 Отображение связей между классами 9.3 Свойства ассоциации 9.4 Связи на диаграммах прецедентов 9.5 Диаграмма последовательности обработки заказа 9.6 Кооперативная диаграмма прохождения заказа 9.7 Диаграмма состояний объекта «заказ» 9.8 Диаграмма деятельности — обработка заказа 9.9 Диаграмма компонентов фрагмента КИС 10.1 Взаимосвязи между диаграммами UML 10.2 Общая диаграмма деятельности медицинского центра по обслуживанию пациента 10.3 Модель бизнес-прецедентов, составляющих обслуживание пациента 10.4 Диаграмма видов деятельности для прецедента “Оказание медицинской помощи” 10.5 Модель бизнес-объектов прецедента “Ответ на запрос” 10.6 Обобщение классов 10.7 Диаграмма последовательностей для прецедента “Ответ на запрос” 10.8 Концептуальная модель данных 10.9 Модель системных прецедентов 10.10Диаграмма последовательностей для прецедента “Проверка прав” 10.11 Диаграмма классов “Защита доступа” 10.12 Связь между проектами базы данных и приложений 10.13Преобразование иерархии в таблицу 10.14Фрагмент модели базы данных 10.15Экстенты таблицы Пациент 10.16Фрагмент диаграммы развертывания ИС Список таблиц 3.1 Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207) 10.1 8 Предметный указатель ИС автоматические, 94 ИС автоматизированные, 94 ИС автоматизированного проектирования, 95 ИС документальные, 94 ИС фактографические, 94 ИС функциональные, 96 ИС информационно-поисковые, 95 ИС информационно-решающие, 95 ИС корпоративные, 98 ИС оперативного уровня, 96 ИС организационного управления, 94 ИС ручные, 94 ИС советующие, 96 ИС стратегическая, 96 ИС управления технологическими процессами, 95 ИС управляющие, 95 экстремальное программирование, 35 коллизия, 17 модель каскадная, 3 модель поэтапная, 3 модель спиральная, 3 рефакторинг, 39 техническое задание, 11 типовое проектное решение, 22 жизненный цикл, 3 CRC, 39 UnitTest, 49 UserStory, 49 XP большой босс, 37 XP дипломат, 38 XP инструктор, 37 9 XP консультант, 38 XP наблюдатель, 37 XP приёмщик, 37 XP программист, 37 XP разработчик, 36 XP составитель историй, 37 XP заказчик, 35 |