3. Описание функциональной модели «Как надо»

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

Рассматриваемая функциональная модель предназначена для описания идеального положения вещей (модель «Как надо»). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы.

Построение модели начинается с описания функционирования системы в целом в виде контекстной диаграммы. На рисунке 1 представлена контекстная диаграмма системы

Рисунок 3 – Контекстная диаграмма

Для процесса «Учет услуг платной поликлиники» входным потоком является «Незарегистрированный пациент».

Выходными потоками системы является потоки «Отчеты», «Прибыль».

После описания контекстной диаграммы проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно. Затем, каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме. На рисунке 2 представлен второй уровень декомпозиции.

Рисунок 4 – Второй уровень декомпозиции

На втором уровне декомпозиции процесс «Учет услуг платной поликлиники» разбивается на четыре подпроцесса:

1. Регистрация пациента;

2. Запись на прием;

3. Выбор и предоставление услуг;

4. Оплата услуг;

Ниже представляются декомпозиции каждого процесса.

Рисунок 5 – Декомпозиция процесса «Регистрация пациента»

Процесс «Регистрация пациента» делится на подпроцессы:

1. Ввод данных пациента;

2. Запись в БД;

3. Создание карточки пациента;

Рисунок 6 - Декомпозиция процесса «Запись на прием»

Процесс «Запись на прием» делится на подпроцессы:

1. Выбор врача и времени;

2. Запись направления в БД;

3. Выдача направления;

Рисунок 7 - Декомпозиция процесса «Выбор и предоставление услуг»

Процесс «Выбор и предоставление услуг» делится на подпроцессы:

1. Прием у врача;

2. Оказание необходимых услуг;

3. Оформление договора;

4. Техническое задание

Введение

Настоящее техническое задание, оформленное в соответствии с ГОСТ 19.201-78, содержит требования к информационной системе платной поликлиники.

Основание для разработки

Основанием для разработки калькулятора является задание по дисциплине “Технология разработки программного обеспечения”.

Исполнитель и заказчик

Заказчиком разработки, выполняемой по-настоящему ТЗ, является Восточно-Сибирский государственный университет технологии и управления.

Исполнителем разработки, выполняемой по-настоящему ТЗ, является студент группы Б-654 Суханов С.Н.

Наименование

Программе, разрабатываемой по-настоящему ТЗ, присваивается наименование:

"Информационная система для платной поликлиники".

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

Требования к составу выполняемых функций

Модуль «Запись на прием» должен выполнять следующие функции:

1. Выводить списки всех работающих специалистов;

2. Записывать персональные данные пациента;

3. Выводить доступное время в заданный день;

4. Заносить информацию в базу данных;

Модуль «Создание договора» должен выполнять следующие функции:

1. Выводить список пациентов;

2. Создавать список медицинских услуг;

3. Подсчитывать итоговою стоимость лечения;

4. Генерировать договор в docx-формате;

Полное техническое задание приведено в приложении А.

2. Проектирование

   1. Проектирование логической модели данных

С помощью программного продукта ERwin Date Modeler 7 проектируется логическая модель данных.

Рисунок 8 – Логическая модель данных

Логическая модель является универсальной, она не связана с конкретной реализацией СУБД, для атрибутов используются абстрактные типы данных.

2. Проектирование физической модели данных

Из логической модели данных средствами среды ERwin Date Modeler 7 сгенерирована физическая модель.

Рисунок 9 – Физическая модель данных

3. Проектирование системы на языке UML

Унифицированный язык моделирования (Unified Modeling Language (UML)) — это стандартный язык спецификации, визуализации, построения и документирования артефактов автоматизированной системы, применяется в бизнес – моделировании и других сферах, связанных с разработкой программного обеспечения. UML представляет собой ряд лучших инженерных нотаций, которые прошли успешную проверку в моделировании больших и комплексных систем. UML является одной из наиболее важных частей разработки объектно - ориентированных программ и процесса разработки программного обеспечения. UML использует по большей части графические нотации, выражающие дизайн проекта автоматизированной системы. Использование UML помогает взаимодействовать проектной команде, рассматривать потенциальные схемы и проверять архитектурный план программного продукта.

1. Диаграмма прецедентов

Диаграмма прецедентов описывает функциональность ИС, которая будет видна пользователям системы. Каждая функциональность изображается в виде прецедентов. На рисунке 8 изображена диаграмма прецедентов для ИС платной поликлиники.

Рисунок 10 – Диаграмма прецедентов

Вариант использования: Выбор врача

Контекст использования: Пользователь выбирает специалиста.

Область: Система

Уровень: Цель пользователя

Основной актер: Пользователь

Предусловие: Нет

Успешное постусловие: Открыто окно записи на прием

Минимальные гарантии: Окно записи на прием не открыто

Триггер: Кнопка «Записаться на прием»

Основной сценарий

1. Пользователь выбирает специалиста из списка.

2. Пользователь нажимает на кнопку «Записаться на прием».

3. Система проверяет, выбран ли специалист.

4. Система открывает окно записи на прием.

Расширения

3.a. Специалист не выбран:

3.а.1. Система уведомляет об ошибке.

3.а.2. Возврат сценария на пункт 1.

Вариант использования: Запись на прием

Контекст использования: Пользователь записывается на прием.

Область: Система

Уровень: Цель пользователя

Основной актер: Пользователь

Предусловие: Пользователь открыл окно записи на прием

Успешное постусловие: Пользователь записан на прием и внесен в базу

Минимальные гарантии: Пользователь не записан на прием и не внесен в базу

Триггер: Кнопка «Записаться»

Основной сценарий

1. Пользователь вводит персональные данные.

2. Пользователь выбирает дату в календаре.

3. Пользователь выбирает время приема из списка.

4. Система проверяет заполнение полей.

5. Система записывает пользователя на выбранное время

Расширения

4.a. Поля не заполнены:

4.а.1. Система уведомляет об ошибке.

4.а.2. Возврат сценария на пункт

2. Диаграмма состояний

Главное предназначение диаграммы состояния – описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. На рисунке 9 представлена диаграмма состояния для объекта «Договор».

Рисунок 11 – Диаграмма состояний

3. Диаграмма деятельности

Диаграмма деятельности представляют переходы потока управления между объектами от одной деятельности к другой внутри системы. Для прецедента «Создание договора» построена диаграмма деятельности, представленная на рисунке 10.

Рисунок 12 – Диаграмма деятельности для прецедента «Создание договора»

На рисунке 11 изображена диаграмма деятельности для прецедента «Запись на прием».

Рисунок 13 – Диаграмма деятельности для прецедента «Запись на прием»