Введение
В настоящее время – время высоких технологий – людям не обойтись без помощи мобильных телефонов, компьютеров и интернета, без помощи техники, которая выполняет за них тяжелую умственную работу. К такой технике принадлежат кассовые аппараты, которые имеет в своем обиходе каждый магазин. Ростовская фирма «Формула торговли» занимается приобретением, производством, сбытом и сервисным обслуживанием кассовых аппаратов. Конечно, при приобретении кассового аппарата покупателю дается гарантия на ремонт (при поломке аппарата), но также покупатель обязан заключить договор на сервисное обслуживание раз в один, два или три месяца. Не смотря на то, что фирма успешно функционирует на протяжении десяти лет, она не останавливается на достигнутом и стремится совершенствовать свою работу.
Задачей данной курсовой работы является минимизация затрат времени и средств в процессе деятельности ООО «Формула торговли» с целью повышения эффективности работы фирмы и привлечения новых клиентов, что, несомненно, обеспечит фирме большую прибыль.
Таким образом, увеличение прибыли ООО «Формула торговли» – и есть цель работы.
1. Описание деятельности ООО «Формула торговли»
1.1 Описание деятельности ООО «Формула торговли»
предприятие моделирование прибыль
ООО «Формула торговли» была создана на рубеже тысячелетий. Ее основал Коренский Сергей Александрович, профессор высшей математики. «Формула торговли» имеет множество филиалов, магазинов в г.Ростове-на-Дону и области. Так как по законам РФ каждый предприниматель или организация, которая совершает какие-либо способы торговли, обязана иметь кассу, она обязана заключить договор с любой сервисной службой, которая ежемесячно или хотя бы раз в три месяца должна проверять работоспособность этой кассы и ставить соответствующие пометки. Коренский предоставил людям наиболее обширный выбор кассовой и другой вспомогательной техники (счетчики денег, денежные ящики, сканеры, пластиковые карты).
Контрольно-кассовая машина ККМ – устройство, предназначенное для пробития чеков, на которых излагается информация о предпринимателе (его ИИН, название его фирмы), серийный номер кассового аппарата, название и цена товара и прочее. ККМ оснащена индикатором, собственной клавиатурой, питается либо от батарейки, либо от напряжения сети.
- ШТРИХ – МИНИ – К;
- ЭЛВЕС – МИКРО – К;
- МЕРКУРИЙ 115К, 130К…;
- ОРИОН 100К, 101К, 110К…;
- ОКА и другие.
Фискальный регистратор ФР – новое поколение «касс». Это устройство соединено с компьютером через COM-порт и все действия выполняет только с его помощью, т.е. полностью пользуется интерфейсом компьютера. Однако он питается от сети через специальный блок питания.
- ШТРИХ – ФР – К;
- ЭЛВЕС – ФР – К;
- ФЕЛИКС – 02К;
- ШТРИХ – МИНИ – ФР – К и другие.
POS-терминал – это устройство, которое объединяет компьютер и ФР в одно целое. Он обладает собственным процессором, монитором, клавиатурой и огромными возможностями.
Главный офис фирмы находится по адресу: улица Карпатская, 41«Б». А на улице Доватора, 144 расположен главный филиал фирмы.
Сервисный центр включает в себя:
- директора сервисного центра;
- начальника сервисного центра;
- главного инженера;
- старшего инженера по ремонту;
- инженера по ремонту;
- регламентного инженера по ремонту;
- 4-х инженеров по регламенту;
- 2-х инженеров по ремонту весов;
- 2-х сервис-менеджеров;
- инженера по приему и ремонту.
Сервис центр Формулы торговли обслуживает более 1000 касс по г.Ростову-на-Дону и области. Обслуживание производят инженеры по регламенту. Существует несколько форм договоров, в соответствии с которыми кассы обслуживаются один раз в месяц (базовый), в два месяца (упрощенный), в три месяца (эконом-договор).
1.2 Постановка задачи объектно-ориентированного анализа деятельности ООО «Формула торговли»
Объектно-ориентированный анализ преследует следующие цели:
1. Понять проблему или проблемы, которые программная (или иная) система должна решить.
2. Задать значимые вопросы о проблеме и о системе.
3. Обеспечить основу для ответов на вопросы о специфических свойствах проблемы и системы.
Одним из важнейших преимуществ анализа вне зависимости от конечного результата является то, что в процессе его задаются важные вопросы (цель 2). Метод анализа позволяет развеять иногда фатальный для разработки туман двусмысленности, предоставляя специалистам данной конкретной области возможность подготовить необходимые исходные данные.
Основой для анализа должна стать объектно-ориентированная модель деятельности ООО «Формула торговли», которая позволит детально рассмотреть различные процессы как часть системы и связь между объектами. Необходимо построить диаграммы прецедентов, классов, деятельности и взаимодействий. В конечном итоге нужно сформировать минимальную совокупность диаграмм, необходимых и достаточных для определения базового инварианта архитектуры, позволяющего исследовать систему на предмет реализуемости в рамках статической структуры, целедостижимости в процессе наблюдаемого поведения и управляемых переходов в пространстве состояний системы [4].
2. Объектно-ориентированный анализ и построение базовой модели деятельности ООО «Формула торговли»
2.1 Моделирование контекста и функциональных требований к системе
В процессе моделирования человек упрощает реальность, чтобы лучше понять проектируемую систему. Используя язык UML, можно строить модели из базовых блоков, таких как классы, узлы, зависимости, обобщения и ассоциации. Диаграммы позволяют обозревать эти строительные блоки в удобной для понимания форме.
UML – это графический язык для визуализации, специфицирования, конструирования и документирования артефактов программной системы. Его используют для того, чтобы моделировать системы. Модель – это упрощение реальности, абстракция, создаваемая, чтобы лучше понять систему. Система, зачастую разложенная на ряд подсистем, – это множество элементов, организованных некоторым образом для выполнения определенной цели. Система описывается набором моделей, по возможности рассматривающих ее с различных точек зрения. Важными составными частями модели являются такие сущности, как классы, интерфейсы, компоненты и узлы. В UML модели применяются для организации подобных абстракций системы. По мере возрастания сложности обнаруживается, что сущность, на одном уровне абстракции представлявшаяся как система, на другом - более высоком – оказывается лишь подсистемой. В UML можно моделировать системы и подсистемы как единое целое и тем самым органично решать проблему масштабирования.
Хорошо структурированные модели помогают визуализировать, специфицировать, конструировать и документировать систему под разными (но вместе с тем взаимосвязанными) углами зрения. Хорошо структурированные системы функционально, логически и физически связаны, но при этом составлены из мало зависящих друг от друга подсистем.
Для моделирования вида системы с точки зрения прецедентов применяются диаграммы прецедентов. Чаще всего это предполагает моделирование контекста системы, подсистемы или класса либо моделирование требований, предъявляемых к поведению указанных элементов. Прецедент – это описание множества последовательностей действий (включая их варианты), которые выполняются системой для того, чтобы актер получил результат, имеющий для него определенное значение. Актер представляет собой логически связанное множество ролей, которые играют пользователи прецедентов во время взаимодействия с ними. Актерами могут быть как люди, так и автоматизированные системы.
Диаграммы прецедентов имеют большое значение для визуализации, специфицирования и документирования поведения элемента. Они облегчают понимание систем, подсистем или классов, представляя взгляд извне на то, как данные элементы могут быть использованы в соответствующем контексте. Кроме того, такие диаграммы важны для тестирования исполняемых систем в процессе прямого проектирования и для понимания их внутреннего устройства при обратном проектировании.
На языке UML способы, которыми элементы связаны друг с другом, моделируются в виде отношений. Отношением (Relationship) называется связь между элементами. В объектно-ориентированном моделировании тремя самыми важными отношениями являются зависимости, обобщения и ассоциации. Графически отношение представлено линией, тип которой зависит от вида отношения.
Ассоциацией (Association) называется структурное отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа.
Зависимостью (Dependency) называют отношение использования, согласно которому изменение в спецификации одного элемента может повлиять на другой элемент, его использующий, причем обратное не обязательно. Графически зависимость изображается пунктирной линией со стрелкой, направленной от данного элемента на тот, от которого он зависит.
Обобщение (Generalization) – это отношение между общей сущностью (суперклассом, или родителем) и ее конкретным воплощением (субклассом, или потомком). Обобщение означает, что объекты потомка могут использоваться всюду, где встречаются объекты родителя, но не наоборот. Другими словами, потомок может быть подставлен вместо родителя. При этом он наследует свойства родителя, в частности его атрибуты и операции. Часто, хотя и не всегда, у потомков есть и свои собственные атрибуты и операции, помимо тех, что существуют у родителя. Графически отношение обобщения изображается в виде линии с большой незакрашенной стрелкой, направленной на родителя.
Важнейшая особенность разработки прецедентов состоит в том, что не специфицируется, как они будут реализованы. Прецеденты специфицируют желаемое поведение, но ничего не говорят о том, как его достичь. И, что очень важно, это позволяет эксперту или конечному пользователю общаться с разработчиками, конструирующими систему в соответствии с требованиями, не углубляясь в детали реализации. Прецеденты могут быть применены ко всей системе или к ее части, в том числе к подсистемам или даже к отдельным классам и интерфейсам. В любом случае прецеденты не только представляют желаемое поведение этих элементов, но могут быть использованы как основа для их тестирования на различных этапах разработки.
Система анализа информации о процессе функционирования ООО «Формула торговли» должна удовлетворять определенным требованиям, которые указаны в таблице 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 условно разделяются на пять типов, один из которых – диаграмма прецедентов – был рассмотрен выше:
- диаграммы последовательностей акцентируют внимание на временной упорядоченности сообщений;
- диаграммы кооперации сфокусированы на структурной организации объектов, посылающих и получающих сообщения;
- диаграммы состояний описывают изменение состояния системы в ответ на события;
- диаграммы деятельности демонстрируют передачу управления от одной деятельности к другой.
2.3.1 Моделирование потоков управления (диаграмма деятельности)
Использовать диаграмму деятельности для моделирования некоторого динамического аспекта системы можно в контексте практически любого элемента модели. Но чаще всего они рассматриваются в контексте системы в целом, подсистемы, операции или класса. Можно присоединять диаграммы деятельности к прецедентам и кооперациям (для моделирования динамических аспектов сообщества объектов).
При моделировании динамических аспектов системы диаграммы деятельности применяются в основном двумя способами:
- для моделирования рабочего процесса. Здесь внимание фокусируется на деятельности с точки зрения актеров, которые сотрудничают с системой. Рабочие процессы часто оказываются с внешней, обращенной к пользователю стороны программной системы и используются для визуализации, специфицирования, конструирования и документирования бизнес-процессов, составляющих существо разрабатываемой системы. Для такого применения диаграмм деятельности моделирование траекторий объектов имеет особенно важное значение;
- для моделирования операции. В этом случае диаграммы деятельности используются как блок-схемы для моделирования деталей вычислений. Для такого применения особенно важно моделирование точек ветвления, разделения и слияния. При этом контекст диаграммы деятельности включает параметры операции и ее локальные объекты.
Диаграммы деятельности могут использоваться самостоятельно для визуализации, специфицирования, конструирования и документирования динамики совокупности объектов, но они пригодны также и для моделирования потока управления при выполнении некоторой операции. Если в диаграммах взаимодействий акцент делается на переходах потока управления от объекта к объекту, то диаграммы деятельности описывают переходы от одной деятельности к другой. Деятельность (Activity) – это некоторый относительно продолжительный этап выполнения в автомате. В конечном итоге деятельность сводится к некоторому действию, которое составлено из атомарных вычислений, приводящих к изменению состояния системы или возврату значения.
Диаграммы деятельности важны не только для моделирования динамических аспектов поведения системы, но и для построения выполняемых систем посредством прямого и обратного проектирования.
Состояние действия (action state) является специальным случаем состояния с некоторым входным действием и, по крайней мере, одним выходящим из состояния переходом. Этот переход неявно предполагает, что входное действие уже завершилось. Состояние действия не может иметь внутренних переходов, поскольку оно является элементарным. Обычное использование состояния действия заключается в моделировании одного шага выполнения алгоритма (процедуры) или потока управления.
Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния. Они имеют такие же обозначения, как и на диаграмме состояний. При этом каждая деятельность начинается в начальном состоянии и заканчивается в конечном состоянии. Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали сверху вниз. В этом случае начальное состояние будет изображаться в верхней части диаграммы, а конечное – в ее нижней части.
Когда действие или деятельность в некотором состоянии завершается, поток управления сразу переходит в следующее состояние действия или деятельности. Для описания этого потока используются переходы (Transitions), показывающие путь из одного состояния действия или деятельности в другое.
Простые и ветвящиеся последовательные переходы в диаграммах деятельности используются чаще всего. Однако можно встретить и параллельные потоки, и это особенно характерно для моделирования бизнес-процессов. В UML для обозначения разделения и слияния таких параллельных потоков выполнения используется синхронизационная черта, которая рисуется в виде жирной вертикальной или горизонтальной линии. Каждый из параллельно выполняющихся потоков управления существует в контексте независимого активного объекта, который, как правило, моделируется либо процессом, либо вычислит
При моделировании течения бизнес-процессов иногда бывает полезно разбить состояния деятельности на диаграммах деятельности на группы, каждая из которых представляет отдел компании, отвечающий за ту или иную работу. В UML такие группы называются дорожками (Swimlanes), поскольку визуально каждая группа отделяется от соседних вертикальной чертой. Дорожки – это разновидность пакетов, описывающие связанную совокупность работ.
Диаграмма деятельности ООО «Формула торговли» представлена на рисунке 3.
Рисунок 3 – Диаграмма деятельности ООО «Формула торговли»
Рассмотрим подробно первую часть диаграммы, которая описывает оформление заказа клиента и продажу товара (рисунок 4). Процесс начинается с действий: Обработать заказ клиента, Оформить заказ, Проверить наличие на складе со стороны Менеджера. Далее происходит ветвление процесса, которое описывает различные пути выполнения в зависимости от значения некоторого булевского выражения. В данном случае если товар на складе в наличии, то Грузчик отгружает товар со склада и доставляет в отдел Менеджеру. Если товара в наличии нет, то Менеджер заказывает товар у фирмы-производителя. Далее потоки Получить товар и Выставить счет клиенту выполняются параллельно.
Рисунок 4 – Диаграмма деятельности для оформления заказа и продажи товара
Вторая часть диаграммы, описывающая процесс сервисного обслуживания, показана на рисунке 5.
Рисунок 5 – Диаграмма деятельности для сервисного обслуживания
2.3.2 Моделирование временного аспекта и структурной организации системы
Диаграммы взаимодействий используются для моделирования динамических аспектов системы. Сюда входит моделирование конкретных и прототипических экземпляров классов, интерфейсов, компонентов и узлов, а также сообщений, которыми они обмениваются, – и все это в контексте сценария, иллюстрирующего данное поведение. Диаграммы взаимодействий могут существовать автономно и служить для визуализации, специфицирования, конструирования и документирования динамики конкретного сообщества объектов, а могут использоваться для моделирования отдельного потока управления в составе прецедента.
Диаграммы взаимодействий важны не только для моделирования динамических аспектов системы, но и для создания исполняемых систем посредством прямого и обратного проектирования.
На диаграммах взаимодействий показывают связи, включающие множество объектов и отношений между ними, в том числе сообщения, которыми объекты обмениваются. При этом диаграмма последовательностей акцентирует внимание на временной упорядоченности сообщений, а диаграмма кооперации – на структурной организации посылающих и принимающих сообщения объектов. Такие диаграммы можно строить двумя способами – уделяя основное внимание временной упорядоченности сообщений или структурным отношениям между взаимодействующими объектами. Получаемые любым из этих способов диаграммы семантически эквивалентны и преобразуются друг в друга без потери информации.
Диаграммой последовательностей (Sequence diagram) называется диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени – вдоль оси Y. Диаграммой кооперации (Collaboration diagram) называется диаграмма взаимодействий, основное внимание в которой уделяется структурной организации объектов, принимающих и отправляющих сообщения. Графически такая диаграмма представляет собой граф из вершин и ребер.
На диаграммах последовательностей внимание акцентируется прежде всего на временной упорядоченности сообщений. Для создания такой диаграммы надо прежде всего расположить объекты, участвующие во взаимодействии, в верхней ее части вдоль оси X. Обычно инициирующий взаимодействие объект размещают слева, а остальные – правее (тем дальше, чем более подчиненным является объект). Затем вдоль оси Y размещаются сообщения, которые объекты посылают и принимают, причем более поздние оказываются ниже. Это дает читателю наглядную картину, позволяющую понять развитие потока управления во времени.
Диаграммы последовательностей характеризуются двумя особенностями, отличающими их от диаграмм кооперации. Во-первых, на них показана линия жизни объекта. Вторая особенность этих диаграмм – фокус управления.
Диаграмма кооперации акцентирует внимание на организации объектов, принимающих участие во взаимодействии. Для создания диаграммы кооперации нужно расположить участвующие во взаимодействии объекта в виде вершин графа. Затем связи, соединяющие эти объекты, изображаются в вид дуг этого графа. Наконец, связи дополняются сообщениями, которые объекты принимают и посылают. Это дает пользователю ясное визуальное представление о потоке управления в контексте структурной организации кооперирующихся объектов.
У диаграмм кооперации есть два свойства, которые отличают их от диаграмм последовательностей. Первое – это путь. Второе свойство – это порядковый номер сообщения.
Поскольку диаграммы последовательностей и кооперации используют одну и ту же информацию из метамодели UML, они семантически эквивалентны. Это означает, что можно преобразовать диаграмму одного типа в другой без какой-либо потери информации. Это не означает, однако, что на обеих диаграммах представлена в точности одна и та же информация. С другой стороны, на диаграмме последовательностей могут быть показаны возвращаемые сообщения, а на соответствующей диаграмме кооперации они отсутствуют. Таким образом, можно сказать, что диаграммы обоих типов используют одну модель, но визуализируют разные ее особенности.
При моделировании динамических аспектов системы диаграммы взаимодействий обычно используются двояко:
- для моделирования временной упорядоченности потоков управления. С этой целью используют диаграммы последовательностей. При этом внимание акцентируется на передаче сообщений во времени, что бывает особенно полезно для визуализации динамического поведения в контексте прецедентов. Простые итерации и ветвления на диаграммах последовательностей отображать удобнее, чем на диаграммах кооперации;
- для моделирования структурной организации потоков управления. В этом случае нужны диаграммы кооперации. Основное внимание при этом уделяется моделированию структурных отношений между взаимодействующими экземплярами, вдоль которых передаются сообщения. Для визуализации сложных итераций, ветвлений и параллельных потоков управления диаграммы кооперации подходят лучше, чем диаграммы последовательностей.
На одной диаграмме последовательностей можно показать только один поток управления (хотя с помощью нотации UML для итераций и ветвлений можно проиллюстрировать простые вариации). Поэтому, как правило, создают несколько диаграмм взаимодействий, одни из которых считаются основными, а другие описывают альтернативные пути и исключительные условия. Такой набор диаграмм последовательностей можно организовать в пакет, дав каждой диаграмме подходящее имя, отличающее ее от остальных.
На рисунке 6 показана диаграмма последовательности, показывающая последовательность действий при оформлении заказа и продажи товара клиенту.
Рисунок 6 – Диаграмма последовательности действий при оформлении заказа и продажи товара клиенту
На рисунке 7 изображена последовательность действий при проведении сервисного обслуживания кассовых аппаратов.
Рисунок 7 – Диаграмма последовательности действий при проведении сервисного обслуживания
На рисунок 8 показана диаграмма кооперации, которая описывает поток управления, связанный с проведением сервисного обслуживания кассовых аппаратов, причем внимание акцентируется на структурных отношениях между объектами. На диаграмме представлено пять объектов: Клиент, Сервис Центр, Инженер по регламенту, ККТ и Инженер по ремонту. Поток управления пронумерован явно. Действие начинается с того, что Клиент подписывает договор на сервисное обслуживание с Сервис Центром, после чего Сервис Центр выдает акты с данными клиентов Инженеру по регламенту, который едет на место, проводит обслуживание кассовых аппаратов, после чего заполняет журнал учета. Далее, если аппарат неисправен, Инженер по регламенту отвозит его в Сервис Центр, где Инженер по ремонту его ремонтирует. В конце Инженер по регламенту отвозит отремонтированную ККТ обратно Клиенту и Клиент оплачивает услуги в Сервис Центр.
Рисунок 8 – Диаграмма кооперации процесса сервисного обслуживания
2.3.3 Моделирование потоков управления (диаграмма состояний)
С помощью взаимодействий можно моделировать поведение сообщества совместно работающих объектов. Автомат же позволяет моделировать поведение отдельного объекта. Автомат (State machine) описывает поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни, отвечая на события, а также его реакций на эти события.
Автоматы используются для моделирования динамических аспектов системы. По большей части под этим понимается описание жизни экземпляров класса, прецеденто и системы в целом. Экземпляры могут реагировать на такие события, как сигналы, операции или истечение промежутка времени. Состояние (State) объекта – это ситуация в его жизни, на протяжении которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает какого-то события. Событие (Event) – это спецификация существенного факта, который происходит во времени и пространстве. В контексте автоматов событие – это стимул, способный вызвать срабатывание перехода. Переход (Transition) – это отношение между двумя состояниями, показывающее, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе состояние, как только произойдет определенное событие и будут выполнены заданные условия. Деятельность (Activity) – это продолжающееся неатомарное вычисление внутри автомата. Действие (Action) – это атомарное вычисление, которое приводит к смене состояния или возврату значения. Диаграмма состояний изображается в виде графа с вершинами и ребрами.
Визуализировать автомат можно двумя способами: выделяя передачу потока управления от одной деятельности к другой (с помощью диаграммы деятельности) или выделяя потенциальные состояния объектов и переходы между ними (с помощью диаграммы состояний). Хорошо структурированные автоматы подобны хорошо структурированным алгоритмам – они эффективны, просты, адаптируемы к разным ситуациям и просты для понимания.
Диаграмма состояний показывает автомат. Ее частной разновидностью является диаграмма деятельности, в которой все или большая часть состояний – это состояния деятельности, а все или большая часть переходов инициируются в результате завершения деятельности в исходном состоянии. Таким образом, при моделировании жизненного цикла объекта полезны как диаграммы деятельности, так и диаграммы состояний. Но если диаграмма деятельности показывает поток управления от деятельности к деятельности, то на диаграмме состояний представлен поток управления от состояния к состоянию.
Диаграммы состояний используются для моделирования динамических аспектов системы. По большей части под этим подразумевается моделирование поведения реактивных объектов. Реактивным называется объект, поведение которого лучше всего характеризуется его реакцией на события, произошедшие вне его собственного контекста. У реактивного объекта есть четко выраженный жизненный цикл, когда текущее поведение обусловлено прошлым. Диаграммы состояний можно присоединять к классам, прецедентам или системе в целом для визуализации, специфицирования, конструирования и документирования динамики отдельного объекта.
Обычно диаграмма состояний включает в себя:
- простые и составные состояния;
- переходы вместе с ассоциированными событиями и действиями.
При моделировании динамических аспектов системы, класса или прецедента диаграммы состояний обычно используются только с целью моделирования реактивных объектов.
Реактивный, или управляемый событиями, объект – это такой объект, поведение которого лучше всего характеризовать его реакцией на внешние события. Как правило, реактивный объект находится в состоянии ожидания, пока не получит событие, а когда это случается, его реакция зависит от предшествующих событий. После того как объект отреагирует на событие, он снова переходит в состояние ожидания следующего события. Для таких объектов интерес представляют прежде всего устойчивые состояния, события, инициирующие переходы из одного состояния в другое, и действия, выполняемые при смене состояния.
Одна диаграмма состояний может описать семантику одного реактивного объекта, но никогда – семантику всей системы, за исключением самых тривиальных случаев.
Диаграмма состояний для процесса сервисного обслуживания показана на рисунке 9 [1, 2, 3].
Рисунок 9 – Диаграмма состояний для сервисного обслуживания
2.4 Моделирование статического вида системы с точки зрения реализации и развертывания
Компонент (Component) – это физическая заменяемая часть системы, совместимая с одним набором интерфейсов и обеспечивающая реализацию какого-либо другого. Компонент изображается в виде прямоугольника с вкладками.
У каждого компонента должно быть имя, отличающее его от других компонентов. Имя – это текстовая строка; взятое само по себе, оно называется простым. К составному имени спереди добавлено имя пакета, в котором находится компонент. Имя компонента должно быть уникальным внутри объемлющего пакета.
Можно выделить три вида компонентов.
Во-первых, это компоненты развертывания (Deployment components), которые необходимы и достаточны для построения исполняемой системы. К их числу относятся динамически подключаемые библиотеки (DLL) и исполняемые программы (EXE).
Во-вторых, есть компоненты – рабочие продукты (Work product components). По сути дела, это побочный результат процесса разработки. Сюда можно отнести файлы с исходными текстами программ и данными, из которых создаются компоненты развертывания. Такие компоненты не принимают непосредственного участия в работе исполняемой системы, но являются рабочими продуктами, из которых исполняемая система создается.
В-третьих, есть компоненты исполнения (Execution components). Они создаются как следствие работы системы.
Диаграммы компонентов – это один из двух видов диаграмм, применяемых при моделировании физических аспектов объектно-ориентированной системы. Они показывают организацию наборов компонентов и зависимости между ними.
Диаграммы компонентов применяются для моделирования статического вида системы с точки зрения реализации. Сюда относится моделирование физических сущностей, развернутых в узле, например исполняемых программ, библиотек, таблиц, файлов и документов. По существу, диаграммы компонентов – это не что иное, как диаграммы классов, сфокусированные на системных компонентах.
Диаграммы компонентов важны не только для визуализации, специфицирования и документирования системы, основанной на компонентах, но и для создания исполняемых систем путем прямого и обратного проектирования.
Для визуализации статического аспекта физических компонентов и их отношений, а кроме того, для специфицирования деталей конструкции в UML используются диаграммы компонентов
Диаграмма компонентов (Component diagram) показывает набор компонентов и отношения между ними. Графически диаграмма компонентов представляется в виде графа с ребрами и вершинами.
Диаграмма компонентов обладает общими свойствами, присущими всем диаграммам – именем и графическим содержанием, которое отражает одну из проекций модели. Отличается она от других диаграмм своим специфичным содержанием.
Диаграммы компонентов обычно включают в себя:
- компоненты;
- интерфейсы;
- отношения зависимости, обобщения, ассоциации и реализации.
Диаграмма компонентов для системы управления заказами и сервисного обслуживания ООО «Формула торговли» представлена на рисунке 10.
Рисунок 10 – Диаграмма компонентов для ООО «Формула торговли»
Узел (Node) – это физический элемент, который существует во время выполнения и представляет вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а зачастую также и процессором. Графически узел изображается в виде куба. Множество объектов или компонентов, приписанных к узлу как группа, называется элементом распределения (Distribution unit).
Диаграммы развертывания, или применения, – это один из двух видов диаграмм, используемых при моделировании физических аспектов объектно-ориентированной системы. Такая диаграмма показывает конфигурацию узлов, где производится обработка информации, и то, какие компоненты размещены на каждом узле.
Диаграммы развертывания используются для моделирования статического вида системы с точки зрения развертывания. В основном под этим понимается моделирование топологии аппаратных средств, на которых выполняется система. По существу, диаграммы развертывания – это просто диаграммы классов, сосредоточенные на системных узлах. Диаграммы развертывания важны не только для визуализации, специфицирования и документирования встроенных, клиент-серверных и распределенных систем, но и для управления исполняемыми системами с использованием прямого и обратного проектирования.
В UML диаграммы развертывания используются для визуализации статических аспектов физических узлов и их взаимосвязей, а также для описания их деталей, которые имеют отношение к конструированию системы.
На диаграмме развертывания, или применения (Deployment diagram), показана конфигурация обрабатывающих узлов, на которых выполняется система, и компонентов, размещенных в этих узлах. Диаграмма развертывания представлена в виде графа с ребрами и вершинами.
Диаграммы развертывания обычно включают в себя:
- узлы;
- отношения зависимости и ассоциации.
Диаграмма развертывания для системы управления заказами и сервисного обслуживания ООО «Формула торговли» представлена на рисунке 11 [2, 3].
Рисунок 11 – Диаграмма развертывания для ООО «Формула торговли»
3. Концептуальное конструирование матрицы ответственностей
3.1 Разработка диаграммы целевых классов
Концептуальное конструирование системы преследует цель формирования минимальной совокупности диаграмм необходимых и достаточных для определения базового инварианта архитектуры, позволяющего исследовать систему на предмет реализуемости в рамках статической структуры, целедостижимости в процессе наблюдаемого поведения и управляемых переходов в пространстве состояний системы. Исходными для интеграции являются полученные на первых двух этапах диаграммы, каждая из которых отражает функциональную, статическую или поведенческую абстракцию системы. Однако принципиальным отличием данного этапа анализа является интегративный характер итеративного процесса, что собственно и позволяет классифицировать его как конструирование. Каждая из заключительных диаграмм представляет собой результат интеграции исходных диаграмм и является соответствующим (функциональным, статическим или поведенческим) инвариантом, образованным соединением целевой и системной (реализационной) диаграмм. При этом, цель выступает как сущность, определяющая направленность процессов самоорганизации (интеграции) на формирование и поддержание внешне- и внутрисистемных инвариантов (соответственно, функционального, статического или поведенческого). Эффективность функционирования механизма концептуального конструирования связана с методологией организации процедур интеграции диаграмм и итераций в процессе проведения анализа.
Объектно-ориентированная методология представляет UML-диаграммы, как инструмент исследования и результат анализа, а моделирование, как процесс исследования реальной системы путем итерационного изменения диаграмм, интерпретирующих ее существенные стороны. Однако процедуры, собственно, итеративных переходов или интеграции диаграмм в нотации UML не описаны, поскольку они в значительной степени связаны с особенностями предметной области.
Задача интеграции диаграмм является частным случаем исследования фундаментальной философской категории развития, как взаимосвязи и взаимодействия "вещи, свойства и отношения". Механизм взаимодействия в рамках указанной категории может быть представлен в виде формирования и поддержания внутрисистемного инварианта, например, нового свойства. Таким образом, в общем виде задача концептуального конструирования может быть сведена к анализу взаимосвязи исходных диаграмм и установления линии пересечения их плоскостей, как линии обретения нового качества.
Совокупность целевых классов определяется исходя из дерева целей и целевых функций, а диаграмма целевых классов представляет собой взаимно однозначное соответствие дереву целей, то есть оно всюду на множествах элементов и соотношений дерева целей и диаграммы классов определено, сюръективно, функционально и прообразом любого элемента из области значений диаграммы классов является единственный элемент из области определения дерева целей.
На рисунке 12 показана диаграмма целевых классов для ООО «Формула торговли». Основной целью на пути повышения прибыли является увеличение скорости и качества обслуживания клиентов, что позволит закрепить численность клиентской базы, и снижение стоимости сервисного обслуживания, что также привлечёт новых клиентов. На основании этого можно выделить целевые классы и построить диаграмму целевых классов [2, 5].
Рисунок 12 – Диаграмма целевых классов для ООО «Формула торговли»
3.2 Разработка диаграммы классов исполняющей системы и диаграммы ответственностей
Разработав диаграмму целевых классов, можно приступить к созданию диаграммы ответственностей. Она показывает, какие подцели должны решиться, чтобы достичь главной цели. Также видно, при помощи каких классов эти цели достигаются.
На диаграмме ответственностей, изображенной на рисунке 13, начальник отдела организует и распределяет введение премий и поощрений, организует проведение семинаров и тренингов для повышения квалификации сотрудников. Сотрудники, в свою очередь, в этих семинарах и тренингах участвуют. Также начальник отдела обеспечивает правильное распределение рабочего времени и обязанностей инженеров по регламенту. Чтобы не платить слишком высокую цену за сервисное обслуживание кассовых аппаратов, клиенты привозят их на фирму сами.
Рисунок 13 – Диаграмма ответственностей для ООО «Формула торговли»
На основе диаграммы ответственностей строится матрица ответственностей (таблица 4).
Таблица 4 – Матрица ответственностей для ООО «Формула торговли»
| Введение премий и поощрений | Проведение и участие в семинарах и тренингах | Распределение обязанностей инженеров по регламентному обслуживанию |
Распределение рабочего времени инженеров по регламентному обслуживанию |
В ремонт ККТ привозят сами клиенты | |
| Сотрудники фирмы | - | Участвуют | - | - | - |
| Начальник отдела | Организует | Организует | Обеспечивает | Обеспечивает | - |
| Клиент | - | - | - | - | Выполняет |
Заключение
В ходе данной работы была описана деятельность ООО «Формула торговли», проведен объектно-ориентированный анализ с построением базовой модели и описано функционирование системы в виде дискретно-событийной модели. Чтобы найти возможные пути повышения эффективности работы и, соответственно, прибыли фирмы была построена концептуальная модель процесса функционирования фирмы и на ее основе – матрица ответственностей. Таким образом, в результате подробного описания деятельности фирмы и концептуального конструирования основная цель – увеличение прибыли ООО «Формула торговли» – была достигнута.
Литература
1. Информационные технологии [Электронный ресурс] Режим доступа: http://www.citforum.ru, свободный.
2. Jacobson, I., Booch, G. and Rumbaugh. J. The Unified Software Development Process. Reading, Mass.: Addison-Wesley, 1999.
3. Язык UML. Руководство пользователя [Электронный ресурс] Режим доступа: http://sitemonitor.ru/doc/UML_HTM/, свободный.
4. Б. Мейер Основы объектно-ориентированного проектирования [Электронный ресурс] Режим доступа: http://www.intuit.ru/department/se/ooad/9/5.html, свободный.
5. Википедия [электронный ресурс]: свободная энциклопедия – http://ru.wikipedia.org/wiki/.