СОДЕРЖАНИЕ
Введение…………………………………….……………………………………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 – система находится а состоянии «окончание реализации заказа».