2.3 Создание макета графического интерфейса

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

Создание GUI начинается еще на этапе анализа, в ходе которого определяются принципы организации ввода и вывода информации пользователем программного продукта. На завершающих стадиях анализа и начальных стадиях проектирования, когда определены все функциональные и нефункциональные требования к разрабатываемому ПО, с помощью CASE–средств могут разрабатываться эскизы экранных форм, составляющих GUI.

Исходя из диаграммы вариантов использования создадим макет графического интерфейса проектируемого программного обеспечения (приложение Б, рисунок Б.1).

В ходе разработки макетов графического интерфейса были созданы следующие веб-страницы:

• авторизации;

• главной страницы;

• добавление, редактирование записи художника;

• добавление, редактирование записи картины;

• добавление, редактирование записи направления;

• таблицы художников (с возможностью формирования отчета);

• таблицы направлений;

• таблицы картин (с возможностью формирования отчета);

• результатов поиска;

• просмотра данных о конкретной картине.

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

• table – элемент, предназначенный для создания таблицы;

• label – предназначен для отображения текстовой информации;

• text – поле, предназначенное для ввода текста;

• combobox – текстовое поле, содержащее выпадающий список;

• button – кнопка, при нажатии выполняет соответствующее ей действие.

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

3 Создание логической модели по

3.1 Разработка диаграммы классов

Диаграмма классов занимает центральное место при проектировании программной системы с использованием объектно–ориентированного подхода к разработке ПО. Большинство современных CASE–средств осуществляют автоматическую генерацию кода основываясь именно на этой диаграмме.

Диаграмма классов – диаграмма, предназначенная для представления модели статической структуры программной системы в терминологии классов объектно–ориентированного программирования. Разработка этой диаграммы преследует следующие цели:

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

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

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

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

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

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

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

Атрибуты описывают свойства объектов класса. Большинство объектов в классе получают свою индивидуальность из-за различий в их атрибутах и взаимосвязи с другими объектами.

Операция есть функция или преобразование. Операция может иметь параметры и возвращать значения.

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

• ассоциация;

• обобщение;

• агрегация;

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

• зависимость;

• реализация.

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

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

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

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

Зависимость – обозначает такое отношение между классами, что изменение спецификации класса–поставщика может повлиять на работу зависимого класса, но не наоборот.

Реализация– отношение между двумя элементами модели, в котором один элемент (клиент) реализует поведение, заданное другим (поставщиком).

На основе диаграммы вариантов использования была составлена диаграмма классов, показанная в приложении В (рисунок В.1, рисунок В.2, рисунок В.3, рисунок В.4).

Для начала были разработаны 3 диаграммы классов: уровня данных, уровня бизнес–логики, уровня интерфейсов.

Диаграмма классов уровня данных представлена семью классами, каждый из которых отображает те понятия, с которыми работает информационная система: «medicine», «request», «staff», «transfer». Классы «request» и «medicine», «staff» связаны между собой связью ассоциации, означающую, что они связаны связью один-к-одному, которая в базе данных будет реализована через автоматически сгенерированную промежуточную таблицу, а на уровне моделей – навигационными свойствами – идентификатор лекарства и идентификатор сотрудника будет содержаться в строке описывающей запрос.

Диаграмма классов уровня бизнес–логики показывает, как будет взаимодействовать информационная система в целом. В используемом фреймворке ASP.NET Core MVC за создание бизнес-логики отвечают классы-контроллеры, запуск которых осуществляется в классе Program, который, в свою очередь, вызывается в классе Program. Таким образом, на диаграмму уровня бизнес-логики были вынесены следующие классы: «Program», «AuthController», «SearchController», «EditorController», «ArchiveController», «ReportController», «DataController», «MedicineController», «StaffController», «TransferController». Класс «AuthController» является частью обработки запросов пользователя и администратора – просмотра записей, поиска, редактирование данных и пр. Из него осуществляется перехода к контроллеру «EditorController», посредством которого администратор может перейти к контроллерам «DataController», «ArchiveController» и «ReportController» c которыми связан отношением ассоциации. Поскольку в классах «MedicineController», «StaffController», «TransferController» осуществляется добавление, редактирование, удаление соответствующих данных, то доступ к ним происходит только из контроллера «DataController». Контроллер «DataController» связан с другими, перечисленными в предыдущем предложении, связью ассоциации.

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

Последней была создана диаграмма пакетов. С помощью Enterprise Architect она была создана автоматически. На ней расположены следующие пакеты: «Уровень интерфейса», «Уровень данных», «Уровень бизнес-логики». Каждый пакет содержит классы или папки, реализованные на диаграммах. Пакет уровня бизнес–логики имеет отношения зависимости с пакетом уровня данных, в то время как пакет уровня интерфейса имеет это же отношения с пакетом уровня бизнес–логики. Данная структура организовывает своеобразную иерархию классов.