- •«Проектирование ис» 2011
- •1. Понятие информационной системы. Типовые функциональные компоненты ис
- •2. Схема развития ис
- •3. Этапы проектирования ис
- •4. Понятие жизненного цикла ис, модели жизненного цикла информационной системы
- •5. Основные принципы создания ис
- •6. Требования к методологии и технологии разработки ис
- •7. Методология rad
- •8. Методы проектирования ис
- •9. Функционально-ориентированные методологии проектирования. Основные принципы функциональной методики idef0
- •10. Методология idef0. Виды стрелок на диаграммах idef0
- •11. Методология idef0. Нумерация работ и диаграмм. Каркас диаграммы
- •12. Методология idef0. Виды диаграммы idef0
- •13. Диаграммы потоков данных. Назначение. Нотации dfd. Рекомендации по построению
- •14. Основные элементы диаграмм dfd
- •15. Диаграммы dfd. Элементы для декомпозиции данных
- •16. Диаграммы dfd. Управляющие элементы диаграмм
- •17. Методология idef3. Назначение диаграмм. Основные элементы
- •18. Виды перекрестков на диаграммах idef3
- •19. SwimLane диаграммы и построение сценариев SwimLaneDiagrams (диаграмма плавательных дорожек).
- •20. Стоимостной анализ. Принципы связи abc анализа и idef0
- •21. Количественный и качественный анализ диаграмм модели idef
- •22. Моделирование данных. Архитектура ansi-sparc
- •24. Er-диаграммы. Определение сущности, атрибута, связи
- •25. Методология idef1x. Виды и мощности связей. Понятие зависимых и независимых сущностей
- •26. Методология idef1x. Виды зависимых сущностей
- •27. Нормальные формы er-диаграмм. Получение реляционной схемы из er-диаграмм
- •28. Реляционная модель данных. Структурная часть. Управляющая связь. Виды ключей
- •29. Реляционная модель данных. Набор ограничений целостности. Операции, нарушающие целостность
- •Ограничения кортежа.Ограничения целостности кортежапредставляют собой ограничения, накладываемые на допустимые значенияотдельногокортежа отношения, ине являющиесяограничением целостности атрибута.
- •30. Реляционная алгебра. Теоретико-множественные операции
- •31. Реляционная алгебра. Специальные операции
- •32. Реляционная модель данных. 1нф, 2нф, 3нф, нфбк
- •33. Реляционная модель данных. Нормальные формы более высоких порядков
- •36. Язык моделирования uml. Назначение. Характеристики. Перечень диаграмм
13. Диаграммы потоков данных. Назначение. Нотации dfd. Рекомендации по построению
Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD – процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища). Рекомендации по построению1. Размещать на каждой диаграмме от 3 до 6-7 процессов. 2. Не загромождать диаграммы несущественными на данном уровне деталями. 3. Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. 4. Выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использовать аббревиатуры. 5. Соблюдать следующие этапы:
1) Идентификация внешних объектов, с которыми система должна быть связана. 2) Идентификация основных видов информации, циркулирующей между системой и внешними объектами. 3) Предварительная разработка контекстной диаграммы. 4) Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям. 5) Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков. 6) Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы. 7) Проверка основных требований по DFD первого уровня. 8) Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса. 9) Проверка основных требований по DFD соответствующего уровня. 10) Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах. 11) Параллельное (с процессом декомпозиции) изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям. 12) После построения двух-трех уровней проведение ревизии с целью проверки корректности и улучшения понимаемости модели. 13) Построение спецификации процесса (а не простейшей диаграммы) в случае, если некоторую функцию сложно или невозможно выразить комбинацией процессов.
14. Основные элементы диаграмм dfd
Потоки данныхявляются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации. Назначениепроцесса (работы)состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, "получить документы по отгрузке продукции"). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.Хранилище (накопитель)данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным.Внешняя сущностьпредставляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, "склад товаров". Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.