Применимость CASE-средств
В [] утверждается, что сфера применения современных CASE-средств - «большие и сложные системы». В самом деле, сложность и стоимость CASE-средств оправдывается только в больших проектах. Следовательно, не стоит даже пытаться применять их в разработке «средних» программ. С этим утверждением можно полностью согласиться, но применительно только (!) к существующим на сегодняшний день на рынке средствам. По собственному опыту знаю: почти в каждой разработке попадается какая-нибудь «закавыка», справиться с которой «в рукопашную» (то есть, без моделирования) в принципе возможно, но только при крайнем напряжении интеллекта. Да и при разработке обычных объектов чрезвычайно полезны схемы, диаграммы, алгоритмы, и т.д., которые в основном рисуются на бумаге от руки. По сути, это - те же модели, только выполненные вручную. Поэтому, возможно, более справедливым будет утверждение, что современные CASE-системы не удовлетворяют некоторым критериям качества, существенным для сферы «средних» программных средств, в силу чего их применение здесь невозможно.
Но что же тогда остается разработчикам «средних» программных средств? Ручка и бумага? Как ни прискорбно будет заметить, но огромнейший класс специалистов оказался, что называется, «за бортом» автоматизации. Это явление представляется ненормальным, что собственно, и стало основным мотивом проделанной работы.
Возможны ли CASE-средства массового применения? Считаю, возможны на сто процентов. Более того, меня удивляет их отсутствие. В это мнение получит подтверждение, а сейчас в связи с этим рассмотрим следующий вопрос: почему в свое время языки высокого уровня получили широкое распространение, и, в конце концов, вытеснили низкоуровневые языки типа ассемблеров? Очевидно, потому, что имели ощутимые преимущества:
- Были основаны на сравнительно простых элементах: достаточно было изучить небольшой набор довольно простых конструкций (операторные скобки, функции, присваивание, ветвление, и т.д.), чтобы начать уверенно программировать.
- Более качественно отображали алгоритмы, структуру программы, и т.п.
- Обеспечивали существенно более высокий уровень автоматизации программирования, т.е. множество ранее ручных операций выполнялось теперь компилятором.
- Со временем перекрыли функциональные возможности языков предыдущего поколения, то есть практически не оставили для них сферы применения.
В ассемблерных языках за кажущейся простотой команд (всего-то несколько символов!) кроется неоднородная структура из кода операции (которых в ассемблере как минимум несколько десятков), набора операндов, специфичных для каждой команды, идентификация которых к тому же осложнена разнообразием методов адресации. Это является пожалуй, наиболее существенной причиной сложности программирования на ассемблере. По сравнению с языками ассемблера, элементы языков высокого уровня были намного проще в понимании и применении.
Обеспечение первых двух качеств дает право на существование и практически неограниченное распространение. Два следующих качества обеспечили вытеснение компиляторов предыдущего поколения. Однако обеспечение первого качества - простоты - стало решающим в распространении не только языков и компиляторов высокого уровня, но и самого программирования на более широкий круг специалистов, превращении его из колдовства, дела избранных, в инженерную науку. Этот фактор - фактор простоты - является фундаментальным условием успеха и в других областях массового применения: чтобы получить массовое распространение, инструментальные средства должны быть простыми для пользователя. Применительно к программированию это означает - должны базироваться на простых элементах.
Зависимость распространенности инструмента от его простоты характерна не только для программирования: пожалуй, во всех областях деятельности человека количество специалистов, владеющих инструментом, всегда примерно обратно пропорционально его сложности.
Значимость фактора простоты в программировании особенно критична в силу итеративности процесса разработки программного обеспечения, то есть необходимости неоднократных повторений, возвратов к предыдущим этапам, присущей в равной степени и большим, и малым проектам. На сегодняшний день необходимость итераций никем не отрицается, более того, настоятельно рекомендуется именно такая схема процесса разработки. Но это означает, что необходимо многократное повторное осмысление ранее разработанных конструкций. Вследствие чего, усложнение элементов представления вызывает экспоненциальный прирост трудоемкости.
Обратное утверждение собственно и составляет основную мысль данной статьи:
Упрощение инструментального средства в программировании дает экспоненциальное упрощение его использования, и придает этому средству соответственный потенциал распространения.
Рассмотрим с этой точки зрения UML как пример CASE-средства, конкретно - диаграммы состояний.
