Информационная система сети автосалонов продажи автомобилей

Автор: Пользователь скрыл имя, 20 Февраля 2011 в 20:35, курсовая работа

Описание работы

Российский рынок продажи новых автомобилей является наиболее привлекательным в Европе. Темпы развития позволяют утверждать, что уже к 2011 году Россия выйдет в лидеры по продажам новых автомобилей в Европе. Одной из тенденций современного автобизнеса является создание и развитие сети автосалонов. Очень важным в таких организациях становится вопрос консолидации данных из филиалов и структурных подразделений сети в единую базу данных.

Содержание

Обозначения и сокращения 3
Введение 4
1. Описание предметной области 5
2. Концептуальная модель предметной области 18
3. Описание проблем и формирование концепции информационной системы 22
3.1 Проблемы предметной области 22
3.2 Концепция информационно системы 22
3.2.1 Основные понятия 22
3.2.2 Функциональные требования 23
3.2.3 Нефункциональные требования 24
4. Концептуальная модель информационной системы 25
5. Логическая модель информационной системы 30
5.1 Модель поведения 30
5.2 Модель структуры 32
6. Реализация модели в среде CASE-средства 33
Заключение 36
Список использованных источников 37

Работа содержит 1 файл

Serega.doc

— 925.50 Кб (Скачать)
    1. Концепция информационно системы

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

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

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

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

      1. Основные  понятия
 
  1. Автосалон – организация, осуществляющая продажу  новых автомобилей.
  2. Сеть автосалонов – объединение автосалонов в рамках одной компании.
  3. Склад – место временного хранения автомобилей автосалона.
  4. Менеджер автосалона – сотрудник автосалона, осуществляющий работу с клиентом, связанную с продажей автомобилей.
  5. Клиент – человек, желающий приобрести автомобиль в автосалоне.
  6. Кассир – сотрудник автосалона, осуществляющий прием оплаты клиентом автомобиля.
  7. Каталог – перечень автомобилей на складе автосалона с описанием параметров.
  8. Договор купли/продажи – документ, содержащий перечень обязательств со стороны автосалона и клиента и подтверждающий их выполнение.
  9. Квитанция – документ, содержащий информацию об автомобиле, сумму к оплате и требование к оплате в кассе автосалона.
  10. Счет на оплату – документ, содержащий информацию об автомобиле, сумму к оплате и требование к оплате в кассе банка.
  11. Чек – документ, выдаваемый клиенту после оплаты квитанции.
  12. Автомобиль характеризуется следующими параметрами: марка, модель, тип кузова, цвет, VIN.
  13. VIN автомобиля – идентификационный номер автомобиля, позволяющий однозначно определить автомобиль.
  14. VIN автомобиля будем именовать кодом автомобиля.
  15. ПТС – паспорт транспортного средства, описывающий основные параметры автомобиля.
  16. Сервисная книжка – документ, содержащий план технического обслуживания автомобиля.
  17. ПТС и сервисная книжка считаются сопроводительными документами.
      1. Функциональные  требования
 

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

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

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

  1. С учетом возможности роста сети должна присутствовать возможность расширения системы.
  2. Иметь удобный пользовательский интерфейс, обеспечивающий безопасность работы.
  3. Использовать современное аппаратное обеспечение.
  4. Поддерживать большие объемы хранимых данных по каталогу автомобилей.
  1. Концептуальная  модель информационной системы

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

  1. Слой представления: предоставляет услуги отображения данных, обработки событий пользовательского интерфейса (щелчки мыши, нажатия клавиш).
  2. Слой предметной области: выполняет вычисления на основе вводимых и хранимых данных, проверку всех элементов данных и обработку команд, поступающих от слоя представления, а также передачу информации слою источника данных.
  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 Граничный класс  для взаимодействия с базой данных

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

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

       

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

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

       

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

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

       

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

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

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

    1. Модель  поведения

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

       

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

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

       

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

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

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

       

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

  1. Реализация  модели в среде  CASE-средства

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

    1. Начало  работы над проектом.
 

     В качестве среды разработки ИС было выбрано CASE-средство фирмы Rational Software Corporation – Rational Rose Enterprise Edition.

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

    1. Разработка  модели поведения.
 

     Для создания диаграммы последовательности действий в программе Rational Rose необходимо добавить в список браузера новую  диаграмму. Для этого нужно щелкнуть правой кнопкой мыши по папке Logical View (Логическое представление) и в появившемся контекстно-зависимом меню выбрать команду New -> Sequence Diagram (Создать -> Диаграмма последовательности действий). Для создания объектов и сообщений на диаграмме последовательности действий, прежде всего, нужно ее открыть, затем выбрать на панели инструментов сообщение или объект и перетащить его на диаграмму. Пример разработки модели поведения представлен на рисунке 20:

       

       Рисунок 20. Пример разработки модели поведения в среде CASE-средства фирмы Rational Software Corporation – Rational Rose Enterprise Edition.

    1.   Разработка  модели структуры.
 

     Для создания диаграммы классов в  программе Rational Rose необходимо добавить в список браузера новую диаграмму. Для этого нужно щелкнуть правой кнопкой мыши по папке Logical View (Логическое представление) и в появившемся контекстно-зависимом меню выбрать команду New -> Class Diagram (Создать -> Диаграмма классов). Пример разработки модели структуры в виде диаграммы классов представлен на рисунке 21:

       

       Рисунок 21. Пример разработки модели структуры  в среде CASE-средства фирмы Rational Software Corporation – Rational Rose Enterprise Edition.

Информация о работе Информационная система сети автосалонов продажи автомобилей