`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Alloy -- инструмент инженера

0 
 

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

Дэниел Джексон

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

Alloy -- инструмент инженера
Встроенный редактор по­спартански строгой интегрированной среды Alloy Analizer не поддерживает подсветку синтаксиса языка Alloy. Но свято место пусто не бывает -- для многих популярных текстовых редакторов существуют файлы описания синтаксиса Alloy
Alloy -- инструмент инженера
Разработчики Alloy Analyzer для решения задач визуализации использовали возможности пакета GraphViz, которому некогда была посвящена отдельная статья -- "Швейцарский нож, или Визуализация графов" ("Компьютерное Обозрение", # 22, 2001)
По мнению ведущего разработчика Alloy, адъюнкт-профессора Массачусетского технологического института Дэниела Джексона, всех специалистов в области программной инженерии (software engineers) можно условно разделить на два основных класса -- с "головами-котелками" (thinkers, иначе -- "мыслители") и с "головами-жестянками" (tinkers, иначе -- "жестянщики"). Первые являются сторонниками строгих высокоуровневых методов разработки, они испытывают чувство удовлетворения от процесса понимания проектных проблем, их обсуждения и решения, и, наконец, главное для них -- чтобы в проектном процессе "все было правильно" (тут уже никаких особенных уточнений "правильности" и быть не может, потому как само это понятие зависит от подготовки, класса и практического опыта специалиста). Вторые -- настоящие мастера адской низкоуровневой механики, для них куда важнее факт "вроде как правильного" первого запуска тестовой версии программы, чем углубленное понимание общих принципов, лежащих в основе правильного функционирования (а в особо тяжелых случаях и вообще принципиальной работоспособности) системы. Роль "мыслителей" в проектном процессе не гарантированно положительна -- они вполне способны утащить проект в дебри "идеальных спецификаций идеальных интерфейсов". Равно как и "жестянщики" могут наносить тяжелый урон проекту, возводя в ранг основного проектного решения обычные низкоуровневые модификации, грубо говоря -- хаки. И при этом обе категории инженеров соответствующей квалификации, смешанные в правильных пропорциях, являются обязательным ингредиентом того волшебного лекарства, которое "доктор прописал" любому творческому процессу. "Мыслители" обеспечивают живучесть разрабатываемой системы в течение продолжительного периода (обеспечивают стратегию), "жестянщики" отвечают за текущие достижения (тактику) и тем самым прямо и косвенно финансируют стратегию.

Кстати, весьма наглядный пример косвенного влияния лекарства на одного больного (многие считали и считают его вообще смертельно больным) демонстрирует сообщение, размещенное 18 октября этого года на сайте SecurityFocus Михалом Залев-ски (автором утилиты p0f пассивного обнаружения типа ОС удаленного компьютера, lcamtuf.coredump.cx/p0f.shtml). Залевски с помощью небольшой разработанной им программки (исходные тексты которой доступны по адресу lcamtuf.coredump.cx/soft/mangleme.tgz) подавал на "входы" распространенных браузеров короткие фрагменты... неправильного, не соответствующего стандартам HTML-кода. Подобная забава вскрыла весьма неожиданные и совсем не забавные результаты. Оказалось (вдруг), что не только мощные графические браузеры Mozilla (и ее коммерческий родственник -- Netscape), Firefox и Opera, но даже и знаменитые "легковесы" -- текстовый Lynx и "почти текстовый" Links -- "kept crashing on a regular basis due to NULL pointer references, memory corruption, buffer overflows, sometimes memory exhaustion" (автор специально оставил текст оригинала сообщения Залевски без перевода). Единственным действительно не замеченным в уязвимостях при нарушениях такого рода оказался... "тот самый" Internet Explorer. Можно до хрипоты спорить (что, собственно, и происходило в ходе обсуждения этого "открытия" на сайте slashdot.org) о чем угодно, но нарушения функционирования программы, вызванные обрабатываемыми ею данными (а HTML -- как раз то, что обрабатывается браузером), -- это одновременно и свидетельство невысокого качества проектирования программы (именно проектирования, а не кодирования), и реальная возможность использовать такие нарушения умышленно (точнее, злоумышленно). Мы не будем обсуждать тот факт, что до Залевски почему-то никто из разработчиков Mozilla, Firefox, Lynx и Lincs не додумался до такого простого эксперимента, нам сие безразлично. Для нас важнее то, что перечисленные программы рождаются и совершенствуются в ходе определенных проектных процессов. У этих процессов есть характерные свойства и особенности, в перечне которых немаловажную роль играет, если так можно выразиться, их пригодность к созданию и эффективному использованию упомянутого волшебного лекарства, а именно, -- к привлечению нужного количества и формированию правильного соотношения программных инженеров двух типов.

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

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

История "браузерной войны", рассказанная программными инженерами

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

Предшественница Netscape -- группа разработчиков NCSA Mosaic из Иллинойского университета не задавалась целью создать "долгоиграющий" проект. Используя классификацию Д. Джексона, в этой команде преобладали "жестянщики", и они добились тактического успеха -- создали Mosaic быстро и быстро же добились его работоспособности. Они же и организовали Netscape и в сжатые сроки (апрель--декабрь 1994 г.) выпустили кросс-платформенный Netscape Navigator 1.0. Второй участник "браузерной войны" -- Microsoft -- начала разрабатывать Internet Explorer в октябре 1994 г. и выпустила его на рынок в августе 1995 г.

В период бурного роста (1995--1997) "жестянщики" из Netscape трудились очень много и интенсивно под девизом: "Новые версии, новые возможности, быстро!" На дизайн браузера времени просто не оставалось. И код, и численность команды разработчиков росли катастрофически быстро -- над тремя миллионами строк Communicator 4.0 уже трудилась команда из 120 человек. В Microsoft поначалу тоже попытались втянуться в эту гонку, но к третьей версии Explorer поняли, что продукт нуждается в радикальных изменениях. К 1997 г. Netscape предприняла отчаянную попытку создать свой браузер заново -- перейти к модульному дизайну хотя бы для того, чтобы уменьшить команду разработчиков и облегчить использование уже написанного кода (по воспоминаниям релиз-менеджера Netscape Михаэля Тоя: "...мы были действительно в ужасной ситуации... мы должны были отказаться от этого кода еще год назад -- он мертв... мы расплачивались за поспешность"). План двухмесячного реинжиниринга, направленного на превращение монолитного браузера в компонентный или хотя бы модульный, провалился. Netscape попыталась создать с нуля Communicator 6.0 -- но задача оказалась непосильной (возможно, потому, что в команде до сих пор преобладали "жестянщики"). Разработчики так никогда и не реализованной "шестерки" были переброшены... на прежний код -- расплату за поспешность, и ими была предпринята вторая попытка изменения архитектуры, известная сегодня под названием Mozilla. Освобождение исходных текстов последней, по сути, ничего не изменило в итогах "браузерной войны" -- компонентный Explorer, несмотря на все его недостатки, оказался более пригодным и к модернизациям, и к повторному использованию сторонними компаниями в своих разработках.


Что моделировать, чем моделировать, зачем моделировать

Мы не будем углубляться в дебри синтаксиса и семантики языка Alloy -- все это описано в документации и многочисленных статьях, доступных на сайте проекта (alloy.mit.edu). Вместо этого попробуем взглянуть на Alloy по-другому... в полном соответствии с основными идеями этого языка и сопутствующей инструментальной системы.

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

Для того чтобы отыскать четкий, лаконичный ответ на столь же четкий и лаконичный вопрос: "А что же именно моделируется с помощью Alloy?", -- вам придется изрядно поработать не только с документацией, но и с "сопутствующими" статьями и публикациями, в разное время написанными участниками проекта. Ответ будет прост: "Предназначение Alloy -- моделирование и анализ конечных автоматов (state machines), характеризующихся сложными состояниями". Тем, кто знаком с теорией и практикой конечно-автоматного моделирования систем, следует обратить внимание на использованное словосочетание "сложные состояния" и не спешить вешать на Alloy ярлык "еще одной утилиты, каких и без того немало". В отличие от большинства программ аналогичного назначения, Alloy не создавался для анализа, например, параллельно работающих конечных автоматов с огромным числом примитивных состояний. Напротив -- сила Alloy в том, что описываемые с его помощью состояния моделируемой системы могут характеризоваться не просто очень сложными структурами данных -- таблицами, списками, деревьями, но и ограничениями на множества возможных значений этих данных. В указанном нюансе кроется и одно из фундаментальных отличий Alloy от разнообразных систем верификации (формальной проверки правильности) моделей: цель Alloy-анализа -- не доказательство "правильности", а поиск "неправильностей", в терминах Alloy именуемых контрпримерами (counter-example). Иначе говоря, успешное (без контрпримеров) Alloy-моделирование позволяет утверждать, что для использованных в модели множеств значений данных система будет правильно функционировать.

Естественно, неоднократно упомянутый термин "множество" здесь не случаен... можете считать это предупреждением -- перед изучением Alloy очень полезно повторить основы курса теории множеств и реляционной алгебры. На самом деле "очень полезно" здесь следует читать как "обязательно" -- освоить фундаментальные понятия декларативного языка Alloy без этих двух в любом случае полезных разделов математики будет трудно. И уж раз речь зашла о декларативном характере Alloy, следует заметить, что и здесь этот язык весьма специфичен и нетривиален. Сущест-вующая классификация декларативных языков выделяет три их основные категории -- функциональные, логические и эквациональные (equational). Функциональных и логических декларативных языков имеется немало, достаточно упомянуть только знаменитые Lisp (функциональный) и Prolog (логический). А вот представители эквациональной категории -- это, можно сказать, редкость. К такой вот редкости и относится Alloy, причем окончательно исключается возможность изучения этого языка с наскока и по аналогии его нацеленность на описание семантики объектов в объектно-ориентированном программировании. Все эти проблемы с лихвой компенсируются главным принципом (обеспеченным идеологией) Alloy -- усложнение модели программы здесь приводит к ужесточению ограничений на возможное поведение моделируемой системы. Иначе говоря, пространство допустимых, "правильных" состояний моделируемой программы при увеличении объема Alloy-кода... сокращается. Свойство более чем полезное, если учесть тот факт, что созданные на основе императивных языков программирования системы при возрастании объемов кода пространство состояний расширяют. Такие противоположности, как показывает инженерная практика, лежат в основе весьма эффективных подходов к проектному процессу -- вспомним хотя бы сочетание нисходящего проектирования и восходящей реализации.

Перед тем, как поставить последние точки над "i", остается разве что еще раз вернуться к главному вопросу, которым задается любой специалист при знакомстве с некоторой потенциально привлекательной технологией, требующей существенных затрат времени и ресурсов на ее освоение. Естественно, это короткий вопрос: "А надо ли оно мне?". Он на самом деле скрывает за собой множество нюансов. Так, Alloy совершенно бесперспективен в качестве "усилителя статуса" -- в отличие от востребованного большинством работодателей UML, за знание Alloy доплачивать не будут. Разработчик-одиночка, владеющий таким инструментом, также не особо интересен для большого проектного коллектива, работающего в условиях жестко ограниченных ресурсов и времени. Скорее всего, Alloy-моделирование перспективно при создании высоконадежного ПО для встраиваемых систем, сетевых сервисов и т. д. -- т. е. в тех областях, где риски могут быть весьма высокими, а ресурсы разработчика не позволяют использовать "тяжелые" и дорогие методики проектирования и верификации. И наконец, Alloy способен стать удачным выбором для создателей ПО, распространяемого на основе "открытых лицензий" (GNU, BSD и т. п.), в первую очередь для тех, кто хочет улучшить качество уже написанного кода методами реинжиниринга.

Итак, с чего начать знакомство с Alloy? Во-первых, существующая реализация инструментального набора системы (Alloy Analyzer) кросс-платформенна и может работать под управлением различных представителей как Unix-совместимых ОС, так и семейства Windows. Во-вторых, для функционирования Alloy Analyzer требуется среда времени исполнения Java-версии не ниже 1.2. В-третьих, постарайтесь загрузить с сайта проекта alloy.mit.edu всю доступную документацию, включая презентации и публикации. Дело в том, что основной документ языка Alloy -- Reference Manual -- трудно назвать доработанным, и упущенное в нем приходится наверстывать из косвенных источников. Не спешите воспользоваться онлайн-руководством по языку Alloy -- вы готовитесь не к тому программированию, в котором язык пробуется на зубок сразу (даже если у вас приличный опыт работы с декларативными, функциональными или логическими языками).

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

0 
 

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT