Разработка базы данных для Дорожно-ремонтной фирмы

Министерство образования и  науки РФ

Новосибирский Государственный Технический  Университет

Кафедра Вычислительной Техники

 

 

 

 

Курсовая работа

По дисциплине «Визуальное  программирование»

на тему: “Разработка  базы данных для Дорожно-ремонтной фирмы”

 

 

 

 

 

 

 

Факультет: АВТФ

Группа: АП-818с

Выполнил: Острецов Ю.И.                                                           Преподаватель: Тюнина Л.В.

 

 

 

Новосибирск 2012 

Содержание

1. Описание предметной  области……………………………………………….………….2

2. Постановка задачи  проектирования. …………………….…………………………….2

3. Business диаграмма. ……………………………………………………………………….2

4. UseCase диаграмма. ……………………………………………………………………….6

5. Потоки событий вариантов использования. ……………………….………………….7

6. Выявление требований к проекту. Техническое задание…………………………….8

     6.1. Требования к функциональным характеристикам….……………….………….8

     6.2.Требования к надежности……………………………………….……………..…….8

     6.3. Условия эксплуатации………………………………………………….……..…….9

     6.4. Требования к информационной и программной совместимости………….…10

     6.5. Требования к программной документации……………………………………..10

7. Диаграмма классов………………………………………………………………………11

8. Диаграммы деятельности………………………………………………………………16

9. Диаграммы последовательности………………………………………………………16

10. Технический проект……………………………………………………………………18

     10.1 База данных, таблицы (типы, форматы, ключи, индексы)………….…..…..18

     10.2 Запросы, описание, формы, отчёты……………………..…………………..…..22

Приложение 1: Структура  БД……………………………………………….……………28

Заключение…………………………………………………………………….……………30

 

 

 

 

  1.Описание предметной области.

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

 

  2.Постановка задачи проектирования.

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

 

  3.Business диаграмма.

 

      а) Business Use Case диаграмма (рис. 1)

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

Исполнитель (business worker) представляет собой абстракцию человека или программной системы, которая представляет роль, выполняемую внутри реализаций бизнес-прецедентов. Исполнитель используется для представления роли, которую человек или программная система будут играть в организации. На диаграмме 1 business workers – менджер (решает все задачи, связанные с оформлениями заявок), Исполнитель (принимает и исполняет заявку) и директор (участвует в оформлении отчетов организации).  Business Actor - Определяет набор экземпляров бизнес-актера (кто-то или что-то вне бизнеса, взаимодействующий с бизнесом), в котором каждый экземпляр бизнес-актера играет одинаковую роль по отношению к бизнесу. Важно, что бизнес-актер представляет некоторого участника вне области действия бизнеса и, следовательно, имеет представление только внешнего видимого поведения бизнеса. На диаграмме 1 Business Actor – клиент ( оформляет заявку на работы в нашей организации) и исполнитель (выполняет эти работы).

Рис. 1. Business диаграмма работы ДРС.

 

                б) Use Case диаграмма (рис. 2)

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

Ответы на следующие вопросы  позволят определить актеров, взаимодействующих  с системой:

кто взаимодействует с системой или использует систему;

кто передает или принимает информацию в/из системы;

кто является внешним по отношению  к системе.

Каждый вариант использования  показывает, как конкретный актер  использует систему и в дальнейшем расширяется диаграммами состояний  и последовательности действий.

Отвечая на эти вопросы, в данном случае, актерами будут являться (уже  знакомые нам по Business Use Case диаграмме): менеджер, директор, клиент, исполнитель. Сюда же следует добавить администратора, ответственного за работу с базой данных предприятия.

Виды взаимодействий:

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

 

 

 

 

 

 

        4.UseCase диаграмма.

 

Рис. 2. UseCase диаграмма работы ДРС.

 

   5.Потоки событий вариантов использования.

5.1 Поток событий варианта использования «Работа с клиентами».

       Основной поток

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

        2. Программа выводит главную форму и предлагает выбрать один из пунктов допустимых действий:

          - 1.Работа  с клиентами; 

          - 2.Добавление  информации;

          - 3.Информация  о компании;

        3. Оператор выбирает действие «1.Работа с клиентами»

        4. Программа переводит оператора в форму «2», где ему предоставляется выбор следующих пунктов:

           -1.Добавить  клиента;

           -2.Оформить  заявку;

           -3.Поиск  информации о клиенте;

           -4.Вернуться  на главную;

         5.Оператор переходит в пункт «1.Добавить клиента». В этом пункте в базу данных добавляется информация о клиенте его Ф.И.О., номер паспорта, номер телефона, адрес и автоматически присваивается идентификационный номер именуемый  «Код заказчика», служащий для оформления заявок. Если запись успешно добавляется, оператор возвращается обратно в форму «2» и переходит в пункт «2.Оформить заявку». В случае если запись не может быть добавлена программа выдаст ошибку о наличии такой записи, оператор выполняет альтернативный поток событий А1.

         6. В пункте «2.Оформить заявку» оператор по предоставленному клиентом идентификационному номеру, оформляет заявку. Вводит его в поле «Код заказчика», адрес участка исполнения, назначает исполняемые работы, количество единиц, согласовывает цену с заказчиком, назначает бригаду-исполнителя и дату начала и окончания работ, сверяя ее в календаре с уже имеющимися заявками.

         7.Заявка оформлена. Оператор возвращается на главную. Вариант использования завершается.

     Альтернативный поток

        Альтернативный поток А1. Запись не добавляется в таблицу «Заказчики».

1. Программа информирует оператора о наличии идентичной записи в таблице.
2. Оператор переходит в форму «2» и выбирает пункт «3.Поиск информации о клиенте»
3. Вводит в поисковой запрос фамилию клиента и просматривает запись.
4. Сообщает клиенту его идентификационный номер и переходит в пункт 6 основного потока использования.
5. Вариант Использования завершается.

  6.Выявление требований к проекту. Техническое задание.

          6.1. Требования к функциональным характеристикам

     Требования к характеристикам взаимосвязей со смежными системами.Смежными системами являются: 
- информационные системы оперативной обработки данных Заказчика; 
Источниками данных для Системы должны быть: 
- Информационная система управления предприятием (СУБД MS SQL). 
- Информационно-справочная система (СУБД MS SQL). 
- Информационная система обеспечения бюджетного процесса (СУБД Oracle). 
Перечень предпочтительных способов взаимодействия со смежными системами приведен ниже. 
- Информационная система управления предприятием - с использованием промежуточной базы данных (ПБД). 
- Информационно-справочная система - обмен файлами ОС определенного формата.

Определяются требования к режимам  функционирования системы. 
Система должна поддерживать следующие режимы функционирования: 
- Основной режим, в котором подсистемы выполняют все свои основные функции. 
- Профилактический режим, в котором система не выполняет своих функций. 
В основном режиме функционирования Система должна обеспечивать: 
- работу пользователей режиме – 24 часов в день, 7 дней в неделю (24х7); 
- выполнение своих функций – сбор, обработка и загрузка данных; хранение данных, предоставление отчетности. 
В профилактическом режиме Система должна обеспечивать возможность проведения следующих работ: 
- техническое обслуживание; 
- устранение аварийных ситуаций. 
Общее время проведения профилактических работ не должно превышать 5% от общего времени работы системы в основном режиме (36 часов в месяц).

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

     6.2.Требования к надежности

К надежности оборудования предъявляются  следующие требования:

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

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

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

К надежности электроснабжения предъявляются  следующие требования:

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

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

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

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

- своевременного выполнения процессов  администрирования;

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

- своевременное выполнение процедур  резервного копирования данных.

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

- надежности общесистемного ПО  и ПО, разрабатываемого Разработчиком;

- проведением комплекса мероприятий  отладки, поиска и исключения  ошибок.

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

     6.3. Условия эксплуатации

   Условия эксплуатации, а также виды и периодичность обслуживания технических средств Системы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации производителя на них. 
Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать        ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды». Размещение технических средств и организация автоматизированных рабочих мест должны быть выполнены в соответствии с требованиями ГОСТ 21958-76 «Система "Человек-машина". Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования». 
Для электропитания технических средств должна быть предусмотрена трехфазная четырехпроводная сеть с глухо заземленной нейтралью 380/220 В (+10-15)% частотой 50 Гц (+1-1) Гц. Каждое техническое средство запитывается однофазным напряжением 220 В частотой 50 Гц через сетевые розетки с заземляющим контактом. 
Для обеспечения выполнения требований по надежности должен быть создан комплект запасных изделий и приборов (ЗИП). 
Состав, место и условия хранения ЗИП определяются на этапе технического проектирования.

     6.4. Требования к информационной и программной совместимости

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

     6.5. Требования к программной документации

Необходимо подготовить следующие  документы:

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

Вся документация должна быть подготовлена и передана как в печатном, так  и в электронном виде (в формате Microsoft Word).