- Дата производства – дата выпуска данного оборудования.
- Id_ingener – уникальный индекс для связи с таблицей инженера.
- Квитанция:
- Organizaciy – организация которая сдала в ремонт технику,
- Id_kvitance – уникальный индекс квитанции,
- Marka, model – наименование техники,
- SN – серийный номер,
- Type_remonta – тип ремонта (гарантийный, не гарантийный),
- Vn_opesanie – внешние описание,
- Data_prinyt – дата принятия в ремонт,
- Neispravnost – неисправность со слов клиента,
- Dispetcher – диспетчер создавший квитанцию,
- Data_finish – дата окончания обслуживания,
- Statys – текущий статус квитанции,
- Ingener – инженер, который обслуживает,
- Id_technika - уникальный индекс техники,
- Id_client – уникальный индекс клиента,
- Id_ingener – уникальный индекс инженера.
Диаграмма классов для классов объектов базы данных:
Тестирование требований:
- предоставление каждому инженеру возможности создавать квитанции. Для тестирования данного требования необходимо создать квитанцию и проверить её наличие в списке квитанций.
- предоставление каждому инженеру возможности редактировать данные в квитанции. Для тестирования данного требования необходимо создать квитанцию и закрыть. Снова зайти, и изменив данные в квитанции и проверить её как сохранились изменения квитанции.
- предоставление каждому инженеру возможности поиска квитанции. Для тестирования данного требования необходимо указать критерии поиска и отобразить квитанции, найденные по этим критериям.
- предоставление инженеру и диспетчеру возможности сортировать квитанции. Для тестирования данного требования необходимо указать по каким-либо параметрам будут сортироваться квитанции (по дате, по статусу, по инженеру) и отобразить полученный результат, проверив результаты выборки.
- предоставление возможности создавать назначать инженера на свободную квитанции. Для тестирования данного требования необходимо создать свободную квитанцию и определить её за каким-либо инженером, запросить через какое-то время и проверить, за кем она числится.
- предоставление каждому инженеру возможности изменения статуса квитанции. Для тестирования данного требования необходимо выбрать квитанцию, изменить её текущий статус, сохранить и закрыть. Через промежуток времени открыть данную квитанцию и проверить статус.
Необходимо проверить корректность одновременной работы инженеров при взятии себе квитанции, если квитанция уже занята один из инженеров, другому инженеру пытающемуся присвоить квитанцию, должно придти сообщение об невозможности присвоения.
Производительность системы. Необходимо замерить количественные показатели производительности при нормальном количестве запросов и сравнить их с номинальными.
- надежность. Сравнить замеренные показатели надежности с номинальными. Если они превосходят заявленные, то требование выполнено.
- затраты на перенастройку системы в связи с возможными изменениями условиями работы. Выполнить расчет стоимости перенастройки и сравнить с заявленным значением.
- ограничение затрат на обслуживание. Если затраты на обслуживание больше планируемых затрат, то требование не выполнено.
- расширяемость. Если систему можно расширить функционально без коренных переделок, то требование выполняется.
- ограничение (сверху) на используемое аппаратное обеспечение. Если аппаратное обеспечение для системы имеет худшие характеристики чем заявлено, то требование выполнено.
Результат разработки программного кода представлен в виде модели реализации на рисунке.
Назначение компонентов:
center.exe – конечный файл, содержащий модуль просмотра данных из словаря
сenter.exe.config – настройки подключения к базе данных.
center.sln – файл решения, содержит ссылку на файл проекта, определяет исходный объект для создаваемого управляемого модуля
center.proj – содержит ссылки на компоненты, включаемые в проект и ссылки на используемые компоненты.
maindisp.cs – автоматически генерируемый файл, содержит описание стандартной функции Main(), которая запускает программу.
app.config – файл настроек подключений к базе данных
centerDataSet.xsd– файл, содержащий описание класса centerDataSet
При запуске программы, и после соединения с базой, появляется стартовое окно, с которой начинается работа диспетчеров. В этом окне диспетчеру предоставляется возможности ввода и вывода информации.
Возможность вывода информации заключается в том, что можно отобразить все квитанции сервисной базы, выполнить сортировку по каким либо определённым критериям, то есть отобразить квитанции по номеру, по дате принятия и завершения, отобразить квитанции которые выполнил или выполняет конкретный сервисный инженер, или выбрать по организации, которая предоставила технику на ремонт.
Возможность ввода информации реализуется созданием нового типа информации.
Возможность выбора добавляемой в сервисную базу информации, которая будет записана в соответствующие таблицы, показана на рисунке/
На рисунке изображена Форма создания квитанции, которую диспетчер при приёме техники в ремонт заполняет необходимыми данными для работы сервисным инженерам. Данная квитанция храниться в базе данных, и доступна для просмотра, и частичного редактирования работающего с ней инженера. В данной форме необходимо будет указывать полною информацию о состоянии оборудования, о клиенте, как показано на рисунке.
При нажатии на кнопку “Сохранить” заполненная форма, а именно данные в ней отправляются и сохраняются в сервисную базу.
В данном окне производится заполнение формы, которая регистрирует вызов инженера в какую либо к частному клиенту, либо к какой, либо организации. В ней указывается полная информация о предстоящей работе, дате принятия, выполнения, модели аппарата, который подлежит обслуживанию и т. д., как показано на рисунке.
3.7 Развертывание.
Развёртывание.
Схема развертывания
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.