Автоматизированная информационная система автосалона

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

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

Главной проблемой  существующего учета в дилерском  центре “Питер-Лада” является отсутствие оперативности в обновлении данных, дублирование данных, и соответственно вызванная этим постоянная необходимость  перепроверки всей отчетности. Данная автоматизация хоть и справляется  с возложенными на нее обязанностями, однако из-за отсутствия унификации отнимает слишком много рабочего времени  у сотрудников автосалона.

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

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

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

1.4 Подходы к проектированию  ИС

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

Функционально модульный или структурный –  в основу положен принцип функциональной декомпозиции, в котором система  описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными  элементами.

Объектно-ориентированный  подход – использует объектную декомпозицию. Система описывается в терминах объектов и связей между ними, а  поведение системы в терминах обмена между ними.

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

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

Во второй половине 80х годов появилось методология  объектно-ориентированного программирования

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

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

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

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

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

1.5 Унифицированный  язык моделирования  UML

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

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

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

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

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

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

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

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

Предварительные версии UML начали использоваться в области  создания программного обеспечения, а  на основании отзывов потребителей производились существенные доработки. Многие корпорации ощутили, что язык UML может оказаться полезным для  достижения их стратегических целей. Это  привело к возникновению консорциума UML, в который вошли такие компании, как DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational и другие. В 1997 году консорциум выработал первую версию UML и представил ее на рассмотрение группе OMG (Object Management Group), откликнувшись на ее запрос о подаче предложений по стандартному языку моделирования.

После расширения консорциума вышла версия 1.1 языка UML, которую группа OMG приняла в  конце 1997 года. После этого OMG приступила к сопровождению UML и выпустила  в 1998 году две его новые версии. Язык 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)

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

Также стоит  добавить, что не всегда обязательно  строить абсолютно все диаграммы, разработчик сам решает - устраивает ли его данный уровень детализации, нужно ли рассмотреть систему  или ее часть с «другого вида», достаточно ли подробно рассмотрены  самые «сложные и скользкие моменты». Т.е. инструменты, поддерживающие UML и  предназначенные для моделирования  программного обеспечения, позволяют  еще на этапе разработки проверить  архитектурные решения, полноту  модели, ее корректность, для того, чтобы, в том числе, уменьшить риск «провала»  проекта. Опишем некоторые из графических  диаграмм, построенных при разработке нашей автоматизированной системы. [5]

1.6 Построение модели  в Rational Rose

Rational Rose - мощное CASE-средство для проектирования  программных систем любой сложности.  Одним из достоинств этого  программного продукта будет  возможность использования диаграмм  на языке UML. Можно сказать,  что Rational Rose является графическим  редактором UML диаграмм.

CASE-средство Rational Rose со времени своего появления  претерпело серьезную эволюцию  и превратилось в современное  и мощное средство анализа,  моделирования и разработки программных  систем. Именно в Rational Rose 98/2000 язык UML стал базовой технологией визуализации  и разработки программ, что определило  популярность и стратегическую  перспективность этого инструментария. [6]