 |
Построение иерархии диаграмм потоков данных
|
|
|
|
Первым шагом при построении иерархии ДПД является построение контекстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы.
Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть:
наличие большого количества внешних сущностей (десять и более);
распределенная природа системы;
многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.
Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС.
Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в разработке которых участвуют разные организации и коллективы разработчиков.
|
|
|
После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами).
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою очередь, может быть детализирован при помощи ДПД или миниспецификации. При детализации должны выполняться следующие правила:
· правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме;
· правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.
Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.
Миниспецификация является конечной вершиной иерархии ДПД. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:
· наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);
· возможности описания преобразования данных процессом в виде последовательного алгоритма;
|
|
|
· выполнения процессом единственной логической функции преобразования входной информации в выходную;
· возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).
При построении иерархии ДПД переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.
После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.
Моделирование данных
Одной из основных частей информационного обеспечения является информационная база. Информационная база (ИБ) представляет собой совокупность данных, организованная определенным способом и хранимая в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. Разработка БД выполняется с помощью моделирования данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).
|
|
|
УД теоретико-множественные модели: иерархическая, сетевая, реляционная
Case-метод Баркера
Цель моделирования данных состоит в обеспечении разработчика информационной системой конфигурационной схемой БД в форме моделей, которые м.б. отображены во все системы БД.
Наиболее распространенные средства моделирования:
- ER-диаграммы П.Чен
Используются для проектирования реляционных БД
- Метод Баркера - развитие ER-Diagram
Поянтия метода Баркера:
Сущность - реальный либо воображаемый объект, имеющий существенное значение для данной предметной области, информация о котором подлежит хранению.
Свойства сущности:
- Имеет уникальное имя
- Имеет один или несколько атрибутов, которые однозначно идентифицируют каждый экземпляр сущности
- Может обладать любым количеством связей с другими сущностями.
Связь - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.
Атрибуты - это любая характеристика сущности, значимая для данной предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности.
# - ключевой атрибут
Супертипы и подтипы
В методе Баркера подтип рисуется внутри супертипа.
Супер-тип - это сущность, которая является обобщенным понятием для группы подобных сущностей.
Взаимоисключающие связи
Каждый экземпляр сущности участвует только в одной связи из группы взаимоисключающих связей. Т.
|
|
|
Рекурсивная связь
Сущность связана сама с собой.
Неперемещаемая связь - экземпляр сущности не м.б. перемещен из одного экземпляра связи в другой.
Методология IDEF
Методология IDEF - это, пожалуй, наиболее глубоко проработанная и наиболее обширная методология, которая позволяет описывать не только бизнес-процессы, но и функциональные блоки (например, маркетинг или финансы), различные объекты в компании и действия над ними (например, весь комплекс процессов обработки и выполнения заказа клиента), а также состояние и динамику развития бизнес-единиц компании и компании в целом. Методология IDEF состоит из 14 компонент, наиболее важными из которых являются:
o IDEF0 (методология моделирования функциональных блоков);
o IDEF1 (методология моделирования информационных потоков в компании);
o IDEF2 (методология моделирования динамики развития компании);
o IDEF3 (методология документирования бизнес-процессов в компании);
o IDEF4 (методология описания различных объектов в компании и действий над ними);
o IDEF5 (методология описания текущего состояния компании и тенденций его изменения).
|
|
|
