Объектно-ориентированный анализ и проектирование программного обеспечения. Программное обеспечение торговой компании

Размещено на http://www.allbest.ru/

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Тема: Объектно-ориентированный анализ и проектирование программного обеспечения. Программное обеспечение торговой компании

Компания - торговый посредник - продает товары различных производителей. Для обеспечения своей деятельности она нуждается в программной системе обработки заказов.

Дважды в год компания публикует каталог продуктов, который рассылается клиентам и другим заинтересованным лицам. Клиенты приобретают товары, направляя в компанию перечень продуктов с информацией об оплате. Компания выполняет заказы и отправляет товары по адресам клиентов.

Система должна отслеживать заказ от момента его получения до отправки товара. Клиенты могут возвращать товары, оплачивая, возможно, при этом некоторые издержки. Некоторые клиенты пользуются заказом товаров через Интернет. Компания пользуется услугами различных транспортных и страховых компаний.



Глоссарий проекта

Менеджер - человек, работающий с системой торговой фирмы, сотрудник фирмы.

Клиент- человек или организация, желающий(ая) оформить заказ на ряд продукции по прайсу.

Товар - позиция прайс-листа, товар, имеющийся в наличии или под заказ, который фирмы может поставить.

Заказ - совокупность сведений о товарах, клиенте, оплате, хранящаяся в БД системы и отражающая одну конкретную операцию продажи ряда товаров клиенту.



Создание модели вариантов использования

В результате анализа технического задания была составлена следующая диаграмма прецедентов рис. 1.

Рис. 1- Диаграмма вариантов использования для системы торговой компании

Описание прецедента «Оформление заказа»

Краткое описание

Вариант использования позволяет клиенту оформить заказ на поставку ряда товаров (не менее одного товара) в соответствии с каталогом (прайс-листом) и сохранить сведения о нем в БД системы.

Предусловия

Перед выполнением этого варианта использования необходимо чтобы были известны исходные данные о товаре (название, производитель, стоимость) и клиенте (имя, телефон, адрес).

Основной поток событий

1. Вариант использования начинается, когда клиент выбирает пункт меню на сайте «Оформить заказ» или отправляет список продукции по e-mail менеджеру и это действие фиксируется в БД.

2. Клиент (или сотрудник, если заказ прислан по e-mail) вводит информацию о заказе в поля формы.

3. Система автоматически присваивает идентификационный номер заказу.

На этом этапе могут возникнуть ошибки формата ввода в поля формы «Оформление заказа», при этом выполняется альтернативный поток событий А1.

4. По запросу менеджера система сохраняет в БД информацию о клиенте.

5. Вариант использования завершается.

Альтернативный поток событий А1. Ошибки формата ввода в поля формы «Оформление заказа»

1. Система выдает предупреждающее сообщение пользователю.

2. В случае исправления ошибок ввода пользователем, система переходит к п.5 основного потока.

3. Вариант использования завершается.

Постусловия

Если вариант использования выполнен успешно, то сведения о новом заказе будут сохранены в БД.

В противном случае состояние системы не изменится.

Описание прецедента «Регистрация клиента»

Краткое описание

Вариант использования позволяет сотруднику торговой фирмы зарегистрировать нового клиента и сохранить сведения о нем в БД системы или же с помощью Интернет новому пользователю самостоятельно зарегистрироваться в системе, как клиенту.

Предусловия

Перед выполнением этого варианта использования необходимо чтобы была известна информация о клиенте (ФИО и телефон).

Основной поток событий

1. Вариант использования начинается, когда сотрудник (пользователь) оформляет новый заказ («Оформление заказа») на поставку товара и такого клиента в БД не существует.

2. Сотрудник (пользователь) вводит информацию о клиенте (ФИО, адрес и номер телефона).

3. Система автоматически присваивает идентификационный номер клиенту.

4. Система по запросу пользователя осуществляет сохранение сведений о новом клиенте в БД.

На этом этапе могут возникнуть ошибки формата ввода в поля формы «Оформление заказа», при этом выполняется альтернативный поток событий А1.

5. Вариант использования завершается.

Альтернативный поток событий А1. Ошибка формата ввода в поля формы «Оформление заказа»

1. Система выдает предупреждающее сообщение пользователю.

2. В случае исправления ошибок ввода пользователем, система переходит к п.4 основного потока событий.

3. Вариант использования завершается.

Постусловия

Если вариант использования выполнен успешно, то сведения о новом клиенте будут сохранены в БД.

В противном случае состояние системы не изменится.

Описание прецедента «Проведение заказа»

Краткое описание

Вариант использования позволяет сотруднику торговой компании провести выполнение заказа клиента на товары.

Предусловия

Перед выполнением этого варианта использования необходимо чтобы была сформирована БД со сведениями о заказах, клиентах и товарах.

Основной поток событий

1. Вариант использования начинается, когда менеджер выбирает пункт меню программы «Принять заказ».

2. Сотрудник выбирает подпункт меню «Ввести данные для оплаты» или «Подобрать транспортную компанию».

3. Сотрудник указывает данные по оплате (реквизиты, сумма) и/или данные о транспортной компании.

На этом этапе могут возникнуть ошибки формата ввода в поля формы «Информация об оплате», при этом выполняется альтернативный поток событий А1.

4. Менеджер указывает дату отгрузки заказа.

5. Менеджер отправляет заказ клиенту для оплаты;

6. Клиент оплачивает заказ (если заказ через интернет, то оплата проходит через платежный терминал и информация сохраняется в БД, в противном случае менеджер вручную вносит информацию по оплате заказа в БД на основании платежных документов).

На этом этапе могут возникнуть ошибки ввода данных на форме «Оплата заказа», при этом выполняется альтернативный поток событий А2.

7. Выполняется отгрузка заказа и заказ переводится на стадию «Отгружен».

8. После получения заказа клиентом, клиент уведомляет об этом торговую компанию, и заказ в БД помечается завершенным.

9. Вариант использования завершается.

Альтернативный поток событий А1. Ошибка формата ввода в поля формы «Информация об оплате»

1. Система выдает предупреждающее сообщение пользователю.

2. В случае исправления ошибок ввода пользователем, система переходит к п.4 основного потока событий.

3. Вариант использования завершается.

Альтернативный поток событий А2. Ошибка формата ввода в поля формы «Оплата заказа»

1. Система выдает предупреждающее сообщение пользователю.

2. В случае исправления ошибок ввода пользователем, система переходит к п.7 основного потока событий.

3. Вариант использования завершается.

Постусловия

Если вариант использования выполнен успешно, то информация по запросу будет обновлена в БД и статус заказа изменится.

В противном случае состояние системы не изменится.

Описание прецедента «Публикация каталога»

Краткое описание

Вариант использования «Публикация каталога» позволяет менеджеру торговой компании опубликовать обновленный каталог товаров (прайс-лист) на основании выборки данных из БД.

Предусловия

Перед выполнением этого варианта использования необходимо чтобы в БД была информация хотя бы по одному товару, имеющемуся в наличии.

Основной поток событий

1. Вариант использования начинается, когда менеджер выбирает пункт меню в программе «Опубликовать каталог».

2. Менеджер вводит данные для выборки товаров (производитель, название и т.д.) и нажимает «Выбрать».

На этом этапе могут возникнуть ошибки ввода и обработки данных, при этом выполняется альтернативный поток А1.

3. Система по запросу менеджера выполняет поиск данных и возвращает список менеджеру.

На этом этапе может возникнуть ошибка отсутствия результатов, при этом выполняется альтернативный поток А2.

4. Менеджер, ознакомившись с результатом выборки, нажимает «Опубликовать каталог».

5. Вариант использования завершается.

Альтернативный поток событий А1. Ошибка ввода и обработки данных.

1. Система выдает предупреждающее сообщение менеджеру.

2. В случае исправления ошибок ввода сотрудником, система переходит к п.3 основного потока событий.

3. Вариант использования завершается.

Альтернативный поток событий А2. Система не может вернуть результат запроса.

1. Система выдает предупреждающее сообщение менеджеру.

2. В случае исправления ошибок сотрудником, система переходит к п.4 основного потока событий.

3. Вариант использования завершается.

Постусловия

Если вариант использования выполнен успешно, то на сайте компании будет опубликован обновленный каталог, кроме того PDF файл каталога будет сохранен на сервере.

В противном случае состояние системы не изменится.

Описание прецедента «Возврат заказа»

Краткое описание

Вариант использования «Возврат заказа» позволяет менеджеру/клиенты оформить возврат товара по определенному заказу в случае, если товар пришел ненадлежащего качества.

Предусловия

Перед выполнением этого варианта использования необходимо чтобы клиент уведомил менеджера торговой фирмы о желании оформить возврат заказа и отправил полученный товар обратно транспортной компанией. Также должен быть известен идентификационный номер заказа.

Основной поток событий

1. Вариант использования начинается, когда менеджер (или клиент, если заказ оформлен через интернет) выбирает пункт меню программы «Оформить возврат заказа».

1.1 Клиент подтверждает возврат заказа с указанием «полный» или «частичный».

2. Менеджер вносит идентификационный номер заказа в форму «Возврат заказа».

3. Система выводит список товаров по заказу из которого менеджер отмечает возвращаемые.

4. Система формирует данные для отправки заказа в торговую компанию и менеджер отправляет эти данные клиенту.

5. Менеджер отмечает получение возвращаемого товара.

6. В случае, если товар получен, менеджер осуществляет возврат денежных средств клиенту.

7. Менеджер переводит возвращенный товар на стадию «в обработке».

8. Система осуществляет сохранение сведений о заказе и товаре в БД.

6. Вариант использования завершается.

Постусловия

Если вариант использования выполнен успешно, то сведения о возврате заказа будут сохранены в БД, статус возвращенных товаров изменится на «в обработке». Данные товары отправятся на проверку качества и в случае определения брака, товары будут списаны. Клиенту осуществляется возврат средств.

В противном случае состояние системы не изменится.

Описание прецедента «Формирование отчетов»

Краткое описание

Вариант использования позволяет менеджеру сформировать все основные отчеты по деятельности компании.

Предусловия

Перед выполнением этого варианта использования необходимо, чтобы БД содержала сведения о товарах и заказах, а также документах оплаты заказов.

Основной поток событий

1. Вариант использования начинается, когда менеджер выбирает соответствующий пункт меню программы.

2. Система по запросу клиента выбирает из БД все необходимые данные (заказы за период, поступления на основании оплаты заказов, товары «в наличии»).

3. В случае отсутствия запрашиваемых данных система выдает соответствующее сообщение и система переходит к п.5

4. На основании результатов запроса формируется текстовый документ и окно программы, содержащие дату составления отчета, запрашиваемую для отчета информацию. Отчет, при необходимости, может быть выведен на печать.

5. Вариант использования завершается.

Постусловия

Если вариант использования выполнен успешно, то будет сформирован текстовый документ - отчет по товарам/заказам/оплатам.

В противном случае состояние системы не изменится.

Создание классов анализа, участвующих в реализации вариантов использования

На рис. 2 представлены предварительно определенные классы анализа системы, т.е. идентифицированы ключевые абстракции предметной области.

база данные реляционный код



Рис. 2- Классы анализа для системы торговой компании

Создание диаграмм последовательности (Sequence Diagram) и кооперативных диаграмм (Collaboration diagram) для каждого прецедента.

В ходе разработки диаграмм взаимодействия помимо вышеперечисленных классов добавились новые, в частности классы входных форм, классы работы с БД, а также классы, обеспечивающие выполнение основных программных функций.

На рис. 3-8 представлены диаграммы последовательности и кооперативные диаграммы, участвующие во всех ранее определенных вариантах использования.



а)

б)

Рис. 3-Диаграммы взаимодействия для варианта использования «Регистрация клиента»

а) диаграмма последовательности

б) кооперативная диаграмма



а)

б)

Рис. 4- Диаграммы взаимодействия для варианта использования «Оформление заказа»

а) диаграмма последовательности

б) кооперативная диаграмма



а)

б)

Рис. 5- Диаграммы взаимодействия для варианта использования «Проведение заказа»

а) диаграмма последовательности

б) кооперативная диаграмма



а)

б)

Рис. 6- Диаграммы взаимодействия для варианта использования «Возврат заказа»

а) диаграмма последовательности

б) кооперативная диаграмма



а)

б)

Рис. 7- Диаграммы взаимодействия для варианта использования «Публикация каталога»

а) диаграмма последовательности

б) кооперативная диаграмма



а)

б)

Рис. 8- Диаграммы взаимодействия для варианта использования «Формирование отчетов»

а) диаграмма последовательности

б) кооперативная диаграмма



ПРОЕКТИРОВАНИЕ СИСТЕМЫ

Создание диаграмм проектных классов, описывающих реализацию вариантов использования.

На основе анализа диаграмм взаимодействия, построим диаграммы классов, описывающих реализацию вариантов использования рис. 9-13.

Рис. 9- Диаграмма классов для варианта использования «Регистрировать клиента»



Рис. 10- Диаграмма классов для варианта использования «Оформление заказа»



Рис. 11- Диаграмма классов для варианта использования «Проведение заказа»



Рис. 12- Диаграмма классов для варианта использования «Публикация каталога»



Рис. 13- Диаграмма классов для варианта использования «Формирование отчетов»

Главная диаграмма проектных классов для всей системы представлена на рис. 14.



Рис. 14- Диаграмма классов для всей системы

Описание классов см. табл. 1

Таблица 1-Описание классов системы

Название	Описание
frmMain Главная форма	Описание Является основным окном программы. Обязанности: - создавать и показывать вызываемые пользователем окна программы.
FrmCreateCustomer, FrmReport, FrmCreateCatalogue, FrmCreateOrder, FrmEditOrder Основные формы программы	Описание Набор форм представляющих собой пользовательский интерфейс. Являются потомками класса FrmMain (базовый класс в иерархии форм данного проекта). Обязанности: -позволяет вводит входные данные по всем ключевым объектам система (создавать и редактировать информацию в БД). Класс FrmReport позволяет также генерировать и сохранять отчеты в системе.
MainController Контроллер главной формы	Описание: Класс предназначен для запуска и управления приложением Обязанности: - осуществлять запуск приложения; - осуществлять вызов форм приложения.
ReportController Контроллер модуля отчетности	Описание: Класс предназначен для генерации отчетов на основании данных из БД. Обязанности: - осуществлять выборку данных на основании заданных параметров; - формировать экранную форму отчета с выводом на печать.
ItemController Контроллер модуля «Товары» (для формы «Публикация каталога»)	Описание: Класс предназначен для управления информацией о товарах. Обязанности: - осуществлять создание/редактирование/удаление товаров; - осуществлять публикацию каталога; - осуществлять рассылку каталога.
CustomerController Контроллер модуля «Клиенты» (для формы «Регистрация клиента»)	Описание: Класс предназначен для оформления нового заказа клиента. Обязанности: - осуществлять проверку данных о заказе; -рассчитывать стоимость заказа; -сохранять сведения о заказе в БД; -формировать отчет о заказе для вывода на печать.
OrderController Контроллер заказов (для форм создания и редактирования заказов)	Описание: Класс предназначен для оформления и проведения заказов, а также их возврата клиентом. Обязанности: - обрабатывать запросы и выводить данные о заказах; - обрабатывать запросы и создавать/изменять информацию о заказах.
TableModel Базовый невизуальный класс, предназначенный для работы программы с таблицами БД.	Описание: Позволяет осуществлять взаимодействие программного приложения и таблицы БД.

Группировка классов по пакетам осуществлялась на основании подхода MVC: по архитектуре проекта (MVC - Model-View-Controller) рис. 16.



Рис. 15- Диаграмма пакетов системы

Проектирование схемы базы данных

На рис. 16 представлена схема реляционной базы данных для системы торговой компании.

Рис. 16- Схема базы данных системы



РЕАЛИЗАЦИЯ СИСТЕМЫ

Построение диаграммы компонентов для каждого пакета и для системы в целом

Диаграммы компонентов для всех пакетов представлены на рис. 17.

Компоненты ControllersComp, ModelsComp, FormsComp, MainComp представляют собой файлы библиотеки кода программы.

а)для пакета «Controllers» b) для пакета «Forms»

c) для пакета «Models» d) для пакета «Main»

Рис. 17- Диаграммы компонентов для каждого пакета системы

На рис. 18 показана диаграмма компонентов всей системы. Компонент videoprokat.exe является спецификацией задачи и представляет собой исполняемую программу.



Рис. 18- Диаграмма компонентов системы

Построение диаграммы размещения

Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. На рис. 19 представлена диаграмма размещения для системы торговой компании.

Рис. 19- Диаграмма размещения для системы торговой компании



Автоматическая генерация кода нескольких компонентов средствами Rational Rose

1. Откройте диаграмму компонентов системы.

2. Выберите все объекты на диаграмме компонентов.

3. Выберите Tools>Java>Code Generation в меню.

4. Выполните генерацию кода.

5. Просмотрите результаты генерации (контекстное меню компонентов Tools> Java >Browse Header и Tools> Java >Browse Body).



ИСПОЛЬЗУЕМАЯ ЛИТЕРАТУРА

1. В. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика, 1998.

2. Информационные системы / Петров В.Н. - СПб.: Питер,2002. - 688 с.: ил.Информационные технологии на железнодорожном транспорте: Учеб. для вузов ж.-д. трансп. / Э.К. Лецкий, В.И. Панкратов, В.В. Яковлев и др.; Под. ред. Э.К. Лецкого, Э.С. Поддавашкина, В.В. Яковлева. - М.: УМК МПС России, 2000 -

680 с.

3. Вендров А.М. Проектирование программного обеспечения экономических информационных систем.- М.: Финансы и статистика, 2002.

4. Дэвид А. Марка и Клемент МакГоуэн / Методология структурного анализа и проектирования SADT.

5. Дружинин Г.В. Расчеты автоматизированных систем управления (на примерах АСУ железнодорожным транспортом)/Под ред. Г.В. Дружинина.- М.: 1985.

6. Якубайтис Э.А. Информационные сети и системы: Справочная книга. М.: Финансы и статистика, 1996 - 368 с.

Размещено на Allbest.ur