Реферат: Моделирование потоков данных - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

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

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 215 kb, скачать бесплатно
Обойти Антиплагиат
Повысьте уникальность файла до 80-100% здесь.
Промокод referatbank - cкидка 20%!
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Моделирование потоков данных (процессов ) В основе данно й методологи и (методологии Gane/Sarson [11]) лежит пост роение модели анализируемой ИС - проектируемой или реально существующей . В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный проце с с преобразования информации от ее ввода в систему до выдачи пользователю . Диаграммы в ерхних уровней иерархии (контекстные диаграммы ) определяют основные процессы или подсистемы ИС с внешними входами и выходами . Они детализируются при помощи диаграмм нижне г о уровня . Такая декомпозиция прод олжается , создавая многоуровневую иерархию диагра мм , до тех пор , пока не будет достигнут такой уровень декомпозиции , на котором пр оцесс становятся элементарными и детализировать их далее невозможно . Источники информации (в нешние сущност и ) порождают информационные потоки (потоки дан ных ), переносящие информацию к подсистемам или процессам . Те в свою очередь преобразуют информацию и порождают новые потоки , кото рые переносят информацию к другим процессам или подсистемам , накоп и телям данн ых или внешним сущностям - потребителям информ ации . Таким образом , основными компонентами ди аграмм потоков данных являются : внешние сущности ; системы /подсистемы ; процессы ; накопители данных ; потоки данных Внешние сущности Внешняя сущность пр едставляет собой материальный предмет или физическое лицо , представляющее собой источник или приемник информации , например , заказчики , персонал , поставщики , клиенты , склад . Определение некоторого объекта или системы в качестве внешней сущности указывает н а то , что она находится за п ределами границ анализируемой ИС . В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС , если это необходимо , или , наоборот , часть процессов ИС может быть вынесена з а пределы диагр а ммы и представлен а как внешняя сущность . Внешняя сущность обозначается квадратом ( рисунок 2.13), расположенным как бы "над " диаграммо й и бросающим на нее тень , для того , чтобы можно было выделить этот символ среди других обозначений : Рис . 2.13. Внешняя сущность Системы и по дсистемы При построении модели сложной ИС она может быть предс тавлена в самом общем виде на так называемой контекстной диаграмме в виде од ной системы как единого целого , либо может быть декомпозирована на ряд подсистем . Подсистема (или система ) на контекстной диаграмме изображается следующим образом (рисун ок 2.14). Рис . 2.14. Подсистема Номер подсистемы служит для ее иденти фикации . В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и доп олнениями . Процессы Процесс представл яет собой преобразование входных потоков данн ых в выходные в соответствии с определенн ым алгоритмом . Физически процесс может быть реализован различными способами : это может быть под разделение организации (отдел ), вып олняющее обработку входных документов и выпус к отчетов , программа , аппаратно реализованное логическое устройство и т.д . Процесс на диаграмме потоков данных и зображается , как показано на рисунке 2.15. Рис . 2.15. Процесс Номер процесса служит для его идентиф икации . В поле имени вводится наименование процесса в виде предложения с акти вным недвусмысленным глаголом в неопределенной форме (вычислить , рассчитать , проверить , определи ть , создать , получить ), за которым следуют с уществительные в винительном падеже , например : "Ввести сведения о клиентах "; "Выдать информацию о текущих расходах "; "Проверить кредитоспособность клиента ". Использование так их глаголов , как "обработать ", "модернизировать " или "отредактировать " означает , как правило , нед остаточно глубокое понимание данного процесса и требует дальнейшего анализа . Информация в поле ф изической реал изации показывает , какое подразделение организаци и , программа или аппаратное устройство выполн яет данный процесс . Накопители данны х Накопитель данных представляет собой абстрактное устройство дл я хранения информации , которую можно в люб ой мо мент поместить в накопитель и через некоторое время извлечь , причем спосо бы помещения и извлечения могут быть любы ми . Накопитель данных может быть реализован физически в виде микрофиши , ящика в к артотеке , таблицы в оперативной памяти , файла на магнитном н осителе и т.д . Накоп итель данных на диаграмме потоков данных изображается , как показано на рисунке 2.16. Рис . 2.16. Накопитель данных Накопитель данных идентифицируется буквой "D" и произвольным числом . Имя накопителя выби рается из соображения наибольшей информативности для проектировщика . Накопитель данных в общем случае явля ется прообразом будущей базы данных и опи сание хранящихся в нем данных должно быть увязано с информационной моделью . Потоки данных Поток данных о пределяет информацию , передаваемую через некоторо е соединение от источника к приемнику . Реа льный поток данных может быть информацией , передаваемой по к абелю между двумя устройствами , пересылаемыми по почте письмами , магнитными лентами или дискетами , переносимы ми с одного компьютера на другой и т.д . Поток данных на диаграмме изображается линией , оканчивающейся стрелкой , которая показы вает направление пот ока (рисунок 2.17). Каждый поток данных имеет имя , отражающее его содержание . Рис . 2.17. Поток данных Построение иерархии диаграмм потоков данных Первым шагом п ри построении иерархии ДПД является построени е контекстных диаграмм . Обычно при проектиров ании относительно простых ИС строится единств енная контекстная диаграмма со звездообразной топологией , в центре которой находится так называемый главный процесс , соединенный с приемниками и источниками информации , пос редством которых с системой взаимодействуют п ользователи и другие внешние системы . Если же для сложной системы ограничит ься единственной контекстной диаграмм ой , то она будет содержать слишком большое ко личество источников и приемников информации , которые трудно расположить на листе бумаги нормального формата , и кроме того , единствен ный главный процесс не раскрывает структуры распределенной системы . Признаками сл ожности (в смысле контекста ) могут быть : наличие большого количества внешн их сущностей (десять и более ); распределенная природа системы ; многофункциональность системы с уже сложи вшейся или выявленной группировкой функций в отдельные подсистемы . Для с ложны х ИС строится иерархия контекстных диаграмм . При этом контекстная диаграмма верхнего уровня содержит не единственный главный проце сс , а набор подсистем , соединенных потоками данных . Контекстные диаграммы следующего уровня детализируют контекст и стру к тур у подсистем . Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой , так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации ), с которыми взаи модействует ИС . Разработка контекстных диаграмм решает пр облему строгого определения функциональной струк туры ИС на самой ранней стадии ее про ектирования , что особенно важно для сложных многофункциональных систем , в разработке которы х участ вуют разные организации и колл ективы разработчиков . После построения контекстных диаграмм пол ученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационны х связей с другими объектами ). Для каждой подсистемы , присутствующей на контекстных диаграммах , выполняется ее детал изация при помощи ДПД . Каждый процесс на ДПД , в свою очередь , может быть детали зирован при помощи ДПД или миниспецификации . При детализации должны выполняться следующи е правила : правило балансировки - означает , чт о при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников /приемников данных может иметь т олько те компоненты (подсистемы , процессы , внеш ние сущности , накопители данных ), с котор ыми имеет информационную связь детализируемая подсистема или процесс на родительской диа грамме ; правило нумерации - означает , что при д етализации процессов должна поддерживаться их иерархическая нумерация . Например , процессы , дет ализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д . Миниспецификация ( описание логики процесса ) должна формулировать его основные функции таким образом , чтобы в дальнейшем специалист , выполняющий реализацию проекта , смог выполнить их или разработат ь соот ветствующую программу . Миниспецификация является конечной вершиной иерархии ДПД . Решение о завершении детали зации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев : наличия у процесса относительно небольшого к оличества входных и выходн ых потоков данных (2-3 потока ); возможности описания преобразования данных процессом в виде последовательного алгоритма ; выполнения процессом единственной логической функции преобразования входной информации в выходную ; возможн ости описания логики процесса при помощи миниспецификации небольшого объем а (не более 20-30 строк ). При построении иерархии ДПД переходить к детализации проц ессов следует только после определения содерж ания всех потоков и накопителей данных , ко торое описы вается при помощи структур данных . Структуры данных конструируются из элементов данных и могут содержать альтернати вы , условные вхождения и итерации . Условное вхождение означает , что данный компонент мо жет отсутствовать в структуре . Альтернатива о значает, что в структуру может вхо дить один из перечисленных элементов . Итераци я означает вхождение любого числа элементов в указанном диапазоне . Для каждого элемен та данных может указываться его тип (непре рывные или дискретные данные ). Для непрерывных данных може т указываться единица измерения (кг , см и т.п .), диапазон значени й , точность представления и форма физического кодирования . Для дискретных данных может указываться таблица допустимых значений . После построения законченной модели систе мы ее необходимо вериф ицировать (проверит ь на полноту и согласованность ). В полной модели все ее объекты (подсистемы , процес сы , потоки данных ) должны быть подробно оп исаны и детализированы . Выявленные недетализирова нные объекты следует детализировать , вернувшись на предыдущие ш аги разработки . В согласованной модели для всех потоков да нных и накопителей данных должно выполняться правило сохранения информации : все поступающ ие куда-либо данные должны быть считаны , а все считываемые данные должны быть запис аны . Литература Вендров А .М . Один из по дходов к выбору средств проектирования баз данных и приложений . "СУБД ", 1995, № 3. Зиндер Е.З . Бизнес-реинжиниринг и технологи и системного проектирования . Учебное пособие . М ., Центр Информационных Технологий , 1996 Калянов Г.Н . CASE. Структур ный системный анализ (автоматизация и применение ). М ., "Лори ", 1996. Марка Д.А ., МакГоуэн К . Методология стру ктурного анализа и проектирования . М ., "МетаТехн ология ", 1993. Международные стандарты , поддерживающие жизне нный цикл программных средств . М ., МП "Экономика ", 1996 Создание информационной системы предприятия . "Computer Direct", 1996, N2 Шлеер С ., Меллор С . Объектно-ориентированный анализ : моделирование мира в состояниях . Киев , "Диалектика ", 1993. Barker R. CASE*Method. Entity-Relationship Modell ing. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990. Barker R. CASE*Method. Function and Process Modelling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990. Boehm B.W. A Spiral Model of Software Development and Enhancement. ACM SIGSOFT Software Engineering Notes, Aug. 1986 Chris Gane, Trish Sarson. Structured System Analysis. Prentice-Hall, 1979. Edward Yourdon. Modern Structured Analysis. Prentice-Hall, 1989. Tom DeMarco. Structured Analysis a nd System Specification. Yourdon Press, New York, 1978. Westmount I-CASE User Manual. Westmount Technology B.V., Netherlands, 1994. Uniface V6.1 Designers' Guide. Uniface B.V., Netherlands, 1994. IEEE Std 1348-1995. IEEE Recommended Practice for the Ado ption of CASE Tools. IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools. PVCS Version Manager. User's Guide.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
В студенческой общаге:
- А у нас в комнате живут два Антона.
- И Лёня, тот ещё Антон!..
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по программированию "Моделирование потоков данных", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2017
Рейтинг@Mail.ru