ВКР_Макаревич П.Е (1218757), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Рисунок 2.1 – Контекстная диаграмма вариантов использования

На рисунке 2.1 можно увидеть:

• всех актеров системы:

1. работник стола справок: ответственен за ведение архива медицинских карт и первичную регистрацию новорожденных;

2. заведующий отделением: дальнейшее ведение журнала новорожденных, дальнейшее ведение журнала инфекционных заболеваний, формирование квартальных и годовых отчетов;

3. врач-инфекционист: ведение журнала регистрации случаев инфекционных заболеваний;

• варианты использования системы (комментарии – на диаграмме):

1. учет архивных карт;

2. учет новорожденных;

3. учет инфекционных заболеваний;

4. формирование отчетов.

Далее представлены диаграммы декомпозиции основных вариантов использования. Они позволяют подробнее рассмотреть довольно крупные функциональные блоки системы. Диаграмма декомпозиции варианта использования «Учет архивных карт» представлена на рисунке 2.3. Она отображает все возможные «подварианты» использования. Отношение включения (стереотип «include») указывает, что некоторое заданное поведение одного варианта использования обязательно включается в качестве составного компонента в последовательность поведения другого варианта использования. Отношение расширения (стереотип «extend») определяет потенциальную возможность включения поведения одного варианта использования в состав другого [12].

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

Рисунок 2.2 – Диаграмма декомпозиции варианта использования «Учет архивных карт»

На диаграмме декомпозиции варианта использования «Учет архивных карт», изображенной на рисунке 2.3, также представлены «подварианты», реализующие выдачу архивных карт на руки, а также утилизацию карт по истечению установленного срока.

Рис. 2.3 – Диаграмма декомпозиции варианта использования «Учет новорожденных»

На диаграмме декомпозиции варианта использования «Учет новорожденных», изображенной на рисунке 2.3, представлена также и возможность редактирования справочника улиц (одноименный вариант использования).

Рис. 2.4 – Диаграмма декомпозиции варианта использования «Учет инфекционных заболеваний»

2.2 Модель анализа

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

Построение этой модели необходимо:

• для выявления внутренней архитектуры (определения основных подсистем и классов);

• поиска альтернативных вариантов реализации системы (подсистем) и выбора основного;

• уточнения всех требований (функциональных и нефункциональных) [13].

Диаграмма классов анализа

Диаграмма классов анализа по существу является прообразом классической диаграммы классов. Элементами, отображаемыми на диаграмме, являются классы и отношения между ними.

Разновидности классов анализа:

• граничный класс – используется для моделирования взаимодействия между системой и актерами (пользователями, внешними системами или устройствами);

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

• класс сущности – используется для моделирования долгоживущей, нередко сохраняемой информации. Классы сущности являются абстракциями основных понятий предметной области – людей, объектов, документов и т. д., как правило, хранимых в табличном или ином виде [14].

Связи между классами анализа отображаются с использованием отношений пяти видов:

• ассоциаций;

• агрегаций;

• композиций;

• обобщения;

• зависимостей [15].

На рисунке 2.5 представлена диаграмма классов анализа системы «PolyClinic».

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

Во время работы программы информация из БД считывается в объекты класса «Таблица» (DataSet), обрабатывается объектами других классов и при необходимости обратно записывается в БД. За каждым диалоговым окном, предназначенным для работы с БД, закрепляется объект класса «Таблица».

Как видно из диаграммы, взаимодействие с пользователями системы происходит с помощью граничных классов:

• Главное диалоговое окно;

• Меню;

• Панель инструментов;

• Вкладка «Архив»;

• Вкладка «Новорожденные»;

• Вкладка «Инфекционные заболевания»;

• Вкладка «Пользователи»;

• Диалоговое окно «Отчеты»;

• Диалоговое окно «Адресатор»

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

• модификация данных:

1. модификация данных о картах;

2. модификация данных о новорожденных;

3. модификация данных о заболеваниях;

• модификация прав;

• формирование отчета;

• актуализация данных.

Следующая важная сущность – класс «Соединение с БД». Через этот класс происходит соединение с БД и всеми ее таблицами [16].

Рисунок 2.5 – Диаграмма классов анализа

2.3 Модель проектирования

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

Построение этой модели необходимо:

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

• уточнения требований;

• определения детализированных алгоритмов работы системы в целом и ее отдельных элементов [17].

2.3.1 Диаграммы классов

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

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

Первая пара диаграмм, представленная на рисунках 2.6 и 2.7, отражает программные классы будущей системы.

Абстрактный класс «Контроллер» предоставляет инструменты для формирования и выполнения различных SQL-инструкций. Он наследуется следующими классами:

• контроллер архива;

• контроллер пользователей;

• контроллер журнала новорожденных;

• контроллер журнала инфекционных заболеваний;

• составитель отчетов.

Класс Соединение отвечает за хранение строки подключения к базе данных, хранение имени, хэша пароля и прав доступа текущего пользователя, реализацию открытия/закрытия соединения и чтения прав доступа.

Также на диаграмме представлено несколько стандартных классов C#, которые реализуют хранение данных и представление их на форме.

Рисунок 2.6 – Концептуальная диаграмма классов системы (код)

Рисунок 2.7 – Физическая (C#) диаграмма классов системы (код)

Вторая пара диаграмм раскрывает структуру базы данных системы.

Таблица 1 – Краткое описание таблиц

Из диаграмм видно, что часть полей (отмеченная знаком *) является обязательной для заполнения при добавлении записи в таблицу. Знаком # обозначены первичные ключи таблиц.

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

Рисунок 2.8 – Концептуальная диаграмма классов системы (БД)

Рисунок 2.9 – Физическая (MS SQL Server 2008) диаграмма классов системы (БД)

2.3.2 Диаграммы деятельности

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

Каждое состояние на диаграмме деятельности соответствует выполнению некоторого действия или деятельности, а переход в следующее состояние срабатывает только при их завершении [19].

На рисунке 2.10 представлена контекстная диаграмма деятельности метода «showArchive» («Показать архив»). На ней видно, что данный метод состоит из множества подфункций, декомпозиция одной из которых («Выполнение SQL») представлена далее.

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

В случае ошибки загрузки данных показ архива не совершается и осуществляется выход из метода.

Характеристики

Список файлов ВКР