Курсовая работа: Объектно-ориентированный анализ и проектирование деятельности ООО "Формула торговли"
- 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.