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

ФГБОУ ВПО Московский Государственный Агроинженерный Университет имени В.П. Горячкина

 

Кафедра: «Информационные системы в экономике»

 

РАСЧЕТНАЯ РАБОТА

по дисциплине:

« Проектирование экономических информационных систем»

на тему: «Система агентства по подбору кадров»

 

 

Москва 2011

Содержание

Введение. 3

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

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

3. Диаграмма IDEF0. 8

4. Диаграмма IDEF3. 12

5. Диаграмма ERD.. 14

Заключение. 16

Список используемой литературы.. 17

 

Введение.

Информационные системы в наше время очень распространены. Они присутствуют практически везде и участвуют в любой сфере деятельности.

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

1. DFD - методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

2. IDEF0 - методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Представлена в виде взаимосвязанных блоков.

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

4. ERD - модель данных, позволяющая описывать концептуальные схемы предметной области. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.

В данной работе будет спроектирована система агентства по подбору кадров.

 

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

Предметной областью будет являться система агентства по подбору кадров.

В данном агентстве производится трудоустройство обратившихся туда клиентов, при этом осуществляется:

1. Внесение данных о работниках

2. Внесение данных о работодателях

3. Прием запросов от работников.

4. Прием запросов от работодателей.

5. Создание каталога кадров.

6. Создание каталога работодателей.

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

 

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

DFD (Data Flow Diagramming) - это стандарт моделирования, в котором система представляется в виде сети работ, соединенных между собой объектами, взаимодействующими с результатами данных работ. Сфера применения DFD находится в области моделирования информационных потоков организации. В этой нотации моделируется не последовательность работ, а именно потоки информации (данных) между работами и объектами, которые используют, хранят или "рождают" эти данные.

В соответствии с DFD (Data Flow Diagram) методологией, модель системы определяется как иерархия диаграмм потоков данных, описывающих процессы преобразования информации от момента ее ввода в систему до выдачи конечному пользователю. Диаграммы верхних уровней иерархии - контекстные диаграммы, задают границы модели, определяя её окружение (внешние входы и выходы) и основные рассматриваемые процессы. Контекстные диаграммы детализируются при помощи диаграмм следующих уровней.

Элементы DFD диаграмм Основными элементами диаграмм потоков данных являются:

1. Внешние сущности;

2. Процессы;

3. Накопители данных;

4. Потоки данных.

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

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

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

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

Теперь создадим диаграмму DFD системы агентства по подбору кадров (рис. 1) и ее декомпозицию (рис. 2).

Рис.1. DFD диаграмма

Рис. 2. Декомпозиция DFD.

 

Диаграмма IDEF0

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

1. Функциональный блок (Activity Box). Функциональный блок графически изображается в виде прямоугольника и представляет собой некоторую конкретную функцию в моделируемой системы. Название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

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

Верхняя сторона имеет значение “Управление” (Control);

Левая сторона имеет значение “Вход” (Input);

Правая сторона имеет значение “Выход” (Output);

Нижняя сторона имеет значение “Ресурсы” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

2. Интерфейсная стрелка - интерфейсная дуга, поток (Arrow). Интерфейсная стрелка отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Интерфейсная стрелка «вход» (Input).

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

Интерфейсная стрелка «управление» (Control).

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

Интерфейсная стрелка «ресурс» (Mechanism)

Интерфейсная стрелка «Ресурсы» – обозначает те ресурсы, которые требуются для преобразования входа в выход. Ресурсами могут являться, например, люди, машины и оборудование. Интерфейсная стрелка «ресурс» не является обязательной.

Интерфейсная стрелка «выход» (Output)

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

Интерфейсные стрелки ссылки (Call Arrow).

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

Обязательное наличие управляющих интерфейсных стрелок является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными стрелками, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.

Создадим диаграмму обработки запросов.

Рис. 3. Диаграмма IDEF0.

Проведем декомпозицию.

Рис.4. Декомпозиция IDEF0.

Диаграмма IDEF3

В отличие от IDEF0, представляющего моделируемую систему как совокупность видов деятельности, IDEF3 представляет собой технику моделирования деятельности как последовательности событий, а также участвующих в этих событиях объектов. В этом смысле IDEF3 похож на стандарт eEPC в ARIS. IDEF3 удобен для подробного моделирования деятельности отдельных подразделений, сотрудников, описания техпроцессов и т.д. Формат листа диаграммы IDEF3 аналогичен IDEF0. В IDEF3 используются следующие типы объектов:

· работа (Unit of Work, Activity)

· стрелка (Arrow)

· перекресток, или коннектор (Junction)

· ссылочный объект (Referent)

Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор).

Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо.

IDEF3 различают три типа стрелок, изображающих связи: Старшая- сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.

Отношения- пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.

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

Перекрестки. Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния и разветвления стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления.

Всё перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Теперь рассмотрим поиск результатов по запросу. Для этого декомпозируем блок «Поиск соответствующей информации» (из предыдущей диаграммы) методологией IDEF3.

Рис. 5. IDEF3

 

Диаграмма ERD

Модель “сущность – связь” (entity – relation diagram – ERD) – является неформальной моделью предметной области (ПО) и используется на этапе инфологического проектирования БД. Моделируются объекты ПО и их взаимоотношения. Модель ERD была разработана П. Ченом.

Достоинства ERD:

1. Относительная простота;

2. Однозначность;

3. Применение естественного языка;

4. Доступность для понимания.

Информация о проекте представляется с использованием графических диаграмм.

Для построения ERD используются 3 основных элемента: сущность, атрибут и связь.

Сущность – собирательное понятие, абстракция реально существующего объекта, процесса или явления, о котором необходимо хранить информацию в системе. Примеры сущностей: материальные (предприятие, сотрудники), нематериальные (описание явления, реферат). Отображается в виде прямоугольника- должна обладать уникальным идентификатором; один или несколько атрибутов.

Атрибут – поименованнная характеристика сущности, его роль – описание свойств сущности: (сущность: КНИГА, атрибуты: НАЗВАНИЕ, АВТОР) и идентификация экземпляра сущности – т.е. каждый экземпляр сущности должен иметь уникальное имя – В качестве имени выступает один или несколько атрибутов. Например, «НОМЕР ЗАЧЕТНОЙ КНИЖКИ» или «НОМЕР» и «СЕРИЯ ПАСПОРТА; может быть обязательным и необязательным.

Связи – средство представления отношений между сущностями, отображаются при помощи линий именованных ассоциацией между 2 сущностями. Связь характеризуется типом (1:1, 1:N, N:М) и классом принадлежности (обязательный и необязательный). Если каждый экземпляр сущности участвует в связи, то класс принадлежности – обязательный, иначе – необязательный.

Составим модель ERD.

Оператор 1. Номер оператора 2. ФИО

Работодатель 1. Название организации 2. ИНН 3. Вид деятельности 4. Вакансии

Соискатели 1. ФИО 2. Номер и серия паспорта 3. Образование 4. Стаж 5. Вид выполняемых работ 6. Номер оператора 7. Номер карточки

Подбирает

P AAAAAAAAAAAAAAAAAAkFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABADzAAAAFAYAAAAA " fillcolor="white [3201]" strokeweight=".5pt">

1, N

1, N

1, N

Регистрирует

1, N

1, N

Запрос на поиск соискателя 1. Номер запроса 2. Критерии поиска

Создает

Соответствует

I fQdrkbhRJ5H6F+JUFZQTHELgwNGNlyRqvI5iNwk8PYs4wHFnPs3OZPvZdmLEwbeOFMTLCARS5UxL tYK318fbLQgfNBndOUIFn+hhny+uMp0aN9ELjmWoBYeQT7WCJoQ+ldJXDVrtl65HYu/DDVYHPoda mkFPHG47mUTRWlrdEn9odI/3DVbn8mIVbI5PZdFPD89fhdzIohhd2J7flbq5ng93IALO4Q+Gn/pc HXLudHIXMl50ClbxbscoG0kMgoF1nLBw+hVknsn/C/JvAAAA//8DAFBLAQItABQABgAIAAAAIQC2 gziS/gAAAOEBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG AAgAAAAhADj9If/WAAAAlAEAAAsAAAAAAAAAAAAAAAAALwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG AAgAAAAhAC4VuEDjAQAA3AMAAA4AAAAAAAAAAAAAAAAALgIAAGRycy9lMm9Eb2MueG1sUEsBAi0A FAAGAAgAAAAhAIZiXK/dAAAACQEAAA8AAAAAAAAAAAAAAAAAPQQAAGRycy9kb3ducmV2LnhtbFBL BQYAAAAABAAEAPMAAABHBQAAAAA= " strokecolor="black [3040]"/>

1, N

1, N

1, 1

 

Рис. 7. Модель ERD.

 

Заключение

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

Для создания диаграмм использовался программный продукт ERWin Process Modeler.

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

 

 

 

Список используемой литературы

1. В. И. Грекул, Г. Н. Денищенко, Н. Л. Коровкина, Проектирование информационных систем, Издательство: Бином. Лаборатория знаний, 2008

2. В. В. Коваленко, Проектирование информационных систем, Издательство: Форум, 2011.

3. И. В. Соловьев, А. А. Майоров, Проектирование информационных систем, Издательство: Академический Проект, 2009.

4. Т. В. Гвоздева, Б. А. Баллод, Проектирование информационных систем, Издательство: Феникс, 2009.

5. Н. З. Емельянова, Т. Л. Партыка, И. И. Попов, Проектирование информационных систем, Издательство: Форум, 2009.