Дефрагментация мозга. Софтостроение изнутри

Программная фабрика: дайте мне модель, и я сдвину Землю

Идея разрабатывать программы, минимизируя стадию кодирования на конкретных языках под заданные платформы, появилась достаточно давно. Прежде всего в связи с неудовлетворительной возможностью языков высокого уровня третьего поколения (3GL) описывать решаемые прикладные задачи в соответствующих терминах. За последнее время к этой причине добавилась ещё и поддержка независимости от целых платформ, ведь прогресс, как мы знаем, неотвратим, особенно «прогресс».

В управляемой моделями разработке [124] (УМР) и в программной фабрике [125] в частности наиболее интересной возможностью является генерация кода, скомпилировав который, можно сразу получить работающее приложение или его компоненты. Мы проектируем и сразу получаем нечто работающее, пусть даже на уровне прототипа. Уточняя модели, мы на каждом шаге имеем возможность видеть изменения в системе. Проектирование становится живым процессом без отрыва от разработки.

Историю управляемой моделями архитектуры и разработки, обобщаемой под термином УМИ – управляемой моделями инженерии [126] , можно вести с 1970-х годов. Именно тогда появились первые языки спецификации требований к программам и целые стандарты, типа упоминавшегося IDEF, включающего в себя ряд языков и нотаций. Однако реальная и доступная многим пользователям автоматизация моделирования появилась лишь вместе с персональными компьютерами. Не случайно форматы IDEF-диаграмм исторически сохранили рамки с ячейками информации, столь необходимыми при бумажной технологии анализа проектирования.

Первые инструменты CASE, выросшие из редакторов графических примитивов, были представлены в 1980-х годах, а одним из пионеров был небезызвестный Эдвард Йордон, соавтор, в компании с Томом ДеМарко, популярной методологии SADT [127] . В начале 1990-х годов наблюдалось возникновение множества языков, нотаций, подходов к анализу и проектированию и, как следствие, пик многочисленных CASE-инструментов, их реализующих.

У программистов «от сохи» отношение к CASE, как правило, негативное на уровне «я не верю, что какие-то картинки генерируют код лучше написанного руками». В таком отношении есть своя сермяжная правда, действительно, экскаватор, в отличие от мужика с лопатой, может вырыть не всякую яму. Доказывать обратное – бесполезная потеря времени.

У более продвинутых программистов, имевших опыт написания и сопровождения тысяч строк однотипного рутинного кода, претензии становятся обоснованными и касаются, как правило, следующих сторон применения CASE-средств:

• Если ручное написание кода принять за максимальную гибкость, то CASE может навязывать каркас, стиль кодирования и шаблоны генерации частей программ, ограничивающие не столько полёт фантазии программиста, сколько возможность тонкой настройки генерируемого кода. Неважно, что такая настройка не требуется в большинстве случаев, но если её нет, то менять придётся непосредственно сгенерированный код.

• CASE работает только в условиях дисциплины, когда ручные изменения генерируемого кода исключены или автоматизированы (пост-обработка). Как только программист залезает руками в код каркаса, модель оказывается рассинхронизированной по отношению к исходным текстам программ и процесс разваливается.

В качестве решения перечисленных проблем появились так называемые двусторонние CASE-инструменты ( two way tools

), позволяющие редактировать как модель, непосредственно видя изменения в коде, так и, наоборот, менять код с полу– или полностью автоматической синхронизацией модели. Зачастую, такой инструмент был интегрирован прямо в среду разработки.

Рис. 17. Двусторонний CASE-инструментарий ModelMaker имеет возможности работы как с моделями, так и непосредственно с кодом приложения

Рис. 18. Работа с кодом приложения в ModelMaker