23 Будущие формы

We use cookies. Read the Privacy and Cookie Policy

23

Будущие формы

CASE умер? Многие жрецы программирования объявляли, что смерть уже наступила. Однако на каждого плакальщика всегда находится тот оптимист, который верит в воскресение из мертвых, а на каждого очернителя находится свой ликующий поборник. Ведомое духом времени, в 1994 году Австралийское компьютерное сообщество (Australian Computer Society, ACS) собрало в Мельбурне две звездных команды австралийских консультантов и специалистов-практиков. Руководили командами сторонник Грэме Симшн (Graeme Simsion) и скептик Роб Томсет (Rob Thomsett). В ходе дискуссии, названной «великим спором о CASE», обсуждались все «за» и «против» в вопросе, как обстоит дело с CASE в Австралии. Этот спор стал весьма значительным событием для такого консервативного сообщества, как ACS, — настолько, что привлек даже больше внимания, чем презентация книги бывшего премьер-министра, которая проводилась в этом же зале несколькими часами ранее. По неизвестным причинам меня втянули в этот спор в качестве члена опровергающей команды. Томсет, которого Симшн называл самым диким консультантом Австралии, привел нашу команду к победе, хотя к концу обсуждения было видно, что обе стороны находились приблизительно на одном уровне.

Действительно, слухи о грядущем погребении CASE вызывают непонимание, поскольку CASE — это (дословно) не более чем проектирование и создание программ с помощью компьютеров. Неужели компьютеры перестали оказывать в этом помощь? Или отрасль проектирования и создания программ прекратила свое существование? Будем надеяться, что не случилось ни то ни другое. CASE не исчез и не обречен, хотя и может заметным образом declasse.[30] Следуя своему вечному стремлению приукрашивать и восхвалять то, что они когда-то вознесли до уровня святости, ученые мужи от промышленности все чаше заменяют термин CASE на «интегрированные среды разработки». Во всяком случае в последний месяц это было так.

Конечно, отчасти проблема заключается в необоснованных ожиданиях, которые подогревались рекламными кампаниями производителей программного обеспечения, а также в надеждах, питаемых любителями выдавать желаемое за действительное. Даже самый великолепный из реальных инструментов будет вызывать разочарование, поскольку почти каждый в нашем деле находится в вечном поиске меча короля Артура для программирования. Другая трудность состоит в том, что разработчики и производители инструментов CASE часто не разбирались ни в моделях и моделировании, ни в тех методах, для поддержки которых предназначались их инструменты. Более того, эти CASE-инструменты просто-напросто не были тем, что необходимо для ускорения разработки и повышения качества программ. Необходимо нечто, дающее одновременно и больше и меньше того, что дает большинство инструментов CASE. Нам следует посмотреть на визуальные среды разработки, чтобы понять, чем должны были и чем еще могут стать инструменты CASE.

Визуальные среды разработки — это одни из самых ярких и крепких нитей в клубке современных методов и продуктов. Визуальная разработка связана с большим разнообразием инструментов и подходов, позволяющих разработчикам создавать код посредством прямого манипулирования визуальными объектами в графическом пользовательском интерфейсе (ГПИ). Самым старым и известным образчиком этого жанра является Visual Basic компании Microsoft. Более поздние продукты, такие как Vis-ualAge компании IBM и Delphi компании Borland, стали вбирать все лучшее из возможностей визуального проектирования. Хотя изначально большинство таких продуктов в основном предназначались для разработчиков приложений, парадигма визуального проектирования может в конце концов стать будущим каждого.

Программное обеспечение для визуальной разработки является всего лишь технологией, но такой технологией, которая может радикально изменить методику разработки программного обеспечения. В самом чистом виде визуальное проектирование позволяет создавать полностью рабочие системы — в значительной степени или исключительно с помощью перемещения визуальных объектов по экрану монитора. Прямое манипулирование графическими элементами является очевидным подходом к разработке графических пользовательских интерфейсов. Именно здесь и началось визуальное проектирование — с применением так называемых конструкторов графических пользовательских интерфейсов. При использовании многих ранних инструментов сложность состояла в том, что за внешней стороной приятного на вид интерфейса скрывался самый отвратительный или беспорядочный код на Basic или С++ из всех, что когда-либо придумывались. Код «за экраном» был в полной неразберихе, и вам приходилось пробираться через это месиво, чтобы заставить работать хоть что-то.

Между ГПИ[31] и гравием

Когда проектируемые системы становятся действительно сложными, разработчики стремятся строить модели на более высоких уровнях абстракции, чтобы описывать и отражать архитектуру системы, а не только ее конструкцию или поверхностные проявления в виде пользовательского интерфейса. Для этого программные единицы и взаимосвязи между ними должны быть представлены визуально. Вам нужно видеть модули, классы и объекты, а также сообщения и ссылки, которые возникают между ними. Вам нужно видеть структуру вашего кода, выраженную с помощью знакомой системы обозначений. Необходима возможность перемещения по этой структуре с помощью устройства, названного Дж. Д. Хилдебрэндом визуальным броузером (J. D. Hildebrand, 1994). Вам нужно, чтобы вы могли, проведя линию, передать информацию из одного места в другое. Вам хочется иметь возможность перенести метод из одного класса в другой с помощью перетаскивания мышью. В общем, вам нужен неизменно активный инструмент CASE с динамическими встроенными механизмами конвертации кода, которые позволяют сразу переводить в код все то, что вы делаете в виде картинок, и наоборот.

Другими словами, вы хотите иметь истинно интегрированную среду визуальной разработки — сочетание CASE-инструментов и приложений WYSIWYG,[32] полученное в результате добавления в среды разработки приложений возможностей CASE и более тесной интеграции средств построения ГПИ и генерации кода внутри самих CASE-инструментов. Vis-ualAge представляет собой направление, согласно которому моделирование осуществляется в самих конструкторах приложений. В таких средах с помощью линий можно соединять ГПИ-объекты, а также невидимые объекты, которые скрыты за экраном. В свете основных принципов CASE такие инструменты, как Together С++, позволяют синхронизировать все составляющие модели реализации — код, проектные модели, схемы и диаграммы.

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

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

Двойственные процессоры

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

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

Вместо того чтобы устраивать поминки по CASE, может быть, есть смысл визуализировать процесс разработки.

Из журнала Software Development, том 3, № 5, май 1995 г.

Данный текст является ознакомительным фрагментом.