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

Реферат

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

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

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

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 215 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

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

Моделирование потоков данных (процессов ) В основе данно й методологи и (методологии 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 - 2016
Рейтинг@Mail.ru