50400 (Объектно-ориентированный анализ и проектирование деятельности ООО "Формула торговли"), страница 2

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

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

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

Ассоциацией называется структурное отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа. Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). Отношение такого типа называют агрегированием.

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

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

Опишем соответствие функциональных требований и классов в виде таблицы (таблица 3).

Таблица 3 – Соответствие функциональных требований и классов

Чтобы получить структуру системы анализа деятельности ООО «Формула торговли» была построена диаграмма классов, показанная на рисунке 2.

Рисунок 2 – Обобщенная диаграмма классов

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

- Сервис Центр,

- Менеджер Сервис Центра,

- Инженер по ремонту,

- Фирма-поставщик,

- Клиент,

- Инженер по регламенту,

- Начальник Сервис Центра,

- Грузчик,

- База данных,

- ККТ.

Класс Сервис Центр связан с классами Менеджер Сервис Центра, Инженер по ремонту, Фирма-поставщик, Клиент, Инженер по регламенту, Начальник Сервис Центра, Грузчик отношениями агрегации, так как имеет более высокий ранг по сравнению с его объектами-частями. Классы База данных и Менеджер Сервис Центра связаны отношением зависимости. Зависимостью называют отношение использования, согласно которому изменение в спецификации одного элемента может повлиять на другой элемент, его использующий, причем обратное не обязательно. Самым распространенным видом отношения зависимости является соединение между классами, когда один класс использует другой в качестве параметра операции. В данном случае зависимость направлена от класса Менеджер Сервис Центра к классу База данных, поскольку последний используется в операциях Обрабатывает заказ клиента, Оформляет заказ и Проверяет наличие товара на складе класса Менеджер Сервис Центра.

Также отношением зависимости связан класс ККТ с классами Фирма-поставщик и Клиент, так как используется в операциях Предоставляет товар класса Фирма-поставщик и Покупает товар класса Клиент соответственно.

2.3 Моделирование динамики деятельности ООО «Формула торговли»

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

В соответствии с основными способами моделирования динамики системы диаграммы поведения в UML условно разделяются на пять типов, один из которых – диаграмма прецедентов – был рассмотрен выше:

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

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

- диаграммы состояний описывают изменение состояния системы в ответ на события;

- диаграммы деятельности демонстрируют передачу управления от одной деятельности к другой.

2.3.1 Моделирование потоков управления (диаграмма деятельности)

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

При моделировании динамических аспектов системы диаграммы деятельности применяются в основном двумя способами:

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

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

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

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

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

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

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

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

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

Диаграмма деятельности ООО «Формула торговли» представлена на рисунке 3.

Рисунок 3 – Диаграмма деятельности ООО «Формула торговли»

Рассмотрим подробно первую часть диаграммы, которая описывает оформление заказа клиента и продажу товара (рисунок 4). Процесс начинается с действий: Обработать заказ клиента, Оформить заказ, Проверить наличие на складе со стороны Менеджера. Далее происходит ветвление процесса, которое описывает различные пути выполнения в зависимости от значения некоторого булевского выражения. В данном случае если товар на складе в наличии, то Грузчик отгружает товар со склада и доставляет в отдел Менеджеру. Если товара в наличии нет, то Менеджер заказывает товар у фирмы-производителя. Далее потоки Получить товар и Выставить счет клиенту выполняются параллельно.

Рисунок 4 – Диаграмма деятельности для оформления заказа и продажи товара

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