Structured Analysis and Design Technique Введение

План лекции

Лекция 3 Моделирование функций ПО. Нотация IDEF0. CASE-средство BPWin

Заключение

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

На протяжении первых трех фаз (стадия разработки) закладываются характеристики качества будущего ПИ, проявляющиеся на стадии его эксплуатации. Этот факт можно проиллюстрировать таблицей 1, отражающей распределение трудозатрат по этапам ЖЦ ПО.

Таблица 1 - Распределение трудозатрат по этапам ЖЦ ПО

Способ разработки	Анализ	Проекти-рование	Коди-рование	Тести-рование
Традиционная разработка	20%	15%	20%	45%
Использование структурных методологий	30%	30%	15%	25%
Использование CASE-технологий	40%	40%	5%	15%

· История возникновения и развития подходов, связанных с графическим моделированием деятельности.

· Подход к моделированию функциональности систем Structured Analisys and Desig Technique (SADT).

· Семейство стандартов IDEF.

· Стандарт IDEF0.

· Графические символы стандарта.

· Виды связей.

· Правила декомпозиции.

Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отражает структуру функций объекта (производимых им действий) и связи между этими действиями.

В основу методологии положены следующие концепции:

· Моделируемая система рассматривается как произвольное подмножество Вселенной;

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

Ø Вход (нечто перерабатываемое системой);

Ø Выход (результат деятельности системы);

Ø Управление (стратегии и процедуры, под управлением которых производится работа);

Ø Механизм (ресурсы, необходимые для проведения работы).

· Находясь под управлением, система преобразует входы в выходы с использованием механизмов.

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

· Строгость и точность. Правила SADT включают:

Ø Ограничение числа блоков на каждой диаграмме (2 – 8 блоков).

Ø Связность диаграмм (структурная нумерация блоков).

Ø Уникальность меток и наименований.

Ø Синтаксические правила для графики (блоков и дуг).

Ø Разделение входов и управлений (определение роли данных).

· Отделение организации от функции, то есть исключение влияния организационной структуры на функциональную модель.

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

Перед построением модели следует определить область моделирования (Scope), которая включает в себя позицию, с которой рассматривается система (View Point) и цель моделирования (Purpose). При описании области моделирования ее следует ограничить по широте (решить, что входит контекст системы, а что останется за ним) и по глубине (решить, на каком уровне детализации модель будет завершена).

Цель моделирования. Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на вопросы:

· Почему эту систему надо моделировать?

· Что должна показывать модель?

· Что может получить читатель от модели?

Формулировка цели позволяет аналитикам сфокусировать усилия в нужном направлении. Примеры целей: «Идентифицировать роли и ответственность служащих для написания должностных инструкций», «Описать деятельность предприятия с целью создания спецификации информационной системы».

Точка зрения. Несмотря на то, что при моделировании системы учитываются мнения различных людей, модель должна строиться, исходя из единой точки зрения. Точка зрения может быть представлена как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Точка зрения различных, участвующих в работе специалистов (например, финансистов и технологов) может быть различной, поэтому важно в процессе моделирования оставаться на единой точке зрения. Как правило, выбирается точка зрения лица, ответственного за моделируемую работу в целом. Если при выборе точки зрения необходимо задокументировать дополнительные альтернативные точки зрения, для этого используется диаграмма FEO (For Exposition Only).

Модели As-Is и To-Be. Модель As-Is – описание существующего положения дел в организации (системе). Модель To-Be строится для анализа альтернативных путей выполнения работ и документирования того, как система будет функционировать в будущем.

При разработке информационных систем принято использовать следующую последовательность работ:

1 Создание модели As-Is.

2 Ее анализ и улучшение бизнес-процессов (создание модели To-Be).

3 На основе модели To-Be – построение модели данных, прототипов и окончательных версий информационной системы.

Если различие между As-Is и To-Be велико и процесс перехода между ними неочевиден, то кроме As-Is и To-Be, строится третья модель, изображающая такой процесс.

Дата добавления: 2014-01-07