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

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

Согласно требованиям организации разрабатываемое программное решение должно выполнять следующие задачи:

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

• управление списком учетных записей пользователей (субъектов);

• управление списком объектов доступа информационной системы;

• управление списком правил разграничения доступа субъектов к объектам;

• формирование полной матрицы доступа и вывод ее в документ;

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

• сохранение и загрузка данных заведенных в приложение.

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

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

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

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

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

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

Сохранение и загрузка данных заведенных в приложение основывается на сериализации и десериализации данных приложения по указанной директории, либо в корневой каталог приложения.

2 Проектирование программного модуля

Для проектирования программного модуля ПБИ-1 был выбран объектно-ориентированный подход по следующим причинам:

• модуль с легкостью разбивается на объекты, что позволяет лучше понимать структуру модуля;

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

• данные и операции совместно представляют определенную сущность и не «расплываются» по всему коду модуля.

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

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

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

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

• реализации в виде диаграммы компонентов.

Прототип программы имеет возможность практического использования.

2.1 Диаграммы вариантов использования

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

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

На рисунке 2.1 представлена соответствующая диаграмма вариантов использования.

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

При работе с любыми списками данного приложения определено четыре возможных варианта использования:

• создание элемента списка;

• изменение существующего элемента;

• удаление элемента из списка;

• поиск элементов удовлетворяющих введенным условиям.

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

Изменение данных происходит по похожей схеме, за исключением того что изначально уже существуют некие данные.

Удаление элемента заключается в удалении его из списка таких элементов, а так же удалении всех связанных с ним данных.

Поиск элементов осуществляется по выбранному администратором полю элемента (типу поиска) и введенным в поле поиска данным. По итогу поиска на экран выводятся все элементы удовлетворяющие условиям поиска.

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

Рисунок 2.2  Диаграмма вариантов использования Работа со списком субъектов

Так же является примером декомпозиция варианта использования работы со списком объектов системы, изображенная на рисунке 2.3. Администратор так же может совершить четыре действия: создание объекта, его изменение, удаление и поиск объекта.

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

Изменение существующего объекта включает те же действия что и создание, за исключением того, что данные изначально уже будут существовать.

Удаление объекта состоит из двух действий: удаление объекта из списка объектов и удаление всех данных связанных с этим объектом.

Поиск объектов осуществляется по выбранному типу поиска (полю объекта) и введенным в поле поиска данным.

Рисунок 2.3  Диаграмма вариантов использования Работа со списком объектов

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

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

Рисунок 2.4  Диаграмма вариантов использования Вывод отчетов по любому элементу системы

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

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

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

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

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

Главной формой проекта считается форма, содержащая правила разграничения доступа. В верхней части данной формы располагается строка меню, которая предоставляет доступ ко всем формам и возможностям приложения. Каждый элемент, вызываемый с помощью меню, представляет собой формы, отображающие списки привязанных к ним элементов, наборы кнопок для работы с этими списками, кнопки для вывода отчетов, а так же блоки элементов для поиска и вывода краткой справки. Формы, предназначенные для работы со списками данных, по нажатию на кнопку «Добавить» вызывают диалоговое окно (ДО) необходимое для создания нового элемента.

Рисунок 2.5  Диаграмма классов анализа программного модуля

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

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

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

Класс Device представляет абстрактное представление устройства системы в программе и используется для создание экземпляров устройств.

Класс SysUser предназначен для представления субъекта, для которого в дальнейшем будут создаваться правила разграничения доступа.

Класс SysObject представляет объект, относительно которого происходит разграничение доступа.

Класс AllDataLists предназначен для хранения списков субъектов, объектов, устройств и правил разграничения доступа. Данный класс хранит в своих списках экземпляры трех предыдущих классов, а так же содержит отдельный список, каждая строка которого представляет объединение из одного экземпляра каждого из вышеперечисленных классов и словаря, хранящего правила разграничения доступа для них.

Класс WordWork реализует функции по формированию отчетов и выводу их через интерфейс приложения Microsoft Word.

Класс Programm является главной точкой входа в приложение и содержит в себе поток создания и отображения главной формы приложения MainForm.

Рисунок 2.6  Диаграмма классов программного модуля

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

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

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