Структурный подход к проектированию ИС. Case - средства разработки ПО.

Структурное проектирование позволяет одновременно сосредотачиваться на меньшем количестве деталей.

Нисходящее проектирование хорошо работает, когда проблема имеет ясно выраженный иерархический характер.

Минусы:

- Трудно поддерживать функциональную точку зрения

- Реальные системы трудно охарактеризовать функционально

- Теряется из виду данные

- Производится код, который плохо подходит для многократного использования

Сущность структурного подхода

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

Все наиболее распространенные методологии структурного подхода [9,11,12,13] базируются на ряде общих принципов [3]. В качестве двух базовых принципов используются следующие:

- принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

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

Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:

- принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;

- принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

- принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

- SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2);

- DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);

- ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь" (подраздел 2.4).

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

 

Методология функционального моделирования SADT. Состав функциональной модели. Иерархия диаграмм. Типы связей между функциями. Примеры функциональных моделей в стандарте IDEF0.

Предложена Дугласом при работе над военными проектами.

На основе SADT разработана методика IDEF0 (для описания предметной области) комитетом ICAM.

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

Основные элементы методологии:

1. блочное моделирование:

- функции - это блоки

- интерфейсы входа/выхода - дуги (стрелки)

2. строгость и точность

Существует определенные правила SADT:

- количество блоков на диаграмме 3-6

- связанность диаграмм (номера блоков)

- уникальность наименования (повторений не д.б.)

- синтаксические правила для блоков и дуг

- разделение входов и управлений

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

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

Состав функциональной модели

Функция - это действие; формулируется в виде глагола в неопред. Форме, либо - отглагольного сущго.

Вход - это информация/ресурсы, подлежащие преобразованию

Управление - это неизменяемые ресурсы/информация, в соответствии с которой выполняются функции. Обычно это законы, нормативные и должностные инструкции ит.д.

Выход - это результат выполнения функции (есть всегда): запросы на ресурсы от других бизнес-процессов, предложение ресурсов, поставка ресурсов под конкретный бизнес-процесс.

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

Признак блокировки

По признаку блокировки ресурсы делятся на:

1. ресурсы, которые не блокируются - ресурсы общего пользования

2. блокируемые - может использоваться только одной функцией в один момент времени (пр.: входы и инструменты).

Иерархия диаграмм

1. контекстная диаграмма

название блока - название всех модели

на диаграмме д.б.:

цель составления работы

точка зрения - должность человека (как min), который строит данную диаграмму, либо со слов которого строится

2. далее след. диаграмма (главная в контекстной диаграмме)

Типы связей между функциями

Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями. Различают по крайней мере семь типов связывания:

Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует

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

2 Связанные по времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.

3 Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса.

4 блоки группируются вследствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные

5 Связь между элементами на диаграмме является более тесной, чем на рассмотренных выше уровнях связок, поскольку моделируются причинно-следственные зависимости

6 Диаграмма отражает полную функциональную связность, при наличии полной зависимости одной функции от другой

Значимость Тип связности Для функций Для данных

0 Случайная Случайная Случайная

1 Логическая Функции одного и того же множества или типа (например, "редактировать все входы") Данные одного и того же множества или типа

2 Временная Функции одного и того же периода времени (например, "операции инициализации") Данные, используемые в каком-либо временном интервале

3 Процедурная Функции, работающие в одной и той же фазе или итерации (например, "первый проход компилятора") Данные, используемые во время одной и той же фазы или итерации

4 Коммуникационнная Функции, использующие одни и те же данные Данные, на которые воздействует одна и та же деятельность

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

6 Функциональная Функции, объединяемые для выполнения одной функции Данные, связанные с одной функцией

Глоссарий

Для каждого элемента IDEF0 существует описание. Все использованное хранится в глоссарии.

Принципы ограничения сложности IDEF0

- Количество функциональных блоков 3-6

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

 

16. Моделирование потоков данных (процессов). Внешние сущности. Системы и подсистемы. Процессы. Накопители данных. Потоки данных. Построение иерархии диаграмм потоков данных.

Ее основой послужила диаграмма Гейна-Сарсона.

Методология позволяет описать асинхронный процесс преобразования информации от ее ввода в систему до выхода пользователю.

Компоненты диаграммы:

1. внешняя сущность

2. системы и подсистемы

3. процесс

4. накопители данных

5. потоки данных

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

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

Пр.: заказчик, клиент, поставщик

Системы и подсистемы(С/ПС)

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

Поле имени формулируется в виде подлежащего и дополнения (нет глаголов)

Процессы

Процессы определяют преобразование входных потоков данных в выходные

Физически это: отдел организации, автоматизированная система, аппаратное устройство и т.д.

Пр. поля физич. реализации: 1С-бухгалтерия

Накопители данных

Это абстрактное устройство для хранения данных.

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

Накопитель данных физически это:

- Ящик в картотеке

- Файл на магнитном носителе, Таблица в бД и т.д.

Накопитель данных для проектировщика является прообразом будущей БД.

Потоки данных

Информация, передаваемая ч/з некоторое соединение от источника к приемнику.

Каждый поток данных должен иметь имя.

Построение иерархии диаграмм потоков данных

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

Правила детализации:

a. Правило балансировки

На детализирующей диаграмме внешние источники/приемники данных - это

только те компоненты, которые присутствуют на родительской диаграмме.

b. Правило нумерации - иерархическая нумерация.

Миниспецификация - это описание логики процесса.

Должна формулировать основные функции таким образом, чтобы специалист, выполняющий реализацию проекта, смог их выполнить или написать программу. Обычно состоит из 20-30 строк.

Для создания миниспецификации у DFD д.б. не более 2-3 потоков, описание которых не более 30 строк.