АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ СТРУКТУРНОМ ПОДХОДЕ

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

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

Формальные модели на этапе определения спецификаций - на 2 группы: модели, зависящие от подхода к разработке (структурного или ОО), и модели, не зависящие от него. Диаграммы переходов состояний, которые демонстрируют особенности поведения разрабатываемого ПО при получении тех или иных сигналов извне, и математические модели предметной области используют при любом подходе к разработке. В рамках структурного подхода на этапе анализа и определения спецификаций используют 3 типа моделей: ориентированные на функции, ориентированные на данные и ориентированные на потоки данных. Каждую модель используют для своего класса программных разработок.

Все функциональные спецификации описывают одни и те же характеристики разрабатываемого ПО: перечень функций и состав обрабатываемых данных. Они различаются только системой приоритетов (акцентов), которая используется разработчиком в процессе анализа требований и определения спецификаций. Диаграммы переходов состояний определяют основные аспекты поведения ПО во времени, диаграммы потоков данных – направление и структуру потоков данных; концептуальные диаграммы классов – отношение между основными понятиями предметной области. Так как разные модели описывают проектируемое ПО с разных сторон, рекомендуется использовать сразу несколько моделей и сопровождать их текстами: словарями, описаниями и т.п.

Методологии структурного анализа и проектирования, основанные на моделировании потоков данных, используют комплексное представление проектируемого ПО в виде совокупности моделей: диаграмм потоков данных (DFD – Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе; диаграмм «сущность-связь» (ERD – Entity-Relationship Diagrams), описывающих БД разрабатываемой системы; диаграмм переходов состояний (STD – State Transition Diagrams), характеризующих поведение системы во времени; спецификаций процессов; словаря терминов.

Функциональные диаграммы - диаграммы, отражающие взаимосвязи функций разрабатываемого ПО. Пример - функциональная (активность на я) модель, Д. Россаа в составе методологии функционального моделирования SADT (Structured Analysis and Design Technique - технология структурного анализа и проектирования), 1973 г Методология SADT предполагает, что модель может основываться либо на функциях системы, либо на ее предметах (данных, оборудовании, информации. В обоих случаях используют схожие графические нотации, но в 1 случае блок соответствует функции, во 2 - элементу данных. Эти модели называют активность юными моделями и моделями данных. Полная модель включает построение обеих моделей - дает полное описание ПО, но широко распространены активно устные (функциональные) модели. На основе SADT была построена методология описания сложных систем IDEFO (Icam DEFinition - нотация ICAM) - основная часть программы ICAM (Integrated Computer-Aided Manufacturing - интегрированная компьютеризация производства).

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

Диаграммы потоков данных позволяют специфицировать функции разрабатываемого ПО и обрабатываемые им данные. Систему представляют в виде иерархии диаграмм потоков данных, описывающих асинхронный процесс преобразования информации с момента ввода в систему до выдачи пользователю. На каждом следующем уровне иерархии происходит уточнение процессов, пока очередной процесс не будет признан элементарным. Модели потоков данных были независимо предложены Е. Йорда­ном (1975). затем Ч. Генном и Т. Сарсоном (1979). На этих моделях основаны классические методологии структурного анализа и проектирования ПО - Йордана- Де Марка и Геина-Сарсона. В основе модели лежат понятия внешней сущности, процесса, хранилища (накопителя) данных и потока данных.

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

В 1 группу входят множества и кортежи. Характеристика элемента данных в этих структурах - его принадлежность некоторому набору, т. е. отношение вхождения. Данные абстрактные структуры используют, если никакие другие отношения элементов не являются существенными для описываемых объектов. Во 2 группу относят векторы, матрицы, массивы (многомерные), записи, строки, таблицы, включающие перечисленные структуры в качестве частей. Использование этих абстрактных типов может означать, что существенным является не только вхождение элемента данных в некоторую структуру, но и их порядок, а также отношения иерархии структур, т. е. вхождение структуры в структуру более высокой степени общности В случаях, когда существенны связи элементов данных между собой, в качестве модели структур данных используют графы.

Возможно вложение структур данных разных типов, для их описания могут потребоваться специальные модели. В зависимости от описываемых типов отношений модели структур данных делят на иерархические и сетевые. Иерархические модели - описывают упорядоченные или не упорядоченные отношения вхождения элементов данных в компонент более высокого уровня - множества, таблицы и их комбинации. Это - модель Джексона-Орра, для графического представления которой используют: диаграммы Джексона, предложенные в составе методики проектирования ПО в 1975 г.; скобочные диаграммы Орра, предложенные в составе методики проектирования ПО Варнье-Орра(1974). Сетевые модели основаны на графах, и позволяют описывать связность элементов данных независимо от вида отношения, в том числе комбинации множеств, таблиц и графов. Сетевая модель - модель «сущность-связь» (ER - Entity- Relationship), используемую при разработке БД.

Диаграммы Джексона. В основе - предположение о том, что структуры данных, так же, как и программ, можно строить из элементов с использованием 3 х основных конструкций: последовательности, выбора и повторения. Конструкция представляется в виде двухуровневой иерархии, на верхнем уровне расположен блок конструкции, а на нижнем - блоки элементов.

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

Сетевая модель данных - используют в случа­ях, если отношение между компонента­ ми данных не исчерпываются включени­ем. Для графического представления разновидностей этой модели используют несколько нотаций. Наиболее известны из них следующие: нотация П. Чена; нотация Р. Баркера; нотация IDEF1 (более современный вариант - IDEF1X используется в CASE-системах, например в системе ERWin).

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

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

ПРОЕКТИРОВАНИЕ ПО ПРИ СТРУКТУРНОМ ПОДХОДЕ сущность структурного подхода – декомпозиция ПО по функциональному принципу. Все предлагаемые методы декомпозиции рассчитаны на анализ и проектирование структур данных и обрабатывающих их программ. Первичным считают проектирование обрабатывающих компонентов, проектирование структур данных выполняют параллельно. Альтернативный подход - первичным считают проектирование данных, а обрабатывающие программы получают, анализируя полученные структуры данных. В любом случае проектирование ПО начинают с определения его структуры. Разработка структурной и функциональной схем Процесс проектирования сложного ПО начин­ают с уточнения его структуры, т. е. определения структурных компонентов и связей между ними. Результат уточнения структуры может быть представлен в виде структурной и/или функциональной схем и описания (спецификаций) компонентов.

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

Функциональная схема -или схема данных (ГОСТ ) - схема взаимодействия компонентов ПО с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Используют специальные обозначения (ГОСТ ). Функциональные схемы более информативны. Все компоненты структурных и функциональных схем должны быть описаны. При структурном подходе необходимо тщательно прора­батывать спецификации межпрограммных интерфейсов, так как от качества их описания зависит количество самых дорогостоящих ошибок - ошибок, обнаруживаемых при комплексном тестировании, так как для их устранения могут потребоваться серьезные изменения уже от­лаженных текстов.

Использование метода пошаговой детализации для проектирования структуры ПО Структурный подход к программированию (70-е годы XX в.) предлагал осуществлять декомпозицию программ методом пошаговой детализации. Результатом является структурная схема программы, которая представляет собой многоуровневую иерархическую схему взаимодействия подпрограмм по управлению. Минимально схема отображает 2 уровня иерархии, т. е. показывает общую структуру программы. Этот же метод позволяет получить структурные схемы с большим количеством уровней. Метод пошаговой детализации реализует нисходящий подход и базируется на основных конструкциях структурного программирования. Он предполагает пошаговую разработку алгоритма. Каждый шаг включает разложение функции на подфункции. На 1 этапе описывают решение поставленной задачи, выделяя общие подзадачи, на следующем аналогично описывают решение подзадач, формулируя при этом подзадачи следующего уровня.На каждом шаге происходит уточнение функций проектируемого ПО. Процесс - пока не доходят до подзадач, алгоритмы решения которых очевидны.

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

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

Проектирование ПО, основанное на декомпозиции данных Практически одновременно были предложены методики проектирования ПО Джексона и Варнье-Орра, основанные на декомпозиции данных. Обе методики предназначены для создания «простых» программ, работающих со сложными, но иерархически организованными структурами данных. При необходимости разработки программных систем в обоих случаях предлагается вначале разбить систему на отдельные программы, а затем использовать данные методики. Методика Джексона - структуры исходных данных и результатов определяют структуру программы. Методика основана на поиске соответствий структур исходных данных и результатов. Но при ее применении возможны ситуации, когда на каких-то уровнях соответствия отсутствуют. Например, записи исходного файла сортированы не в том порядке, в котором соответствующие строки должны появляться в отчете. Такие ситуации назвывают «столкновениями». Выделяют несколько типов столкновений, которые разрешают по-разному.

Разработка структуры программы в соответствии с методикой Джексона: строят изображение структур входных и выходных данных; выполняют идентификацию связей обработки (соответствия) между этими данными; формируют структуру программы на основании структур данных и об­наруженных соответствий; добавляют блоки обработки элементов, для которых не обнаружены соответствия; анализируют и обрабатывают несоответствия, т.е. разрешают «столкновения»; добавляют необходимые операции (ввод, вывод, открытие/закрытие файлов и т. п.); записывают программу в структурной нотации (псевдокоде).

Пример: Разработать структуру программы, которая читает записи об успеваемости студентов и формирует список неуспевающих студентов группы.

Методика Варнье-Орра -базируется на том же положении, что и методика Джексона, но основными при построении программы считаются структуры выходных данных и, если структуры входных данных не соответствуют структурам выходных, то их допускается менять. Так ликвидируется основная причина столкновений. На практике не всегда существует возможность пересмотра структур входных данных: эти структуры уже могут быть строго заданы, например, если используются данные, полученные при выполнении других программ, поэтому данную методику применяют реже. Методики Джексона и Варнье-Орра могут использоваться только в том случае, если данные разрабатываемых программ могут быть представлены в виде иерархии или совокупности иерархий.

Контрольные вопросы и задания 1 - Что понимают под структурной и функциональной схемами ПО? В каких случаях их применяют? Чем отличаются структурные и функциональные схемы ПО с различной архитектурой? 2 - На каких свойствах программных систем основан метод пошаговой детализации? Почему с его применением получают только структурные алгоритмы? В чем, по-вашему, заключается основная сложность данного метода? 3 - Как используется метод пошаговой детализации при разработке алгоритмов и структуры ПО? 4 - Используя метод пошаговой детализации, разработайте алгоритм сложения чисел (n, m < 1000), записанных римскими цифрами: I - 1; II - 2; III - 3; IV - 4; V - 5; VI-6; IX-9; X- 10; L-50; С-100; D-500; М Для чего строят структурные карты Константайна? Что положено в основу методик Джексона и Варнье-Орра? Чем различаются данные методики? 6 - Какие вопросы решают при проектировании структур данных? Какие характеристики проектируемых структур при этом учитывают? 7 - Для каких разработок целесообразно использовать структурные методоло­гии?