Построение иерархии диаграмм потоков данных

Первым шагом при построении иерархии DFD является создание контекстной диаграммы. Для достаточно простых систем строится единственная контекстная диаграмма со звездообразной топологией., в центре которой помещается главный процесс, соединенный с источниками и приемниками информации.

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

Признаками сложности (в смысле контекста) могут быть:

- наличие большого числа внешних сущностей,

- распределенная структура системы,

- многофункциональность системы, с группировкой функций в автономные подсистемы.

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

Каждый процесс на DFD может быть детализирован при помощи DFD более низкого уровня или при помощи миниспецификации (описания логики процесса). При детализации должны выполняться следующие правила:

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

- правило нумерации – определяющее, чтопри детализации процессов и подсистем должна поддерживаться иерархическая нумерация. Т. е. при детализации процесса с номером 5 детализирующие его процессы будут иметь номера 5.1, 5.2, 5.3 и т.д.

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

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

Миниспецификация является самым нижним уровнем иерархии. Решение о завершении процесса детализации и написании миниспецификации принимает аналитик исходя из следующих критериев:

- наличие у процесса небольшого количества входных и выходных потоков данных (2-3),

- возможность описания процесса преобразования данных в виде последовательного алгоритма,

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

- возможность описания логики процесса при помощи мини спецификации небольшого размера (порядка 20-30 строк).

После завершения построения модели ее необходимо верифицировать, т.е. проверить на полноту и согласованность. В полной системе все ее компоненты: подсистемы, процессы, потоки данных – должны быть подробно описаны и детализированы. При выявлении не детализированных объектов, их необходимо детализировать, вернувшись на предыдущие этапы.

2.3.2.2 Моделирование данных при помощи диаграммы ”сущность-связь” (ERD)

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

Наиболее распространенным средством моделирования данных являются диаграммы ”сущность-связь”. с их помощью определяются важные для предметной области объекты--сущности, их свойства—атрибуты и их отношения—связи. Диаграммы такого типа можно использовать для проектирования реляционных БД.

Базовыми понятиями ERD являются:

Сущность – т.е. реальный или абстрактный объект, имеющий важное значение для данной предметной области. Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех остальных экземпляров данного типа сущности. Каждая сущность должна обладать следующими свойствами:

- иметь уникальное имя,

- обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь,

- обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый атрибут сущности,

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

Графически сущность обозначается следующим образом.

Связь- поименованная ассоциация между двумя сущностями, имеющая значение для данной предметной области. При этом, как правило, каждый экземпляр одной сущности (именуемой родительской) ассоциирован с произвольным количеством экземпляров другой сущности (именуемой сущностью --потомком), а каждый экземпляр сущности—потомка ассоциирован только с одним экземпляром сущности—родителя. Т.о. экземпляр сущности—потомка может существовать только при наличии сущности—родителя. Имена связей на диаграмме не обязательно должны быть уникальным, но имена каждой связи между двумя сущностями должны быть уникальными.. Имя связи указывается возле линии связи

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

Моделирование данных можно разбить на несколько шагов:

1- извлечение информации из описания предметной области,

2- идентификация связей,

3-идентификация атрибутов.

Дата добавления: 2015-10-29