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

Свою самую радикальную реализацию этот принцип находит в более упрощенных методах объектной технологии. Согласно этим методам, все, что вам требуется делать, — это смотреть на реальное окружение задачи и создавать объектные классы для всего, что вы там видите. Есть стул — вот вам, пожалуйста, стул! Мы создаем класс «стулья» в родительском классе «мебель». Слепое следование этому принципу приводит к топорным отображениям физических систем в неуклюжих программах. Еще одна трудность: ваше представление о реальности может не совпадать с моим.

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

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

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

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

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

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

Понятие сущностного моделирования в разработке программ происходит, по крайней мере, от идей структурного проектирования. Схемы потоков данных были придуманы в качестве непроцедурной модели вычислений, которая отделяла суть того, что должен был выполнить компьютер, от того, как это должно быть исполнено посредством алгоритма или процедуры. Модульная конструкция, соответствующая сути задачи, позволяет создавать более надежное программное обеспечение, основа которого сохраняется при изменениях в деталях процесса. По крайней мере, такова была идея. На практике схемы потоков данных зачастую превращались чуть ли не в обыкновенные блок-схемы с забавными символами. Последующие дополнения, такие как сохранение данных и управляю-щая логика, неявным образом способствовали процедурному мышлению. В конце концов сущностные модели получили признание с появлением книги «Essential Systems Analysis» (Основы системного анализа) (МсМе-namin и Palmer, 1984). Эта книга, признанная сегодня классической, сделала сущностные модели краеугольным камнем перестроенного и обновленного метода структурного анализа.

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

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

Разработка пользовательских интерфейсов — это одна из областей, где сущностные модели могут найти хорошее применение. Моделирование сущностных пользовательских ситуаций при проектировании интерфейсов является подходом, расширяющим разработанный Джекобсоном (Jacobson и др., 1992 [44]) метод объектно-ориентированных пользовательских ситуаций. Сущностная пользовательская ситуация — это абстрактный сценарий одного законченного и полезного взаимодействия с системой, рассматриваемого с точки зрения намерений или цели пользователя. Это обобщенное описание вида или категории использования системы, которое передает действия пользователя и ответы системы[28] в упрощенной и обобщенной форме. Суть идеи состоит в том, что разрабатываемые интерфей-сы должны соответствовать намерениям пользователей — тому, что пользователи хотят достичь. Исходные условия, связанные с технологией, — форма визуальных компонентов или даже вид устройств, применяемых для взаимодействия, — должны быть минимальны.

Для примера возьмем задачу по извлечению наличных денег из банкомата. Физическая модель может быть следующей: клиент вставляет карту; система читает информацию с магнитной полоски и запрашивает PIN-код;[29] пользователь вводит PIN-код; система подтверждает PIN-код и предлагает меню возможных операций; пользователь выбирает нужную операцию; система предлагает меню счетов; пользователь выбирает счет; система запрашивает сумму; пользователь вводит сумму и нажимает на кнопку подтверждения; система выдает наличность; пользователь берет деньги и убегает. Что может быть проще?

Лишенная физических подробностей и технологических предпосылок, сущностная пользовательская ситуация этой задачи заключается в простом процессе: клиент идентифицирует себя, система предлагает варианты действий, пользователь выбирает, система выдает деньги, пользователь берет их. Такое описание допускает намного больше вариантов для интерфейса пользователя. Оно открывает дорогу для множества способов, с помощью которых пользователю можно предложить различные варианты действий, а он сможет из них выбрать. К числу таких способов относятся сенсорный экран и голосовая система. Ясно, что карты или PIN-коды не являются необходимыми, так как их основная задача состоит в том, чтобы просто идентифицировать пользователя. В некоторых случаях может применяться сравнение отпечатков пальцев, сканирование радужной оболочки глаза, распознавание голоса, а также устройства чтения жетонов. Сущностная модель предоставляет много возможностей, тем самым увеличивая вероятность того, что отдельные части любого решения смогут быть повторно использованы, даже если условия и предпосылки изменятся.