4.5.7. Применение технологий разработки программного обеспечения к разработке экспертных систем
4.5.7.1. Основные принципы реализации и проектирования ПО
Проектирование – составление формальных или формализованных спецификаций.
Реализация – преобразование (в частности, автоматическое или автоматизированное) этих спецификаций в программный код.
Сопровождение – тестирование разработанной системы, ее внедрение и последующая модификация (в том числе с возвратом в стадию проектирования).
Для того, чтобы преодолеть разрушающий эффект изменений требований в процессе разработки, должны обеспечиваться основные свойства программных систем:
Модифицируемость. Модификация ПО может выполняться по причине необходимости исправления ошибок или необходимости отражения в системе изменений требований.
Эффективность системы подразумевает оптимальное использование ею ресурсов (аппаратных и временных).
Надежность системы предполагает, что она должна предотвращать ошибки концепции, проектирования и реализации, ошибки, возникающие в процессе ее функционирования.
Понимаемость – «прозрачность» с точки зрения предметной области.
Достижение этих целей (свойств) обеспечивается выполнением следующих принципов:
абстракции;
модульности;
сокрытия информации;
локализации;
единообразия;
полноты;
подтверждаемости.
Абстракция – выделение существенных свойств с игнорированием несущественных деталей. По мере декомпозиции решения на компоненты каждая из них становится частью абстракции на соответствующем уровне.
Сокрытие информации имеет целью сделать недоступными детали, которые могут повлиять на остальные, более существенные части системы. Сокрытие проектных решений нижнего уровня (реализации объектов или операций) оберегает стратегию принятия решений верхнего уровня от влияния деталей.
Абстракция и сокрытие информации способствуют модифицируемости и понимаемости систем ПО. На каждом уровне абстракции допускается применение лишь определенного набора операций и не допускается применение любых операций, нарушающих логическую концепцию данного уровня, за счет чего повышается надежность программной системы.
Модульность оценивается в критериях связности (взаимной зависимости модулей) и прочности (связности элементов внутри модуля). Модули могут быть функциональными (процедурно-ориентированными) и декларативными (объектно-ориентированными).
Принципы единообразия, полноты и подтверждаемости гарантируют получение согласованных и правильных систем.
Основные теоретические подходы к разработке ПО:
нисходящее структурное проектирование (Йордан);
проектирование, структурированное по данным (Джексон);
объектно-ориентированное проектирование (Буч).
Нисходящее структурное проектирование заключается в декомпозиции функций системы и получении таким образом иерархии функциональных модулей.
Проектирование, структурированное по данным, заключается в декомпозиции данных и определении их структур, а затем, на их основе, разработке программных модулей.
Объектно-ориентированное проектирование является сбалансированным решением, избавленным от недостатков этих двух подходов.
Базисными понятиями при автоматизации проектирования программных комплексов являются модель программы и модель системы.
4.5.7.2. Методологии проектирования ПО
W/O-методология – методология Вернира-Орра (Warnier/Orr)
Объединяет методологию Вернира по использованию логических структур данных и логических конструкций программ и систем и методологию Орра DSSD (Data Structured System Development). Методология Орра базируется на аксиоме о логическом соответствии между эвристической структурой программ и обрабатываемых ими данных. На практике такая методология предполагает, что в распоряжении проектировщика имеется представительный набор процедурных шаблонов для достаточно широкого класса программируемых задач.
В настоящее время DSSD-методология переросла из методологии разработки программ в методологию разработки систем. В рамках ее выделены явно уровень программирования (programming level) и системный уровень (system level). Применяются два концептуальных представления – диаграммы входов (Entity Diagrams), обеспечивающие определение системного контекста, и модифицированные W/O-диаграммы (Assembly-line Diagrams), специфицирующие функциональное развитие системы.
Логическое моделирование Гэйна
Метод ориентирован на создание систем обработки данных. Логическая модель системы проектируется в семь этапов:
Описание предметной области с помощью диаграмм потоков данных (DFD – Data Flow Diagram).
Выделение первичной модели данных (списка элементов данных в каждом информационном узле).
Проверка структуры данных в DFD.
Сведение полученной на предыдущих этапах информации в двумерные таблицы.
Коррекция DFD с учетом результатов нормализации предыдущего этапа.
Разбиение полученной в результате выполнения предыдущих этапов модели на «процедурные единицы» (procedure units).
Определение деталей каждой процедурной единицы.
После выполнения этих этапов принимается решение о необходимости прототипирования системы на целевом языке.
Метод Йордана
Ориентирован на проектирование систем обработки данных. Включает два компонента: инструментальные средства и методики. Под инструментальными средствами здесь понимаются различные диаграммы, используемые при описании моделей требований и моделей архитектуры ИС. Недостатком DFD является отсутствие средств описания отношений между данными и их «поведения» во времени. Поэтому в состав инструментальных средств Йордана, кроме DFD, включены диаграммы «сущность-связь» (ERD – Entity Relationship Diagram) и диаграммы переходов (STD – State Transition Diagram).
Метод Йордана позволяет получить хорошо организованную системную модель на традиционном нисходящем (top-down) моделировании. Однако в настоящее время здесь используется метод событийного разбиения (event partitioning).При этом сначала создается контекстная диаграмма верхнего уровня (top level context diagram), где определяются системные ограничения и интерфейсы с внешним «миром». Затем с помощью техники интервью формируется список событий из внешней среды, на которые система должна реагировать. Такой подход обеспечивает простой базис для формирования «сырой» DFD. Несколько DFD-реакций могут быть объединены в реакцию более высокого уровня. Критерием такого объединения является наличие узлов, связанных общими данными. Событийное разбиение есть метод объектно-ориентированного проектирования.
Проблемы метода ERD связаны с трудностями интеграции компонентов. Этот метод был обобщен за счет введения интегрированной БД. При этом ERD-метод трансформируется в структурную методологию, основные этапы которой сводятся к разработке ERD, определению кардинальности – однозначности-многозначности типов связей, преобразованию ERD по определенным правилам в соответствующий файл и структуру БД. В процессе такого преобразования каждый тип сущности трансформируется в отношение, а тип связи – в особое отношение или объединяется с другими отношениями в зависимости от кардинальности типа связи. На основе сформированного файла и структуры БД производится разработка прикладного ПО.
Структурное проектирование Йордана
Мощный и активно используемый подход, использующий оценки результатов проектирования. Предлагается все проектные решения располагать в трехмерном пространстве «содержание-сложность-связность». Хорошие проектные решения при заданном содержании имеют минимальную сложность и максимальную связность. Пример структурного подхода – «водопадная» или «каскадная» (waterfall) модель разработки систем ПО.
Спиральная модель процесса разработки Боэма.
Суть – отдельные фазы процесса прокручиваются на постепенно повышающихся уровнях иерархии. Такая модель предполагает наличие более гибких механизмов взаимодействия между потребителями и разработчиками и соответствующих инструментальных средств.
Методология Шлайера-Мэллора
Относится к спиральным моделям. В рамках данного подхода проектирование рассматривается как процесс, протекающий в пространстве трех измерений «статика-динамика-алгоритмы». Указанные измерения обходятся последовательно в течение следующих стадий:
Вдоль оси «Статика»: идентификация и описание объектов, атрибутов и отношений.
От оси «Статика» к оси «Динамика»: описание поведения каждого объекта в качестве реакции на внешние факторы и формирование жизненных циклов объектов.
От оси «Динамика» к оси «Алгоритмы»: проектирование алгоритмов, специфицированных на предыдущей стадии.
От оси «Алгоритмы» к оси «Статика»: валидация спроектированной системы на полноту и функциональное соответствие исходной задаче.
4.5.7.3. Инструментальные средства поддержки разработки систем ПО
В общей структуре типовой технологической системы поддержки разработки обычно выделяют:
БД проекта;
подсистему автоматизации проектирования и программирования;
подсистему отладки;
подсистему документирования и сопровождения;
подсистему управления ходом выполнения проекта.
Проект Gandalf
Аспекты поддержки проектирования ПО:
Управление проектом.
Контроль версий.
Инкрементное программирование.
Разрабатываемый проект трактуется как множество абстрактных типов данных, над которыми могут выполняться лишь определенные операции.
В результате проекта появилась система SDC (Software Development Control).
Проект FAFOS
Исследования в области контроля версий были начаты Л.Коопридером на безе проекта FAFOS (нач. 1970-х г.г.), где изначально анализировались возможности создания семейства операционных систем. Была разработана нотация для описания взаимодействий между подсистемами, для описания различных версий подсистем, для описания действующих на этапе разработки механизмов (компиляции, редактирования связей и т.п.).Был создан специальный язык Intercol как средство описания взаимосвязей и версий модулей в системе. В систему были встроены знания о том, как конструировать систему из частей. Была создана система SUCE, в которой отслеживались различия между реализациями (версиями, которые действительно дают код для ряда спецификаций) и композициями (версиями, определяющими новые подсистемы как группы существующих подсистем).
Система LOIPE (Language-Oriented Incremental Programming Environment)
Пользовательский интерфейс базируется на подсистеме синтаксически-ориентированного редактирования ALOE (A Language-Oriented Editor).
CASE-технология (Computer Aided Software Engineering)
Ранние CASE-системы поддерживали проектирование информационных потоков. Сейчас наблюдается отход от ориентации на системы обработки данных, и CASE-средства становятся все более универсальными.
Разновидности CASE-средств: CASE-ToolKit и CASE-WorkBench.
CASE-ToolKit – коллекция интегрированных программных средств обеспечивающих автоматическое ассистирование в решении задач одного типа в процессе создания программ.
Синонимы: пакеты разработчика, технологические пакеты, инструментальные сундучки.
Используют общее хранилище всей технической и управляющей информации по проекту (репозиторий), имеют общий интерфейс с пользователем и унифицированные интерфейсы между отдельными инструментами пакета. Как правило, концентрируются вокруг поддержки разработки одной фазы производства программ или на одном типе прикладных задач.
CASE-WorkBench – средства реализации замкнутого производственного цикла разработки, реализации и сопровождения ПО.
Синонимы: технологические линии (станки) для производства программ.
Обеспечивают автоматизированную поддержку анализа решаемых задач по производству ПО, которая базируется на общих предположениях о процессе и технологии такой деятельности, автоматическую передачу результатов работы от одного этапа к другому.
Функциональные возможности CASE-средств:
