Методология и технология

Тема 1. Вопросы 3 (Этапы …) и 4 (Совр. методол. …). Файл 308845278
С. 1 из 11
3. Этапы разработки программ
 Разработка программного обеспечения составляет часть его жизненного цикла.
Жизненный цикл программного обеспечения – это весь процесс его создания и применения от
начала до конца, т.е. от момента постановки задачи до вывода программы из эксплуатации. Это
понятие широко используется при описании процесса разработки.
На рис. 1.2 рассмотрена структура жизненного цикла программного обеспечения и затраты на выполнение отдельных его этапов1.
5
Сопровождение – внесение
изменений и поддержание
программы в рабочем состоянии
(50%)
Требования пользователя
Решение пользователю
1
Определение требований-спецификаций
(10%)
4
2
3
Проектирование
(10%)
Кодирование
(10%)
Отладка и
тестирование (20%)
Рис. 1.2. Этапы жизненного цикла и затраты по стадиям
Поскольку в нашем случае речь идет о разработке ПО, объектом рассмотрения будет нижняя половина диаграммы; соответственно, речь будет идти об относительном весе этапов разработки в
общем процессе, суммарные «затраты» (в любом смысле) на который следует взять за 100%. Заметим только, что эффективность сопровождения практически полностью определяется качеством
выполнения предшествующих этапов разработки.
Приведенные численные оценки являются результатом экспериментальных исследований. По
словам авторов упомянутой книги, они подтверждают интуитивные предположения. Эти результаты относятся ко времени «классического процедурного программирования», однако следует отметить два важных обстоятельства.
Во-первых, является неоспоримым фактом то, что с усложнением задач, решаемых с помощью ПО
(точнее, с усложнением объектов, фигурирующих в постановках задач), акцент смещается на этапы проектирования и – прежде всего – спецификации как уточнения постановки задачи; отсюда
можно предположить, что увеличивается относительная роль этих этапов. Однако при этом конечной целью является все же программный продукт, и очень маловероятно, что при сложной структуре как объектов задачи, так и взаимосвязей между ними не возрастает сложность кодирования и
особенно – отладки и тестирования.
Во-вторых, ввиду характера современного процесса разработки ПО в целом – отсутствии общих
объединяющих концепций, раздробленности, открытости одних и корпоративности других технологий и т.д. – в общедоступных источниках исследования подобного характера не встречаются и в
любом случае соответствующие оценки заслуживали бы доверия только при сильных ограничениях области их применения.
Отсюда следует, что остается по-прежнему полагаться на интуитивные оценки, которые ввиду
первого обстоятельства представляются близкими к изображенным на схеме.
● Этапы разработки программы отображены в нижней половине рис. 1.2 в той последовательности, как они выполняются. Этапы должны обладать свойством преемственности, но принципиально важно, чтобы эта преемственность реализовывалась сверху вниз, т.е. чтобы предшествую1
Рис. 1.2 – 1.5: из кн.: Глас Р., Нуазо Р, Сопровождение программного обеспечения. – М.: Мир, 1983 – 156 с.
Тема 1. Вопросы 3 (Этапы …) и 4 (Совр. методол. …). Файл 308845278
С. 2 из 11
щие этапы захватывали последующие, а не наоборот. Возвратов назад по возможности быть не
должно.
Кратко охарактеризуем этапы.
1. Составление внешней спецификации. Цель – уточнение постановки задачи, а именно:
 точная формулировка задачи и всех вводимых ограничений;
 определение состава и взаимосвязей объектов задачи (или состава и структуры входных и
выходных данных) и формы ввода входных и вывода выходных данных;
 описание аномалий – ситуаций, при которых решение не может быть получено (выход данных за границы диапазона, деление на ноль при вычислениях и т.п.), либо аномальных состояний системы;
 описание тестов – примеров, на которых будет проверяться работа программы;
 описание метода решения – связей входных и выходных величин, общей идеи и схемы решения задачи.
Спецификация представляет собой интерфейс между разработчиком программы и ее пользователем. Для задач, оперирующих сложными реальными объектами, этот этап выделяется как самостоятельный вплоть до реализации его средствами специально для этого предназначенных технологий, пограничных между системным анализом и проектированием (например, путем описания
задачи на языке UML1).
Большая часть желательных качеств программы должна быть сконцентрирована в ее
спецификации, так, чтобы программа после первой ее реализации требовала улучшений
в минимально возможной мере. Исключением является быстродействие, которое можно повышать уже после реализации программы.
2. Проектирование
Цель – создание проекта, понятного человеку.
В любом случае здесь речь идет о проектировании структур данных и алгоритма их обработки.
В случае применимости процедурной парадигмы алгоритм и данные проектируются параллельно,
но акцент делается на алгоритме.
В случае объектно-ориентированной парадигмы проектируются классы объектов, которые, в свою
очередь, требуют проектирования методов класса как процедур обработки данных.
Это центральный и наиболее трудоемкий этап разработки. Требует творчества и не может быть
полностью формализован. Созданный на этом этапе проект (текст алгоритма или совокупность
объектов) – носитель всей информации о решении, поэтому для его записи используются наиболее универсальные и одновременно точные средства – «отказ от красивого и умного в пользу незамысловатого и четкого». Такими средствами являются диаграммы (например, в случае объектно-ориентированной парадигмы) и полуформальные языки проектирования алгоритмов и данных –
псевдокоды.
3. Кодирование состоит в переводе проекта алгоритма с одного языка, достаточно жесткого (языка диаграмм или псевдокода), на другой, полностью формализованный (язык программирования).
Сложность этого этапа определяется качеством выполнения предшествующих.
Для задач небольшого объема, если первые два этапа выполнены тщательно, то кодирование выполняется без особых трудностей.
В случае сложных проектов для полной или (что реальнее) частичной автоматизации кодирования
могут быть использованы соответствующие инструменты, являющиеся компонентами инструментов проектирования (яркий и, пожалуй, самый представительный пример – инструмент Rational
Rose, базирующийся на языке UML и позволяющий довести разработку до кодирования классов
на ряде языков – Java, C++, C#).
4. Отладка и тестирование. Цель – получение работоспособной программы. Очень важный
этап, требующий особого рассмотрения и здесь представленный только самыми основными положениями.
Забегая вперед, следует отметить, что язык UML рассматривается как стандарт графического моделирования не только объектов, но и программного обеспечения в целом.
1
Тема 1. Вопросы 3 (Этапы …) и 4 (Совр. методол. …). Файл 308845278
С. 3 из 11
Отладка – процесс изменения программы с целью исправления ошибок.
Тест в классическом определении – совокупность специально подобранных входных и соответствующих им выходных данных, используемая для контроля правильности программы.
Расширяя это понятие на случай задач со сложной структурой объектов и схем их взаимодействия, можно говорить об исходном состоянии объектов и их реакции на те или иные события. Исходное состояние объектов и события служат аналогом входных данных, а формируемая программой реакция – аналогом выходных. Например, при тестировании приложения с визуальным
интерфейсом входом теста может служить состояние компонентов и щелчок мыши на одном из
них, а выходом – ожидаемое действие программы.
Здесь хорошо просматривается связь парадигмы программирования со сложностью задачи. Так,
классическое определение отражает процедурную парадигму (данные и алгоритм разделяются), а
расширенное тяготеет к обектно-ориентированной парадигме. Тем не менее суть остается неизменной: тест – заранее заготовленная пара «вход – выход».
Тестирование – исполнение программы на наборе тестов на компьютере.
Отладка включает тестирование.
Принципиальная трудность проектирования тестов состоит в практической невозможности составления всех тестовых наборов данных для всех возможных режимов работы разрабатываемой программной системы. Поэтому задача проектирования тестов сводится к проектированию ограниченного их набора, гарантирующего с достаточной достоверностью правильную работу программы во всех практически значимых режимах.
Содержание тестов определяется спецификацией задачи и логикой ее решения.
Функциональные тесты составляются на уровне спецификации, до решения. Будущий алгоритм
рассматривается как «черный ящик» - функция с неизвестной структурой, преобразующая входы в
выходы. Суть функциональных тестов: каким бы способом ни решалась задача, при заданных
входных значениях должны получиться соответствующие выходные значения.
Структурные тесты составляются для проверки логики решения, или логики работы уже готового алгоритма. Логика определяется последовательностью операций, их условным выполнением
или повторением. Совокупность структурных тестов должна обеспечить проверку каждой из таких
конструкций.
Чаще всего совокупность тщательно составленных функциональных тестов покрывает множество
структурных тестов.
Длительность и сложность данного этапа полностью определяется качеством выполнения предыдущих этапов.
5. Документирование. Для удобства описания представлено как некоторый этап, но по сути таковым не является.
Элементы документации – все элементы проекта, полученные при его разработке, т.е. описание
результатов отдельных этапов. Если процесс разработки программы организован правильно, то
документация появляется постепенно и процесс ее создания сопровождает все этапы. Поэтому
стрелка-окружность на рис. 1.1 проходит через все этапы жизни программы.
Характерно, что с ростом сложности ПО роль документации уже не подвергается обсуждению, а
органично отражена в средствах проектирования: так, язык UML позиционируется одновременно
как язык документирования этапа спецификации и проектирования.
 Значимость отдельных этапов в общем процессе разработки
На рис. 1.3 – 1.5 жизненный цикл программного обеспечения рассмотрен с точки зрения внесения
и обнаружения ошибок и надежности1.
1
Из кн.: Глас Р., Нуазо Р, Сопровождение программного обеспечения. – М.: Мир, 1983 – 156 с.
Тема 1. Вопросы 3 (Этапы …) и 4 (Совр. методол. …). Файл 308845278
С. 4 из 11
Приемочные испытания
и сопровождение
(54%)
Кодирование
(36 - 39%)
Проектирование
(61 - 64%)
Отладка
(46%)
Рис. 1.3. Количество ошибок по стадиям
Рис. 1. 4. Обнаружение ошибок по стадиям
5
Сопровождение
(62%)
1
Определение требований-спецификаций
(8%)
Проектирование
(7%)
4
2
3
Кодирование
(10%)
Отладка (13%)
Рис. 1.5. Затраты на устранение ошибок по стадиям
Из рисунков видно, что чем дальше зашел процесс разработки, тем дороже обходятся ошибки. Поэтому более тщательная разработка каждой предыдущей стадии неизменно приводит к снижению
стоимости и числа ошибок на последующих стадиях.
 Модели жизненного цикла ПО
Представленная на рис. 1.2 структура жизненного цикла ПО – статическая схема. В процессе разработки возможны различные способы ее реализации, называемые моделями жизненного цикла.
Модели подразделяются по принципу реализации функциональности ПО – за один проход или
итеративно с постепенным наращиванием функциональности. Наиболее распространенными являются две модели:
 каскадная, или водопадная;
 итеративная, или инкрементная, спиральная, эволюционная.
Каскадная модель предполагает последовательное выполнение этапов, каждый из которых на
своем уровне отображает всю функциональность и должен быть полностью завершен перед переходом на следующий. Эта модель относится к 70 – 85 гг. и хорошо работает, когда все требования
задачи можно достаточно точно и полно сформулировать на этапе ее постановки. Главным недостатком ее является то, что степень соответствия разработанного программного продукта поставленной задаче можно определить только по завершении всей разработки. В процессе разработки
очень трудно утверждать, что она (разработка) идет в нужном направлении.
Итеративная модель предполагает разделение всего процесса на итерации. Первоначально
берется некоторая часть требований к функциональности и выполняется полный цикл разработки
Тема 1. Вопросы 3 (Этапы …) и 4 (Совр. методол. …). Файл 308845278
С. 5 из 11
для этой части требований. В результате должен появиться готовый программный продукт с частичной функциональностью. От итерации к итерации объем требований расширяется и процесс
повторяется. Соответственно появляются последующие версии программного продукта с итеративно расширяющейся функциональностью вплоть до реализации всех требований.
Эта модель более поздняя и в настоящее время рассматривается как предпочтительная. Она позволяет оценить правильность направления разработки по ходу процесса, на каждой итерации
оценивая полученный программный продукт, и в случае отклонения от требований задачи внести
необходимые коррективы. Такой ход разработки предполагает исходную недоопределенность
требований, что соответствует реальности.
Замечание. При более детальном рассмотрении второй модели не все приведенные ее наименования являются синонимами. Так, в кн. Орлова1 выделяются инкрементная (итеративная) и эволюционная (спиральная) модели. Здесь приведена общая классификация согласно кн. Фаулера 2;
где подчеркнуто, что различия смыслов приведенных терминов не играют принципиальной роли.
Каскадная и итеративная модели как показатели состояния индустрии
В противовес разработке ПО, в классической современной индустрии материальных объектов
имеет место только каскадная модель. Итеративность присутствует в незначительных дозах и связана с индивидуализацией изделия (например, можно тонировать стекла автомобиля; но изготовление автомобиля не будет считаться завершенным, если у него нет кузова). Кроме того, любая
доработка изделия не является частью производственного процесса.
Каскадная модель – нормальное индустриальное производство, итеративная – кустарное изготовление единичных изделий.
Основной недостаток итеративной модели – итоговый готовый продукт переусложнен из-за того,
что реализация влияет на начальные стадии проекта. Версии с расширенной функциональностью
не разрабатываются заново, а строятся на основе модификаций предыдущих, что приводит к искажению первоначального проекта.
Таким образом, распространенность итеративной модели в разработке ПО является свидетельством того, что соответствующая индустрия находится в стадии становления и пока не в силах реализовать каскадную модель для задач с гигантски возросшей (!) сложностью, т.е. на очередном
этапе своего развития.
4. Современная методология и технология программирования
 Об использовании терминов «методология» и «технология»
В реальной жизни применительно к разработке ПО эти два понятия используются достаточно произвольно и практически в одном и том же смысле, хотя при их противопоставлении интуитивно понятие методологии воспринимается как более общее, лежащее в основе технологии. Например,
применительно к одной и той же области употребляются словосочетания «структурная методология» и структурная технология» и пр.; с другой стороны, существуют «новые информационные
технологии», но нет «новых информационных методологий»; наконец, в источниках присутствует
даже утверждение, что CASE-технология представляет собой методологию проектирования информационных систем. Самое интересное состоит в том, что такая произвольная трактовка базовых терминов не имеет негативных последствий (за исключением затрат времени и сил на приводимые рассуждения) и не приводит к путанице.
Причина состоит в том, что точная трактовка обоих понятий относятся к области философии, где
на самом деле такая трактовка отсутствует. Чтобы далее не вдаваться в тонкости различий этих
понятий там, где это не играет роли, и покончить с этой проблемой, рассмотрим ряд определений
и трактовок этих терминов.
Методология – учение о структуре, логической организации, методах и средствах деятельности
(СЭС3, с. 806).
Здесь метод – способ достижения какой либо цели, решения конкретной задачи; совокупность
приемов или операций практического или теоретического освоения действительности (там же).
В современной литературе под методологией понимают прежде всего методологию научного познания, т.е. учение о принципах построения, формах и способах научно-познавательной деятельОрлов С.А. Технология разработки программного обеспечения. Учебное пособие. – 2-е изд. – СПб: Питер,
2003. – 480 с.
2
Мартин Фаулер. UML. Основы, 3-е издание. – СПб: Символ-плюс, 2004. – 192 с
3
Советский энциклопедический словарь
1
Тема 1. Вопросы 3 (Этапы …) и 4 (Совр. методол. …). Файл 308845278
С. 6 из 11
ности. Методология науки дает характеристику компонентов научного исследования его объекта,
предмета анализа, задач исследования, совокупности исследовательских средств, необходимых
для их решения, а также формирует представление о последовательности движения исследователя в процессе решения исследовательских задач 1.
Разработка ПО в самом общем плане – плане использования социумом компьютера как средства
обработки информации – может рассматриваться как форма научно-познавательной деятельности. Поэтому правомочно употреблять здесь понятие методологии в описанном выше смысле, т.е.
как о принципах построения, формах и способах деятельности, осуществляемой при решении задач с помощью компьютера, т.е. при переходе от описания задачи на языке проблемной области к
ее решению совокупностью программных продуктов.
Всякая методология выполняет регулятивные, нормативные функции. В этом, собственно, и состоит ее назначение. (Юдин, см. сноску 2). Методология программирования призвана исследовать
и рекомендовать организационные рамки, способствующие написанию хороших программ.
Технология – совокупность методов обработки сырья, осуществляемых в процессе производства
продукции. Задача технологии как науки – выявление закономерностей с целью определения и
использования на практике наиболее эффективных процессов (СЭС, с. 1338).
Следуя этому, технологию разработки ПО можно определить как совокупность методов, применение которых приводит от постановки задачи к программному продукту, дающему ее решение. В
качестве сырья здесь выступает информация.
В кн. Орлова2 технология конструирования ПО определена как система инженерных принципов
для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах.
В работе Вендрова3 технология проектирования ПО определяется как совокупность трех составляющих:
 пошаговой процедуры, определяющей последовательность технологических операций
проектирования;
 критериев и правил, используемых для оценки результатов выполнения технологических
операций;
 нотаций (графических и текстовых средств), используемых для описания проектируемой
системы.
Таким образом, технология предполагает наличие методов и операций разработки и процедуру их
последовательного применения, приводящую к результату; при этом процедура должна быть эффективной с точки зрения заданных критериев.
Что касается технологии как науки, то это определение имеет весьма много общего с понятием
методологии. Возможно, это сходство и неразличение двух аспектов технологии – практического и
теоретического – и приводит к употреблению терминов «методология» и «технология» в одном и
том же смысле.
В дальнейшем мы не будем заниматься разделением рассмотренных понятий. Однако там, где это
важно, будем употреблять термин «методология» так же, как и «теоретический аспект технологии»
– как совокупность общих принципов, лежащих в основе процесса разработки ПО и являющихся
неотъемлемой его частью, а термин «технология» – как конкретизированную систему принципов,
методов и средств, применяемую на практике. Иными словами, методология определяет рамки
деятельности, а технология – схему действий в этих рамках.
Например, можно говорить о структурной и объектно-ориентированной методологиях разработки
ПО и соответствующих технологиях; последние могут быть воплощены в CASE- инструментах.
 Технологии разработки ПО и CASE-технологии
Естественно понимать термин «технология» (в единственном числе) в зависимости от контекста
либо как общее понятие в приведенном выше смысле, либо как конкретную его реализацию. Множество реализаций дает множество различных технологий, т.е. «технологии» во множественном
числе.
См.: Юдин Э.Г. Системный подход и принцип деятельности. - М., 1978. - С. 31
Орлов С.А. Технология разработки программного обеспечения. Учебное пособие. – 2-е изд. – СПб: Питер,
2003. – С.15.
3 Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. http://www.citforum.ru/database/case/index.shtml
1
2
Тема 1. Вопросы 3 (Этапы …) и 4 (Совр. методол. …). Файл 308845278
С. 7 из 11
CASE (Computer Aided Software Engineering) – автоматизированная разработка программного
обеспечения. Под этим термином объединяются средства, или инструменты, позволяющие вести
разработку с помощью компьютера, начиная с анализа задачи в предметной области. CASEсредства представляют собой реализацию принципов соответствующих технологий. Поскольку
разработка ПО с помощью этих средств также является технологией, в зависимости от контекста
можно говорить о CASE-технологии как совокупности технологий, ориентированных на автоматизированную разработку ПО или конкретных CASE-технологиях.
Однако необходимо принять во внимание, что конкретные CASE-технологии, будучи ощутимой на
практике реальностью (в отличие от теоретических положений), оказывают свое влияние на понятийный аппарат,ставя телегу впереди лошади. Например, в кн. Леоненкова 1 CASE определяется
как методология разработки программ, основанная на комплексном использовании компьютеров
не только для написания исходных кодов, но и для анализа и моделирования соответствующей
предметной области. Тем не менее по некотором размышлении и это представляется вполне приемлемым, находя свое объяснение ...
Мы договоримся под технологиями разработки ПО понимать принципы, средства, методы, процессы, реализуемые в любой форме (в том числе и вручную), а под CASE-технологиями – технологии
разработки с использованием CASE-инструментов.
 Основные этапы становления технологии разработки ПО
 «Кризис программирования» и создание структурной методологии
Вернемся к таблице, описывающей эволюцию информационных технологий (из вопроса 1 темы), и
рассмотрим причины резкой смены критериев качества ПО – от ориентации на ресурсы компьютера к ориентации на человеческие ресурсы (конец 60-х –70-е годы).
Итак, пользователю предоставляются все большие возможности для создания программ. Растет
вес программного обеспечения в общих расходах на использование ЭВМ. В середине 70-х годов
стоимость программного обеспечения в США была примерно равна общей стоимости установленных в стране ЭВМ и периферийных устройств 2. Программное обеспечение становится определяющим фактором использования ЭВМ.
Создается индустрия программного обеспечения. Программа становится товарной продукцией,
которая разрабатывается целыми коллективами, хотя сам процесс остается неформализованным,
«творческим». Индустриальный характер продукции вступает в противоречие с кустарным способом его производства. Суть этого противоречия кроется в том, что существует порог сложности, за
которым уже невозможно контролировать создаваемые программы. Этот порог определяется «человеческим фактором» – ограниченными возможностями отдельного человека при переработке
информации. Такого рода ограничения фундаментальны и никак не снимаются прогрессом технического обеспечения.
Возникает необходимость в создании методологии программирования, в его стандартизации и
введении логических правил синтеза программ.
В 1968 году состоялась конференция по математическому обеспечению, где был сделан вывод о
том, что имеется кризис математического обеспечения и что сущность программирования слабо
понята. В 1969 г. была создана рабочая группа по вопросам методологии программирования. Программирование стало важной областью научных исследований.
Появление в конце 60-х – начале 70-х гг. работ Дейкстры и Вирта, а затем – Лингера, Миллса, Йодана и др. определило исследования на много лет вперед.
Была создана методология, которую точнее было бы назвать философией программирования,
сформулировавшая ряд фундаментальных принципов решения задач применительно к компьютеру. Цель ее – повышение производительности труда программистов, причем «производительность» означает оптимальное использование как машин, так и людей.
Поскольку такое комплексное понятие производительности формально определить невозможно,
критерии также оказываются не строго определенными, взаимосвязанными, а иногда противоречивыми. В разных источниках могут приводиться различные наборы критериев. Но, несмотря на
это, как правило эти наборы сводимы один к другому и хорошо работают! Остановимся на следующей совокупности критериев:
1. работоспособность;
1
2
Леоненков А.В. Самоучитель UML. – 2-е изд., перераб. и доп. – СПб: БХВ-Петербург, 2004. – 432 с.
В настоящее время стоимость программного обеспечения в целом значительно больше стоимости «железа»
Тема 1. Вопросы 3 (Этапы …) и 4 (Совр. методол. …). Файл 308845278
С. 8 из 11
2. правильность: программа должна решать именно поставленную, а не более широкую, более
узкую или измененную задачу;
3. надежность: программа должна работать при любых исходных данных – анализировать их
правильность и выдавать результаты или диагностику ошибок;
4. читабельность: текст программы – итоговый носитель всей информации о решении, поэтому
он должен иметь четкую и ясную организацию, отображающую решение;
5. легкость отладки и тестирования;
6. модифицируемость: возможность внесения изменений в программу;
7. документированность: наличие документации по всему процессу разработки, начиная от постановки задачи; это свойство обеспечивает отчуждение программы, т.е. возможность ее
передачи другим лицам;
8. простота пользования (сервис);
9. эффективность с точки зрения использования машинных ресурсов – минимизация последних, а именно, объема памяти и времени выполнения.
Видно, например, что критерии 4, 6, 7 взаимосвязаны, критерий 5 ими определяется; критерии 3 –
8 противоречат 9-му, и сам он внутренне противоречив. Делать акцент на тех или иных критериях
следует в зависимости от реальной ситуации. Так, мощность современных компьютеров в большинстве случаев позволяет не слишком учитывать ресурсы. Однако если речь идет о специальных
расчетных инженерных задачах, время решения которых объективно велико, на первый план выступают ресурсы.
Таким образом, критерии качества программ в корне изменились; лозунгом стал тезис: программы
пишутся для человека!
В основу методологии разработки программ положены следующие принципы.
1. Разбиение процесса создания программы на четкие этапы и обеспечение максимальной их
автономности:
 не следует переходить к очередному этапу, не закончив предыдущего;
 предыдущий этап может захватывать последующий, но не наоборот.
2. Уделение основного внимания начальным этапам разработки – уточнению постановки задачи (спецификации) и проектированию алгоритма и данных.
3. Использование для проектирования специального языка высокого уровня. Этот принцип носит название надъязыкового подхода.
4. Использование метода нисходящего проектирования, состоящего в постепенном разбиении задачи на подзадачи.
5. Использование принципа структурного программирования, предписывающего построение алгоритма из ограниченного числа базовых конструкций.
При таком подходе суть решения закладывается в постепенно создаваемый проект, а собственно
составление программы сводится к перекодировке алгоритма с языка проектирования на конкретный алгоритмический язык и представляет собой один из этапов жизненного цикла – кодирование.
Из изложенного хорошо видно, что, с одной стороны, акцент ставится на разработке алгоритма,
но, с другой стороны, рассматриваемые проблемы гораздо шире и сосредоточиваются на человеческом факторе.
Введенные понятия и принципы проработаны до уровня достаточно стандартизированной технологии программирования. Они являются базовыми и лежат в основе, с той или иной расстановкой
акцентов, в любой технологии разработки ПО.
Методология программирования, как и любая методология, не является универсальным инструментом, позволяющим автоматически составить программу решения любой задачи. Она призвана
исследовать и рекомендовать организационные рамки, способствующие написанию хороших программ.
 Эволюция структурного подхода. «Война методов»
В плане практических разработок термин «структурный» приобрел значение имени собственного
целого ряда конкретных технологий анализа, проектирования и разработки информационных систем. Общей характеристика структурного подхода здесь заключается в иерархической декомпо-
Тема 1. Вопросы 3 (Этапы …) и 4 (Совр. методол. …). Файл 308845278
С. 9 из 11
зиции системы на функциональные подсистемы вплоть до конкретных процедур. При этом на каждом уровне декомпозиции автоматизируемая система описывается полностью, но с разной степенью детализации1.
Как хорошо видно, такое определение полностью подпадает под определение нисходящего проектирования. Однако работы по «структурному подходу» в приведенном ранее (классическом, исходном) и вышеприведенном смысле являют собой различные направления. Это можно отнести к
расхождению теории и практики, которое в области разработки ПО особенно сильно.
Описываемое направление, развивающееся также с 60-х годов, имеет практическую направленность, первоначально ориентировано на автоматизацию разработки СУБД и реализуется в ряде
CASE-средств. Основной его момент – визуализация процесса разработки концептуальной схемы
проблемной области (в частности, БД).
Неоднозначная оценка эффективности CASE-средств и отсутствие единой графической нотации
породило несколько подходов. Так, В рамках структурного подхода принято рассматривать три
графические нотации, или диаграммы: диаграммы «сущность-связь», диаграммы функционального
моделирования и диаграммы потоков данных.
Структурный подход характеризуется также слабой взаимосвязью процессов и данных, присутствующих в системе, т.е. ориентацией на процедурную парадигму.
В конце 70 -х гг. появляются языки объектного моделирования, ориентированные на тесную взаимосвязь процессов и данных системы и более адекватные объектам реального мира. В период 8994 гг. общее число таких языков возросло с 10 до более чем 50. При этом ни один из них не удовлетворял всем требованиям, предъявляемым к построению сложных систем. Попытки принятия
отдельных методик в качестве стандарта не привели к успеху. Конкуренция между различными
подходами в начале 90-х привела к ситуации, получившей название «война методов».
 Эволюция объектно-ориентированного анализа и проектирования (ООАП). язык UML
В течение 1994-96 годов создатели трех наиболее распространенных методологий - Гради Буч
(BOOCH), Джим Рамбо (OMT - Object Modeling Technique) и Айвар Якобсон (OOSE - Object Oriented
Software Engineering) объединили свои усилия под эгидой Rational Software Corporation для создания единого языка моделирования, который объединил бы все существенные и успешные разработки в данной области и стал стандартом языка объектного моделирования. В январе 1997 года
появилась версия 1.0 языка Unified Modeling Language (UML), которая после бурного обсуждения в
течение 1997 года превратилась в сентябре в версию 1.1 и была передана в консорциум OMG2
для принятия UML в качестве отраслевого стандарта расширяемого языка объектного моделирования. В настоящее время все вопросы дальнейшей разработки языка сосредоточены в рамках
этого консорциума. Последняя версия языка – UML 2.0.
UML может быть применен на всех этапах жизненного цикла анализа бизнес-систем и разработки
приложений. Различные виды диаграмм, поддерживаемые UML, и богатейший набор возможностей представления определенных аспектов системы делает UML универсальным средством описания как программных, так и деловых систем.
 Общая характеристика состояния технологии разработки ПО
1. Состояние рассматриваемой технологии признается весьма неудовлетворительным (см. кн. Орлова, введение; Купера; статью Бобровского; статьи Вирта и Дейкстры 2000 года).
Отмечается несоответствий технологий разработки ПО и требований к его качеству – существующие технологии не обеспечивают нужного качества.
Причины разные авторы видят под несколько различными углами, однако выводы совпадают:
фиксация неудовлетворительного положения дел и поиск выхода в разработке унифицированных
средств анализа задач и проектирования.
Одним из ведущих направлений здесь является разработка UML; Купер предлагает ряд конструктивных идей в области проектировании взаимодействия программ с человеком, что коррелирует с
наиболее значительными работами в области создания WEB-приложений и интерфейсов.
2. Отмечается отсутствие кардинальных идей в области создания ПО со времени появления
структурного подхода (см. статью Бобровского).
См., напр., Вендров
OMG - некоммерческая международная организация, отвечающая за принятие стандартов в области информационных технологий, в которую входит более 600 ведущих мировых компаний
1
2
Тема 1. Вопросы 3 (Этапы …) и 4 (Совр. методол. …). Файл 308845278
С. 10 из 11
3. В настоящий момент наличествует целый ряд технологий, не поддающихся однозначной классификации. Ни одна из них не имеет в основе достаточно фундаментальных концепций и являет
собой скорее набор техник, предназначенных для решения определенного класса задач (что отображено в названии одной нотации SADT – Structured Analysis and Design Technique).
4. Возрастает актуальность положений, разработанных в период разрешения «кризиса программирования» конца 60-х гг., что можно наблюдать по переизданиям и публикациям соответствующих работ (см. Брукс, Мифический человеко-месяц; Кнут; Макконнелл С. Совершенный код). Очевидно, идеи того времени опередили эпоху, не реализовав значительную часть своего потенциала.
5. На данный момент магистральным направлением представляется ООАП, идеи которого включены в UML. Это направление вобрало в себя все наиболее важные концептуальные моменты
анализа проблемной среды задачи и проектирования.
На другом полюсе находится технология структурной разработки в ее классическом варианте, базирующаяся на принципах структурного программирования и нисходящего проектирования. Эти
принципы лежат в основе и более поздних технологий, перенесших акцент на визуализацию процесса проектирования через различного рода диаграммы и больше ориентирующихся на проблемную область, т.е. на первые этапы жизненного цикла ПО,
 Виды технологий
По областям применения можно дать следующую приблизительную классификацию технологий
разработки ПО:





разработка СУБД;
разработка прикладного ПО;
разработка системного ПО;
разработка сетевого ПО;
разработка Веб-приложений.
Каждый из классов располагает своими специфичными технологиями.
На самом высшем уровне для первых этапов жизненного цикла ПО (точнее, для этапа системного
анализа, предшествующего разработке) ООАП обеспечивает единый подход, а язык UML – единый стандарт описания сложных систем и проектирования, в силу чего методология ООАП может
служить основой технологии ПО для любого из перечисленных классов.
 Стандарты разработки ПО
С обзором наиболее популярных стандартов в области разработки программного обеспечения,
используемых в настоящее время в мире, можно ознакомиться в статье «Стандарты для ITиндустрии» по адресу в Интернете: http://interface.ru/misc/standart_it.htm.
Описание и анализ стандартов см. также в работе: В.В Липаев. Технологические процессы и стандарты обеспечения функциональной безопасности в жизненном цикле программных средств. –
Информационный бюллетень "Jet Info 03(130)/2004". Адрес работы в Интернете:
http://utc.jinr.ru/security/articles/techproc/index.shtml.
Пример представления технологии компанией Аргуссофт
(http://www.argussoft.ru/instr/tech/index.html)
Технология Аргуссофт Компани определяет процессы разработки прикладного программного
обеспечения, порядок их выполнения, а также методологическую и инструментальную поддержку.
В основу технологии положен международный стандарт ISO 12207, определяющий основные, организационные и вспомогательные процессы жизненного цикла. В основе технологии лежит сочетание объектно-ориентированного подхода к разработке прикладного программного обеспечения с
идеями быстрой разработки (Rapid Application Development - RAD), в том числе DSDM.
Основные положения, на которых базируется технология:
 Разработка на основе моделей. В основе проектирования software лежит построение моделей, которые используются на всех этапах жизненного цикла.
 Разработка ведется небольшими группами (3 - 5 человек).
 Заказчик привлекается к работе над проектом в качестве эксперта на всех этапах жизненного цикла, что позволяет на ранней стадии работы точно сформулировать требования к системе, а впоследствии - получить систему, устраивающую заказчика.
Тема 1. Вопросы 3 (Этапы …) и 4 (Совр. методол. …). Файл 308845278
С. 11 из 11
 Предъявление системы осуществляется в виде развиваемой последовательности прототипов, что дает возможность как можно раньше учесть замечания заказчика и потенциальных
пользователей.
 Спецификация и модель требований утверждаются заказчиком до начала прототипирования.
 По завершении каждого прототипа выполняется уточнение и развитие модели путем реинжиниринга.
 Разработка и сопровождение прикладного программного обеспечения осуществляется версиями.
 Применение конфигурационного управления на всех этапах жизненного цикла