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

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

• визуализации общей структуры исходного кода программной системы;
• спецификации исполняемого варианта программной системы;
• обеспечения многократного использования отдельных фрагментов программного кода;
• представления концептуальной и физической схем баз данных.

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

Также на диаграмме изображены интерфейсы "Справочник" - для предоставления данных в виде справочника, интерфейс "Форма" - представление данных на форме, интерфейс "Меню" - меню выбора действий.

 

 

 

 

 

 

 

 

2.6 Диаграмма размещения (развертывания)

Диаграмма развертывания (рис.9) предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов.

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

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

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

 

На диаграмме выделены два узла – клиент и сервер. На сервере  находится два объекта “execution environment” – среды исполнения, представляющие собой сервер веб-приложения и среда, поддерживающая базу данных. В качестве “artifact” на сервере представляются страницы, с которыми могут работать определенные категории пользователей. На узле клиент представлено описание относительно поддерживаемых браузеров при обращении к веб-сервису и возможное их количество при одновременном доступе.

 

3. Разработка и реализация тестов

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. Сценарий тестов «Корректность данных»

Пользователь  Система

Ввод данных

    Анализ данных

Сообщение

Сценарий выполнения:

1.1 Корректность добавления нового пациента
Тест 1.1.1	Фамилия = «» Имя = «Ольга» Отчество = «Петровна» Сообщение  = «Поле для ввода  пустое»
Тест 1.1.2	Фамилия = «Исаева» Имя = «121212» Отчество = «Петровна» Сообщение  = «Неверно заполнено поле - Имя»
Тест 1.1.3	Фамилия = «Исаева23» Имя = «Ольга» Отчество = «Петровна» Сообщение  = «Неверно заполнено  поле - Имя»
Тест 1.1.4	Дата рождения = «29.12.2011» Адрес = «» Сообщение = «Поле для ввода пустое»
Тест 1.1.5	Дата рождения = «29.17.2011» Адрес = «ул. Вязовая 94-78, г. Челябиснк» Сообщение = «Неверно введена дата»

 

 

2. Проверка быстродействия поиска  пациента:

1) Ввод данных для фильтрации

2) Обработка данных системой

3. Вычисление времени на ответ

Сценарий тестов для блока «Быстродействие»:

Пользователь   Система

Ввод данных

     Обработка данных

Ответ в виде времени

 

Таблица 2 – Тесты на быстродействие

Номер теста	Введенные данные	Время
2.1.1	Фамилия	< 60 мс
2.1.2	Имя	< 30 мс
2.1.3	Отчество	< 20 мс
2.1.4	Адрес	< 60 мс

 

3. Тестирование на корректность  совместного использования:

1) Редактирование истории болезни  врачом

2) Поиск истории болезней пациента администратором

Сценарий тестов для блока «Совместное  использование»:

Пользователь    Система

Запрос на редактирование  

Запись в базу

Запрос на поиск

Запись в базу

 

Статус-сообщение

 

 

 

Таблица 3 – Тесты на совместное использование

Номер теста	Введенные данные	Статус-сообщение
3.1.1	Редактирование.История_болезни = Поиск. История_болезни	Ошибка
3.1.2	Редактирование.История_болезни != Поиск. История_болезни	Завершено

 

4 Оценка характеристик разработанной модели системы

4.1 Набор метрик Чидамбера и Кемерера

Метрика 1: Взвешенные методы на класс WMC (Weighted Methods Per Class)

Данная метрика определяет количество методов класса, тем самым дает относительную меру сложности класса.

Метрика 2: Высота дерева наследования DIT (Depth of Inheritance Tree)

DIT определяется как максимальная  длина пути от листа до корня  дерева наследования классов.

Метрика 3: Количество детей NOC (Number of children)

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

Метрика 4: Сцепление между  классами объектов СВО (Coupling between object classes)

СВО — это количество сотрудничеств, предусмотренных для класса, то есть количество классов, с которыми он соединен. Соединение означает, что методы данного  класса используют методы или экземплярные переменные другого класса.

Метрика 5: Отклик для  класса RFC (Response For a Class)

Метрика RFC является мерой потенциального взаимодействия данного класса с  другими классами, позволяет судить о динамике поведения соответствующего объекта в системе. Данная метрика характеризует динамическую составляющую внешних связей классов.

Метрика 6: Недостаток связности  в методах LСOM (Lack of Cohesion in Methods)

Метрика LCOM показывает, насколько  методы не связаны друг с другом через свойства (переменные).

 

Рисунок 11 – Диаграмма классов для расчета метрик

 

Таблица 4 – Расчет метрик Чидамбера-Кемерера

	WMC	DIT	NOC	CBO	RFC	LCOM
Роль	0	0	2	2	2	0
Врач	2	1	0	2	4	1
Администратор	3	1	0	3	6	3
История болезней	3	1	0	2	5	0
Отчеты	2	0	0	1	3	0
Талоны	1	0	0	2	3	0
Справочник	4	0	2	2	6	0
ВрачФИО	1	1	0	2	3	0

 

Метрика RFC определяет возможное  выполнение методов классом как  собственным так и наследуемым, рассчитывается так: WMC + CBO.

Для вычисления метрики LCOM для начала необходимо определить количество пар методов класса. Оно рассчитывается по формуле

,

где m – количество методов класса.

Классы врач, отчеты имеют  по 2 метода, соответственно по 1 паре.

Методы в классе врач не связаны друг другом, это значит, что значение LCOM=1. Методы «Сформировать» и «Удалить» в классе отчеты взаимодействуют с одними и теме же параметрами и LCOM=0.

LCOM = 3 для класса администраторы, так как пары методов не взаимодействуют друг с другом. История болезней имеет методы добавить, изменить и удалить, которые работают с одними и теме же полями. В справочнике методы связаны между собой, так как работают с одними и теме же данными, которые связаны по коду. Талоны и ВрачФИО имеют по одному методу, поэтому очевидно, что LCOM = 0.

 

 

Заключение

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

 

1.  Методическое пособие: «Метрические особенности объектно-ориентированных программных систем»
2. Технологии разработки программного обеспечения: Учебник/ С. Орлов. – СПб.: Питер, 2002. – 464 с.
3. Самоучитель UML. Леоненков А.В. – Издательство: БХВ-Петербург, 2007. г. – 576 с.
4. Сайт http://www.info-system.ru/ // http://www.info-system.ru/designing/methodology/uml/theory/theory.html