ПояснительнаяЗаписка 2 (1206728), страница 4

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

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

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

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

Построение этой модели необходимо:

• для выявления внутренней архитектуры (определения подсистем и основных классов);

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

• для уточнения всех требований (функциональных и нефункциональных).

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

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

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

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

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

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

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

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

На диаграмме последовательности мы можем увидеть следующие аспекты:

• сообщения, побуждающие объект к действию;

• действия, которые вызываются сообщениями (методы) – зачастую это передача сообщения следующему объекты или возвращение определенных данных объекта;

• последовательность обмена сообщениями между объектами.

Итак, прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено. Сообщение в большинстве случаев (за исключением диаграмм, описывающих концептуальный уровень системы) это вызов методов отдельных объектов, поэтому для корректного исполнения метода в сообщении необходимо передать какие-то данные и определить, что мы хотим видеть в ответ. В качестве имени сообщения на уровне проектирования реализации системы следует использовать имя метода.

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

На рисунке 2.10 представлена диаграмма последовательности «Получение исходных данных».

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

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

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

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

1. Диаграммы коммуникации

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

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

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

Диаграммы коммуникации могут быть построены на основе диаграмм последовательностей.

На рисунке 2.12 приведена диаграмма «Получение выходного документа».

Во взаимодействии участвуют следующие объекты: ДО Технические средства и организационный меры, подключение к БД, создание связи с MS WORD, таблица Угрозы безопасности информации, таблица Входные данные, таблица меры, таблица Средства защиты информации, а также актер-Пользователь или Администратор.

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

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

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

Построение модели проектирования необходимо:

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

• уточнения требований;

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

Модель проектирования представляется диаграммами классов и диаграммами деятельности.

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

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

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

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

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

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

Понятие «класс » присутствует и в объектно-ориентированных языках программирования, то есть между классами UML и программными классами есть соответствие, являющееся основой для автоматической генерации программных кодов или для выполнения реинжиниринга. Каждый класс имеет имя, атрибуты и операции. С точки зрения структурного подхода, атрибуты – это переменные, а операции (методы) – это функции, описанные в теле класса.

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

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

Каждая из двух видов диаграмм будет представлена в логической и физической формах (рисунки 2.14  2.17).

В данных диаграммах используются следующие отношения между объектами:

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

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

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

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

Рисунок 2.14  Логическая диаграмма классов БД

Рисунок 2.15  Физическая диаграмма классов БД

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

Таблица 2.1  Меры защиты информации

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

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

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