Декабрьский номер журнала CrossTalk по программной инженерии полностью посвящен современным походам к построению архитектуры сложных ИТ-систем. При этом, пожалуй, впервые за все годы своего существования это издание делает самые серьезные акценты на системной инженерии. Да и инновационно-прорывная тематика в финальном номере года выглядит весьма знаковой и многообещающей.
Открывает номер программное интервью с Гради Бучем -- создателем универсального языка моделирования UML, автора настольных книг по объектно-ориентированному проектированию. Желающие могут прочитать полное интервью самостоятельно -- номер можно скачать тут: http://www.crosstalkonline.org/storage/issue-archives/2010/201011/201011-0-Issue.pdf
Предлагаю сокращенный пересказ наиболее интересных мест интервью. Другие не менее важные материалы номера тоже обязательно обсудим и проанализируем.
- Куда идет UML?
- UML 2.0 оказался излишне сложен, и он будет развиваться в сторону упрощения. Не в том смысле, что следующая версия будет качественно новой и несовместимой с предыдущими, просто будет проведен серьезный рефакторинг UML.
Кроме того, пользователи графических сред проектирования в погоне за визуальными "эффектами" часто забывают основное назначение этого языка -- моделирование. Поэтому будет усилена семантическая составляющая UML, дабы этот язык можно было применять, например, к задачам реверс-инжиниринга (Гради упоминает эту технологию, учитывая контекст интервью -- CrossTalk издание военное), раскопки и изучения данных, их жизненному циклу. На базе UML мы постараемся поддержать и стандарты биологического моделирования, классические системы систем -- например, для моделирования поведения клетки в биологическом организме.
- Что делать со сложностью в крупных проектах?
- Уровень сложности в современных военных системах значительно выше сложности любой коммерческой системы в мире, но при этом в гражданских областях наработано множество замечательных практик и методологий, которые полезно изучать и внедрять.
Кстати, интересен подход Буча к анализу подобных проектов: он выискивает не шаблоны успеха в удачных проектах, а анти-паттерны, характерные для проектов неудачных, и после их анализа формулирует правильные стратегические направления ИТ-развития крупных организаций. Таких направлений три.
1. Следование принципам open source. Опенсорсные платформы.
МО США создало сайт Force.mil по аналогии с SourceForge.org, который открывает путь к повышению прозрачности и понятности эксплуатируемых программных систем, упрощает повторность использования кода и хорошо помогает в обучении.
2. Коллаборативная инфраструктура.
В создании и развертывании сложных систем участвует много субподрядчиков, подчас разбросанных по всему миру, поэтому следует всесторонне развивать средства коллективного взаимодействия. При этом классических вещей Web 2.0 типа вики и совместных виртуальных досок для некоторых форм обсуждений может и не хватить -- сегодня уже надо смотреть в сторону более продвинутых средств наподобие виртуальных миров.
3. Соотношение между архитектурой и артефактом.
Буч покритиковал военный фреймворк Department of Defense Architecture Framework, в котором основной акцент сделан на стандартах. Стандарты конечно очень важны, но в сверхкрупных системах ключевым становится само соотношение между архитектурой и артефактом -- когда архитектура на некотором этапе сама превращается в артефакт, стыкуемый с другими артефактами-архитектурами в рамках мета-архитектуры, и т. п.
- Каков ближайший ожидаемый в плане эффективности шаг в деле создания программных систем?
- Это рост нашего понимания системной инженерии. Сейчас системы создаются примерно так: "сюда поставим вот такую периферию, и вот такие процессоры, затем программеры напишут код, и все заработает". Но в терминах системной инженерии вы не можете трактовать софт как что-то, что можно отложить в сторону. ПО -- это внутренняя, существенная, неотъемлемая и универсальная часть системы. Посему, нам надо двигаться к включению в системную инженерию все большего и большего числа практик по созданию чистых софт-систем, потому что все современные военные комплексы программно-аппаратные, но программная специфика часто недооценивается.
Международная организация по развитию системной инженерии INCOSE также начинает двигаться в этом направлении, стимулирует появление новых языков -- например, SysML [Systems Modeling Language, расширение UML]. Но пока у нас есть лишь малое число ответов, и мы движемся почти на ощупь.
- Что же случится с языками программирования под воздействием программной инженерии?
- В исследовательских языковых вещах я, например, возбужден тем, что происходит в аспектно-ориентированном программировании. В то же время я бы не назвал уровень аспектов наивысшим уровнем абстракций. В этом направлении развиваются и мэйнстримовские языки наподобие С++, о чем можно судить по изменению их стандартов -- хоть и инкрементальному, но весьма важному.
И все же основные изменения случатся со стороны программной инженерии (программирования в большом). Какие же это будут изменения и какие силы приводят в действие эти изменения?
Сначала посмотрим на стимулы изменений.
Прежде всего, наличие огромного числа легаси-систем. Инвестиции в них огромны, а интеграционные подходы наподобие сервисных архитектур SOA помогают лишь частично.
Другая причина -- мультиядерные системы. Выполнить декомпозицию легаси-решения и пересобратьь его для работы в параллельной архитектуре очень и очень тяжело.
Проблемы с безопасностью. Чем сложнее система, тем труднее выявить в ней все каналы утечек.
Но у меня есть и хорошие новости. Мы сейчас хорошо понимаем, как могут совместно работать сильно формализованные процессы и гибкие agile-процессы. В ближайшей перспективе следует ожидать роста практик "архитектура как артефакт", а в более длительной -- уменьшения роли программной инженерии и увеличения роли системной инженерии.
- Имеются ли какие-то ограничивающие параметры, мешающие новым прорывам в программной инженерии?
- Я не верю в прорывы. Реальный прогресс и изменения в науке и в ПО приходят от слияния многих вещей. Я больше эволюционист, нежели революционер, и объектно-ориентированное проектирование -- вещь эволюционная.
В дополнение к вышеназванным факторам я назову еще один: сложность. Мы создаем системы, которые уже давно за пределами интеллектуальных возможностей одного человека. И нам не хватает подходящихs нотаций, процессов и средств измерений -- это то, что отбрасывает нас назад. Это крайне серьезная проблема.
во второй части интервью Гради Буч расскажет про триллион строк кода, пояснит, как рождаются инновации, и укажет, в чем же сила
