Автоматизированная система подбора автомобильных запчастей

СОДЕРЖАНИЕ Введение…………………………………….……………………………………3 Основание для разработки…………………………………………… ………4 Назначение……………………………………………………………………… 4 Требования к программе или программному изделию……………………… 4 Требования к программной документации…………………………………… 5 meibes
Теоретическая часть………………………………………………………………6 Диаграммы………………………………………………………………… .6 Диаграммы Потоков Данных……………………………………………….7 Контекстная Диаграмма(0 Уровень)……………………………………….8 Детализированная Диаграмма Потоков Данных И Управляющих Потоков Данных(1 Уровень)…………………………………………………….8 Диаграмма Переходов Состояний………………………………………….9 ПРАКТИЧЕСКАЯ ЧАСТЬ…………………………………………………… 10 СЛОВАРЬ ТЕРМИНОВ……………………………………………………… 19 ВВЕДЕНИЕ Цель курсовой работы: разработать программный продукт, предназначенный для автоматизации процесса подбора запчастей для ремонта автомобилей. Разрабатываемая программа должна рассчитывать варианты подбора запчастей к конкретному автомобилю по условиям заданной неисправности, а также их экономическую стоимость для клиента. Кроме этого программа должна запоминать введенные значения, результаты запросов по все критериям, а также записывать их в отдельный файл на жесткий диск или на сменный носитель. Моя курсовая работа направлена на разработку программы автоматизации процесса подбора запчастей для ремонта автомобилей, предназначенной для использования специалистами в автомобильных сервисах. В современных условиях ремонта автомобилей возникает потребность быстро и качественно подобрать требуемые запчасти в зависимости от неисправности автомобиля. В основном данный процесс занимает достаточно емкий промежуток времени, приблизительно от нескольких часов до нескольких суток, особенно при работе с On-Line Электронными Базами Данными автозапчастей. Сложность состоит в том, что для работы с такими Базами Данных требуется знание не только основ пользования персонального компьютера, но и опыт работы с Internet приложениями, знание достаточно сложного пользовательского интерфейса. Данное программное обеспечение позволяет руководствуясь только несколькими критериями запроса по Базе Данных, дать исчерпывающую информацию клиенту о возможности ремонта его автомобиля с указанием цен и сроков исполнения. Данный программный продукт рассчитан на пользователей общего уровня и предназначен только для коммерческого использования. 1. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ. Проект «Автоматизированная система подбора запчастей для ремонта автомобилей» разрабатывается в виде курсовой работы, на основе учебного плана кафедры ПО вычислительной техники и автоматизированных систем. 2. НАЗНАЧЕНИЕ. Основным назначением программы является помощь персоналу автосервиса заключающаяся в быстром и качественном поиске и подборе автозапчастей по анализу неисправности автомобиля. 3. ТРЕБОВАНИЯ К ПРОГРАММЕ ИЛИ ПРОГРАММНОМУ ИЗДЕЛИЮ. 3.1 Требования к функциональным характеристикам 3.2.1 Система должна обеспечивать возможность выполнения следующих функций: · Регистрация в системе; · Аутентификация (получение пользовательских или администраторских прав); · Отображение, ввод и коррекцию информации о тарифах, об имеющихся в наличии автозапчастей, комплектующих; · Отображение, ввод и коррекцию информации о клиентах; · Ввод и коррекцию информации о заказах, предоставление клиенту его экземпляра договора по ремонту, вывод на печать экземпляра договора фирмы; · Обработка заказов и ведение финансового журнала выполнения и стадиях выполнения заказов; · Обработка и своевременное оповещение клиента о ходе выполнения заказа; · Вывод информации о сроках выполнения заказа, а также возможность их корректировки на стадии выполнения; · Отслеживание клиентов-должников, ввод их в «чёрный список» фирмы; · Ввод и коррекция «чёрного списка»; · Пример выполнения заказа; · Гостевая книга; 3.2.2 Исходные данные: · Сетевое имя и пароль; · Список возможных неисправностей автомобиля; · Список автозапчастей; · Цены на автозапчасти; · Тарифы на услуги; · Информация о клиенте (ФИО, адрес, номер и серия паспорта); · Информация о заказе (код интересующего договора, дата и срок выполнения заказа). 3.2.3 Результаты: · «Чёрный список» фирмы; · Список договоров; · Финансовый отчёт руководителю (прибыль и убытки за определённый промежуток времени); · Электронные и напечатанные экземпляры договоров. 3.2 Требования к надёжности 3.2.1 Предусмотреть контроль вводимой информации. 3.2.2 Предусмотреть блокировку некорректных действий пользователя при работе с системой. 3.2.3 Обеспечить целостность хранимой информации. 3.2.4 Обеспечить защиту от несанкционированного доступа к информации. 3.3 Требования к составу и параметрам технических средств 3.3.1 Система должна работать на IBM совместимых компьютерах. 3.3.2 Минимальная конфигурация: · Тип процессора…………………… ………… Pentium III или Athlon и выше; · Частота процессора ……………………………………………….850Mhz и выше; · Объём оперативного запоминающего устройства………………256 Мб и более; · Тип постоянного запоминающего устройства ………………….…………SCSI; · Объём постоянного запоминающего устройства ……………….20 Гб и выше. 3.4 Требования к информационной и программной совместимости Система должна работать под управлением семейства операционных систем Win 32 (Windows 95, Windows 98, Windows Me, Windows 2000, Windows NT, Windows XP). 4. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ 4.1. Разрабатываемые программные модули должны быть самодокументированны, т.е. тексты программ должны содержать все необходимые комментарии. 4.2. Программная система должна включать справочную систему о работе и подсказки пользователю. 4.3. В состав сопровождающей документации должны входить: 4.3.1. Пояснительная записка на 25-30 листах, содержащая описание разработки. 4.3.2 Руководство системного программиста. 4.3.3 Руководство пользователя. 4.3.4 Графическая часть на двух листах формата А1: 4.3.4.1. Схема структурная программной системы. 4.4.3.2. Формы интерфейса пользователя.
ТЕОРЕТИЧЕСКАЯ ЧАСТЬ
Общее представление о диаграммах ДИАГРАММЫ Методологии структурного анализа и проектирования, основанные на моделировании потоков данных, обычно используют комплексное представление проектируемого программного обеспечения в виде совокупности моделей: · Диаграмм потоков данных(DFD- Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе · Диаграмм «сущность-связь» (ERD-Entity Relationship Diagrams), описывающих базы данных разрабатываемой системы · Диаграмм переходов состояний (STD-State Transition Diagrams), характеризующих поведение системы во времени · Словаря терминов · Спецификаций процессов Все они содержат графические и текстовые средства описания: первые – для удобства демонстрирования компонентов модели, вторые – для обеспечения точного определения ее компонентов и связей.
DFD показывает внешние по отношению к системе источники и приемники данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители данных), к которым осуществляется доступ. Структуры потоков данных и определение их компонентов хранятся в словаре данных. Каждая логическая функция может быть детализирована DFD нижнего уровня. Когда детализация исчерпана, переходят к описанию логики с помощью спецификации процесса.
Структура каждого хранилища описывается с помощью ERD. В случае наличия реального времени DFD дополняется средствами описания, зависящего от времени поведения системы, которые описываются с помощью STD. ДИАГРАММЫ ПОТОКОВ ДАННЫХ Диаграммы потоков банных позволяют специфицировать как функции разрабатываемого программного обеспечения, так и обрабатываемые им данные. При использовании этой модели систему представляют в виде ие­рархии диаграмм потоков данных, описывающих асинхронный процесс пре­образования информации с момента ввода в систему до выдачи пользовате­лю. На каждом следующем уровне иерархии происходит уточнение процес­сов, пока очередной процесс не будет признан элементарным. В основе модели лежат понятия внешней сущности, процесса, хранили­ща (накопителя) данных и потока данных. Внешняя сущность - материальный объект или физическое лицо, вы­ступающие в качестве источников или приемников информации, например, заказчики, персонал, поставщики, клиенты, банк и т. п. Процесс - преобразование входных потоков данных в выходные в соот­ветствии с определенным алгоритмом. Каждый процесс в системе имеет свой номер и связан с исполнителем, который осуществляет данное преобра­зование. Как в случае функциональных диаграмм, физически преобразова­ние может осуществляться компьютерами, вручную или специальными уст­ройствами. На верхних уровнях иерархии, когда процессы еще не определе­ны, вместо понятия «процесс» используют понятия «система» и «подсисте­ма», которые обозначают соответственно систему в целом или ее функцио­нально законченную часть. Хранилище данных - абстрактное устройство для хранения информа­ции. Тип устройства и способы помещения, извлечения и хранения для тако­го устройства не детализируют. Физически это может быть база данных, файл, таблица в оперативной памяти, картотека на бумаге и т. п. Поток данных - процесс передачи некоторой информации от источника к приемнику. Физически процесс передачи информации может происходить по кабелям под управлением программы или программной системы или вручную при участии устройств или людей вне проектируемой системы. Таким образом, диаграмма иллюстрирует как потоки данных, порожден­ные некоторыми внешними сущностями, трансформируются соответствую­щими процессами (или подсистемами), сохраняются накопителями данных и передаются другим внешним сущностям - приемникам информации. В ре­зультате мы получаем сетевую модель хранения/обработки информации. Для изображения диаграмм потоков данных традиционно используют два вида нотаций: нотации Иордана и Гейна-Сарсона. КОНТЕКСТНАЯ ДИАГРАММА(0 УРОВЕНЬ) Построение иерархии диаграмм потоков данных начинают с диаграммы особого вида – контекстной диаграммы, которая определяет наиболее общий вид системы. На такой диаграмме показывают, как разрабатываемая система будет взаимодействовать с приемниками и источниками информации без указания исполнителей, т.е описывают интерфейс между системой и внешним миром. Обычно начальная диаграмма имеет форму звезды. Полученную таким образом модель системы проверяют на полноту исходных данных об объектах системы и изолированность объектов (отсутствие связей с другими объектами). ДЕТАЛИЗИРОВАННАЯ ДИАГРАММА ПОТОКОВ ДАННЫХ И УПРАВЛЯЮЩИХ ПОТОКОВ ДАННЫХ(1 УРОВЕНЬ) Для представления управляющих процессов в проектируемых системах можно применить диаграммы управляющих потоков данных, которые используют понятия: управляющий процесс, управляющий поток данных и, возможно, хранилище управляющих данных. Управляющий процесс получает с помощью уп­равляющих потоков некоторую информацию о ситуа­ции в системе и инициирует посредством управляю­щего потока соответствующие процессы. На диаграммах управляющих потоков данных ис­пользуют те же обозначения, что и для обычных пото­ков, но изображают их пунктирной линией. Дополни­тельно может быть указан тип управляющего потока: • Т-поток (Trigger Flow - тригерный поток) - поток управления, который может только «включать» процесс - следующий управляющий сигнал опять «включит» процесс, даже если процесс уже активен; • А-поток (Activator Flow - активирующий поток) - поток управления, который может как «включать», так и «выключать» управляемый процесс -если процесс включен, то следующий сигнал его выключит; • E/D-поток (Enable/Disable Flow - переключающий поток) - поток уп­равления, который может включать процесс сигналом по одной (Е) линии и выключать - сигналом по другой (D) линии. ДИАГРАММА ПЕРЕХОДОВ СОСТОЯНИЙ Диаграмма переходов состояний является графической формой предо­ставления конечного автомата - математической абстракции, используемой для моделирования детерминированного поведения технических объектов или объектов реального мира. На этапе анализа требований и определения спецификаций диаграмма переходов состояний демонстрирует поведение разрабатываемой программ­ной системы при получении управляющих воздействий. Под управляющими воздействиями или сигналами в данном случае понимают управляющую ин­формацию, получаемую системой извне. Например, управляющими воздей­ствиями считают команды пользователя и сигналы датчиков, подключенных к компьютерной системе. Получив такое управляющее воздействие, разраба­тываемая система должна выполнить определенные действия и или остаться в том же состоянии, или перейти в другое состояние взаимодействия с внеш­ней средой. Для построения диаграммы переходов состояний необходимо в соответ­ствии с теорией конечных автоматов определить: основные состояния, уп­равляющие воздействия (или условия перехода), выполняемые действия и возможные варианты переходов из одного состояния в другое. Если программная система в процессе функционирования активно не взаимодействует с окружающей средой (пользователем или датчиками), на­пример, использует примитивный интерфейс и выполняет некоторые вычис­ления по заданным исходным данным, то диаграмма переходов состояний обычно интереса не представляет. В этом случае она демонстрирует только последовательно выполняемые переходы: из исходного состояния в состоя­ние ввода данных, затем после выполнения вычислений - в состояние выво­да и, наконец, в состояние завершения работы. Для интерактивного программного обеспечения с развитым пользова­тельским интерфейсом основные управляющие воздействия - команды поль­зователя, для программного обеспечения реального времени — сигналы от датчиков и/или оператора производственного процесса. Общим для этих ти­пов программного обеспечения является наличие состояния ожидания, когда программное обеспечение приостанавливает работу до получения очередно­го управляющего воздействия. Для интерактивного программного обеспече­ния наиболее характерно получение команд различных типов, а ес­ли это еще и программное обеспечение реального времени - однотипных сигналов (либо от многих датчиков, либо требующих продолжительной об­работки).

ПРАКТИЧЕСКАЯ ЧАСТЬ
В своей курсовой работе я показал все вышеперечисленные диаграммы. На нулевом уровне представлена контекстная диаграмма Automobile Services. На нулевом уровне представлены две внешних сущности: ü Clients – пользователь автоматизированной системы
ü Financial Administrator – специалист, подготовленный управляющий системы. В автоматизированную систему от Financial Administrator поступают данные: ü List of Clients ü List of Spares ü List of Prices Исходящие данные от АСУ - Financial Administrator: ü Financial Information В автоматизированную систему от Clients поступают данные: ü Network Name & Password ü Orders Исходящие данные от АСУ - Clients: ü Results of Order ü Copies of Order Исходящие и входящие данные обрабатываются в АСУ, выдаются результаты запроса и интересующие данные. Далее процесс дальнейшей обработки информации более детализируется и представлен на следующем уровне. Контекстная диаграмма, описанная выше, представлена в Автоматизированной Системе подбора запчастей на автомобили следующим образом. Следующий уровень представлен Детализированной Диаграммой потоков данных и управляющих потоков данных(1 уровень). На ней я разработал четыре управляющих процесса: 1. Registration & List of Clients – регистрация клиентов в системе и построение списков клиентов 2. Information about Tariff & Spare – обработка поступающей информации о тарифах и наличии запчастей 3. Information about Orders – аккумуляция поступающей информации из управляющих потоков и построение списка заказов 4. Realization Orders – обработка полученной информации из вышеперечисленных управляющих потоков и прослеживание реализации заказов В первый управляющий поток Registration & List of Clients поступают данные Network Name & Password, происходит их обработка. Результат Client {данные} поступают в потоки «3» и «4»(Information about Tariff & Spare и Information about Orders). Во второй управляющий поток Information about Tariff & Spare поступают данные List of Prices, List of Spares и List of Clients. Данные о Тарифах и Наличии запчастей Tariff и Spares аккумулируются в управляющих потоках Information about Orders и Realization Orders. «3» и «4» управляющие потоки Realization Orders и Information about Orders представляют собой результаты обработанной информации, а также работу с Базами Данных “Data about Prices on Spares” и “Data about Realization Orders”. Детализированная Диаграмма потоков данных и управляющих потоков данных(1 уровень) описанная выше, представлена в Автоматизированной Системе подбора запчастей на автомобили следующим образом. На следующем уровне я детализирую Диаграмму потоков данных “Network Name & Password” на три составляющие: 1. Registration – регистрация клиента в системе. 2. Formation List of Clients – формирование списка клиентов. 3. Formation List of Employees – формирование списка служащих. «2» и «3» Диаграммы потоков данных (Formation List of Clients и Formation List of Employees) взаимодействуют с базами данных “Data about Client’s” и “Data about Employee’s”, а также с управляющими процессами “Client’s Work Control” и “Financial Work’s Control” Управляющий процесс Client’s Work Control представляет собой взаимодействие клиентов в автоматизированной системе. Управляющий процесс Financial Work’s Control представляет собой взаимодействие служащих в автоматизированной системе. Детализированная Диаграмма потоков данных “Registration & List of Client’s” представлена в Автоматизированной Системе подбора запчастей на автомобили следующим образом. На следующем уровне я детализирую Диаграмму потоков данных “Information about Tariff & Spare ” на три составляющие: 1. Formation List of Clients 2. Formation List of Prices – формирование списка цен. 3. Formation List of Spares – формирование списка запчастей. «2» и «3» Диаграммы потоков данных (Formation List of Prices и Formation List of Spares) взаимодействуют с базами данных “Data about Client’s” и “Data about Prices on Spares”, а также с управляющими процессами “Client’s Work Control” и “Financial Work’s Control” Детализированная Диаграмма потоков данных “Information about Tariff & Spare” представлена в Автоматизированной Системе подбора запчастей на автомобили следующим образом. Управляющий процесс Client’s Work Control представляет собой взаимодействие клиентов в автоматизированной системе и представляет собой Диаграмму перехода Состояний. Управляющий процесс Financial Work’s Control представляет собой взаимодействие служащих в автоматизированной системе и представляет собой Диаграмму перехода Состояний.
СЛОВАРЬ ТЕРМИНОВ 1. АСУ – автоматизированная система управления. 2. Results of Order – результат заказа, полученный после обработки информации. 3. Clients – пользователь автоматизированной системы 4. Financial Administrator – специалист, подготовленный управляющий системы. 5. Registration & List of Clients – регистрация клиентов в системе и построение списков клиентов. 6. Information about Tariff & Spare – обработка поступающей информации о тарифах и наличии запчастей. 7. Information about Orders – аккумуляция поступающей информации из управляющих потоков и построение списка заказов. 8. Realization Orders – обработка полученной информации из вышеперечисленных управляющих потоков и прослеживание реализации заказов. 9. Registration – регистрация клиента в системе. 10. Formation List of Clients – формирование списка клиентов. 11. Formation List of Employees – формирование списка служащих. 12. Formation List of Prices – формирование списка цен. 13. Formation List of Spares – формирование списка запчастей. 14. Tariff – список тарифов на услуги. 15. Spare – список запчастей, находящихся в наличии. 16. Clients – список клиентов, зарегистрированных в системе. 17. Order – список сформированных заказов. 18. Weight – система находится в состоянии «ожидание». 19. Initialization – система находится в состоянии «инициализация пользователя». 20. Registration Query – система находится в состоянии «оформление запроса». 21. Realization Orders – система находится а состоянии «реализация заказа». 22. Cancel – система находится а состоянии «Отмена действия». 23. End – система находится а состоянии «окончание реализации заказа».