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

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

3 Проектирование системы

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

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

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

• при объектно-ориентированном подходе иерархия отношений между объектами выстраиваться при помощи отношений композиции и наследования, таким образом связь между объектами представлена в виде ориентированного графа. Что даёт мощный инструмент для представления очень сложных связей между сущностями из реального мира.

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

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

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

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

• модель проектирования, содержащая диаграмму классов;

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

Для проектирования программного продукта требуется использовать case-средство. CASE (computer-aided software engineering) - средства представляют собой инструменты позволяющие автоматизировать процесс проектирования и разработки программных продуктов. Данные средства разграничивают процесс проектирования программного продукта от процесса его кодирования. Большинство CASE средств содержит в себе следующие инструменты:

• инструменты моделирования данных;

• инструменты для построения UML-диаграмм;

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

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

• инструменты анализа и проектирования;

• инструменты редактирования программного кода;

• инструменты рефакторинга кода;

• генераторы кода.

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

3.1 Модель вариантов использования

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

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

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

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

• отношение общения. Указывает на то, что некоторая сущность может быть обобщена до другой сущности;

• отношение включения. Указывает, что вариант использования (функция системы) включается в качестве компонента в совокупность поведения другого варианта использования;

• отношение расширения. Данное отношение показывает потенциальную возможность вхождения одного варианта использования в состав другого.

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

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

На рисунке 3.2 представлен процесс автоматической настройки прав доступа субъекта доступа к объекту доступа. Данный процесс включает в себя: считывание конфигурационного файла. В конфигурационном файле содержатся данные о субъекте доступа, объекте доступа, название компьютера на котором осуществляется настройка доступа, а также перечень типов доступа для назначения прав. Затем система определяет название компьютера и получает список субъектов, которые имеют учётные записи на данном компьютере. После чего программа ищет объект доступа в компьютере. И в конце согласно списку типов доступа, производит настройку прав доступа к объекту доступа.

Рисунок 3.2 – Диаграмма декомпозиции вариантов использования “Автоматическая настройка прав доступа”

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

Рисунок 3.3 – Диаграмма декомпозиции вариантов использования “Ручная настройка прав доступа”

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

Р исунок 3.4 – Диаграмма декомпозиции вариантов использования “Считывание и вывод прав доступа”

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

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

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

Ранее был выбран объектно-ориентированы подход к проектированию программного продукта, он подразумевает использование такой категории как объект и класс. Объект является абстракцией из внешнего мира, а класс содержит его основные свойства и описание поведения. Класс анализа – представляет собой ещё более абстрактную сущность чем просто класс, он представляет собой совокупность из одного или нескольких классов. То есть класс анализа описывает некоторый фрагмент программного продукта без конкретики в плане будущих атрибутов и выполняемых операций. На рисунке 3.5 представлена диаграмма классов анализа разрабатываемого продукта. Она содержит классы сущности и управляющие классы. К классам сущности относиться: начальная форма, главная форма, главное меню, все эти элементы наследуются от класса “форма”. Формы представляют собой графический интерфейс для работы с программой. Ещё к классам сущностям относить пункты главного меню и главное меню, они являются объектами класса “Форма” и помогают взаимодействовать с другими классами такими как: объект, субъект, устройство, список всех данных, тип доступа. К управляющим классам относятся классы: Формирование отчёта и назначение прав. Каждый из этих классов выполняют операцию соответствующею их н
азванию.

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

3.2.2 Диаграмма последовательности

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

Последовательность происходящая при автоматической настройки прав субъекта доступа к объекту доступа изображенна на рисунке 3.6 Взаимодейтсвие происходит следующим образом, администратор осуществляет вход на главную форму, выбирает пункт меню “автоматическая настройка”, после чего открываеться обозреватель объектов, в нём администратор должен выбрать конфигурационный файл. После его нахождения, программа считает данные на нём и передаёт их в метод находящийся на главной форме, затем отработает алгаритм производящий автоматизированую настройку прав доступа и в конце администратор получит уведомление об окончании найтройки прав доступа.

Рисунок 3.6 – Диаграмма последовательности “Автоматическая настройка прав доступа субъекту доступа к объекту доступа”

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

Рисунок 3.7 – Диаграмма последовательности “Ручная настройка прав доступа субъекту доступа к объекту доступа”

На рисунке 3.8 представлен процесс считывания и отображения прав доступа субъектов доступа к объектам доступа. Администратор запускает программу и переходит на главную форму, при загрузки главной формы происходит считывание учётных записей, заведённых на компьютере, а также считывается наименование компьютера. После загрузки пользователь выбирает на главной форме пункт меню “Объект”, выбирает тип объекта файл или папка, после выбора типа объекта происходит открытие обозревателя объектов, после выбора нужного объекта в обозревателе администратор выбирает из ранее полученного списка субъектов, интересующий его субъект. Затем отрабатывает алгоритм считывания прав доступа субъекта доступа к объекту доступа после чего полученные данные передаются в графический интерфейс для отображения прав доступа.

Рисунок 3.8 – Диаграмма последовательности “Считывание прав доступа субъекта доступа к объекту доступа”

3.2.3 Диаграмма коммуникаций.

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

На рисунке 3.9 показана диаграмма коммуникаций при автоматическом режиме настройки прав доступа. Действующий актор - это администратор. Цепочка взаимодействия выглядит следующим образом:

• 1 – администратор, с помощью исполняемого файла запускает программу;

• 2 – после запуска программы появляется начальная форма – стартовое окно, в нём содержится краткая информация о программе и кнопка “Старт”;

• 3 – администратор нажимает кнопку “Старт”, после чего происходит переход на главную форму;

• 4 – происходит переход на главную форму, которая содержит главное меню программы;

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

• 6 – в процессе инициализации после загрузки списка пользователей, идёт получение названия устройства;

• 7 – для того что бы начать процесс автоматической настройки администратор нажимает на пункт меню “Автоматическая настройка”;

• 8 – главная форма инициализирует новый обозреватель объектов;

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

• 10 – после того как администратор выбрал файл, данные передаётся на главную форму;

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

• 1
  2 – после выполнения метода настройки главная форма извещает пользователя об окончании настройки.

Рисунок 3.9 – Диаграмма коммуникаций “Автоматическая настройка прав доступа”

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

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

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