Модели процесса разработки ПО

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

В литературе существует множество нареканий на несовершенство данного раз­биения [Липаев и др., 1983], но смысл его в целом достаточно ясен - борьба со сложностью процесса разработки программных продуктов за счет структуриза­ции этапов и локализации на каждом из них только тех задач, которые могут и должны решаться именно здесь. Если перечисленные выше этапы укрупнить, останутся стадии проектирования, реализации и сопровождения.

Проектирование предполагает составление формальных и/или формализован­ных спецификаций.

Реализация - преобразование этих спецификаций в программный код (автома­тическое и/или автоматизированное).

Сопровождение - тестирование разработанной системы, ее внедрение и последу­ющую модификацию, которая, в свою очередь, может вернуть весь процесс к ста­дии проектирования (перепроектирование).

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

Существуют различные подходы к разработке таких моделей [Миллс, 1970]. Однако с точки зрения целей настоящей книги нас будут интересовать, в первую очередь, те из них, которые имеют непосредственное продолжение в инструмен­тальных средствах и интегрированных инструментальных средах. Поэтому ниже основное внимание будет уделено моделям программ, которые использу­ются в так называемых WorkBench-системах (наиболее близким по семантике к этому термину является словосочетание «станок для производства ПО»).

Одну из таких моделей предлагает W/O (Warnier/Orr) методология [Оrr et al., 1977]. Она объединяет методологию Warmer по использованию логических структур данных и логических конструкций программ и систем и методологию DSSD (Data Structured System Development) Oppa, базисом которой является аксиома о логическом соответствии между эвристической структурой программ и данных, обрабатываемых этими программами. На практике такая методология предполагает, что в распоряжении проектировщика системы имеется представи­тельный набор процедурных шаблонов для достаточно широкого класса програм­мируемых задач.

В настоящее время DSSD-методология «переросла» из методологии разработки программ в методологию разработки систем. При этом выделены явно уровень программирования (programming level) и системный уровень (system level). Применяются в DSSD два концептуальных представления - диаграммы входов (Entity diagrams), обеспечивающие определение системного контекста, и моди­фицированные W/O-диаграммы (Assembly-line Diagrams), специфицирующие функциональное развитие системы [McClure, 1979].

Следующим подходом к созданию моделей программ (по идее достаточно близ­ким к W/O-методологии) является логическое моделирование Гэйна [Cane et al., 1979]. Сам метод ориентирован на создание систем обработки данных. Логичес­кая модель системы проектируется в процессе последовательного применения следующих семи этапов: описание природы предметной области с помощью диа­грамм потоков данных (Data Flow Diagram); выделение первичной модели дан­ных (списка элементов данных в каждом информационном узле); проверка того, что DFD действительно отражает структуру данных, хранимых в системе; сведе­ние полученной на предыдущем этапе информации в двумерные таблицы, кото­рые в дальнейшем нормализуются; коррекция DFD с учетом результатов норма­лизации предыдущего этапа; разбиение полученной в результате выполнения предыдущих этапов модели на «процедурные единицы» (procedure units), а так­же определение деталей каждой процедурной единицы. После выполнения этих этапов принимается решение о необходимости прототипирования системы на целевом языке.

И, наконец, третьим в ряду подходов к созданию модели проектируемой про­граммы является метод Йордана (Yourdon) [Yourdon et al., 1979; Yourdon, 1989]. Он включает два компонента: инструментальные средства и методики. Ориенти­рована методология Йордана на проектирование систем обработки данных. Под инструментальными средствами здесь понимаются различные диаграммы, ис­пользуемые при описании моделей требований и моделей архитектуры проекти­руемой информационной системы. Самые известные из таких диаграмм - диа­граммы потоков данных DFD. Однако их недостатком является отсутствие средств описания отношений между данными и их «поведения» во времени. Вот почему в инструментальные средства метода Йордана на сегодняшний день кро­ме DFD включены ERD-диаграммы (Entity Relationship Diagrams) и STD-диаграммы (State Transition Diagrams).

Методики в методе Йордана помогают перейти от бланка на бумаге и/или экран­ной формы к хорошо организованной системной модели. Первоначально эти ме­тодики базировались на традиционном top-down проектировании. В настоящее времяздесь используется метод событийного разбиения (event partitioning). При этом сначала создается контекстная диаграмма верхнего уровня (top level context diagram), где определяются системные ограничения и интерфейсы с внешним «миром». Затем с помощью техники интервью формируется список событий из внешней среды, на которые система должна реагировать. Такой подход обеспечи­вает простой базис для формирования «сырой» DFD. Несколько DFD-реакций могут быть объединены в реакцию более высокого уровня. Критерием такого объединения является наличие узлов, связанных общими данными. По существу, событийное разбиение не что иное, как метод объектно-ориентированного проек­тирования.

Проблемы, возникающие при использовании метода ERD-диаграмм, связаны, прежде всего, с трудностями интеграции компонентов при разработке всей систе­мы. Вот почему в последнее время этот метод был обобщен за счет введения ин­тегрированной базы данных. При этом ERD-метод трансформируется в струк­турную методологию, основные этапы которой сводятся к разработке ERD (здесь выделяются как собственно сущности с их типами, так и связи, тоже с их типами); определению кардинальности (cardianality) - однозначности-много­значности типов связей; преобразованию ERD по определенным правилам в со­ответствующий файл и структуру БД. В процессе такого преобразования каж­дый тип сущности трансформируется в отношение, а тип связи - в особое (stand alone) отношение или объединяется с другими отношениями в зависимости от кардинальности типа связи. Разработка прикладных программ на основе сфор­мированного файла и структуры базы данных является заключительным этапом в этом подходе.

Последним методом, который кратко рассматривается в данном подразделе, яв­ляется метод структурного проектирования (Structured Design) [Yourdon et al., 1979]. Структурное проектирование сделалось действительно мощным и активно используемым на практике подходом за счет того, что к моделям и методам были добавлены оценки результатов проектирования. Здесь предлагаются все проект­ные решения располагать в 3-мерном пространстве (содержание - сложность - связность). И утверждается, что хорошими проектными решениями будут лишь те, которые при заданном содержании имеют минимальную сложность и макси­мальную связность. По существу, этот критерий отражает уже обсуждавшиеся выше понятия абстрагируемости, модульности, сокрытия информации, связнос­ти и т. п. Конкретным примером воплощения структурного подхода является «водопадная» или «каскадная» (waterfall) модель разработки систем ПО [Balzer et al., 1983].

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

В качестве примера смены парадигм можно отметить спиральную модель процес­са разработки МО (рис. 6.1), предложенную Боэмом [Boehm, 1986], суть, которой состоит в том, что отдельные фазы процесса «прокручиваются» на постепенно повышающихся уровнях иерархии.

Рис. 6.1. Спиральная модель Боэма

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

В Европе это направление ассоциируется, прежде всего, с проектированием ПО на основе объектно-ориентированных методологий, среди которых наиболее по­пулярными являются технология MERISE и методология Шлайера-Мэллора (Shlaer-Mellor) [Andre et al, 1994; Shlaer et al., 1992].

В рамках данного подхода проектирование рассматривается как процесс, проте­кающий в пространстве трех измерений: «статика» - «динамика» - «алгоритмы» (рис. 6.2).

Жизненный цикл при этом похож на виток в спирали Боэма, но включает другие стадии. Первая из них связана с осью «Статика» и предполагает идентификацию и описание объектов, атрибутов и отношений, которые требуются для специфи­кации проектируемой системы. Вторая стадия служит для описания поведения каждого объекта в ответ на внешние запросы и дает в качестве результата сово­купность жизненных циклов всех введенных объектов. Затем проектируются алгоритмы реализации действий, специфицированных на предыдущей стадии, и, наконец, на четвертой стадии осуществляется валидация спроектированной сис­темы на полноту и функциональное соответствие исходной задаче. Последняя стадия может потребовать нового витка в модели жизненного цикла.

Рис. 6.2. Проектирование в методологии Shlaer-Mellor

Таким образом, мы рассмотрели основные модели процессов разработки систем «традиционного» программного обеспечения и теперь переходим к анализу соот­ветствующего инструментария.

Дата добавления: 2015-07-02