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

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

ри подсистемы или взаимодействие подсистем между собой, вы оказываетесь беспомощны. Менеджеры слушают, изображают графически то, что, как им кажется, они услышали, показывают рисунки разработчикам и обычно получают в ответ: «Угу. Наверно. Может быть».

Здесь необходимо проявлять осторожность. Агитируя за графику, следует отметить ее ограниченность. Насколько графика позволяет передавать ценную информацию, настолько же она способна выражать различную ложную информацию. Речь идет не о детальных технических чертежах, содержащих неточности - последние быстро обнаруживаются. Подлинно опасными оказываются картинки «уровня менеджмента», какие часто встречаются в презентациях PowerPoint. Эти картинки претендуют на то, чтобы сообщить нам что-то, но на практике обычно оказываются чрезвычайно неясными и расплывчатыми. Они не сильно превосходят наборы графических примитивов. Каждый может понимать их, как ему угодно. Поскольку они бывают лишены всякой содержательности, большинство разработчиков относится к ним с полным презрением. И поскольку большинство разработчиков не считают своей обязанностью точно отображать создаваемые ими системы с помощью графики, мы заходим в тупик.

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

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

Как рассказывать об UML.

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

На практике я обнаружил, что разработчикам ПО бывает трудно объяснить нюансы своего ремесла другим профессионалам-инженерам. Во время поездки в Китай мне пришлось объяснять, что такое универсальный язык моделирования (Unified Modeling Language - UML) и каково его значение, техническим менеджерам, которые не были профессионалами в программировании. Я не ожидал, что такое препятствие возникнет, но когда я впервые произнес «UML», то увидел обращенные ко мне непонимающие взгляды. Я не мог двигаться дальше, не объяснив им, что такое UML. Но как это сделать?.

Ниже следует 10-минутная презентация, которую я быстро сочинил, а впоследствии отшлифовал.

Что такое UML и в чем его значение?.

Начнем с простого примера. В каком бы уголке света я ни написал на доске:.

1 + 1 =.

все поймут, что я хочу сказать. Как правило, кто-нибудь из присутствующих всегда выступит и скажет «2!». После этого я завершаю равенство:.

1 + 1 = 2.

и объясняю, что нас не только понимают всюду в мире, но и обычно подсказывают правильный ответ.

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

На первый взгляд этот пример кажется тривиальным, но в действительности он демонстрирует поразительный факт: числа универсальны, а такие символы, как + и = , всюду имеют одинаковый смысл.

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

Второй, менее тривиальный пример.

Мне пришлось согласиться, что этот первый пример, вероятно, излишне прост. Поэтому я начертил на доске треугольник (рис. 6.1).

Затем я отмечаю, что этот треугольник приобретает новое значение, если я дополню чертеж, как на рис. 6.2.

Рис. 6.2. Прямоугольный треугольник.

Теперь этот треугольник вне всякого сомнения оказывается прямоугольным, потому что маленькая квадратная штуковина по общепринятому соглашению означает прямой угол. Кроме того, я теперь могу пометить стороны треугольника буквами A, B и C, как на рис. 6.3.

Рис. 6.3. Поименованный прямоугольный треугольник.

И теперь я могу написать, что

A

+ B

= C

Теперь у моего примера появилось несколько поучительных особенностей. Во-первых, это опять пример универсальной нотации. Прямые углы, прямоугольные треугольники и представляющие их символы всюду одинаковы, и в принципе с помощью таких схем древний египтянин мог бы обсуждать прямоугольные треугольники с современным перуанцем. Кроме того, начерченная схема прямоугольного треугольника определяет соотношение между его сторонами A, B и C. Теперь A, B и C не могут быть абсолютно произвольными величинами: если заданы любые две из них, то определена и третья. Эта схема заключает в себе теорему Пифагора. Можно даже утверждать, что у этой диаграммы есть некая «семантика», что существует понятная связь между картинкой и значениями, выраженными буквами.

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

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

Третий пример.

Приведенные выше примеры демонстрируют пользу универсальной системы обозначений. Проблема в том, что оба они взяты из мира математики, а математика, хотя имеет конкретные приложения, абстрактна по своей сути. А можно ли привести пример не из области математики?.

Я нарисовал на доске рис. 6.4.

Рис. 6.4. Первая электрическая цепь.

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

И смелыми завершающими штрихами я показываю, что если батарея дает напряжение 6 вольт, а сопротивление резистора составляет 6 ом, то в цепи течет ток в 1 ампер, как показано на рис. 6.6.

Что такое шестивольтовая батарейка, люди знают: ее можно купить в магазине. И большинство вспомнит, пусть смутно, что электрическое сопротивление измеряется в омах. Поэтому, когда вы наконец пишете на схеме «1 А», т. е. в цепи протекает ток в 1 ампер (я даже указываю направление то-

ка!), все совершенно уверены, что знают, о чем вы говорите, даже если не помнят закон Ома.

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

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

Кстати, я уже переместил порог восприятия до уровня тех, кто прослушал годичный курс по основам физики.

А теперь вспомним о программах...

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

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

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

Вклад Rational Software в этой области был огромен. Разработать UML и заставить крупнейшие мировые компании, такие как IBM, Microsoft, HP, Oracle и другие, согласиться с ним, было огромным шагом. Принятие UML в качестве стандарта международным органом - группой управления объектами (Object Management Group) - стало формальным процессом, необратимо изменившим положение. Строительство Вавилонской башни прекратилось, и все согласились с тем, как надо описывать программы.

Итак, значение UML установлено, и можно двинуться дальше.

Выходим на новый уровень абстракции.

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

Любопытно в нашем обзоре то, что для объяснения сути системы технических обозначений я обратился к аналогии. Мне удалось обойти западню «самоссылки», т. е. я объяснил UML, не описывая самого UML. Я описал жаргон, не обращаясь к жаргону. Сначала это покажется уверткой («послушайте, мне же не показали ни одной диаграммы UML!»), но на самом деле уметь описать предмет, не пользуясь им самим, необходимо.

В противном случае «население» окажется не в состоянии воспринять первую же диаграмму, которую вы начертите. Благодаря же такому вводному контексту, я считаю, первая UML-диаграмма будет воспринята гораздо лучше. Аудитория вернется к «1+1», теореме Пифагора и закону Ома и поймет, что то же самое вы делаете для программных конструкций.

Резюме.

U ML действительно стал lingua franca для описания ПО. Это хороший пример того, как вместо попытки сохранить закрытый стандарт можно отказаться от интеллектуальной собственности с целью дать толчок принятию отраслевого стандарта. В результате несколько компаний смогли заняться созданием инструментов для поддержки UML. Никому не пришлось создавать собственный стандарт, и конкуренция возникла на уровне инструментов, а не на уровне системы обозначений. Это в свою очередь принесло ту пользу, что диаграммы, созданные разными инструментами, были понятны, поскольку в них была задействована одинаковая система обозначений и семантика. В большинстве сфер человеческой деятельности это принято называть прогрессом.

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

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

Для нас, менеджеров, есть несколько иное препятствие. Дни, когда мы писали код, миновали, но развитие языков продолжается. Как же нам освоиться с новейшим языком? Это будет темой следующей главы.