Задумывались ли вы, почему так много людей учат иностранные языки: инглиш, дойч, франсе...?

Некоторые платят весьма значительную часть заработанных средств для того, чтобы после работы идти не к любимому телевизору с полноценным ужином, а совсем в другое место. Наспех перекусив йогуртом с бананом, эти люди вечером едут в переполненном метро в другой конец города, где их ждут неправильные глаголы, произношение, правила и исключения чужого, неуютного языка. После того, как учащийся поздно вечером возвращается с занятий домой, он все равно не может расслабиться с любимой книжкой. Его ждет домашнее задание: аудирование, грамматика, эссе. Лишь часам к двум ночи, выполнив уроки - и это в 30-40 лет-то! - ученик может позволить себе уснуть. И этот факт абсолютно никак не влияет на то, что ему завтра (точнее - уже сегодня) к 9 утра на работу. Значит, подъем - где-то около 7 утра. Итого: 5 часов сна. И так продолжается 3 раза в неделю, долгие месяцы и годы.

Что же мотивирует людей на такие жертвы? Жертвы времени, денег, сна и нервных клеток.

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

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

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

Пожалуй, лучший ответ на этот вопрос был дан еще в конце 80-х начале 90-х годов прошлого столетия. Это - язык UML, он же - Unified Modeling Language, он же - Универсальный Язык Моделирования. Секрет Полишинеля и, одновременно, рояль в кустах для многих IT-шников. Уникальность данного языка даже не в его универсальности, а в том, что многие о нем что-то знают, но почти никто не может воспользоваться всем предлагаемым богатством для моделирования на разных уровнях абстракции. Часто участники софтверной разработки произвольным образом используют логические и графические конструкции UML, даже не пытаясь понять их истинного предназначения. "Забивать микроскопом гвозди" - очень верная метафора для данной ситуации.

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

А делать можно действительно многое: проектировать софтверные системы на различных уровнях детализации. Модели вариантов использования, алгоритмы расчета, логика перехода состояний системы, схемы компонентов системы и их размещения в "физических" носителях (артефактах и устройствах) - далеко не полный список возможностей проектирования на этом "эсперанто" IT-шного мира.

Помимо создания локальных моделей, UML позволяет проектировать связи зависимостей между отдельными элементами: классами, свойствами, компонентами, пакетами. Наличие этих связей позволяет разработчикам быстро оценить стоимость изменений продукта.

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

Многие современные средства проектирования (например, Sparx Enterprise Architect), используя созданные конструкции UML, автоматически генерируют фрагменты кода. В конце 20 века об этом можно было только мечтать!

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

Команда разработчиков, один раз выбрав UML, уже никогда от негоне откажется. Строгость, наглядность и краткость - вот что отличает его от естественного языка общения. Инвестиции времени и денег в изучение UML окупаются сторицей. Команда разработчиков из банды, говорящей, в основном, жестами и на "птичьем" языке, вдруг превращается в коллектив, общающийся на едином универсальном, понятном IT-шникам всего мира, языке. "Речь" членов команды становится ясной и четкой. Документация избавляется от двусмысленностей и противоречий. Аутсорсеры перестают надоедать частыми вопросами.

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

Сергей РУБАНОВ,
CSBA, тренер по бизнес-анализу в учебном центре "БелХард"