Инструменты для создания программного обеспечения продолжают совершенствоваться, особенно визуальные средства разработки. Начиная с Visual Basic и Delphi и заканчивая Visual С++ и J-Builder, визуальные инструментальные средства сделали большой шаг вперед в области разработки приложений и программного обеспечения. Это относится не только к технологии, но и к тому, как такие инструменты соответствуют методам, с помощью которых люди решают задачи. Лучшие из этих инструментов помогают разработчикам легко перемещаться между визуальным представлением программного продукта (пользовательским интерфейсом) и кодом, лежащим в его основе. Другими словами, они позволяют думать либо о видимых объектах, либо о невидимом коде — в зависимости от того, что требуется для решения текущей задачи.

Швы в инструментах начинают проявляться именно между пользовательским интерфейсом и теми моделями, которые разработчики применяют для представления объектов, взаимосвязей и задач. Обещание полной и совершенной интеграции, о которой шла речь в главе 23, еще не материализовалось. Инструменты моделирования все еще являются лишь инструментами моделирования, а инструменты проектирования — лишь инструментами проектирования. Даже если они импортируют файлы друг у друга и способны обмениваться информацией через API, швы и молнии зачастую очень заметны. Более того, инструменты не способны распознать ключевые связи и отношения. Например, пользовательские ситуации повсеместно признаны в качестве модели, имеющей важное значение для объектно-ориентированного проектирования. Они поддерживаются некоторыми инструментами моделирования, однако связь пользовательских ситуаций с пользовательским интерфейсом не распо-знается большинством таких инструментов и пребывает исключительно в умах разработчиков.

Что же в таком случае мы хотим получить от наших инструментов, чтобы создавать высококачественные программы с помощью бесшовного проектирования? Нужно, чтобы поставщики инструментов выходили за пределы своих привычных представлений. Нужно, чтобы они поняли саму идею визуального проектирования — идею, которая так долго ждала своего часа (см. главу 18).

Программную систему можно рассмотреть с различных ракурсов. Каждый ракурс или точка зрения высвечивает определенные характеристики или аспекты системы, игнорируя или затеняя другие. Модель процесса, например, известная всем блок-схема, удобным образом описывает структуру алгоритмов, но почти (или совсем) не показывает данные. Модель предметной области эффективно представляет объектные классы и взаимосвязи между ними, но является бесполезной для дизайна экранных изображений. Тот факт, что общепринятые модели, применяемые в проектировании программного обеспечения, столько внимания уделяют конкретным аспектам систем, является не изъяном, а достоинством. Каждый ракурс позволяет упростить систему для определенных целей, тем самым помогая разработчикам говорить и думать о конкретных вопросах и задачах, возникающих при создании программного обеспечения.

Пользовательский интерфейс сам по себе является одним из таких ракурсов, представляя программу так, как она будет выглядеть с точки зрения конечного пользователя. Контент-модель показывает пользовательский интерфейс с точки зрения проектировщика и моделирует его содержание в отрыве от визуального представления или каких-либо графических интерфейсов (Constantine, 1998 [29]). Карта контекстной навигации представляет собой отображение всех составных частей пользовательского интерфейса и взаимосвязи между ними (более подробно о контент-моделях и навигационных моделях рассказано в главе 44).

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

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

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

Согласно методам разработки программ на основе ракурсов, целью разработчика становится построение системы с помощью различных ракурсов, которые полностью ее описывают и конкретизируют. Назначение инструментов проектирования — поддерживать создание основы программы, обеспечивая согласование между кодом (одним ракурсом) и всеми другими ракурсами. В любой момент каждый ракурс может применяться для обзора и модификации системы. Измените код, и вместе с ним изменится интерфейс. Измените модель, и изменится код. Создадите новую контент-модель, и в интерфейсе появится пустая форма. Добавите пользовательскую ситуацию, и в файле справки появится еще один раздел. Разработчик, который испытывает затруднения в одном ракурсе, может мгновенно переключиться на другой ракурс и продолжить свою работу.

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

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

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