Предлагается набор таких средств, как диаграммы потоков данных, диаграммы состояний- [c.202]
На данном этапе целесообразно построить обзорную диаграмму потоков данных для оценки существующей ситуации с целью ее использования для подгонки всех фрагментов друг к другу и выявления недостатков. [c.88]
Диаграммы потоков данных (ДПД), как правило, жестко ориентированы на какую-либо технологию обработки данных и отражают передачу информации от одной функции к другой в рамках заданной технологии обработки. В узлах диаграммы потоков данных (прямоугольниках) отражаются процедуры, а стрелками между узлами показываются потоки данных (над стрелками задаются имена передаваемых/используемых единиц информации - документов, экранных форм, файлов). [c.332]
Рассмотрим основные понятия диаграммы потоков данных. [c.332]
U3 - конструктивные элементы диаграмм иерархии функций U4 - конструктивные элементы диаграмм потоков данных, [c.345]
Входом технологической операции с преобразователем П4 Построение диаграммы потоков данных являются [c.346]
Выходом данной операции является описание в репозитории диаграммы потоков данных D5. [c.347]
Взять диаграмму потока данных (соответствующие уровни DFD) для выделенных функций и подфункций и проанализировать ее с учетом входных и выходных потоков данных. [c.349]
Зачем создаются диаграммы потоков данных [c.384]
Определите основные понятия и конструктивные элементы диаграммы потоков данных. [c.384]
Методы моделирования для разработки требований 3.2.1 Диаграммы потоков данных [c.51]
Рис. 3.1 Диаграмма потоков данных. |
На рис. 3.1 приведен простой пример традиционного использования диаграммы потоков данных для моделирования информационный системы. [c.52]
Для иллюстрации применения диаграмм потоков данных рассмотрим пример контекстной диаграммы для системы управления и контроля скорой помощи (рис. 3.4). Эта диаграмма является отправной точкой для анализа потоков данных системы. [c.53]
Отсюда возникает необходимость рассматривать системные транзакции с разных точек зрения - пути, который они проходят внутри системы времени, которое требуется для их выполнения ресурсов, которые они задействуют. Альтернативой динамическим моделям, показывающим пользовательские требования в действии и иллюстрирующим основные операции системы, является отображение системных транзакций на диаграммах потоков данных, как это сделано на рис. 3.9, где путь системной транзакции показан жирными стрелками. [c.56]
Диаграммы потоков данных хорошо подходят для представления структур, но они недостаточно аккуратны . Они гораздо менее точны, чем текстовое представление разрабатываемой системы. На диаграмме потоков данных линии связи могут быть неоднозначны, любое слово диаграммы может обобщать что угодно и иметь массу значений. Кроме этого, на диаграммах потоков данных нельзя корректно отображать ограничения. [c.56]
Следует заметить, что рис. 3.6, на самом деле, является не совсем корректным с точки зрения договоренностей, принятых для отображения диаграмм потоков данных, поскольку на одной диаграмме показана и декомпозиция всей системы на несколько процессов, и показаны внешние сущности, с которыми взаимодействует система. Если точно следовать правилам построения DFD диаграмм, то внешние сущности должны присутствовать только на контекстной диаграмме и, следовательно, не должны присутствовать на этом уровне декомпозиции. Однако если убрать внешние сущности, то диаграмма станет менее понятной и связи к внешним сущностям зависнут в воздухе. [c.57]
Вот почему неукоснительному следованию концептуально правильным идеалам, авторы книги предпочитают прагматический подход к использованию DFD. Таким образом, диаграммы потоков данных [c.57]
Прецеденты изображаются овалами, так же как и процессы на диаграммах потоков данных (DFD). На диаграммах прецедентов изображаются прецеденты, актеры и связи между ними. При этом каждый прецедент определяет функциональное требование к системе. [c.62]
Q диаграммы потоков данных — DFD (Data Flow Diagrams). Они обеспечивают спецификацию внешних устройств (источников или приемников информации), систем/подсистем, процессов (функций системы), потоков входной и выходной информации, накопителей данных (БД). Используется иерархия взаимосвязанных диаграмм потоков данных, что позволяет последовательно детализировать и описывать алгоритмы обработки данных с помощью таблиц решений, языков программирования, блок-схем алгоритмов [c.51]
Проектирование ПО с помощью ASE-систем. Оно включает несколько этапов. Начальный этап — предварительное изучение проблемы. Результат представляется в виде исходной диаграммы потоков данных и согласуется с заказчиком. На следующем этапе выполняется детализация ограничений и функций программной системы, и полученная логическая модель вновь согласуется с заказчиком. Далее разрабатывается физическая модель, т.е. определяется модульная структура программы, выполняется мифологическое проектирование базы данных, детализируются граф-схемы программной системы и ее модулей, проектируется пользовательский интерфейс. [c.120]
В большинстве случаев функциональные диаграммы — это диаграммы потоков данных (DFD — Data Flow Diagram). В DFD блоки (прямоугольники) соответствуют функциям, дуги — входным и выходным потокам данных. Поясняющий текст дается в виде словарей данных , в которых указываются компонентный состав потоков данных, число повторений циклов и т.п. Для описания структуры информационных потоков можно использовать нотацию Бэкуса — Наура. [c.122]
DFD [Data Flow Diagrams] — диаграммы потоков данных — методология структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. [c.299]
В функциональных моделях (DFD-диаграммах потоков данных, SADT-диаграммах) главными структурными компонентами являются функции (операции, действия, работы), которые на диаграммах связываются между собой потоками объектов (подробное изложение структурного функционально-ориентированного подхода изложено в гл. 13). [c.281]
Диаграммы потоков данных достаточно хорошо отображают функции и интерфейсы. Они также могут использоваться для определения системных транзакций типа начало-конец (end-to-end transa tions), хотя и отражают их только косвенно. В идеале, конечно, было бы неплохо иметь возможность так просматривать диаграммы и разворачивать элементы структуры прямо на диаграмме, чтобы видеть контекст каждой диаграммы, каждого уровня декомпозиции. Кстати, некоторые ASE средства позволяют это делать. [c.56]
С точки зрения авторов данной книги, мнение этих ведущих специалистов отражает не суть явления (а суть в том, что обе модели в большинстве случаев являются динамическими), а возможности используемых ими инструментальных средств. Дело в том, что до недавнего времени для моделирования деятельности компании разработчики могли использовать только статические ИС, так как других средств не было. Типичными ИС, применяемыми для моделирования деятельности компаний, являлись разнообразные ASE-средства, которые описывали деятельность компании в статических понятиях, например, E/R-диаграммы, диаграммы потоков данных и т.п. (см. разд. 3.4). Эти средства позволяли описать компанию в виде взаимосвязанной совокупности блоков (отделений, отделов, лабораторий, групп и т.п.), указывая при этом их функции, входы, выходы, диапазоны передаваемых параметров и т.п. Однако эти ИС не позволяли описывать реальное, текущее состояние компании и ее подразделений, изменяемое во времени. В последнее время в ряд ASE-средств начинают вводить компоненты, позволяющие в ограниченном виде описывать некоторые аспекты динамики. Не вызывает сомнения, что любая модель компании (в том числе и статическая) лучше, чем отсутствие модели, однако для многих компаний их деятельность не может быть адекватно описана без привлечения динамики, т.е. без учета временного фактора. Например, в Приложении 2 описана модель автоматизированного грузового комплекса (Шереметьево-Карго), обеспечивающего прием (отправку) и хранение грузов при авиационных перевозках. Учитывая высокую динамичность подобных компаний (самолеты прибывают или убывают каждые несколько минут), адекватно описать их модель статическими средствами невозможно даже теоретически. Другим примером компаний, требующих для их описания динамической модели, являются любые компании, использующие для производства продукции технологические процессы (металлургические, химические, перерабатывающие и др.). [c.126]
Модель является внутренней с позиций пользователя. Традиционные модели, с которыми пользователь работает непосредственно, такие как диаграммы потоков данных, SADT-диаграммы, диаграммы "сущность-связь" [1] и другие, могут быть транслированы в предложенную модель бизнес-процесса. [c.229]
Смотреть страницы где упоминается термин Диаграммы потоков данных
: [c.371] [c.527] [c.203] [c.90] [c.327] [c.462] [c.330] [c.345] [c.346] [c.348] [c.348] [c.349] [c.51] [c.75] [c.87] [c.133] [c.82] [c.82] [c.82]Смотреть главы в:
Разработка и управление требованиями -> Диаграммы потоков данных