Введение
В настоящее время – времявысоких технологий – людям не обойтись без помощи мобильных телефонов, компьютерови интернета, без помощи техники, которая выполняет за них тяжелую умственную работу.К такой технике принадлежат кассовые аппараты, которые имеет в своем обиходе каждыймагазин. Ростовская фирма «Формула торговли» занимается приобретением, производством,сбытом и сервисным обслуживанием кассовых аппаратов. Конечно, при приобретении кассовогоаппарата покупателю дается гарантия на ремонт (при поломке аппарата), но также покупательобязан заключить договор на сервисное обслуживание раз в один, два или три месяца.Не смотря на то, что фирма успешно функционирует на протяжении десяти лет, она неостанавливается на достигнутом и стремится совершенствовать свою работу.
Задачей данной курсовойработы является минимизация затрат времени и средств в процессе деятельности ООО«Формула торговли» с целью повышения эффективности работы фирмы и привлечения новыхклиентов, что, несомненно, обеспечит фирме большую прибыль.
Таким образом, увеличениеприбыли ООО «Формула торговли» – и есть цель работы.
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)– это некоторый относительно продолжительный этап выполнения в автомате. В конечномитоге деятельность сводится к некоторому действию, которое составлено из атомарныхвычислений, приводящих к изменению состояния системы или возврату значения.
Диаграммы деятельности важныне только для моделирования динамических аспектов поведения системы, но и для построениявыполняемых систем посредством прямого и обратного проектирования.
Состояние действия (actionstate) является специальным случаем состояния с некоторым входным действием и, покрайней мере, одним выходящим из состояния переходом. Этот переход неявно предполагает,что входное действие уже завершилось. Состояние действия не может иметь внутреннихпереходов, поскольку оно является элементарным. Обычное использование состояниядействия заключается в моделировании одного шага выполнения алгоритма (процедуры)или потока управления.
Каждая диаграмма деятельностидолжна иметь единственное начальное и единственное конечное состояния. Они имеюттакие же обозначения, как и на диаграмме состояний. При этом каждая деятельностьначинается в начальном состоянии и заканчивается в конечном состоянии. Саму диаграммудеятельности принято располагать таким образом, чтобы действия следовали сверхувниз. В этом случае начальное состояние будет изображаться в верхней части диаграммы,а конечное – в ее нижней части.
Когда действие или деятельностьв некотором состоянии завершается, поток управления сразу переходит в следующеесостояние действия или деятельности. Для описания этого потока используются переходы(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. Информационные технологии [Электронный ресурс]Режим доступа: www.citforum.ru, свободный.
2. Jacobson,I., Booch, G. and Rumbaugh. J. The Unified Software Development Process. Reading, Mass.: Addison-Wesley,1999.
3. Язык UML.Руководство пользователя [Электронный ресурс] Режим доступа: sitemonitor.ru/doc/UML_HTM/,свободный.
/>4. Б. Мейер Основыобъектно-ориентированного проектирования [Электронный ресурс] Режим доступа: www.intuit.ru/department/se/ooad/9/5.html,свободный.
5. Википедия [электронный ресурс]: свободнаяэнциклопедия – ru.wikipedia.org/wiki/.