Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ОСА / 08 IDEF0 электрооборудование.rtf
Скачиваний:
154
Добавлен:
25.12.2014
Размер:
18 Mб
Скачать

1.6 Анализ требований к программным и аппаратным средствам

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

Система позволяет эксплуатацию на любой системе соответствующей требованиям к СУБД Microsoft SQL Server:

─ ОЗУ 1Gb;

─ CPU Pentium IV 2 GHz.

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

информационный автоматизация модель данные

2. Разработка системного проекта

2.1 Построение модели прецедентов

Список прецедентов:

─ Прием в ремонт;

─ Выполнение ремонта;

─ Выдача из ремонта;

─ Прием комплектующих;

─ Оформление акта о выполненном ремонте;

─ Определение неисправности;

─ Составление списка запчастей;

─ Заказ комплектующих.

Описание прецедентов

Рисунок 1 – Диаграмма прецедентов

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

Актеры:

Секретарь ─ составляет заявку на ремонт и заносит ее в базу, составляет заказ на комплектующие.

Мастер ─ получает заявку на ремонт, выявляет неисправность, составляет список запчастей, составляет акт о выполненном ремонте.

Главный актер: Мастер.

Основной успешный сценарий

  1. “Мастер” получает заявку на ремонт электрооборудования из базы данных.

  2. “Мастер” определяет причину неисправности.

  3. “Мастер” составляет список необходимых для ремонта комплектующих и заносит его в базу данных.

  4. “Мастер” получает необходимые комплектующие со склада.

  5. “Мастер” оформляет акт о выполненном ремонте и заносит его в базу данных.

Альтернативные сценарии:

3(а) Не все комплектующие из списка доступны на складе ─ “Секретарь” составляет заявку на закупку недостающих элементов.

3(б) “Мастер” принимает заказанные комплектующие.

2.2 Модели потоков данных dfd

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

Рисунок 2 – Первый уровень DFD диаграммы

На втором уровне DFD диаграммы отображаются основные потоки данных.

Рисунок 3 – Второй уровень DFD диаграммы

Рисунок 4 – Детализация деятельности “работа с клиентами”

Рисунок 5 – Детализация деятельности “выполнение ремонта”

2.3 Концептуальная инфологическая модель интегрированной базы данных

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

Рисунок 6 – Концептуальная инфологическая модель

3. Разработка моделей системы учета ремонта электрооборудования

3.1 Разработка моделей процессов

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

Рисунок 7 – Контекстная модель

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

На следующем уровне модель процессов раскрывается следующим образом (рисунок 8): выделяются два основных вида деятельности, выполняемых в системе и соответствующих ранее описанным прецедентам. На данном уровне кроме входных и выходных данных, управляющих потоков выделены механизмы, представленные пользователями, взаимодействующими с системой. Разграничение пользователей по правам и выполняемым в системе задачам осуществляется путем разветвления общей стрелки на отдельные и присвоением им различных наименований. Аналогичным образом осуществляется разграничение других потоков данных.

Рисунок 8 – Второй уровень модели

Рисунок 9 – Детализация “работа с клиентом”

Рисунок 10 – Детализация “выполнение ремонта”