Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции_ПСОД_2010.doc
Скачиваний:
12
Добавлен:
23.09.2019
Размер:
1.32 Mб
Скачать

Сравнительный анализ sadt моделей и моделей потоков данных

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

С этой точки зрения все разновидности структурного анализа могут быть разбиты на две группы:

  • Использующие методы и технологии DFD (в разных нотациях);

  • Использующие SADT-методологию.

Соотношение этих двух разновидностей структурного анализа в существующих CASE-средствах составляет по некоторым оценкам 90% для DFD и 10% для SADT.

Методология SADT успешно работает только для реорганизации хорошо стандартизированных западных бизнес-процессов, поэтому она и принята на Западе в качестве типовой.

В российской действительности с ее слабой типизацией разумнее ориентироваться на методологию организации и/или реорганизации потоков информации и отношений.

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

4.3.6. Технология проектирования на основе функционально-ориентированного подхода

Технологическая сеть проектирования ИС на основе использования функционально-ориентированной CASE-технологии включает технологические операции с 11-тью этапов.

Этап 1 «Инициализация проекта».

На основании документа «Материалы обследования» создается репозитарий для проектируемой системы.

Этап 2 «Задание начальных параметров проекта».

Выбирается CASE-методология проектирования, а также составляется перечень проектировщиков и их прав доступа к проекту. Результатом выполнения этапа является описание начальных параметров проекта в репозитарии.

Последующие этапы 3, 4, 5 и 6 выполняются последовательно параллельно и взаимно уточняются в ходе выполнения.

Этап 3 «Построение диаграмм иерархии функций (BFD)».

На основе документа «Материалы обследования» строится диаграмма иерархии функций.

На этапе выполняются следующие работы:

  • отображение основной функции;

  • декомпозиция основной функции на подфункции;

  • дальнейшая декомпозиция подфункций до необходимой степени детализации;

  • контроль правильности построенной диаграммы;

Результатом выполнения этапа является описание в репозитарии дерева функций проекта.

Этап 4 «Построение диаграммы потоков данных».

Исходными данными для выполнения этапа являются: материалы обследования и диаграмма иерархии функций.

Построение диаграммы потоков данных сводится к следующим шагам:

  1. Расчленение множества требований на функциональные группы;

  2. Идентификация внешних по отношению к системе объектов;

  3. Идентификация информации, которая передается между процессами;

  4. Разработка контекстной диаграммы;

  5. Формирование DFD первого уровня, где отражены основные функции системы;

  6. Дальнейшая декомпозиция каждого процесса до тех пор, пока процесс самого нижнего уровня можно будет представить в виде некоторой спецификации (алгоритма);

  7. Ревизия всех уровней с целью выяснения некорректности, а при ее обнаружении – устранение.

Выходом данного этапа является описание в депозитарии диаграммы потоков данных.

Этап 5 «Построение диаграммы переходов состояний».

Исходными данными являются:

    • материалы обследования;

    • диаграмма иерархии функций;

    • диаграмма потоков данных.

На этом этапе описываются возможные состояния проектируемой системы и переходы между ними.

Применяются два способа построения STD:

  • Первый способ заключается в том, что выявляются все возможные состояния системы. Далее выявляются переходы из одного состояния в другое;

  • При втором способе сначала строится начальное состояние, затем осуществляется переход в очередное состояние и т.д. (последовательный переход).

Если число состояний и переходов достаточно велико, то эта диаграмма может быть представлена в форме «Матрица переходов состояний».

Текущее

состояние

Условие

перехода

Действие,

связанное

с переходом

Следующее состояние

Список всех Условия перехода Действия, Перечень всех

состояний из текущего которые связаны с последующих

системы состояния конкретным (их состояний

в последующем может и не быть) по отношению

к текущему

Рис. Графы матрицы переходов состояний

Результатом выполнения данного этапа является интегрированное описание в репозитарии функций, потоков данных и состояний проектируемой системы.

Этап 6 «Построение диаграммы «Сущность-связь»».

Для выполнения этапа необходима следующая входная информация;

    • материалы обследования;

    • диаграмма потоков данных.

Построение ER-диаграмм сводится к следующим операциям:

  1. Идентификация всех сущностей и их атрибутов;

  2. Идентификация отношения между сущностями и указание мощностей этих отношений.

Выходом данного этапа является описание в репозитарии диаграммы «сущность-связь».

Этап 7 «Построение системной структурной диаграммы».

Этап используется для построения структуры программного приложения ИС.

Исходными данными этапа являются:

  • Диаграмма иерархии функций;

  • Диаграмма потоков данных;

  • Диаграмма «сущность-связь»;

  • Диаграмма переходов состояний;

Результатом выполнения этапа является описание в репозитарии структуры программного приложения.

Работы по построению системной структурной диаграммы выполняются в следующей последовательности:

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

  2. Взять диаграмму потоков данных (соответствующие уровни DFD) для выделенных функций и подфункций. Проанализировать эти диаграммы с учетом входных и выходных потоков данных.

  3. Определить структуру потоков данных, задав список атрибутов сущностей из ER-диаграммы.

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

  5. Задать программную реализацию каждого состояния в виде библиотечного модуля CASE-системы или модуля, написанного на другом языке.

  6. Нарисовать эскиз системной диаграммы для каждой выделенной функции.

  7. Объединить построенные системные диаграммы в одну исходя из диаграммы бизнес-функций.

  8. Проконтролировать, если позволяют CASE-средства, построенную системную структурную диаграмму.

  9. Если ошибок не найдено, то перейти к прототипированию (макетированию) интерфейса программного приложения на основе системной диаграммы.

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

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

Последующие этапы 8, 9, 10 и 11 технологической цепочки отражают процесс кодогенерации проекта.

Этап 8 «Генерация описания схемы БД».

На основании диаграммы «сущность-связь» и системной структурной диаграммы производится выбор СУБД и генерация для нее описания схемы БД.

Этап 9 «Генерация модуля описания системы БД».

Исходными данными для выполнения этапа являются:

    • описание схемы БД;

    • структура программного приложения;

    • набор языков определения данных (DDL).

В результате процесса генерации получаем исходные тексты программ на выбранном языке.

Генерация может быть двух видов:

  1. Неполная генерация. В результате выполнения неполной генерации на выбранном языке описания данных (SQL и т.п.) создается модуль описания данных;

  2. Полная генерация включает в себя:

    • Генерацию DDL на языке описания данных;

    • Выбор среды, в которой будет приведен исходный код, полученный во время генерации;

    • Запуск процесса генерации.

Этап 10 «Генерация приложения (DDM

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

Этап 11 «Интеграция модулей приложения»

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]