Главная страница
Навигация по странице:

  • Элемент Описание Обозначение

  • База данных-понятия. Классификация по


    Скачать 0.55 Mb.
    НазваниеКлассификация по
    АнкорБаза данных-понятия.docx
    Дата17.07.2018
    Размер0.55 Mb.
    Формат файлаdocx
    Имя файлаБаза данных-понятия.docx
    ТипДокументы
    #21614
    страница16 из 23
    1   ...   12   13   14   15   16   17   18   19   ...   23

    5.3.Методологии функционального моделирования.



    5.3.1.Диаграммы потоков данных. Нотация Йордона - Де Марко


    Диаграммы потоков данны (DFD - Data Flow Diagramm) строятся из следующих элементов:

    Элемент

    Описание

    Обозначение

    Функция

    Действие, выполняемое моделируемой системой

    http://www.mstu.edu.ru/study/materials/zelenkov/dfd_func.gif

    Поток данных

    Объект, над которым выполняется действие. Может быть информационным (логическим) или управляющим. (Управляющие потоки обозначаются пунктирной линией со стрелкой).

    http://www.mstu.edu.ru/study/materials/zelenkov/dfd_df.gif

    Хранилище данных

    Структура для хранения информационных объектов

    http://www.mstu.edu.ru/study/materials/zelenkov/dfd_ds.gif

    Внешняя сущность

    Внешний по отношению к системе объект, обменивающийся с нею потоками данных

    http://www.mstu.edu.ru/study/materials/zelenkov/dfd_ee.gif

    Такой тип обозначений элементов DFD-диаграммы получил название "нотация Йордона - Де Марко", по именам разработавших его специалистов.

    Функции, хранилища и внешние сущности на DFD-диаграмме связываются дугами, представляющими потоки данных. Дуги могут разветвляться или сливаться, что означает, соответственно, разделение потока данных на части, либо слияние объектов. При интерпретации DFD-диаграммы используются следующие правила:

    • Функции преобразуют входящие потоки данных в выходящие

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

    • Преобразования потоков данных во внешних сущностях игнорируется

    Помимо этого, для каждого информационного потока и хранилища определяются связанные с ними элементы данных. Каждому элементу данных присваивается имя, также для него может быть указан тип даных и формат. Именно эта информация является исходной на следующем этапе проектирования - построении модели "сущность-связь". При этом, как правило, информационные хранилища преобразуются в сущности, проектировщику остается только решить вопрос с использованием элементов данных, не связанных с хранилищами.

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

    http://www.mstu.edu.ru/study/materials/zelenkov/dfd.gif

    Эта диаграмма представляет самый верхний уровень функциональной модели. Естественно, это весьма грубое описание предметной области. Уточнение модели производится путем детализации необходимых функций на DFD-диаграмме следующего уровня. Так мы можем разбить функцию "Определение потребностей и обеспечение материалами" на подфункции "Определение потребностей", "Поиск поставщиков", "Заключение и анализ договоров на поставку", "Контроль платежей", "Контроль поставок", связанные собственными потоками данных, которые будут представлены на отдельной диаграмме. Детализация модели должна производится до тех пор, пока она не будет содержать всю информацию, необходимую для построения ифнормационной системы.

    5.3.2.Другие нотации, используемые при построении диаграмм потоков данных.


    Помимо нотации Йордона - Де Марко для элементов DFD-диаграм могут использоваться и другие условные обозначения (OMT, SSADM, нотация Гейна - Сарсона и т.д.). Все они обладают практически одинаковой функциональностью и различаются лишь в деталях. Например, в нотации Гейна-Сарсона для обозначения функций используются прямоугольники с закругленными углами, а также не рассматриваются управляющие потоки данных. В остальном эти системы обозначений эквивалентны.

    Инструментальные средства проектирования (CASE - системы), как правило, поддерживают несколько нотаций представления DFD-диаграмм. Одной из таких систем является Power Designer компании Sybase, который включает следующие модули:

    • Process Analyst - построение диаграмм потоков данных с использоваанием любой из вышеупомянутых нотаций

    • Data Analyst - построение диаграмм "сущность-связь" и преобразование ее в реляционную модель

    • Application Modeller - средство для генерации приложений

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

    5.3.3.Методология SADT (IDEF0).


    Методология SADT (Structured Analisys and Design Technique) разработана Дугласом Т. Россом в 1969-73 годах. Она изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения. IDEF0 (подмножество SADT) используется для моделирования бизнес-процессов в организационных системах и имеет развитые процедуры поддержки коллективной работы.

    В терминах IDEF0 система представляется в виде комбинации блоков и дуг. Блоки представляют функции системы, дуги представляют множество объектов (физические объекты, информация или действия, которые образуют связи между функциональными блоками). Место соединения дуги с блоком определяет тип интерфейса:

    http://www.mstu.edu.ru/study/materials/zelenkov/idef0_1.gif

    Правила интерпретации модели:

    • Функциональный блок (функция) преобразует входные объекты в выходные

    • Управление определяет, когда и как это преобразование может или должно произойти

    • Исполнитель осуществялет это преобразование

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

    Дуги могут разветвляться и соединяться. Ветвление означает множественность (идентичные копии одного объекта) или расщепление (различные части одного объекта). Соединение означает объединение или слияние объектов.

    Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующего уровня. Эти блоки представляют подфункции (подмодули) исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничивается, зато рекомендуется на одной диаграмме использовать не менее 3 и не более 6 блоков.

    На следующем рисунке представлена IDEF0-модель деятельности описанного выше предприятия.

    http://www.mstu.edu.ru/study/materials/zelenkov/idef0_2.gif

    5.3.4.Сравнительный анализ методологий функционального моделирования.


    Несмотря на то, что методология IDEF0 получила широкое распространение в российских компаниях, на наш взгляд DFD гораздо больше подходит для проектирования информационных систем вообще и баз данных в частности. DFD позволяет уже на стадии функционального моделирования определить базовые требования к данным (этому способствует разделение потоков данных на материальные, информационные и управляющие). Вообще интеграция DFD и ER (entity-relationship, "сущность-связь") моделей не вызывает затруднений. Например, можно определить список атрибутов хранилищ данных, последние на стадии информационного моделирования однозначно отображаются в сущности модели "сущность- связь".

    В свою очередь, как уже отмечалось, IDEF0 больше подходит для решения задач, связанных с управленческим консультированием (перепроектированием деловых процессов, бизнес - реинжинирингом). Этому способствует также тесная связь IDEF0 с методом функционально - стоимостного анализа ABC (Activity Based Costing), позволяющим определить схему расчета стоимости выполнения той или иной деловой процедуры. Однако, существует ряд CASE - систем, предлагающих методологию IDEF0 на этапе функционального обследования предметной области. В таких системах на следующий этап передается просто список всех объектов IDEF0-модели (входы, выходы, механизмы, управление), которые затем рассматриваются на предмет включения в информационную модель.

    На этом мы закончим рассмотрение способов функционального моделирования предметной области, поскольку эта тема должна быть гораздо полнее освещена в курсе, касающегося проектирования информационных систем. Подробнее о методологии SADT / IDEF0 можно узнать из книги Д.Марки и К. МакГоуэна, DFD описана в книге Г.Н. Калянова. Более полный сравнительный анализ рассмотренных здесь методологий сделан в статье Г.Н.Калянова, А.В.Козлинского и В.Н.Лебедева, указанной в списке литературы.

    В предыдущей главе мы кратко рассматрели методы функционального моделирования, которые позволяют выделить первичные информационные объекты, из которых затем строятся концептуальная и реляционная модели данных. Однако, в случае достаточно простой предметной области выделение информационных объектов можно произвести и без функционального анализа. Один из способов такого проектирования структуры реляционной базы данных описан в этом и следующем разделах. В параграфе 5.6 будет рассмотрен другой способ проектирования реляционной структуры, основанный на декомпозиции универсального отношения.
    1   ...   12   13   14   15   16   17   18   19   ...   23


    написать администратору сайта