Определение визуального моделирования

О пользе чертежей

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

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

В конце 60-х годов прошлого века исследователи в поисках способов упорядочивания и стандартизации процесса создания ПО обратились к другим, уже устоявшимся промышленным областям. Было замечено, что в строительстве, машиностроении, электротехнике и т. д. работы по созданию новых систем разбиваются на два основных этапа - проектирование и реализацию. Проектирование осуществляют архитекторы, конструкторы, инженеры, а изготовляют систему рабочие, строители, монтеры. Результаты проектирования фиксируются с помощью чертежей - схематичных изображений создаваемой системы. Эти чертежи служат хорошим интерфейсом между проектировщиками и теми, кто, собственно, создает, делает саму систему. Чертежи обязывают последних строго следовать принятым решениям, избавляя от необходимости думать над принципиальными вопросами. Главное уже продумано и решено, и все, что нужно - это разобраться в чертежах системы, понять, как и что нужно сделать, и сделать это. Ситуации, когда по ходу разработки приходится менять проектные решения, как правило, случаются крайне редко. Таким образом, чертежи сыграли важную роль в становлении современной промышленности, позволяя эффективно разделить труд между квалифицированными инженерами и обычными рабочими.

Аналогичным образом хотелось бы применять чертежи и в программировании. Однако здесь существуют некоторые особенности, которые не позволили использовать чертежное проектирование "as is".

ПО и другие инженерные объекты

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

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

Таким образом, можно выделить психический мир человека, где происходит эта не вполне понятная психологам деятельность человеческого сознания, а также физический мир воспринимаемый нами через органы чувств и где процессы более понятны и научно обоснованы. Эти миры человека сильно переплетены, связаны друг с другом. Например, абстрактные научные теории (несомненно, явления психического мира) приводят к созданию новых машин и механизмов (явлений физического мира). Доктор Бэйтс использовал воображение (психический инструмент) для улучшение зрения (физический эффект) [1.10]. В медицине и психологии известно большое количество "связок" физического и психического.

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

Фредерик Брукс в своей знаменитой статье "Серебряной пули нет" [1.1] выделил следующие характеристические признаки ПО, отличающие его от других инженерных объектов: невидимость, изменчивость, согласуемость (в основном с людьми - заказчиками и разработчиками, а также между различными категориями задействованных в его создании лиц), а также огромную сложность (другими словами - трудности концептуализации программных систем). Можно сказать, что ПО - это некоторый текст (программа на языке программирования), снабженный большим количеством ментальных (то есть психических) интерпретаций - от идеи целевого сервиса, который реализует данное ПО, до концепций его внутреннего устройства. Ну и, конечно, данный текст обладает вычислительной интерпретацией - программа должна исполняться вычислителем.

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

А вот, например, построенный дом, созданный автомобиль или подводная лодка - это полноценные объекты физического мира. Поэтому эти объекты можно увидеть. А значит, нарисовать, начертить.

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

Чертить ПО…

Итак, программное обеспечение, находится более в психическом, чем в физическом мире человека и оказывается невидимым. Поэтому его чертежи не привносят в проект той магической ясности, как чертежи (пусть даже очень сложные) строящегося здания, конструируемого самолета, монтируемой электроустановки. Не имея очевидных, зримых образов ПО, мы не можем однозначно сказать, как его изображать. Каждый склонен "видеть" и, соответственно, изображать ПО как-то по-своему или вовсе обходиться без этого. Среди программистов много скептиков в отношении визуального моделирования, и UML используется далеко не в каждом проекте.

Не все понятно и с тем, какую часть ПО имеет смысл изображать. Скорее всего, его архитектуру… Но в литературе по программной инженерии на настоящий момент существует более ста различных определений этого термина (вспомним о концептуальной сложности ПО, на которую указывал Брукс). То есть однозначности нет и в этом вопросе.

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

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

Метафора визуализации

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

Так возникают метафоры визуализации ПО - способы сопоставлять абстрактные и невидимые человеческому глазу элементы ПО некоторым зрительно воспринимаемым объектам. Метафорично ли это сопоставление, то есть используются ли при этом какие-либо знакомые зрительные аналогии или конструируются принципиально новые зрительные образы, - вопрос философский. Важно лишь всем договориться, что ПО мы видим и изображаем так-то и так-то, тем самым задействовав зрительный канал при проектировании и разработке ПО, при передаче знаний о создаваемых и уже созданных и работающих программных системах. В этом смысле неоценимую пользу оказывает развитие стандартных визуальных языков разработки ПО. В настоящее время это, в первую очередь, UML. Люди привыкают к изображениям классов, пакетов, объектов, процессов и пр., к определенному набору диаграмм. Они привыкают мыслить, строя те или иные диаграммы UML. А другие легко читают эти мысли в этих диаграммах. То есть с помощью стандартных визуальных языков мы все вместе договариваемся, как видеть невидимое. Может быть, мы скоро начнем действительно видеть ПО…

Существует большое количество различных метафор для изображения ПО. На рис. 1.1 представлен пример, изображающий условное предложение if B then S1 else S2; S3 с использованием графического языка VIPR (VIsual Imperative Programming) [1.11]. Однако очевидно, что большие программы так изображать неудобно…

Рис. 1.1. Условное предложение в нотации языка VIPR