Курсовая работа: Объектно-ориентированный анализ и проектирование деятельности ООО "Формула торговли"
Важнейшая
особенность разработки прецедентов состоит в том, что не специфицируется, как они
будут реализованы. Прецеденты специфицируют желаемое поведение, но ничего не говорят
о том, как его достичь. И, что очень важно, это позволяет эксперту или конечному
пользователю общаться с разработчиками, конструирующими систему в соответствии с
требованиями, не углубляясь в детали реализации. Прецеденты могут быть применены
ко всей системе или к ее части, в том числе к подсистемам или даже к отдельным классам
и интерфейсам. В любом случае прецеденты не только представляют желаемое поведение
этих элементов, но могут быть использованы как основа для их тестирования на различных
этапах разработки.
Система анализа информации
о процессе функционирования ООО «Формула торговли» должна удовлетворять определенным
требованиям, которые указаны в таблице 1.
интернет
журналистика портал информационный
Таблица 1 – Распределение
требований по субъектам и прецедентам
№ |
Требование |
Субъект |
Прецедент |
1 |
Осуществлять беспрепятственный прием заявок
на покупку или ремонт контрольно-кассовой техники. |
Клиент |
Заявка на ремонт, Заявка на покупку ККТ |
2 |
Предоставлять необходимые программные и
технические средства для оформления заявки клиента. С помощью ПО изменять, добавлять,
сортировать данные по времени поступления |
Клиент |
Оформить заявку на покупку ККТ |
3 |
Осуществлять быструю подачу данных о заявках
и предыдущих работах для дальнейшего их оформления, распечатки, отправки и прочее. |
Клиент |
Оформить договор на сервисное обслуживание,
Выписать счет |
4 |
Система должна предоставлять информацию
о текущем состоянии, чтобы ориентироваться в дальнейших действиях по обслуживанию
или ремонту. |
Клиент |
Отремонтировать ККТ, Провести обслуживание
ККТ, Исправить неполадки |
Исходя из данных
таблицы 1 построена диаграмма прецедентов (рисунок 1).

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