Структурный подход к разработке программного обеспечения Содержание Модели структурного подхода Проектирование архитектуры ПО помощью 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.