Пояснительная записка (1206274), страница 3

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

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

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

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

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

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

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

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

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

Рисунок 2.5 – Диаграмма автоматов для подсистемы «Авторизация»

Рассмотрим еще одну реализацию диаграммы автоматов для подсистемы «Пользователь» на рисунке 2.7. В данной диаграмме показано взаимойдествие с системой зарегистрированного пользователя.

Рисунок 2.7 – Диаграмма автоматов для подсистемы «Пользователь»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На рисунке 2.9 представлена диаграмма последовательности «Регистрация пользователя».

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

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

Рисунок 2.9 – Диаграмма последовательности «Регистрация нового пользователя»

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

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

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

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

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

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

Рисунок 2.10 – Диаграмма последовательности «Аутентификации»

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

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

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

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

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

Рисунок 2.11 – Диаграмма коммуникации «Аутентификации»

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

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

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

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

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

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

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

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

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

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

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