Человеческий фактор в программировании - Ларри Константин

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

Ракурсы

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

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

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

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

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

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

Следы

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

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

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

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