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

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

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

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

В SQL Server авторизация пользователей может происходить двумя путями:

• на основе собственного списка пользователей;

• на основе базы пользователей Windows.

1.4.3 Подход и язык проектирования

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

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

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

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

Объектно-ориентированный подход помогает справиться с такими сложными проблемами:

• уменьшение сложности программного обеспечения;

• повышение надежности программного обеспечения;

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

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

Проектирование данного программного комплекса выполняется на основе объектно-ориентированного подхода и унифицированного языка программирования  UML (Unifiedmodelinglаnguаge).

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

2 Разработка программного комплекса

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

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

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

• определить общие границы и контекст моделируемой предметной области;

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

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

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

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

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

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

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

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

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

• специалист по информационной безопасности (далее  Пользователь);

• администратор программного комплекса (далее – Администратор).

И следующие варианты использования:

• получение исходных данных;

• получение набора мер;

• нейтрализация полученного набора мер;

• вывод документа;

• учетная запись;

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

• угрозы безопасности информации;

• список мер защиты информации;

• средства защиты информации.

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

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

На основе контекстной диаграммы были созданы несколько диаграмм декомпозиций. Такие диаграммы, как правило, представляют собой «ромашку», в центре которой декомпозируемый вариант использования, а вокруг – входящие в него обязательные (include) или расширяющие (extend) составные части. В работе представлены три диаграммы декомпозиции для разных вариантов использования.

Рассмотрим декомпозицию варианта использования «Получение исходных данных» (рисунок 2.2), на которой отражено взаимодействие Пользователя с системой.

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

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

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

Получение набора мер включает в себя:

• получение базового набора мер;

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

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

• получение дополненного уточненного адаптированного базового набора мер.

Рисунок 2.3 Диаграмма декомпозиции варианта использования «Получение набора мер»

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

Рисунок 2.4 Диаграмма декомпозиции варианта использования «Нейтрализация полученного набора мер»

1. Диаграммы автоматов

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

Одним из видов диаграмм, позволяющих детализировать варианты использования, – это диаграммы автоматов.

Диаграммаавтомата (stаtemаchinediаgrаm) - это один из способов детального описания поведения в UML на основе явного выделения состояний и описания переходов между состояниями.

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

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

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

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

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

Рисунок 2.5 Контекстная диаграммаавтоматов

Инициализация той или иной подсистемы происходит после успешной аутентификации пользователя с учетом предоставленных ему прав доступа.

Каждая подсистема более подробно представлена на диаграммах декомпозиции.

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

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

Рассмотрим еще одну реализацию диаграммы автоматов для подсистемы «Администратор» (рисунок 2.7). Администратор может изменять, добавлять, удалять записи в базу данных, а также может произвести работу по получению выходного документа.

Следующая диаграмма автоматов представляет собой процесс авторизации в ИС (рисунок 2.8).

Рисунок 2.8  Диаграмма автоматов для формы «Авторизация»

После ввода логина и пароля происходит проверка существования логина в базе данных данной ИС и сверка пароля, при неверном введении логина/пароля более трех раз выводится сообщение об ошибке и происходит принудительный выход из программы.

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

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

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

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