Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Обзор источников).pdf

В контексте языка UML деятельность (activity) представляет собой совокупность отдельных вычислений, выполняемых автоматом, приводящих к некоторому результату или действию (action). На диаграмме деятельности отображается логика и последовательность переходов от одной деятельности к другой, а внимание аналитика фокусируется на результатах. Результат деятельности может привести к изменению состояния системы или возвращению некоторого значения.

Состояние действия

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

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

Действие может быть записано на естественном языке, некотором псевдокоде или языке программирования. Никаких дополнительных или неявных ограничений при записи действий не накладывается. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами. Если же действие может быть представлено в некотором формальном виде, то целесообразно записать его на том языке программирования, на котором предполагается реализовывать конкретный проект[CASE-технологии. Современные методы и средства проектирования информационных систем / Вендров А.М.].

Иногда возникает необходимость представить на диаграмме деятельности некоторое сложное действие, которое, в свою очередь, состоит из нескольких более простых действий. В этом случае можно использовать специальное обозначение состояния под-деятельности (subactivity state). Такое состояние является графом деятельности и обозначается специальной пиктограммой в правом нижнем углу символа состояния действия (рис. 6). Эта конструкция может применяться к любому элементу языка UML, который поддерживает вложенность своей структуры. При этом пиктограмма может быть дополнительно помечена типом вложенной структуры.

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

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

При приеме техники на обслуживание и ремонт сначала определяется, подлежит ли техника ремонту , если нет, то клиент получает отказ, затем определяется список необходимых запчастей и их стоимость, если клиента она устраивает, то заполняется заявка на ремонт, в противном случае клиент отказывается от обслуживания[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

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

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

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

Данная диаграмма описывает последовательность во времени событий, происходящих в системе при выполнении клиентом запроса на оформление заявки[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

Рис.3. диаграмма последовательности

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

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

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

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

Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое название или имя в форме глагола с пояснительными словами[Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

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

Каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемая сущность по запросу актера, то есть определяет способ применения этой сущности. Сервис, который инициализируется по запросу актера, представляет собой законченную неделимую последовательность действий. Это означает, что после того как система закончит обработку запроса, она должна возвратиться в исходное состояние, чтобы быть готовой к выполнению следующих запросов[CASE-технологии. Современные методы и средства проектирования информационных систем / Вендров А.М].

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

Для создания модели взаимодействий сначала определим действующих лиц или актеров.

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

Варианты работы Сервисного центра (см. рис. 3): 1) Принять технику – Приемщик принимает у клиента технику в ремонт. 2) Определение неисправности – Выполняется проверка, возможно ли исправить данный дефект силами Сервисного центра и определить; какие для этого потребуются запчасти 3)Проверить наличие запчастей –проверка наличия на складе нужных запчастей, определение недостающего количества 4) Заказ запчастей – заказ необходимого количества запчастей и расходных материалов; 5) Оформление заявки - оформление заявки на техническое обслуживание.

Определим начальное и конечное события для каждого варианта использования: 1) Принять технику– Начальное событие - Приемщик принимает у клиента технику в ремонт. Конечное событие – Определение неисправности 2) Определение неисправности – Начальное событие - Выполняется проверка, возможно ли исправить данный дефект силами Сервисного центра и определить; какие для этого потребуются запчасти; Конечные события – если техника подлежит ремонту – определение запчастей, если нет – отказ; 3) Проверить наличие запчастей –Начальное событие - проверка наличия на складе нужных запчастей, конечное событие - заказ запчастей; 4) Заказ запчастей – начальное событие - заказ необходимых запчастей, конечное событие - получение запчастей; 5) Оформление заявки – начальное событие – согласование стоимости ремонта – конечное событие – оформление заявки[Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

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

Диаграмма состояний

Каждая диаграмма состояний в UML описывает все возможные состояния одного экземпляра определенного класса и возможные последовательности его переходов из одного состояния в другое, то есть моделирует все изменения состояний объекта как его реакцию на внешние воздействия[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

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

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

Система может находиться в состояниях: Подлежит ремонту (техника подлежит ремонту), Ремонту не подлежит (Отказ в обслуживании0, Проверить наличие запчастей (Проверка наличия запчастей и расходных материалов), Оформить заявку (Оформление заявки)[ Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

Рис. 5 Диаграмма состояний

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

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

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

Классы

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

Имя класса должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм классов или одной диаграммой. Оно указывается в первой верхней секции прямоугольника. В дополнение к общему правилу наименования элементов языка UML, имя класса записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать существительные, записанные без пробелов. Имена классов образуют словарь предметной области[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].