Построение объектной модели информационной системы «Обеспечение продаж автосалона»

 

Необходимые высказывания, представленные в таблице 2, будут  представлены UML-диаграммами:

1. Диаграмма вариантов  использования моделирует функциональную  структуру предметной области  посредством вариантов использования  и отношений между ними. Данная  диаграмма представлена на рисунке  11.

 

 

Рисунок 11 – Диаграмма  вариантов использования

 

2. Диаграмма активности  моделирует алгоритмы ключевых  процессов предметной области.  Данная диаграмма представлена  на рисунке 12.

Рисунок 12 – Диаграмма активности 
1. Диаграмма классов моделирует отношения ключевых объектов. Данная диаграмма представлена на рисунке 13.

 

 

Рисунок 13 – Диаграмма  классов

 

3. Описание проблем и формирование концепции информационной системы

 

3.1 Проблемы предметной  области

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

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

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

В результате проведения проблемного  анализа выявлены следующие проблемы:

1. Необоснованные затраты  времени кассира на ввод номера  квитанции и номера автомобиля  в расчетно-кассовый аппарат.

2. Затраты времени на  устранения ошибок ввода номера  автомобиля в случае неправильного  ввода.

3.2 Концепция информационной  системы

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

Концепция ИС содержит набор  требований, сгруппированный как  минимум в три подраздела:

1. Основные понятия, которые  должна использовать в процессе  функционирования ИС;

2. Функциональные требования (или функциональные возможности), которыми должна удовлетворять  (обладать) ИС для того, чтобы успешно  решать проблемы;

3. Нефункциональные требования, которые определяют другие аспекты построения ИС (режимы работы, среда разработки, типовую архитектуру, используемые форматы данных и т.п.

3.2.1 Основные понятия

1. Автосалон – организация,  осуществляющая продажу новых  автомобилей.

2. Сеть автосалонов –  объединение автосалонов в рамках  одной компании.

3. Склад – место временного  хранения автомобилей автосалона.

4. Менеджер автосалона  – сотрудник автосалона, осуществляющий  работу с клиентом, связанную  с продажей автомобилей.

5. Клиент – человек,  желающий приобрести автомобиль  в автосалоне.

6. Кассир – сотрудник  автосалона, осуществляющий прием  оплаты клиентом автомобиля.

7. Каталог – перечень  автомобилей на складе автосалона  с описанием параметров.

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

9. Квитанция – документ, содержащий информацию об автомобиле, сумму к оплате и требование  к оплате в кассе автосалона.

10. Счет на оплату –  документ, содержащий информацию  об автомобиле, сумму к оплате  и требование к оплате в  кассе банка.

11. Чек – документ, выдаваемый  клиенту после оплаты квитанции.

12. Автомобиль характеризуется  следующими параметрами: марка,  модель, тип кузова, цвет, VIN.

13. VIN автомобиля – идентификационный  номер автомобиля, позволяющий однозначно  определить автомобиль.

14. VIN автомобиля будем  именовать кодом автомобиля.

15. ПТС – паспорт транспортного  средства, описывающий основные  параметры автомобиля.

16. Сервисная книжка –  документ, содержащий план технического  обслуживания автомобиля.

17. ПТС и сервисная книжка  считаются сопроводительными документами.

3.2.2 Функциональные  требования

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

Основные требования

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

2. Формировать кассовый  чек покупки на основе электронного  требования на оплату.

Обеспечивающие требования

1. Обеспечивать защиту  информации от несанкционированного  доступа и изменения;

2. Обеспечивать проверку  правильности данных.

 

 

3.2.3 Нефункциональные  требования

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

1. С учетом возможности  роста сети должна присутствовать  возможность расширения системы.

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

3. Использовать современное  аппаратное обеспечение.

4. Поддерживать большие  объемы хранимых данных по  каталогу автомобилей.

 

 

4 Концептуальная модель информационной системы

 

При решении задач нашего курсового проекта мы будем рассматривать программную архитектуру как архитектуру взаимодействия классов, организованную в три слоя (представление, предметная область, источник данных) в рамках одного приложения.

Основные высказывания о  программной архитектуре заимствуются из описаний шаблонов архитектуры.

Для разработки архитектуры  информационной системы выбран шаблон трехслойной архитектуры. Представим основные высказывания по каждому слою архитектуры:

1. Слой представления:  предоставляет услуги отображения  данных, обработки событий пользовательского  интерфейса (щелчки мыши, нажатия  клавиш).

2. Слой предметной области:  выполняет вычисления на основе  вводимых и хранимых данных, проверку  всех элементов данных и обработку  команд, поступающих от слоя представления,  а также передачу информации  слою источника данных.

3. Слой источника данных: выполняет обращения к базе  данных, обмен сообщениями, мониторинг  транзакций.

Представим назначение классов  по слоям в таблице 3.

 

Таблица 3 – Назначение классов  по слоям

 

№	Наименование  класса	Назначение класса
Слой представления
1.	E-UI-Manager	Граничный класс, отвечающий за отображение формы каталога автомобилей, параметров поиска и результатов  поиска в каталоге.
2.	E-UI-Cashier	Граничный класс, отвечающий за отображение формы требования, атрибутов покупки автомобиля (код  квитанции, код автомобиля), параметров и результатов поиска требований оплаты
3.	Wtrixkod-UI-Cashier	Граничный класс, отвечающий за обработку сканирования штрих-кода квитанции
4.	Rules	Класс хранения, содержащий данные бизнес-правил
5.	ControllerAuto	Управляющий класс, методы которого отвечают за управление приложением в целом
Слой предметной области
6.	Serv_vizov	Граничный класс, отвечающий за взаимодействие с классами слоя предметной области
7.	E-KvAuto	Класс хранения, содержащий ключевые данные об автомобилях в  каталоге посредством квитанции
8.	E-Auto_Spec	Класс хранения, содержащий характеристики автомобилей в каталоге (модель, тип кузова, цвет, комплектация)
9.	E-Sotrudnik	Класс хранения, содержащий данные сотрудников, являющихся пользователями информационной системы
10.	E-Rights	Класс хранения прав доступа пользователей информационной системы
11.	E-TrebovanieOpl	Класс хранения ключевых данных требования на оплату
12.	E-TrebovanieOplAuto	Класс хранения, содержащий данные атрибутов автомобилей в  требовании на оплату
Слой источника  данных
13.	Data	Граничный класс для взаимодействия с базой данных

 

Результат разработки концептуальной модели информационной системы представлен  на рисунке 14.

На рисунке 15 представлена диаграмма последовательности, моделирующая функцию аутентификации пользователя.

На рисунке 16 представлена диаграмма последовательности, моделирующая поддержку расчета за покупку.

 

 

Рисунок 14 – Диаграмма классов,

моделирующая структуру ПО ИС на концептуальном уровне

 

 

Рисунок 15 – Диаграмма последовательности,

моделирующая функцию аутентификации пользователя

 

 

 

Рисунок 16 – Диаграмма  последовательности,

моделирующая поддержку расчета за покупку

 

 

5 Логическая модель информационной системы

 

В данном разделе содержится набор UML-диаграмм, моделирующих функциональные возможности и структуру программного обеспечения (ПО) ИС на логическом уровне. Исходными данными для диаграмм логической модели служат диаграммы  концептуальной модели ИС.

5.1 Модель поведения

Модель поведения разработана  посредством диаграмм последовательности. На рисунке 17 представлена диаграмма  последовательности, моделирующая процесс  формирования требования оплаты.

На рисунке 18 представлена диаграмма последовательности, моделирующая поддержку процесса расчета за покупку  автомобиля.

5.2 Модель структуры

Модель структуры является целевой моделью курсового проекта, разработанная посредством диаграммы  классов. На рисунке 19 представлена диаграмма  классов ПО ИС, на которой отражены все классы, составляющие ПО ИС продаж в автосалоне.

 

 

 

Рисунок 17 – Диаграмма последовательности,

моделирующая процесс формирования требования оплаты

 

 

Рисунок 18 – Диаграмма последовательности,

моделирующая поддержку процесса расчета за покупку автомобиля

 

 

Рисунок 19 – Диаграмма классов,

моделирующая структуру ПО ИС на логическом уровне

 

6 Поэтапная реализация модели в среде CASE-средства

 

В качестве примера реализации модели в среде Case-средства опишем процесс  моделирования диаграмм логической модели ПО ИС.

Начало работы над проектом. В качестве среды разработки ИС было выбрано CASE-средство фирмы Rational Software Corporation – Rational Rose Enterprise Edition. Запустить программу Rational Rose Enterprise Edition. Создать новый проект: FiIe->New. После того, как проект будет создан и работа с ним будет завершена, необходимо сохранить полученные диаграммы. Для этого в меню File выбрать пункт Save или Save As, дать имя проекту и сохранить его в файл с расширением *.mdl. В нашем случае проект имеет название КП.mdl.