Моделирование и проектирование справочной информационной системы сотрудника ГИБДД (IDEF0, DFD, ERD)

Тип работы: Отчет по практике
Бесплатно: Антиплагиат
Объем: 9 страниц
В избранное:

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РЕСПУБЛИКИ КАЗАХСТАН

Казахский национальный технический университет имени К. И. Сатпаева

Факультет информатики и информационных технологий

Кафедра информатики

ОТЧЕТ ПО ЛАБОРАТОРНОЙ РАБОТЕ

Тема: Справочник сотрудника ГИБДД

Дисциплина: Проектирование информационных и программных систем

Выполнил: студент гр. ПОС-00-3

Пак В. В.

Принял: доцент кафедры информатики

Кубеков Б. С.

Алматы 2003

СОДЕРЖАНИЕ

ВВЕДЕНИЕ3

1 СОДЕРЖАТЕЛЬНАЯ ПОСТАНОВКА ЗАДАЧИ4

2 ОСНОВНАЯ ЧАСТЬ4

2. 1 Функциональная модель процессов ( IDEF 0 ) 4

2. 2 Диаграмма потоков данных ( DFD ) 6

2. 3 Диаграмма «Сущность - Связь» ( ERD ) 8

ВЫВОДЫ10

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ11

ВВЕДЕНИЕ

Технология создания крупных информационных систем предъявляет особые требования к методикам реализации и программным инструментальным средствам. CASE - средство верхнего уровня - BPwin , поддерживающий методологии IDEF0 (функциональная модель), DFD (DataFlow Diagram) и IDEF3 (WorkFlow Diagram) .

Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы.

Моделирование документооборота удобнее проводить с помощью нотации DFD, потому что именно диаграмма потоков данных отображает такие объекты, как: внешняя ссылка и хранилище данных.

Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы.

На основе разработанных при помощи BPwin'а моделей можно построить модель данных, для чего можно использовать другой CASE - инструмент - Erwin , имеющий два уровня представления модели - логический и физический. На логическом уровне данные представляются безотносительно конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных - это, по - существу, отображение системного каталога, который зависит от конкретной реализации СУБД.

1 СОДЕРЖАТЕЛЬНАЯ ПОСТАНОВКА ЗАДАЧИ

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

Данные о владельце

персональные данные: фамилия, имя, отчество, дата рождения, место рождения, место проживания;
паспортные данные: номер удостоверения, дата выдачи, орган выдачи, действителен до, гражданство и национальность;
водительские данные: номер водительского удостоверения, дата выдачи, орган выдачи, действителен до, допустимые категории

Данные о транспортном средстве

марка, цвет, тип (легковой, грузовой и др. ), заводской и бортовой номера, дата выпуска, особенности конструкции и окраски, дата последнего техосмотра.

2 ОСНОВНАЯ ЧАСТЬ

2. 1 Функциональная модель процессов ( IDEF 0 )

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

Для нашего примера на контекстной диаграмме показана работа ПОЛУЧЕНИЕ СПРАВОЧНОЙ ИНФОРМАЦИИ, описывающая основную цель разработки системы.

БАЗА ДАННЫХ и РЕКВИЗИТЫ, например, новая или отредактированная запись, являются входами работы (Input), т. е. тем материалом или информацией, которая используется или может преобразовываться работой. Так, оператор, чтобы получить необходимую ему информацию, задает определенные РЕКВИЗИТЫ, которые используются в ходе выполнения работы. В работе также используется информация из БАЗЫ ДАННЫХ, при этом возможно и ее (информации) изменение.

Стрелка РЕКВИЗИТЫ, входящая в работу сверху, является управлением (Control) , т. е. правилом, стратегией, процедурой или стандартом, которым руководствуется работа. Действительно, невозможно найти необходимую информацию, не задав параметры поиска. Но под РЕКВИЗИТАМИ подразумеваются не только параметры поиска, сюда входят и параметры сортировки, и условия фильтрации данных. Фактически, управление - это алгоритм, которого придерживается система при выполнении той или иной операции.

Далее опишем механизмы (Mechanism) - ресурсы, которые выполняют работу, например, персонал предприятия станки и т. д. Это сотрудник ГИБДД, управляющий системой, он «обеспечивает» работу входами и следит за корректным выполнением.

И, наконец, СПРАВОЧНЫЕ ДАННЫЕ - выход (Output) - материал или информация, которая производится работой, т. е. измененные, преобразованные в соответствие с определенными правилами входы.

рис. 1 Контекстная диаграмма (IDEF 0)

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

После того, как контекстная диаграмма описана, проводится функциональная декомпозиция системы, при которой система разбивается на подсистемы и каждая подсистема описывается отдельно. Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности.

рис. 2 Диаграмма декомпозиции первого уровня (IDEF 0)

На рис. 2 представлена диаграмма декомпозиции первого уровня, содержащая две работы ПРОСМОТР ДАННЫХ и ИЗМЕНЕНИЕ ДАННЫХ.

Работа ПРОСМОТР ДАННЫХ использует следующие управления:

под РЕКВИЗИТАМИ подразумеваются критерии выборки данных из всех имеющихся в БД;
сама БАЗА ДАННЫХ, из которой осуществляется операция выборки информации;
ОТКОРРЕКТИРОВАННЫЕ ДАННЫЕ, являющиеся выходным потоком работы ИЗМЕНЕНИЕ ДАННЫХ, о которой будет сказано ниже.

Выходом являются определенные СПРАВОЧНЫЕ ДАННЫЕ, которые пользователь получает в результате выполнения данной работы.

В работе ИЗМЕНЕНИЕ ДАННЫХ управлением являются только РЕКВИЗИТЫ, параметры изменения данных или же новая запись, добавляемая в БД, которые сами при выполнении работы не изменяются. Входом служат РЕКВИЗИТЫ, например, редактируемая информация, т. е. данные, которые пользователь редактирует или удаляет. Отредактированные данные пользователь вправе увидеть на экране, что показано на диаграмме выходной стрелкой ОТРЕДАКТИРОВАННЫЕ ДАННЫЕ, поступающей в качестве управления на работу, описанную выше.

Представленными на диаграмме работами управляет оператор - сотрудник ГИБДД, это изображает стрелка механизм, идущая снизу к обоим работам.

рис. 3 Диаграмма декомпозиции второго уровня (IDEF 0)

Диаграмма декомпозиции для работы ПРОСМОТР ДАННЫХ (см. рис. 3) включает три работы:

ВЫБОРКА ДАННЫХ (ВД)
СОРТИРОВКА
СОЗДАНИЕ ОТЧЕТНОГО ДОКУМЕНТА (СОД)

Работа ВД использует ОТКОРРЕКТИРОВАННЫЕ ДАННЫЕ - выход работы ИЗМЕНЕНИЕ ДАННЫХ, об этом говорилось выше - и БД. После выполнения данной работы, пользователю предоставляется возможность произвести операцию сортировки над набором данных (стрелка управления НАБОР ДАННЫХ) или использовать полученную информацию при создании отчетного документа (входная стрелка в работу СОД), данные при этом могут редактироваться. И только после того, как отчет сформирован в электронном виде, документ можно распечатать или сохранить на дискету. При формировании отчета можно использовать также отсортированные данные - одноименная выходная стрелка. Необходимо отметить, что данные после выполнения операции сортировки отображаются пользователю, об этом свидетельствует выходная стрелка СПРАВОЧНЫЕ ДАННЫЕ на диаграмме.

РЕКВИЗИТЫ используются во всех работах, изображенных на диаграмме, также как и СОТРУДНИК ГИБДД, который управляет всем процессом ПРОСМОТРА ДАННЫХ.

На мой взгляд, процесс детализации на этом этапе можно завершить вследствие достижения нужной степени подробности.

2. 2 Диаграмма потоков данных ( DFD )

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

Потоки данных являются механизмами, использующимися для моделирования передачи информации из одной части системы в другую. Этот объект дает название целому инструменту.

Процесс продуцирует выходные потоки из входных в соответствие с действием, задаваемым именем процесса.

Хранилище (Накопитель) данных определяет данные, которые сохраняются в памяти прежде чем использовать в работах .

Внешняя сущность (Терминатор) является источником или приемником данных извне модели.

рис. 4 Контекстная диаграмма ( DFD )

рис. 5 Контекстная диаграмма первого уровня ( DFD )

рис. 6 Детализация процесса ПРОСМОТР ДАННЫХ ( DFD )

рис. 7 Детализация процесса КОРРЕКТИРОВКА ДАННЫХ ( DFD )

2. 3 Диаграмма «Сущность - Связь» ( ERD )

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

Логический уровень не зависит от конкретной реализации БД и позволяет наглядно представить данные для обсуждения с экспертами предметной области. На логическом уровне модели данных информация отображается в виде сущностей (соответствуют таблицам на физическом уровне), состоящих из атрибутов сущностей (соответствуют колонкам таблицы) . Сущности состоят из совокупности отдельных записей - экземпляров сущностей (соответствуют записям в таблице) . Понятие логический уровень подразумевает, что мы мыслим в понятиях реального мира и непосредственно из него берем объекты для моделирования.

Построение модели данных предполагает определение сущностей и атрибутов. Связь - это соотношение либо между двумя сущностями, либо между сущностью и этой же сущностью. Связь - “логический” объект, представленный одним или несколькими атрибутами - внешними ключами На рис. 8 изображена логическая схема БД.

Перечислим основные сущности, представленные на диаграмме: