Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой АИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует АИС.
Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры АИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в разработке которых участвуют разные организации и коллективы разработчиков.
После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами). Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или миниспецификации. При детализации должны выполняться следующие правила:
♦ правило балансировки — означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме;
♦ правило нумерации — означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т. д.
Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.
Миниспецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком, исходя из следующих критериев:
♦ наличия у процесса относительно небольшого количества входных и выходных потоков данных (2—3 потока);
♦ возможности описания преобразования данных процессом в виде последовательного алгоритма;
♦ выполнения процессом единственной логической функции преобразования входной информации в выходную;
♦ возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20— 30 строк).
При построении иерархии DFD переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т. п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.
После построения законченной модели системы ее необходимо верифицировать. В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.
Моделирование данных
Цель моделирования данных состоит в обеспечении разработчика АИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы "сущность—связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных (см. подразд. 2.2).
Нотация ERD была впервые введена П. Ченом (P. Chen) и получила дальнейшее развитие в работах Баркера.
Методология IDEF1
Метод IDEF1, разработанный Т. Рэмеем (Т. Ramey), также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия — методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF IX-диаграммы используются рядом распространенных CASE-средств (в частности, ERWin, Design/IDEF).
Использованная литература
· Федотова Д.Э. CASE – технологии: учебник – М: Горячая линия – Телеком, 2007
· Трофимов В.Е., Лобачева И.Н. Информационные системы в экономике – М: Юнити-Дана, 2008
· Балдин Н.В., Уткин В.Б. Информационные системы и технологии в экономике – М: Юнити, 2007
· Титоренко Т.А. Автоматизированные информационные технологии в экономике – М: Юнити, 2006
· Барановская Т.П., Лойко В.И., Семенов М.И., Трубилин И.Т. Автоматизированные информационные технологии в экономике – М: Финансы и статистика, 2006
· www.citforum.ru
· www.interface.ru
· msk.treko.ru