Разработка программы автоматизации процесса подбора запчастей для ремонта автомобилей

Оглавление

Введение

1.Постановка задач автоматизированной системы управления
«Автосервис»

1.1. Основания для разработки

1.2. Назначение

1.3. Цель проекта

1.4. Точка зрения

1.5. Границы моделирования

1.6. Требования к функциональным характеристикам

1.7.Требования к информационной и программной
совместимости

1.8. Требования к программной документации

2. Проектирование автоматизированной системы
«Автосервис»

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

2.1.1 Описание BPwin, стандарты моделирования

2.1.2 Описание, преимущества Rational Rose Enterprise
Edition

2.1.3. Назначение языка UML

2.1.4.Общая структура языка UML

2.2. Диаграмма функций IDEF0

2.3.Перечень функций в соответствии с
функциональными блоками в диаграмме IDEFO

2.4. Перечень функций в соответствии с блоками

3.Реализация автоматизированной системы «Автосервис»

3.1. Решение задач автоматизированной системы

3.1.1.Регистрация клиента в системе

3.1.2.Регистрация автомобиля клиента в системе

3.1.3. Ведение базы данных автозапчастей

3.1.4. Ведение базы данных зарегистрированных
клиентов

3.1.5. Ведение базы данных производимых ремонтных
работ

3.1.5. Выдача клиенту на руки форм отчетности
документов и формирование электронной форм экономической отчетности по
выполненным заказам

3.2. Описание информационной модели

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

3.3.1.Исходные данные

3.3.2 Итоги Нормализации БД

3.4.Схема связей АСУ «Автосервис»

3.5.Проектирование форм электронных документов

3.5.1. Документ «Заказ-наряд на работы»

3.5.2.Документ «Счет-Фактура»

3.5.3. Документ «Приходный кассовый ордер»

3.5.4. Документ «Расходный кассовый ордер»

3.6. Руководство пользователя АСУ «АВТОСЕРВИС»

3.6.1.Регистрация клиентов

3.6.2.Регистрация автомобиля

3.6.3.Заказ запчастей и работ

3.6.4. Оформление заказа

3.6.5. Ведение склада

4. Оценка экономической эффективности разработки

Заключение

Список используемой литературы

Введение

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

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

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

Актуальность
состоит в том, что в современных условиях ремонта автомобилей возникает
потребность быстро и качественно подобрать требуемые запчасти в зависимости от
неисправности автомобиля. В основном данный процесс занимает достаточно емкий
промежуток времени, приблизительно от нескольких часов до нескольких суток,
особенно при работе с On-Line Электронными Базами Данными автомобильных,
запчастей.

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

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

1. Постановка
задач автоматизированной системы управления «Автосервис»

1.1
Основание для разработки

Проект
«Автоматизированная система АВТОСЕРВИС» разрабатывается в виде дипломной
работы, на основе учебного плана кафедры Информационных Технологий.

1.2
Назначение

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

1.3
Цель проекта

Основной
задачей является разработать автоматизированную систему для управления заказами
клиентов на предприятиях Автосервиса.

1.4
Точка зрения

Руководитель
предприятия.

1.5
Границы моделирования

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

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

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

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

1.6
Требования к функциональным характеристикам

Регистрация
клиента в системе

Регистрация
автомобиля клиента в системе

Ведение базы
данных автозапчастей

Ведение базы
данных производимых ремонтных работ

Ведение базы
данных зарегистрированных клиентов

Выдача
клиенту на руки форм отчетности документов

Формирование электронной
форм экономической отчетности по выполненным заказам

1.7
Требования к информационной и программной совместимости

Система
должна работать под управлением семейства операционных систем Win 32 (Windows 95, Windows 98, Windows Me, Windows 2000, Windows NT, Windows XP).

1.8
Требования к программной документации

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

2.
Проектирование автоматизированной системы «Автосервис»

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

В своем
проекте я останавливаюсь на таких инструментальных средствах проектирования как
BPWin и Rational Rose Enterprise Edition, Delphi 7

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

анализ - определение
того, что система будет делать,

проектирование - определение
подсистем и их взаимодействие,

реализация - разработка
подсистем по отдельности, объединение - соединение подсистем в единое целое,

тестирование - проверка
работы системы,

установка - введение
системы в действие,

функционирование -
использование системы.

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

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

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

Описание документооборота
предприятия.

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

Создание сущностей и
атрибутов и построение на этой основе модели данных.

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

Создание объектной
модели, на которой в дальнейшем может быть автоматически сгенерирован
программный код.

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

2.1.1
Описание BPwin, стандарты моделирования

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

Создавать модели
процессов и поддерживает три стандарта (нотации) моделирования - IDEF0, DFD и
IDEF3. Каждая из трех нотаций, поддерживаемых в BPwin, позволяет рассмотреть
различные стороны деятельности предприятия.

Модель IDEF0
предназначена для описания бизнес-процессов на предприятии, она позволяет
понять, какие объекты или информация служат сырьем для процессов, какие
результаты производят работы, что является управляющими факторами и какие
ресурсы для этого необходимы. Методология структурного моделирования
предполагает построение модели AS-IS (как есть), анализ и выявление недостатков
существующих бизнес-процессов и построение модели TO-BE (как должно быть), то
есть модели, которая должна использоваться при построении автоматизированной
системы управлением предприятия.

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

Диаграммы потоков данных
(Data flow diagramming, DFD) используются для описания документооборота и
обработки информации. DFD описывают функции обработки информации, документы,
объекты, а также сотрудников или отделы, которые участвуют в обработке
информации. Наличие в диаграммах DFD элементов для описания источников,
приемников и хранилищ данных позволяет более эффективно и наглядно описать
процесс документооборота.

Для описания логики
взаимодействия информационных потоков более подходит IDEF3, называемая также
workflow diagramming, - нотация моделирования, использующая графическое
описание информационных потоков, взаимоотношений между процессами обработки
информации и объектов, являющихся частью этих процессов. Диаграммы IDEF3
позволяют описать как отдельные сценарии реализации бизнес-процессов, так и
полное описание последовательности действий. Диаграммы нового типа - Swim Lane,
использующие методологию Process Flow Network и могут быть добавлены в модель,
содержащую диаграммы IDEF3.

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

2.1.2 Описание, преимущества Rational Rose Enterprise
Edition

Rational Rose Enterprise Edition - является по моему
мнению наиболее удобным визуальным CASE средством проектирования информационных системна
языке UML.

Появление на рынке
программных продуктов первых CASE-средств (Computer Aided Software Engineering)
ознаменовало новый этап развития программной инженерии, характерными
особенностями которого являются существенное сокращение сроков разработки
программных проектов, реализация проектов группой программистов и ориентация на
визуальные средства специфицирования компонентов программного обеспечения.

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

Среди всех
фирм-производителей CASE-средств именно компания Rational Software Coip. одна
из первых осознала стратегическую перспективность развития
объектно-ориентированных технологий анализа и проектирования программных
систем. Эта компания выступила инициатором унификации языка визуального
моделирования в рамках консорциума OMG, что, в конечном итоге, привело к
появлению первых версий языка UML. И эта же компания первой разработала
инструментальное объектно-ориентированное CASE-средство, в котором был
реализован язык UML как базовая нотация визуального моделирования.

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

Rational Rose
Enterprise Edition

Rational Rose
Professional Edition

Rational Rose
Modeler Edition

Rational Rose для UNIX

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

Интеграция с MS Visual
Studio 6, что включает в себя поддержку на уровне прямой и обратной генерации
кодов и диаграмм VB 6, Visual C++ 6, Visual J++ 6 (ATL-Microsoft Active
Template Library, Web-Classes, DHTML, Data Connections).

Непосредственная работа
(инжиниринг и реинжиниринг) с исполняемыми модулями и библиотеками форматов
EXE, DLL, TLB, OCX.

Поддержка технологий MTS
(Microsoft Transaction Server) и ADO (ActiveX Data Objects) на уровне шаблонов
и исходного кода, а также элементов стратегической технологии Microsoft — СОМ+
(DCOM).

Полная поддержка CORBA
2.2, включая реализацию технологии компонентной разработки приложений CBD
(Component-Based Development), языка определения интерфейса IDL (Interface
Definition Language) и языка определения данных DDL (Data Definition Language).

Полная поддержка среды
разработки Java-приложений JDK 1.2, включая прямую и обратную генерацию классов
Java формата JAR, а также работу с файлами форматов CAB и ZIP.

Уже этого перечня
основных особенностей может оказаться достаточно, чтобы сделать вывод о
достижении совершенно нового уровня реализации CASE-технологий, когда само
инструментальное средство становится не только рабочим инструментом, но и
своеобразной базой данных для практически всех современных объектных стандартов
и компонентных интерфейсов.

2.1.3
Назначение языка
UML

Язык UML предназначен для
решения следующих задач:

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

Речь идет о том, что
важным фактором дальнейшего развития и повсеместного использования методологии
ООАП(объектно-орентированый анализ и проектирование) является интуитивная
ясность и понятность основных конструкций соответствующего языка моделирования.
Язык UML включает в себя не только абстрактные конструкции для представления
метамоделей систем, но и целый ряд конкретных понятий, имеющих вполне
определенную семантику. Это позволяет языку UML одновременно достичь не только
универсальности представления моделей для самых различных приложений, но и
возможности описания достаточно тонких деталей реализации этих моделей
применительно к конкретным системам.

Снабдить исходные понятия
языка UML возможностью расширения и специализации для более точного представления
моделей систем в конкретной предметной области.

Хотя язык UML является
формальным языком — спецификаций, формальность его описания отличается от
синтаксиса как традиционных формально-логических языков, так и известных языков
программирования. Разработчики из OMG предполагают, что язык UML как никакой
другой может быть приспособлен для конкретных предметных областей. Это
становится возможным по той причине, что в самом описании языка UML заложен
механизм расширения базовых понятий, который является самостоятельным элементом
языка и имеет собственное описание в форме правил расширения.

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

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

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

С другой стороны, язык UML
должен обладать потенциальной возможностью реализации своих конструкций на том
или ином языке программирования. Конечно, в первую очередь имеются в виду
языки, поддерживающие концепцию ООП, такие как C++, Java, Object Pascal. Именно
это свойство языка UML делает его современным средством решения задач
моделирования сложных систем. В то же время, предполагается, что для
программной поддержки конструкций языка UML могут быть разработаны специальные
инструментальные CASE-средства. Наличие последних имеет принципиальное значение
для широкого распространения и использования языка UML.

Описание языка UML должно
включать в себя семантический базис для понимания общих особенностей ООАП.

Говоря об этой
особенности, имеют в виду самодостаточность языка UML для понимания не только
его базовых конструкций, но что не менее важно — понимания общих принципов
ООАП. В этой связи необходимо отметить, что поскольку язык UML не является
языком программирования, а служит средством для решения задач
объектно-ориентированного моделирования систем, описание языка UML должно по
возможности включать в себя все необходимые понятия для ООАП. Без этого
свойства язык UML может оказаться бесполезным и невостребованным большинством
пользователей, которые не знакомы с проблематикой ООАП сложных систем.

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

Поощрять развитие рынка
объектных инструментальных средств.

Способствовать
распространению объектных технологий и соответствующих понятий ООАП.

Эта задача тесно связана
с предыдущей и имеет с ней много общего. Если исключить из рассмотрения
рекламные заявления разработчиков об исключительной гибкости и мощности языка
UML, а попытаться составить объективную картину возможностей этого языка, то
можно прийти к следующему заключению. Следует признать, что усилия, достаточно
большой группы разработчиков были направлены на интеграцию в рамках языка UML
многих известных техник визуального моделирования, которые успешно
зарекомендовали себя на практике (см. главу 2). Хотя это привело к усложнению
языка UML по сравнению с известными нотациями структурного системного анализа,
платой за сложность являются действительно высокая гибкость и изобразительные
возможности уже первых версий языка UML. В свою очередь, использование языка UML
для решения всевозможных практических задач будет только способствовать его
дальнейшему совершенствованию, а значит и дальнейшему развитию объектных
технологий и практики ООАП.

Интегрировать в себя
новейшие и наилучшие достижения практики ООАП.

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

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

2.1.4 Общая
структура языка UML

С самой общей точки
зрения описание языка UML состоит из двух взаимодействующих частей, таких как:

Семантика языка UML. Представляет
собой некоторую метамодель, которая определяет абстрактный синтаксис и
семантику понятий объектного моделирования на языке UML.

Нотация языка UML.
Представляет собой графическую нотацию для визуального представления семантики
языка UML.

Формальное описание
самого языка UML основывается на некоторой общей иерархической структуре
модельных представлений, состоящей из четырех уровней:

Мета-метамодель

Метамодель

Модель

Объекты пользователя

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

Диаграмма вариантов
использования (use case diagram)

Диаграмма классов (class
diagram)

Диаграммы поведения
(behavior diagrams)

Диаграмма состояний
(statechart diagram)

Диаграмма деятельности
(activity diagram)

Диаграммы взаимодействия
(interaction diagrams)

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

Диаграмма кооперации
(collaboration diagram)

Диаграммы реализации
(implementation diagrams)

Диаграмма компонентов
(component diagram)

Диаграмма развертывания
(deployment diagram)

2.2
Диаграмма функций IDEF0

 Применительно
к моей системе EDEFO используется для анализа функций, выполняемых
системой и отображения механизмов, посредством которых эти функции выполняются.
Двумя наиболее важными компонентами, из которых строятся диаграммы EDEFO, являются бизнес-функции
или работ! (представленные на диаграммах в виде прямоугольников) и данные и
объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом
стрелки, в зависимости от того в какую грань прямоугольника работы они входят
или из какой грани выходят, делятся на пять видов:

Стрелки входа
(входят в левую грань работы) - изображают данные или объекты, изменяемые в
ходе выполнения работы.

1.Детальный
заказ клиента

2.Запчасти от
поставщика

3.Платежи
клиента

4.Регистрационные
данные клиента

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

1.Законодательство

2.Список
зарегистрированных клиентов

3.Сопроводительная
документация

4.Список
запчастей на складе

Стрелки
выхода (выходят из правой грани работы) - изображают данные или объекты, появляющиеся
в результате выполнения работы.

1.Отчетность

2.Документы
подлежащие к оплате клиентом

3.Список для
доставки необходимых запчастей

4.Бракованые
детали

5.Дкументы
подтверждающие выполнения заказа

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

1.Оборудование

2.Персонал

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