Тема6 Структурное проектирование ПО

Структурный подход к
разработке программного
обеспечения
Содержание

Модели структурного подхода

Проектирование архитектуры ПО помощью
DFD-моделей
Структурная схема

Проектирование спецификаций

Словарь терминов

Диаграмма переходов состояний

Литература

Основные подходы к
разработке ПО


Функционально-модульный или структурный. В
его основу положен принцип функциональней
декомпозиции, при которой структура системы
описывается в терминах иерархии ее функций и
передачи информации между отдельными
функциональными элементами.
Объектно-ориентированный подход использует
объектную декомпозицию. При этом структура системы
описывается в терминах объектов и связей между ними,
а поведение системы описывается в терминах обмена
сообщениями между объектами.
СТРУКТУРНЫЙ ПОДХОД К
ПРОЕКТИРОВАНИЮ
ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
ПРОБЛЕМА СЛОЖНОСТИ
БОЛЬШИХ СИСТЕМ
Основные понятия

При проектированию сложной
программной системы ее необходимо
разделять (декомпозировать) на
небольшие подсистемы, каждую из
которых можно разрабатывать независимо
от других.
Основные понятия
Правила декомпозиции:
 Количество связей между
отдельными подсистемами должно
быть минимальным;
 Связность отдельных частей внутри
каждой подсистемы должна быть
максимальной.
Структурный подход предполагает
использование следующих моделей


:
DFD(Data Flow Diagrams) - диаграммы потоков
данных;
SADT(Structured Analysis and Design technique) модели и соответствующие функциональные
диаграммы;

STD (State Transition
переходов состояний;
Diagrams)
-
диаграммы

ERD (Entity-Relationship Diagrams) диаграммы
"сущность-связь«

спецификаций процессов;

словаря данных.
Применение моделей


На стадии формирования требований к ПО SADT, ERD и DFD
используются для построения модели "AS-IS" и модели "ТО-ВE“
Модели SADT и DFD отражают существующую и предлагаемую
структуру бизнес-процессов организации и взаимодействие между
ними.

С помощью ERD выполняется описание используемых в организации
данных на концептуальном уровне.

На стадии проектирования DFD используются для описания

На стадии проектирования ERD уточняются и дополняются новыми
архитектуры проектируемой системы ПО, при этом они могут
уточняться, расширяться и дополняться новыми конструкциями.
конструкциями, описывающими представление данных на
логическом уровне.
СТРУКТУРНЫЙ ПОДХОД К
ПРОЕКТИРОВАНИЮ ПО
МОДЕЛИРОВАНИЕ ПОТОКОВ
ДАННЫХ (ПРОЦЕССОВ)
ОБЩИЕ СВЕДЕНИЙ



Диаграммы потоков данных (DFD) используются для
описания архитектуры проектируемой системы ПО.
Диаграммы потоков данных (DFD) являются основным
средством моделирования функциональных требований
проектируемой системе. С их помощью эти требования
представляются в виде иерархии функциональных
компонентов (процессов), связанных потоками данных.
Главная цель представления (DFD) —
продемонстрировать, как каждый процесс преобразует
свои входные данные в выходные, а также выявить
отношения между этими процессами.
Порядок построения


Первым шагом при построении иерархии DFD
является построение контекстной диаграммы.
Для простых систем строится единственная
контекстная диаграмма со звездообразной
топологией, в центре которой находится
главный процесс, соединенный с приемниками
и источниками информации, посредством
которых с системой взаимодействуют
пользователи и другие внешние системы.
Порядок построения

Для сложных систем контекстная
диаграмма верхнего уровня содержит не
единственный главный процесс
(система), а набор подсистем,
соединенных потоками данных.
Порядок построения


Построение диаграмм первого уровня как
декомпозиция системы (подсистем),
которые присутствует на контекстной
диаграмме.
Каждое, событие представляется в виде
процесса с соответствующими входными и
выходными потоками, накопителями
данных, внешними сущностями и ссылками
на другие процессы для описания связей
между этим процессом и его окружением.
Порядок построения


Построение иерархии DFD, которая
заключается в декомпозиции
процессов более высокого уровня в
диаграммы нижнего уровня.
Каждый процесс на DFD, в свою
очередь, может быть детализирован
при помощи DFD или (если процесс
элементарный) спецификации.
При детализации должны
выполняться следующие правила:


правило балансировки - при детализации подсистемы
или процесса детализирующая диаграмма в качестве
внешних источников или приемников данных может
иметь только те компоненты (подсистемы, процессы,
внешние сущности, накопители данных), с которыми
имеют информационную связь детализируемые
подсистема или процесс на родительской диаграмме;
правило нумерации - при детализации процессов
должна поддерживаться их иерархическая
нумерация. Например, процессы, детализирующие
процесс с номером 12, получают 12.1, 12.2, 12.З и
т.д.
Порядок построения


Процесс декомпозиции продолжается до
тех пор, пока процессы могут быть
эффективно описаны с помощью коротких
спецификаций процессов.
Спецификация процесса должна
формулировать основные функции
процесса таким образом, чтобы в
дальнейшем специалист, выполняющий
реализацию проекта, смог выполнить их
или разработать соответствующую
программу.
Решение о завершении детализации процесса и
использовании спецификации принимается исходя
из следующих критериев:




наличия у процесса относительно небольшого
количества входных и выходных потоков данных (2 - 3
потока);
возможности описания преобразования данных
процессом в виде последовательного алгоритма;
выполнения процессом единственной логической
функции преобразования входной информации в
выходную;
возможности описания логики процесса при помощи
спецификации небольшого объема (не более 20 — 30
строк).
Спецификации должны удовлетворять
следующим требованиям:





для каждого процесса нижнего уровня должна
существовать одна и только одна спецификация;
спецификация должна определять способ
преобразования входных потоков в выходные;
нет необходимости определять метод реализации этого
преобразования;
спецификация должна стремиться к ограничению
избыточности - не следует переопределять то, что уже
было определено на диаграмме;
набор конструкций для построения спецификаций
должен быть простым и понятным.
Спецификации


Спецификации представляют собой описания
алгоритмов задач, выполняемых процессами.
Спецификации содержат номер и/или имя
процесса, списки входных и выходных данных
и тело (описание) процесса, являющееся
спецификацией алгоритма или операции,
трансформирующей входные потоки данных в
выходные.
Порядок построения



После построения законченной модели системы
ее необходимо верифицировать (проверить на
полноту и согласованность).
В полной модели все ее объекты (подсистемы,
процессы, потоки данных) должны быть подробно
описаны и детализированы.
В согласованной модели для всех потоков данных и
накопителей должно выполняться правило сохранения
информации: все поступающие куда-либо данные
должны быть считаны, а все считываемые данные
должны быть записаны.
Структурная схема


это схема, отражающая состав и
взаимодействие по управлению
частей разрабатываемого ПО
определяется архитектурой
разрабатываемого ПО
Компоненты структурной
схемы





Программы
Подсистемы
Формы
Базы данных
Библиотеки ресурсов
Диспетчер
Блок решения
Блок вывода результатаа
Структурная схема
Решение задачи
Ввод и накопление
данных
Поиск
данных
База
данных
Ввод данных
Редактирование
данных
Оформление
сделки
Формирование
отчетных
документов
Структурная схема
Структурная схема
Пример
Пример
БД
Головной модуль
Спецификация

Спецификация программного модуля
состоит из функциональной спецификации
модуля, описывающей семантику функций,
выполняемых этим модулем по каждому из
его входов, и синтаксической
спецификации его входов, позволяющей
построить на используемом языке
программирования синтаксически
правильное обращение к нему.
Спецификации программного
модуля





Псевдокод
Блок-схема алгоритма
Flow - форма
Диаграмма Насси-Шнейдермана
Краткое текстовое описание
Псевдокод
Структура
Псевдокод
Структура
Псевдокод
<Действие 1>
< Действие 2>
Выбор
Выбор <код>
< код 1>:< Действие 1 >
< код 2>:< Действие 2 >
…
Все-выбор
Ветвление
Если <Условие>
то < Действие 1 >
иначе < Действие 2 >
Все-если
Цикл с
Для <индекс>=
заданным
<n>,<k>,<h>,
количеств- < Действие>
ом
Все-цикл
повторений
Цикл-пока
Цикл-пока< Условие >
< Действие 1 >
Все цикл
Цикл-до
Следование
Выполнять
< Действие>
До < Условие >
Псевдокод
Процесс: Проверка и внесение данных о
клиенте
Вход: Информация о клиенте по его звонку
Выход: Формирование данных о клиенте в
БД
Алгоритм:
1. Проверить в накопителе наличие данных о
клиенте
2 . Если данные отсутствуют ТО
внести новую запись о клиенте в БД
3. Вывести данные о клиенте на экран
Псевдокод












Процесс: Формирование заказа
Вход: Данные о клиенте, Данные о продуктах
Выход: Заказ
Алгоритм:
1.
Открыть форму для формирования заказа
2.
Открыть таблицу со списком продукции
3.
Внести данные в проект заказа
4.
Произвести расчет услуг по заказу
5.
Вывести на экран проект заказа
6.
ЕСЛИ формирование заказа незакончено
ТО
6.1.
Произвести его корректировку
7.
Вернуться к пункту 4
Схемы алгоритмов
(ГОСТ 19.702-90)
Название
Терминатор
Процесс
Данные
Решение
Подготовка
Обозначение Назначение
Действие
Начало, завершение
программы или
подпрограммы
Обработка данных
Действие
Операции ввода-вывода
Данные
Условие
Ветвление, выбор,
поисковые и
итерационные процессы
Счетные циклы
Подготовка
Схемы алгоритмов
Название
Обозначение
Назначение
Граница цикла
Любые циклы
Предопределенный
процесс
Выбор процедуры
Соединитель
Комментарий
Имя
Имя
Комментарий
Маркировка разрыва
линий
Пояснение к
операциям
Flow - форма
Следование
<Действие 1>
<Действие 2>
<Действие 3>
Flow - форма
Ветвление
Если <Условие>
то
<Действие 1>
иначе
<Действие 2>
Диаграмма НассиШнейдермана
Ветвление
Да
<Действие 1>
Нет
<Действие 2>
Flow - форма
Цикл - до
Пока <Условие>
<Действие >
Словарь терминов


Термин
Словарь терминов представляет
собой краткое описание основных
понятий, используемых при
составлении спецификации
Описание терминов в словаре
содержит
Категория (понятие предметной
области, элемент данных, условное
обозначение и т.п.)
Краткое
описание
Методология проектирования
ПО на основе DFD
Система
Процесс
Спецификация
процесса
Накопитель
Словарь
терминов
Диаграмма
«сущностьсвязь»
Функциональная схема
(технологическая)

Это схема взаимодействия
компонентов ПО с описанием
информационных потоков, состава
данных в потоках и указанием
используемых файлов и устройств
Функциональная схема (ГОСТ 19.702-90)
Название
Обозначение
Назначение
Сохранение
данных
Для структур данных, которые
должны быть сохранены без
уточнения типа устройств
ОЗУ
Для обозначения структур данных,
хранящихся в ОП
ЗУ с прямым
доступом
Документ
Для обозначения структур данных,
хранящихся на магнитных дисках
Ручной ввод
Для обозначения ручного ввода
данных с клавиатуры
Дисплей
Для обозначения данных, выводимых
на дисплей компьютера
Ручная
операция
Для обозначения любого процесса,
выполняемого человеком
Для обозначения структур данных,
выводимых на печать
Диаграммы переходов
состояний (STD)

Демонстрирует поведение
разрабатываемой программной
системы при получении управляющих
воздействий (извне)
Узел

Соответствуют состоянию
динамической системы
Имя состояния
Промежуточное
состояние
Терминальное состояние
Дуга

Соответствует переходу системы из
одного состояния в другое
Условие
Действие
Диаграмма переходов
состояния программы
Исходное
состояние
Состояние
завершения
Ввод
Инициализация
Вывод
Вычисление
Завершение
Диаграмма переходов состояния
торгового аппарата
Ожидание
монеты
«Товар доступен»=НЕТ
«Выдать монеты»
Ожидание
выбора
товара
Выдача
товара
Обнаружена
монета
«Оплата
достаточна»
«Выдать
сдачу»
«Оплата достаточна»
«Выдать товар»
Литература
1. Гусятников
В.Н.,
Безруков
А.И.
Стандартизация и разработка программных
систем. - М: Финансы и статистика, 2010.
2.
Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д.
Технология разработки программного
обеспечения.- М: ИД «ФОРУМ»: ИНФРА-М,
2008.
3.
Благодатских В.А., Волнин В.А., Поскакалов
К.Ф. Стандартизация разработки
программных средств. – М: Финансы и
статистика, 2003.