Объектно-ориентированный анализ и проектирование деятельности ООО "Формула торговли" (стр. 2 из 5)
Система анализа информации о процессе функционирования ООО «Формула торговли» должна удовлетворять определенным требованиям, которые указаны в таблице 1.
интернет журналистика портал информационный
Таблица 1 – Распределение требований по субъектам и прецедентам
| № | Требование | Субъект | Прецедент |
| 1 | Осуществлять беспрепятственный прием заявок на покупку или ремонт контрольно-кассовой техники. | Клиент | Заявка на ремонт, Заявка на покупку ККТ |
| 2 | Предоставлять необходимые программные и технические средства для оформления заявки клиента. С помощью ПО изменять, добавлять, сортировать данные по времени поступления | Клиент | Оформить заявку на покупку ККТ |
| 3 | Осуществлять быструю подачу данных о заявках и предыдущих работах для дальнейшего их оформления, распечатки, отправки и прочее. | Клиент | Оформить договор на сервисное обслуживание, Выписать счет |
| 4 | Система должна предоставлять информацию о текущем состоянии, чтобы ориентироваться в дальнейших действиях по обслуживанию или ремонту. | Клиент | Отремонтировать ККТ, Провести обслуживание ККТ, Исправить неполадки |
Исходя из данных таблицы 1 построена диаграмма прецедентов (рисунок 1).
Рисунок 1 – Диаграмма прецедентов для ООО «Формула торговли»
Опишем прецедент «Провести обслуживание ККТ» с помощью документально зафиксированного потока событий. Соответствующий текстовый документ определяет, что должна делать система, когда субъект инициирует прецедент. Описательная спецификация данного прецедента представлена в таблице 2.
Таблица 2 – Описательная спецификация прецедента «Провести обслуживание ККТ»
| Прецедент «Провести обслуживание ККТ» | |
| Краткое описание | Проведение в соответствии с условиями договора планового осмотра ККТ, чистки, исправление возможных неполадок. |
| Субъект | Клиент |
Продолжение таблицы 2
| Предусловие | Клиент заключает с фирмой договор на сервисное обслуживание, при этом выбирает базовый вариант договора, упрощенный или эконом-договор. |
| Основной поток | В начале прецедента клиент предоставляет кассовый аппарат для планового осмотра. По завершении осмотра клиент может продолжить работу с кассовым аппаратом, либо отдает ККТ в ремонт. |
| Альтернативные потоки | Расторжение договора с фирмой, в связи с чем сервисное обслуживание ККТ клиента прекращается. |
| Постусловие | В Журнале учета фиксируется информация о проведенном обслуживании. |
2.2 Моделирование структуры деятельности ООО «Формула торговли»
Система анализа деятельности ООО «Формула торговли» характеризуется состоянием системы. Состояние является функцией содержимого системной информации в заданный момент времени – это функция системного текущего набора объектов-экземпляров. Определение внутреннего состояния системы дается в модели классов. К элементам, принимающим участие в моделировании классов, относятся сами классы, атрибуты и операции над классами, ассоциации, агрегации и композиции, а также обобщения.
Классом называется описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Классы используются для составления словаря разрабатываемой системы. Это могут быть абстракции, являющиеся частью предметной области, либо классы, на которые опирается реализация. С их помощью описывают программные, аппаратные или чисто концептуальные сущности.
Операцией называется реализация услуги, которую можно запросить у любого объекта класса для воздействия на поведение. Класс может содержать любое число операций или не содержать их вовсе. Часто (хотя не всегда) обращение к операции объекта изменяет его состояние или его данные.
Атрибут – это именованное свойство класса, включающее описание множества значений, которые могут принимать экземпляры этого свойства. Класс может иметь любое число атрибутов или не иметь их вовсе. Атрибут представляет некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Таким образом, атрибут является абстракцией данных объекта или его состояния.
Ассоциацией называется структурное отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа. Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). Отношение такого типа называют агрегированием.
Агрегирование является простой концепцией с достаточно глубокой семантикой. Простое агрегирование – чисто концептуальное отношение, оно лишь позволяет отличить "целое" от "части", но не изменяет смысла навигации по ассоциации между целым и его частями и не накладывает никаких ограничений на соотношение времен жизни целого и частей.
Однако существует вариация простого агрегирования – композиция, которая добавляет к семантике агрегирования новые важно. Композицией называется форма агрегирования с четко выраженным отношением владения, причем время жизни частей и целого совпадают. Части с нефиксированной кратностью могут быть созданы уже после самого композита, но, будучи созданы, живут и умирают вместе с ним. Впрочем, части могут быть удалены явным образом еще до уничтожения композита.
Опишем соответствие функциональных требований и классов в виде таблицы (таблица 3).
Таблица 3 – Соответствие функциональных требований и классов
| № | Требование | Субъект |
| 1 | Осуществлять беспрепятственный прием заявок на покупку или ремонт контрольно-кассовой техники. | Сервис Центр, Начальник Сервис Центра, Менеджер Сервис Центра |
| 2 | Предоставлять необходимые программные и технические средства для оформления заявки клиента. С помощью ПО изменять, добавлять, сортировать данные по времени поступления | Сервис Центр, Фирма-поставщик, Менеджер Сервис Центра, База данных, ККТ |
| 3 | Осуществлять быструю подачу данных о заявках и предыдущих работах для дальнейшего их оформления, распечатки, отправки и прочее. | Менеджер Сервис Центра, Грузчик |
| 4 | Система должна предоставлять информацию о текущем состоянии, чтобы ориентироваться в дальнейших действиях по обслуживанию или ремонту. | Инженер по регламенту, Инженер по ремонту, Клиент, ККТ |
Чтобы получить структуру системы анализа деятельности ООО «Формула торговли» была построена диаграмма классов, показанная на рисунке 2.
Рисунок 2 – Обобщенная диаграмма классов
Построенная диаграмма включает в себя десять классов:
- Сервис Центр,
- Менеджер Сервис Центра,
- Инженер по ремонту,
- Фирма-поставщик,
- Клиент,
- Инженер по регламенту,
- Начальник Сервис Центра,
- Грузчик,
- База данных,
- ККТ.
Класс Сервис Центр связан с классами Менеджер Сервис Центра, Инженер по ремонту, Фирма-поставщик, Клиент, Инженер по регламенту, Начальник Сервис Центра, Грузчик отношениями агрегации, так как имеет более высокий ранг по сравнению с его объектами-частями. Классы База данных и Менеджер Сервис Центра связаны отношением зависимости. Зависимостью называют отношение использования, согласно которому изменение в спецификации одного элемента может повлиять на другой элемент, его использующий, причем обратное не обязательно. Самым распространенным видом отношения зависимости является соединение между классами, когда один класс использует другой в качестве параметра операции. В данном случае зависимость направлена от класса Менеджер Сервис Центра к классу База данных, поскольку последний используется в операциях Обрабатывает заказ клиента, Оформляет заказ и Проверяет наличие товара на складе класса Менеджер Сервис Центра.
Также отношением зависимости связан класс ККТ с классами Фирма-поставщик и Клиент, так как используется в операциях Предоставляет товар класса Фирма-поставщик и Покупает товар класса Клиент соответственно.
2.3 Моделирование динамики деятельности ООО «Формула торговли»
Пять основных диаграмм поведения в UML используются для визуализации, специфицирования, конструирования и документирования динамических аспектов системы. Можно считать, что динамические аспекты системы представляют собой ее изменяющиеся части. Например, динамические аспекты жилого дома – это перемещение потоков воздуха и людей по комнатам. Динамические аспекты программной системы охватывают такие ее элементы, как поток сообщений во времени и физическое перемещение компонентов по сети.
В соответствии с основными способами моделирования динамики системы диаграммы поведения в UML условно разделяются на пять типов, один из которых – диаграмма прецедентов – был рассмотрен выше: