Файл: 3 глава.docx

3.3 Построение диаграмм прецедентов

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

Вариант использования представляет собой последовательность действий (транзакций) выполненных системой в ответ на события, инициируемые действующим лицом. Вариант использования описывает типичное взаимодействие между пользователем и системой и отражает представления о поведении системы с точки зрения пользователя. Суть диаграммы вариантов использования состоит в следующем. Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актеру. Диаграмма вариантов использования может дополняться пояснительным текстом, который раскрывает смысл или семантику составляющих ее компонентов. Цель - описать, что будет делать система, а не она будет делать это. Для этого необходимо определить действующих лиц. Затем, исходя из потребностей актеров, выделяются варианты использования [17].

Рис. 3.1 Диаграмма прецедентов (вариантов использования)

Действующие лица (businessactors):

Клиент–просматривает сайт, знакомится с продукцией; выбирает необходимое ПО.

Работник магазина проверяет, поступила ли оплата (в случае безналичного расчета) и делает соответствующую пометку при поступлении денег;

Варианты использования (BusinessUseCase).

Исходя из потребностей действующих лиц, выделяются следующие вари­анты использования:

выбор ПО;

подсчёт стоимости;

оформление заказа;

оплата заказа;

проверка оплаты заказа.

3.4 Построение диаграмм деятельности

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

---

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

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

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

Последовательность выполнения действий следующая (рис. 3.2):

1. Поступает заявка на оформление заказа.

2. Отображается номер заказа и форма заказа.

3. При необходимости происходит изменение позиций в заказе.

4. Замена изменений.

5. Направление информации в бухгалтерию и на склад

Рис. 3.2. Диаграмма деятельности

---

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

Диаграммы классов наиболее часто используются при моделировании информационных систем. Они являются одной из форм статического описания системы с точки зрения ее проектирования, показывая ее структуру. Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов. На диаграммах классов показываются классы, интерфейсы и отношения между ними (рис. 3.5).Класс – это основной строительный блок информационной системы. Это понятие присутствует и в объектно-ориентированных языках программирования, то есть между классами UML и программными классами есть соответствие, являющееся основой для автоматической генерации программных кодов или для выполнения реинжиниринга. Каждый класс имеет название, атрибуты и операции. Класс на диаграмме показывается в виде прямоугольника, разделенного на 3 области. В верхней содержится название класса, в средней – описание атрибутов (свойств), в нижней – названия операций – услуг, предоставляемых объектами этого класса.

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

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

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

Открытый (public) – атрибут виден для любого другого класса (объекта);

Защищенный (protected) – атрибут виден для потомков данного класса;

---

Закрытый (private) – атрибут не виден внешними классами (объектами) и может использоваться только объектом, его содержащим.

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

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

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

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

В RationalRose допустимы следующие отношения:

ассоциация - это такой вид взаимосвязи, который показывает что одни классы связанны с другими;

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

обобщение, или наследование, что один класс наследует свойства, методы и события другого класса.

Рис. 3.3. Диаграмма классов

В таблицах 3.1 – 3.4 представлены описательные спецификации диаграммы классов.

Таблица 3.1

Описание структуры класса «Заказы» (Zakazi)

Наименование	Обозначение в БД	Тип данных
Идентификатор заказа	Zakazi_id	integer
Идентификатор клиента	Klient_id	integer
Идентификатор товара	Tovari_id	integer
Идентификатор сотрудника	Sotrudniki_id	integer
Дата заказа	Data_zak	data

---

Таблица 3.2

Описание структуры класса «Клиент» (Klient)

Наименование	Обозначение в БД	Тип данных
Идентификатор клиента	Klient_id	integer
ФИО	FIO	string
Контактные данные	kont_dan	string

Таблица 3.3

Описание структуры класса «Товары» (Tovari)

Наименование	Обозначение в БД	Тип данных
Идентификатор товара	Tovari_id	integer
Наименование товара	naim_tov	string
Стоимость	stoimost	integer
Производитель	proizv_name	string
Страна изготовления	strana_proizv	string

Таблица 3.4

Описание структуры класса «Сотрудники» (Sotrudniki)

Наименование	Обозначение в БД	Тип данных
Идентификатор сотрудника	Sotrudniki_id	integer
ФИО	FIO	string
Табельный номер	tab_nom	integer
Должность	dolzhnost	string

---