Именно это предлагает хорошая система моделирующих обозначений — ясное, однозначное и легко понимаемое отображение программного обеспечения. В отличие от зеркала, хорошая система моделирующих обозначений не может дать детальную картину, «один к одному» соответствующую ее коду. Хорошая модель — это точное, но все же избирательное изображение программы, то есть ее намеренно упрощенное описание. Эффективность системы моделирующих обозначений для изображения задач и их программных решений зависит от того, каким образом достигается это упрощение. Сама суть преобразований между средой программирования и средой моделирующих обозначений должна быть простой, непосредственной, логичной и легко запоминаемой.
К сожалению, многие из существующих систем обозначений для программного анализа и проектирования не отвечают этим фундаментальным требованиям. Они чрезмерно сложны, непоследовательны и неясны. Их трудно запомнить и интерпретировать. А еще их слишком много.
Полное моделирование программного обеспечения — это сложный процесс. Он включает в себя рассмотрение множества статических и динами-ческих аспектов: структура и композиция информации, суть алгоритмов и их реализация в виде процедур, разбиение на составные части и взаимосвязи между частями. Если модель данных, процедурная модель, модель коммуникаций, модель состояния и функциональная структура программы слиты в единую схему с одной всеобъемлющей системой обозначений, то результат принимает причудливую форму, становится непонятным и визуально перегруженным.
Модели разработки программного обеспечения во многом служат той же цели, что и зеркало злой королевы. Системы обозначений должны делать ясным различие между прекраснейшими решениями и теми, которые всего-навсего прекрасны. Рассматривая модель, разработчики хотят знать, является ли их замысел здравым или глупым. Модель проектирования программного обеспечения — это не просто место хранения пока еще нереализованных идей. Такая модель позволяет разработчикам найти упущения и ошибки в замысле, а также сравнить разные подходы и выяснить, какой из них лучше. Вот почему хорошие разработчики рисуют картинки перед тем, как приступить к кодированию, — создать «бумажную» модель дешевле, чем создать программное обеспечение. Кроме того, хорошие модели помогают увидеть самый подходящий способ решения задачи.
Хорошая система обозначений предполагает простой, непосредственный и понятный способ преобразований модель-код, то есть позволяет писать код на основе модели или составить модель на основе существующего кода. Небрежная, неясная и неточная система обозначений приводит к небрежному, неясному и неточному преобразованию. Каждый визуальный элемент в системе обозначений должен соответствовать конкретному и существенному аспекту моделируемого программного обеспечения. Каждый важный элемент кода должен иметь возможность быть выраженным в системе обозначений.
Хорошая система обозначений позволяет создавать картины, которые можно интерпретировать аналитически, с помощью тщательного изучения деталей, и понять интуитивно как гештальт,[27] то есть как целое, представляющее общий характер системы. Сложные схемы должны выглядеть сложнее, чем простые. Хорошая архитектура должна быть визуально привлекательнее, чем плохая. Другими словами, хорошая система
.
обозначений позволяет разработчикам использовать оба полушария мозга; она помогает думать о проектируемой системе как с позиций логики, так и на основе интуиции.
Для точного и достаточно простого отображения программ хорошая система обозначений выделяет важные элементы и скрывает несущественные. Главные части и основные компоненты выделяются крупно, в то время как менее значимые детали становятся примечаниями или комментариями или совсем не обозначаются на схеме.
Картина сохраняет простоту, так как не отображает внутренних деталей. Компонент программы, который по сути является «черным ящиком», становится простым прямоугольником, нарисованным на экране или бумаге без отображения внутренних деталей. Здесь речь идет о целых программных блоках, а не об их внутреннем содержимом.
В идеале мы хотели бы получить такой инструмент контроля отображения, который достижим только с помощью компьютерных средств. Например, мы хотели бы просматривать схему коммуникаций между объектами, пробегая глазами мелкие элементы, а затем увеличивать масштаб, чтобы изучить взаимосвязи в какой-то одной части схемы. Мы могли бы увеличить какой-нибудь объект, чтобы узнать, какие методы он поддерживает. Делаем двойной щелчок мышью и видим код С++, определяющий данный метод. Или же мы могли бы переключиться в режим, в котором сценарий взаимодействия с пользователем совмещен со схемой коммуникаций между объектами, причем объекты, участвующие в данном сценарии, выделены или подсвечены.