Программная инженерия. Часть 4.

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

Если проектные решения упорядочены только по времени, то для исправления ошибки требуется как минимум повторное рассмотрение всех решений, расположенных между моментами совершения и обнаружения ошибки. Это приводит к нелинейному и даже комбинаторному росту объема работы при удлинении необходимой для ее выполнения цепочки проектных решений. Достаточно сложные проекты могут навсегда остаться незавершенными.

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

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

Детализация абстрактных понятий завершается их отображением на понятия объектной машины (это может быть и виртуальная машина, например ЛИСП-машина, АДА-машина и т.д.), поэтому построенная структура в целом является не деревом, а ориентированным графом без циклов, который по аналогии с дельтами рек называют также «рекоподобным» графом. Развитие проекта может вестись как «сверху вниз» (от постановки задачи к объектной машине), так и «снизу вверх». В обоих случаях локальная правильность каждого шага детализации обеспечивает корректность процесса разработки ПО, но не гарантирует от ошибок в выборе целей и от попадания в тупиковые ситуации. Например, при движении «сверху вниз» имеется опасность получить понятие, не реализуемое на объектной машине, а при движении «снизу вверх» — отклониться от постановки задачи. Как правило, оптимальной является некоторая смешанная стратегия проектирования, выбор которой зависит от постановки задачи и доступных средств ее решения. Вряд ли стоит применять чистое проектирование «сверху вниз», если требуется предельная эффективность, а состав реализуемых функций может уточняться разработчиком (типичная ситуация для пакетов прикладных программ).

Количество решений, подлежащих пересмотру при обнаружении ошибки, зависит от применяемых правил видимости имен. Оно минимально при жесткой дисциплине — понятие «видно» на один узел вверх или вниз. Но жесткий подход непрактичен; если понятие почти нигде нельзя использовать, то не окупятся затраты на его введение. С другой стороны, чем дальше видны понятия, тем больше переделок в случае их ошибочности. Необходим компромисс. Сейчас концепцию видимости имен составляют идея необходимости управления видимостью и ряд конкретных методов, таких, как:

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

Часто для понятий объектной машины определяются отдельные правила видимости. Например, в языках CDL и CDL2 реализована концепция «открытости снизу» — понятия объектной машины отделены от средств понижения уровня абстрактности (фактически удалены из языка) и могут использоваться («видны») только на самых нижних уровнях графа проекта.