Дипломная (вкр): Автоматизация управления современной станцией технического обслуживания автомобилей на базе информационных технологий

Закрытие наряда:

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

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

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

Приход товара:

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

от иностранного поставщика (выполняется учет различных таможенных процедур и пошлин);

от российского поставщика (возможен учет дополнительных расходов на приобретение товаров);

в результате перемещений между складами фирмы;

в случае возврата товара покупателем.

Заказы от клиентов:

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

Заказы поставщикам:

Существует возможность ручного и автоматического оформления заказа поставщикам на поставку товаров.

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

Отчеты:

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

Отчеты программы можно разделить на несколько групп:

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

отчеты по движению товарно-материальных ценностей (складские): товарно-материальные отчеты, сводки по резервам и заказам, "лист заказа", статистика продаж

отчеты по движению денежных средств (банк, касса);

отчеты по взаиморасчетам с контрагентами (покупатели и поставщики);

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

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

Документы, участвующие в работе автосервиса

• Акт выполненных работ

• Акт сдачи-приемки автомобиля (с картой внешних дефектов автомобиля, его комплектностью и перечнем запчастей заказчика)

• Диагностическая карта автомобиля (более 40 позиций контроля, с местом для рекомендаций по каждой позиции)

• Договор на мойку автомашин

• Два варианта договоров на техническое обслуживание и ремонт автомобилей

• Договор о материальной ответственности (с Приложением)

• Бланки заказ-нарядов на ремонт автомобиля - два типа (большой - 1 шт. на странице и малый - 2 шт. на странице)

• Обязательство о неразглашении коммерческой тайны

• Правила внутреннего трудового распорядка

• Прейскурант на ремонт автомобилей (в виде таблицы, более 300 позиций, работы разбиты по разделам)

• Прейскурант на шиномонтажные работы

• Прейскурант на мойку автомобилей

• Расчетный листок (для мастера, учет расходов и выплат зарплаты за смену) - два вида: 6 листков на странице и 4 листка на странице

• Трудовой договор для автослесаря

• Функциональные обязанности сменного мастера

Инструкции по охране труда (ИОТ) (то же что Инструкции по технике безопасности):

• ИОТ для административно-управленческого персонала

• ИОТ для аккумуляторщика

• ИОТ для газосварщика

• ИОТ для слесаря по ремонту автомобилей

• ИОТ для слесаря по ремонту топливной аппаратуры

• ИОТ для слесаря-ремонтника

• ИОТ для электросварщика ручной сварки

• ИОТ при вывешивании автомобиля и работе под ним

• ИОТ при выполнении шиноремонтных работ

Формы журналов по ИОТ (технике безопасности):

• Форма журнала регистрации вводного инструктажа (обложка и шапка таблицы, согласно законодательству);

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

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

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

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

Все документы созданы на базе единого стиля и гармонично сочетаются друг с другом, оставляя у клиентов автосервиса приятные впечатления чётким деловым оформлением и продуманностью деталей. Документы созданы на базе дизайнера отчетов Crystal Report. C электронными полями-подсказками заполнять документы легко и удобно.

.4 Место задачи в системе автоматизации

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

2.5 Определение требований к вычислительной системе

Проектируемая информационная система должна обладать следующими эксплуатационными свойствами:

. В системе должен быть обеспечен быстрый поиск информации по неполным данным;

Система должна обеспечивать корректность хранимой информации в базе данных;

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

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

Система должна обеспечивать защиту информационной базы данных от несанкционированного доступа;

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

Система должна иметь возможность наращивания как программной, так и аппаратной части;

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

При проектировании информационной системы всегда происходит поиск компромисса между использованием самых современных программных продуктов с их новейшими способами наглядного и эффективного представления данных и имеющимися вычислительными ресурсами, недостаток которых не только может нивелировать все преимущества новых программных продуктов, но и сделать работу с ними абсолютно некомфортной. Для разработки автоматизированной была выбрана среда программирования Microsoft Visual Studio 2010 Express Edition и реляционная СУБД MS SQL Server. Так как система предназначена для работы в архитектуре «клиент-сервер», необходимо определить требования к серверу и к рабочей станции.

Минимальные требования к серверу:

Компьютер на базе процессора Intel с тактовой частотой от 2800 MHz;

Оперативная память объемом 1024 Mb;

Свободного места на жестком диске должно быть около 1 Gb;

Операционная система MS Windows 2000 и выше.

Минимальные требования к рабочей станции:

Компьютер на базе процессора Intel с тактовой частотой 1600 MHz и выше;

Оперативная память объемом 512 Mb;

Свободного места на жестком диске должно быть около 1 Gb;

Операционная система MS Windows 2000.

.6 Семантическое моделирование данных, ER-диаграммы

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

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

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

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

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

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

.7 Семантические модели данных

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

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

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

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

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

Основные понятия модели (Сущность-Связи)

Далее мы кратко рассмотрим некоторые черты одной из наиболее популярных семантических моделей данных - модель "Сущность-Связи" (часто ее называют кратко ER-моделью).

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных.

Основными понятиями ER-модели являются сущность, связь и атрибут.

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

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