На рисунке 6 изображена разработанная диаграмма вариантов использования. Она содержит 1 актанта. Актант “Специалист по эксплуатации объекта” производит редактирование справочников пользователей, параметров, объектов, состояний; ведёт контроль вводимой информации, ведёт журнал событий и состояний.
Рисунок 6 - Диаграмма вариантов использования
1.4.2 Сценарии вариантов использования
Сценарий - текстовое описание последовательности действий, необходимых для выполнения экземпляра варианта использования. Сценарий пишется по определенному шаблону. При создании сценариев тщательно прорабатывается интерфейс системы, и учитываются отношения между вариантами использования. Для абстрактных вариантов использования, являющихся обобщениями конкретных вариантов, сценарии обычно не пишут.
Ниже приведен сценарий для варианта использования “Вести справочник пользователей”.
Вариант использования: Вести справочник пользователей.
Краткое описание. Позволяет специалисту по эксплуатации объекта вводить, удалять и редактировать информацию о пользователях программного комплекса.
Актант. Специалист по эксплуатации объекта.
Предусловия. Вариант использования “Вход в систему” выполнен с правами специалиста по эксплуатации объекта. На экране - главная форма приложения и одновременно форма оценки состояния объектов с пунктами меню, настроенными на права специалиста по эксплуатации объекта: “Обновить”, “Справочники”, “Журнал”, “Справка”, “Выход”.
Основной поток событий
1. Специалист по эксплуатации объекта выбирает пункт меню “Справочники”.
А1: Обновление состояния объектов.
А2: Просмотр журнала.
А3: Просмотр справки.
А4: Выход.
2. Система выводит на экран форму выбора справочников с пунктами меню “Справочник пользователей”, “Справочник параметров”, “Справочник состояний”, “Справочник объектов” и кнопкой “Закрыть”.
3. Специалист по эксплуатации объекта щёлкает пункт меню “Справочник пользователей”.
А5: Просмотр справочника параметров.
А6: Просмотр справочника состояний.
А7: Просмотр справочника объектов.
4. Система выводит на экран форму просмотра и редактирования справочника пользователей с полями “Логин”, “Пароль”, с кнопками “Добавить запись”, “Удалить запись” и “Сохранить и выйти”.
5. Специалист по эксплуатации объекта вводит информацию о новом пользователе в поля и щёлкает кнопку “Добавить запись” пользователей.
А8: Удалить запись.
5. Система выводит сообщение об успешном добавлении записей в справочник пользователей, если были заполнены все поля на форме и информация отвечала критериям добавления записи.
6. Специалист по эксплуатации объекта просматривает сообщение и щёлкает кнопку “ОК”. Затем щёлкает кнопку “Сохранить и выйти”, затем щёлкает кнопку “Закрыть”. Система выводит на экран главную форму приложения с пунктами меню, настроенными на права специалиста по эксплуатации объекта. Вариант использования завершается успешно.
Альтернативы
А1: Обновление состояния объектов.
А1.1: Специалист по эксплуатации объекта щёлкает кнопку “Обновить”.
А1.2: Система заново прочитывает соответствующую таблицу базы данных и обновляет состояния объектов на форме. Вариант использования завершается.
А2: Просмотр журнала.
А2.1: Специалист по эксплуатации объекта выбирает пункт меню “Журнал”.
А2.2: Система выводит на экран форму статистики событий и состояний с кнопкой “Закрыть”.
А2.3: Специалист по эксплуатации объекта просматривает отчёт и щёлкает кнопку “Закрыть”.
А2.4: Система закрывает форму статистики событий и состояний и выводит на экран главное окно приложения с пунктами меню, настроенными на права специалиста по эксплуатации объекта. Вариант использования завершается.
А3: Просмотр справки.
А3.1: Специалист по эксплуатации объекта выбирает пункт меню “Справка”.
А3.2: Система выводит на экран форму справки по системе с кнопкой “Закрыть”.
А3.3: Специалист по эксплуатации объекта просматривает справку и щёлкает кнопку “Закрыть”.
А3.4: Система закрывает форму “Справка по системе” и выводит на экран главное окно приложения с пунктами меню, настроенными на права специалиста по эксплуатации объекта. Вариант использования завершается.
А4: Выход.
А4.1: Специалист по эксплуатации объекта выбирает пункт меню “Выход”.
А4.2: Система закрывает окно программы и выводит на экран главное окно операционной системы. Вариант использования завершается.
А5: Просмотр справочника параметров.
А5.1: Аналогично варианту использования “Вести справочник пользователей”. Вариант использования завершается.
А6: Просмотр справочника состояний.
А6.1: Аналогично варианту использования “Вести справочник пользователей”. Вариант использования завершается.
А7: Просмотр справочника объектов.
А7.1: Аналогично варианту использования “Вести справочник пользователей”. Вариант использования завершается.
А8: Удалить запись.
А8.1 Специалист по эксплуатации объекта щёлкает кнопку “Удалить запись”.
А8.2 Система выдаёт подтверждающее сообщение об удалении выбранной строки в справочнике с кнопками “Yes” и “No”.
А8.3 Специалист по эксплуатации объекта щёлкает кнопку “Yes”.
А8.4 Система удаляет выбранную строку справочника. Вариант использования завершается.
1.4.3 Диаграмма граничных классов
Диаграмма граничных классов -- диаграмма, демонстрирующая классы взаимодействия системы с внешним окружением и их основные функции.
Классы по своей роли в системе делятся на группы. Сам по себе язык UML жестко не оговаривает эти группы, оставляя группировку на усмотрение разработчиков. На основе опыта, накопленного при создании автоматизированных систем, целесообразно выделить группу граничных (boundary) классов. Объекты этих классов реализуют интерфейсы системы с внешней средой и различными пользователями (не следует их путать с внутренними интерфейсами взаимодействия классов).
Диаграмма граничных классов разработанного программного комплекса изображена на рисунке 7.
Рисунок 7 - Диаграмма граничных классов
1.4.4 Диаграмма сущностных классов
Сущностные (entity) классы: объекты этих классов представляют собой блоки длительно хранимой информации, используемые для организации баз данных и знаний, файловых систем хранения данных различной логической структуры; в основном в этих классах развит атрибутный раздел, однако имеется небольшое число операций контроля ограничений целостности, как стандартных, так и специфичных для данной предметной области.
Диаграмма сущностных классов разработанного программного комплекса изображена на рисунке 8.
1.4.5 Диаграмма классов управления
Классы управления (control): объекты этих классов являются активными, берущими на себя управление и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем и систем управления базами данных (СУБД), таймеры, координаторы и т.п.
Диаграмма классов управления разработанного программного комплекса изображена на рисунке 9.
Рисунок 8 - Диаграмма сущностных классов
1.1.1.
Рисунок 9 - Диаграмма классов управления
1.1.1. 1.4.6 Логическая структура базы данных
Задача логической модели данных заключается в описании объектов данных предметной области и взаимосвязей между ними. При разработке модели, зачастую, приходится сталкиваться с сущностями, уникальность которых зависит от значений атрибута внешнего ключа. Для этих сущностей (для уникального определения каждой сущности) внешний ключ должен быть частью первичного ключа дочернего объекта.
Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью.
Существует ряд правил организации структур данных, называемых нормальными формами. Нормализация - процесс приведения модели структуры данных к некоторой нормальной форме. Как правило, используется третья нормальная форма. Она обеспечивает эффективное и не избыточное хранение данных. В таблице 5 приведены требования, которым должна удовлетворять структура БД для того, чтобы быть в одной из первых трех нормальных форм. В процессе нормализации анализируется структура БД, и выявляются элементы, противоречащие определенной нормальной форме.
Таблица 3 - Требования нормализации
|
Нормальная форма |
Требования нормализации |
|
|
1НФ |
БД находится в 1НФ тогда и только тогда, когда поля всех таблиц содержат только атомарные значения и в таблицах нет полностью повторяющихся строк. |
|
|
2НФ |
БД находится в 2НФ тогда и только тогда, когда значение любого не ключевого поля зависит от всего первичного ключа. Так же она должна находиться в 1НФ. |
|
|
3НФ |
БД находится в 3НФ тогда и только тогда, когда значение любого не ключевого поля зависит только от значения первичного ключа, но не от значения другого не ключевого поля. Так же она должна находиться во 2НФ. |
В результате анализа предметной области и, исходя из поставленных задачей, для функционирования ИС было выделено 5 сущностей:
1) Пользователи - предназначена для хранения данных о пользователях программного комплекса.
Атрибуты: ID пользователя, Логин, Пароль, Роль.
2) Параметры - предназначена для хранения данных о параметрах.
Атрибуты: ID параметра, Параметр, Размерность.
3) Состояния - предназначена для хранения данных о состояниях.
Атрибуты: ID состояния, Состояние, Условие.
4) Журнал - сводная сущность для просмотра статистики событий и состояний.
Атрибуты: ID события, ID параметра (FK), ID состояния (FK), ID объекта (FK), Дата, Время, Значение.
5) Объекты - предназначена для хранения данных об объектах.
Атрибуты: ID объекта, Объект, Адрес.
Логическая модель данных проектируемой ИС была разработана в Erwin Data Modeler r7 (рисунок 10). В ней учтены все необходимые для функционирования программного комплекса сущности и их атрибуты, а также проставлены связи между ними.
Рисунок 10 - Логическая структура базы данных
2. РЕАЛИЗАЦИЯ СИСТЕМЫ
2.1 Архитектура и платформа реализации
2.1.1 Операционная система Windows 7
Windows 7 под кодовыми наименованиями Blackcomb и Vienna - операционная система семейства Windows NT, следующая за Windows Vista. В линейке Windows NT система носит номер версии 6.1 (Windows 2000 - 5.0, Windows XP - 5.1, Windows Server 2003 - 5.2, Windows Vista и Windows Server 2008 - 6.0). Серверной версией является Windows Server 2008 R2, версией для интегрированных систем - Windows Embedded Standard 2011 (Quebec), мобильной - Windows Embedded Compact 2011 (Chelan, Windows CE 7.0) [11].
Операционная система поступила в продажу 25 октября 2009 года, меньше чем через три года после выпуска предыдущей операционной системы, Windows Vista. Хотя изначально операционная система должна была поступить в продажу уже 31 августа 2009 года. Партнёрам и клиентам, обладающим лицензией Volume Licensing, доступ к RTM был предоставлен 24 июля 2009 года. Финальная нелицензионная версия (копия с дисков, которые потом пошли в продажу) была доступна всем с первых чисел августа 2009 года.
В состав Windows 7 вошли как некоторые разработки, исключённые из Windows Vista, так и новшества в интерфейсе и встроенных программах. Из состава Windows 7 были исключены игры Incball, Ultimate Extras; приложения, имеющие аналоги в Windows Live (Почта Windows, Календарь Windows и пр.), технология Windows Agent, Windows Meeting Space; из меню "Пуск" исчезла возможность вернуться к классическому меню и Версии Windows 7.
2.1.2 Библиотека Qt 5.4.1
Qt -- кросс платформенный инструментарий разработки ПО на языке программирования C++. Qt позволяет запускать написанное с его помощью ПО в большинстве современных операционных систем путем простой компиляции программы для каждой ОС без изменения исходного кода. Включает в себя все основные классы, которые могут потребоваться при разработке прикладного программного обеспечения, начиная от элементов графического интерфейса и заканчивая классами для работы с сетью, базами данных и XML. Qt является полностью объектно-ориентированным, легко расширяемым и поддерживающим технику компонентного программирования [12].
2.1.3 СУБД Microsoft Office Access 2003
Microsoft Office Access -- реляционная СУБД корпорации Microsoft входящая в пакет программ MS Office. Access включает связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в Access можно писать приложения, работающие с базами данных [13].
2.1.4 Язык программирования C++