Размещено на http://www.allbest.ru/

Введение

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

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

Предметом исследования данного дипломного проекта является анализ существующей информационной системы автосалона «Питер-Лада», и улучшение ее при помощи СУБД MySQL, а так же языков PHP и HTML.

1. Предпроектное исследование

1.1 Изучение деятельности компании

Компания “Питер-Лада” - официальный дилер АО АВТОВАЗ на Северо-западе Российской Федерации. Данная компания предоставляет услуги в сфере продажи автомобилей, сервисного обслуживания, кредитования, страхования, лизинга, а так же одна из первых дилерских сетей АВТОВАЗ, которая откликнулась на Государственный проект по утилизации автомобилей старше 10 лет, предоставляя весьма существенную скидку на приобретение нового авто. В автосалоне компании предоставлен полный модельный ряд автомобилей Лада во всевозможных комплектациях. Так же компания предоставляет своим клиентам богатый выбор дополнительного оборудования и различных аксессуаров, начиная с банальных “плечиков” для одежды и заканчивая современными мультимедийными системами, при помощи которых можно осуществлять доступ в интернет.

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

Автосалон в настоящее время очень динамично развивается, соответственно возрастает необходимость более точного отслеживания стадий, на которых находится автомобиль. А благодаря новой Государственной программе по утилизации старых автомобилей от 10 марта 2010 года, поток клиентов компании должен увеличиться в несколько раз. В связи с такими прогнозами, руководством компании было принято решение увеличить количество находящихся автомобилей на складе в 1.5 раза. В настоящее время на складе автомобилей учет частично автоматизирован, за счет использования MS Excel, однако данная автоматизация частична, и при прогнозируемом возрастании как числа клиентов компании, так и автомобилей на складе - уже не будет справляться с возложенными на нее задачами, в связи с тем, что на своевременное редактирование и обновление данных уходит значительное количество времени и трудовых ресурсов.

Целью данного дипломного проекта является построение автоматизированной информационной системы при помощи СУБД MySQL, РНР и HTML, посредством которой можно будет оперативно вносить, удалять и редактировать сведения об автомобилях, проходящих через отдел склада автосалона «Питер-Лада», а так же получать все необходимые сведения для нужд менеджмента компании.

Для достижения поставленной цели необходимо рассмотреть и решить ряд следующих задач:

1) Изучить теоретический аспект внедрения автоматизированной системы;

2) Проанализировать существующее программное обеспечение;

3) Формализовать деятельность автосалона «Питер-Лада», выделив необходимые к отслеживанию процессы;

4) Выбрать необходимую среду реализации ПО;

5) Разработать действующее ПО, решающее задачи автоматизации учета автомобилей автосалона;

6) Проанализировать экономическую эффективность внедрения данного программного продукта;

7) А так же проанализировать безопасность труда на рабочем месте.

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

1.2 Описание деятельности фирмы

Более 30 лет компания “Питер-Лада” представляет АО “АВТОВАЗ” на северо-западе России. Качество, надежность и выработанный за многие годы успешной работы профессионализм позволили компании войти в число лидеров автомобильного рынка Северо-Запада. С 2003 года “Питер-Лада” становится так же официальным дилером ЗАО “Джи Эм-АВТОВАЗ”, а с 2008 года ОАО “Питер-Лада” входит в крупнейший в России дилерский холдинг “Лада-Сервис”.

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

Структура управления сети автосалонов “Питер-Лада” выглядит следующим образом:

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

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

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

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

- осуществлять управление деятельностью дилерского центра;

- решать организационные, кадровые проблемы;

- осуществлять анализ спроса на продукцию, тем самым обеспечивая рост прибыльности и конкурентоспособности;

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

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

В должностные обязанности руководителя СТО входит:

- Составление заявок на ремонт автомобилей;

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

- Принятие решений по гарантийным случаям;

- Контроль полноты и своевременности выполняемых работ;

- Управление складом автозапчастей; следить за тем, чтобы все необходимые запчасти всегда были в наличии;

- Контроль дисциплины персонала на участке рем-зоны;

- Ведение документооборота, составление отчетности.

В задачи бухгалтерии автосалона входит:

- Взаимодействие с банками по документам, срокам оплаты кредитов;

- Взаимодействие с налоговыми органами;

- Решение организационных и оперативных вопросов;

- Составление бухгалтерской отчетности.

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

- проверка и контроль состояния продаваемых автомобилей;

- проведение презентаций клиентам компании в шоу-руме;

- общение с клиентами компании, умение их заинтересовать;

- составление договоров купли-продажи;

- консультирование клиентов по вопросам кредитования и страхования;

- информирование клиентов о завершении работ с их автомобилем;

- ведение телефонных переговоров с возможными клиентами автосалона;

- составление и заполнение бланков об утилизации старых автомобилей.

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

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

- прием поступающих на склад товарных автомобилей;

- проверка наличия и правильность оформления сопроводительных документов на доставленные автомобили;

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

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

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

- поддержание товарных автомобилей в надлежащем техническом и эстетическом состоянии;

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

В подчинении у руководителя станции технического обслуживания находятся администратор СТО и механики.

В задачи администратора СТО входит:

- прием заявок от клиентов на техническое обслуживание автомобилей или их ремонт;

- открытие (закрытие) заказ-нарядов на заявленные работы;

- консультирование клиентов по телефону;

- своевременное уведомление клиентов о завершении ремонтных работ;

- составление отчетности.

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

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

- для каждого покупателя определить общую сумму покупки;

- получение денег от покупателей, проверка подлинности полученных купюр;

- сдача выручки в конце рабочего дня в бухгалтерию.

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

1.3 Оценка функций учета в дилерском центре “Питер-Лада”

Основная деятельность дилерского центра “Питер-Лада” заключается в продаже и сервисном обслуживании автомобилей марки Lada.

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

Сервисное обслуживание, выполнение ремонтных, диагностических работ, связано с ведением заказ-нарядов, определением стоимости работ, а так же поиском по электронным каталогам наличия той или иной запчасти на складе. Руководитель СТО в 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]

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

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

· сокращение время разработки;

· уменьшение ручного труда, увеличение продуктивности;

· улучшение потребительских качеств создаваемых программ;

· способность вести большие проекты или группу проектов;

· позволяет быть языком общения между различными разработчиками.

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

1.6.1 Диаграмма вариантов использования

Разработка данной диаграммы преследует следующие цели:

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

· Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Use Case диаграмм (сценариев). Опишем основные элементы в таблице 1.1. [7]

Таб.1.1. Условные обозначения диаграммы вариантов использования

Условное обозначение	Описание условного обозначения
	Actor-актер системы, т.е. любое действующее лицо, которое представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей. В системе актерами являются «директор», «Менеджер по продажам», «руководитель отдела продаж» и «клиент».
	Use case -стандартное обозначение варианта (прецедента) использования, описывающий типичное взаимодействие между пользователем и системой
	связь, называемая коммуникацией (communication). Устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования
	связь включения (include) между двумя вариантами использования, которая указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательности поведения другого варианта использования
	связь расширение (extend)отмечает тот факт, что один из вариантов использования может присоединять к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования

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

Рис. 1.2. Диаграмма прецедентов

1.6.2 Диаграммы состояний

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

Таб 1.2. Условные обозначения диаграммы состояний

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

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

Процессы, происходящие в этот момент, когда объект находится в определенном состоянии, называются действиями (actions).

С состоянием можно связывать следующие данные: деятельность, входное действие, выходное действие и событие.

Деятельность (activity) - это поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность изображают внутри самого состояния; ее обозначению должно предшествовать слово do (делать) и двоеточие.

Входное действие (entry action) - это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

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

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

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

1.6.3 Диаграмма деятельности

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Activity диаграмм (деятельности).

Таб. 1.3. Условные обозначения диаграммы деятельности

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

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

· анализ варианта использования. На этой стадии нас не интересует связь между действиями и объектами, а нужно только понять, какие действия должны иметь место и каковы зависимости в поведении системы. Связывание методов и объектов выполняется позднее с помощью диаграмм взаимодействия;

· анализ потоков работ (workflow) в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, диаграммы деятельностей являются мощным средством представления и анализа их поведения. [6]

1.6.4 Диаграммы взаимодействия

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

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

сообщения - запросы (interrogative) - сообщения, запрашивающие выдачу информации об объекте-получателе;

императивные (imperative) - сообщения, запрашивающие у объекта-получателя выполнение действия.

Существует два вида диаграмм взаимодействия:

1. последовательности (sequence diagrams);

2. кооперативные (collaboration diagrams).

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

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



Рис. 1.5. Диаграмма последовательности «заказ дополнительного оборудования»

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

Рис. 1.6. Диаграмма кооперации «заказ дополнительного оборудования»

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

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

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

1.7 Вывод по главе 1

По результатам предпроектного исследования, делается вывод о необходимости модификации существующей информационной системы учета автосалона «Питер-Лада». В качестве средства построения логической модели был выбран язык UML.

2. Проектирование автоматизированной информационной системы

2.1 Требования, предъявляемые к информационной системе

Целю данной дипломной работы является построение автоматизированной информационно системы для упрощения условий труда сотрудников автосалона «Питер-Лада». Проектируемая база данных является удобным средством решения перечисленных в предыдущей главе проблем и задач. Работа с данной базой данных не требует никакой специальной подготовки пользователей, благодаря удобному дружественному интерфейсу, а так же благодаря тому, что при авторизации пользователя (будь то менеджер, или руководитель СТО), последнему для работы предоставляется только та область базы данных, требуемая для выполнения служебных обязанностей. Например при работе с базой данных руководителя СТО, ему не требуется информация об автомобилях находящихся в наличии на складе автосалона, в то время как менеджмент компании не интересуют данные о автомобилях поступающих в рем-зону. Таким образом, при авторизации в данной базе данных, пользователю предоставляется минимально необходимый для работы набор данных, что позволяет избежать лишней путаницы и максимально упрощает пользовательский интерфейс.

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

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

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

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

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

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

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

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

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

2.2 Проектирование базы данных в Rational Rose Data Modeler

При создании программных систем процесс создания структуры данных (модели) является одним из важнейших этапов. Однако до недавнего времени аналитики-проектировщики, работающие с Rational Rose, должны были обращаться к другим CASE-средствам для автоматизации этого процесса, например, к ERwin компании PLATINUM. С появлением подключаемого модуля (Add-In) под названием Data Modeler у разработчиков появилась возможность не отказываться от своего любимого инструмента и использовать Rational Rose не только для создания логического представления системы, но и для моделирования физического представления данных.

Авторы Data Modeler прежде всего ориентировались на создание инструмента проектирования физической модели данных. При этом не произошло отказа от UML как от средства моделирования данных, а некоторым образом были смещены акценты: теперь UML предполагается использовать для построения логической модели. По сути, логическая модель - это та же объектная модель, состоящая из объектов - сущностей. Переход от логической модели к физической и наоборот в части моделирования данных обеспечивается Rational Rose автоматически. Для этого введено соответствие элементов моделей, приведенное в таблице 2.1.:

Таб. 2.1. Соответствие логической и физической модели

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

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

Подводя итог, к основным особенностям Data Modeler стоит отнести:

o Data Modeler поддерживает большинство возможностей структурных CASE-средств в плане физического моделирования данных;

o Data Modeler обеспечивает генерацию эффективной физической структуры БД, поддерживающей механизмы обеспечения ссылочной целостности;

o Data Modeler тесно интегрирован с Rational Rose, а диаграмма Data Model естественным образом вписывается в общую технологию разработки ПО с использованием линейки продуктов фирмы Rational Software Corporation;

o Можно отказаться от интеграции Rational Rose с другими средствами генерации физических моделей;

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

2.3 Проектирование логической модели базы данных

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

Работа Data Modeler основана на известном механизме отображения объектной модели в реляционную. Результатом являются построение диаграммы «сущность - связь» и последующая генерация описания базы данных на SQL.

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

Далее более подробно рассмотрим сущности таблиц диаграммы классов.

Рис. 2.2. Таблица «СТО».

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

Рис. 2.3. Таблица «клиенты».

В таблице «клиенты» содержатся данные о клиентах компании, без разделения на клиентов СТО и клиентов отдела продаж автомобилей Lada.

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

Рис. 2.4. Таблица «Новые автомобили».

В данной таблице отображаются сведения о новых автомобилях приобретаемых компанией «Питер-Лада». Таблица содержит данные о модели автомобиля, его цвете, VIN - номере, комплектации и статус, в котором находится автомобиль. Если в статусе стоит Spb, значит автомобиль находится в наличии, и стоит на складе автосалона. Так же в статусе могут стоять следующие данные:

Таб. 2.2 Статусы новых автомобилей

Значение находящееся в таблице:	Расшифровка
20	Сборка автомобиля запланирована на конкретную дату следующего месяца (время ожидания примерно 1.5 месяца)
32	Автомобиль поступил на сборку (ожидание от одной недели до месяца)
40	Автомобиль собран и ждет очереди на покраску.* (ожидание от одной недели до месяца)
48	Автомобиль полностью собран и находится на складе в Тольятти
60	Автомобиль находится в пути от Тольятти до Санкт-Петербурга (срок ожидания 3-4 дня)

*Покраска автомобилей в определенный цвет производится строго по графику, например в цвет 606 - «Млечный путь» 11-12 числа каждого месяца, а цвет 105 - «Франкония» только 1-го числа.

Рис. 2.5. Таблица «Заказы».

Таблица «Заказы» определяет заказ клиента на конкретный автомобиль. В таблице отображаются данные о номере заказа, модели выбранного автомобиля, дате сборки , дате оформления договора с клиентом, ФИО менеджера составившего договор, данные об оставленной клиентом предоплате. Отдельное внимание стоит уделить графе «автомобиль в зачет». Если клиент сдает свой старый автомобиль по программе утилизации, то в графе ставится значение «Да», и клиенту предоставляется скидка в 50 000 рублей, в противном случае ставится значение «Нет» и скидка не предоставляется.

Рис.2.6. Таблица «Утилизация».

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

Рис. 2.7. Таблица «Пользователи».

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

Рис. 2.8. Таблица «Дополнительное оборудование».

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

Рис. 2.9. Таблица «Диски».

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

Рис. 2.10. Таблица «Мультимедиа»

Данная таблица отображает сведения о фирме мультимедийной системы, сведения о ее размерах (1-2 din), а так же информацию о ее основных функциях.

Для создания физической модели базы данных, из меню на пакете Моя модель выполняем команду Data Modeler/Transform to Data Model.

В открывшемся окне в списке Target Database указать DB_0 и закрыть окно кнопкой ОК. В результате в логическом представлении в пакете Schemas появится пакет «Schema» S_0, в которую войдут все таблицы имеющие стереотип Сущность (entity). После чего из меню на пакете «Schema» S_0 выполняем команду Data Modeler/New/Data Model Diagram. В пакете «Schema» S_0 появится новая диаграмма NewDiagram (диаграмма «сущность - связь»). Затем открываем эту диаграмму и наносим на нее все классы - таблицы, находящиеся в пакете «Schema» S_0.

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

После того, как мы создали физическую модель базы данных, приступим к генерации описания базы данных на SQL. Для этого из меню на пакете «Schema» S_0 выполняем команду Data Modeler/Forward Engineer. Произойдет запуск генератора описания БД на SQL, после чего нажимаем клавишу Next. На следующем шаге мастера устанавливаем все флажки генерации и опять жмем Next. В следующем меню в графе «File Name» указываем имя и расположение текстового файла с результатами генерации. После чего доводим до конца работу с мастером.

После завершения генерации получаем следующий файл с описанием структуры БД на SQL:

CREATE TABLE DO (

name_option VARCHAR ( 255 ) NOT NULL,

cena INT NOT NULL,

DO_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_DO13 PRIMARY KEY NONCLUSTERED (DO_ID)

)

GO

CREATE TABLE Diski (

id_Disk INT NOT NULL,

radius INT NOT NULL,

firma VARCHAR ( 255 ) NOT NULL,

Diski_ID INT IDENTITY NOT NULL,

DO_ID INT NOT NULL,

CONSTRAINT PK_Diski12 PRIMARY KEY NONCLUSTERED (Diski_ID)

)

GO

CREATE TABLE Multimedia_system (

id_system INT NOT NULL,

firma VARCHAR ( 255 ) NOT NULL,

din BIT NOT NULL,

function VARCHAR ( 255 ) NOT NULL,

Multimedia_system_ID INT IDENTITY NOT NULL,

DO_ID INT NOT NULL,

CONSTRAINT PK_Multimedia_system14 PRIMARY KEY NONCLUSTERED (Multimedia_system_ID)

)

GO

CREATE TABLE Users (

id_users BIGINT NOT NULL,

FIO VARCHAR ( 255 ) NOT NULL,

Dostup INT NOT NULL,

Users_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_Users15 PRIMARY KEY NONCLUSTERED (Users_ID)

)

GO

CREATE TABLE Т_3 (

Zakazi_ID INT NOT NULL,

Clients_ID INT NOT NULL,

CONSTRAINT PK_220 PRIMARY KEY NONCLUSTERED (Zakazi_ID, Clients_ID)

)

GO

CREATE TABLE Т_2 (

Zakazi_ID INT NOT NULL,

DO_ID INT NOT NULL,