Статья в формате PDF - Кафедра «Технологии программирования
10.06.2015 • Views
Share Embed Flag

Статья в формате PDF - Кафедра «Технологии программирования

Статья в формате PDF - Кафедра «Технологии программирования

Статья в формате PDF - Кафедра «Технологии программирования

SHOW MORE
SHOW LESS
ePAPER READ
DOWNLOAD ePAPER
is.ifmo.ru

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

START NOW

<strong>Статья</strong> опублико<strong>в</strong>ана <strong>в</strong> журнале “Информационно-упра<strong>в</strong>ляющие системы”. 2005. № 6, с. 9 – 22.<br />

УДК 602-507<br />

ВИЗУАЛЬНОЕ КОНСТРУИРОВАНИЕ ПРОГРАММ<br />

Ф. А. Но<strong>в</strong>ико<strong>в</strong>,<br />

канд. физ.-мат.наук<br />

Санкт-Петербургский государст<strong>в</strong>енный политехнический уни<strong>в</strong>ерситет<br />

В статье описы<strong>в</strong>ается подход к проектиро<strong>в</strong>анию и реализации набора компоненто<strong>в</strong>,<br />

соста<strong>в</strong>ляющих <strong>в</strong> со<strong>в</strong>окупности инструментальное средст<strong>в</strong>о, осно<strong>в</strong>анное на<br />

UML и поддержи<strong>в</strong>ающее <strong>в</strong>се фазы процесса разработки приложений.<br />

В<strong>в</strong>едение<br />

В настоящее <strong>в</strong>ремя эффекти<strong>в</strong>ность и результати<strong>в</strong>ность процесса разработки программного<br />

обеспечения <strong>в</strong> целом оста<strong>в</strong>ляет желать лучшего. Несмотря на заметные<br />

успехи технологии программиро<strong>в</strong>ания, остается <strong>в</strong>есьма значительной доля проекто<strong>в</strong><br />

по разработке программного обеспечения, которые нельзя считать <strong>в</strong>полне успешными.<br />

Наряду с эффектными достижениями имеются и сра<strong>в</strong>нительно многочисленные<br />

досадные неудачи (обзор со<strong>в</strong>ременного состояния, например, <strong>в</strong> работе<br />

[1]). К сожалению, до сих пор слишком часто приходится делать <strong>в</strong>ы<strong>в</strong>од, что программиро<strong>в</strong>ание<br />

– это риско<strong>в</strong>анный бизнес, программы ненадежны, а программисты<br />

неупра<strong>в</strong>ляемы.<br />

Дальнейший прогресс <strong>в</strong> области со<strong>в</strong>ершенст<strong>в</strong>о<strong>в</strong>ания процесса разработки за<strong>в</strong>исит<br />

от множест<strong>в</strong>а факторо<strong>в</strong>, таких как со<strong>в</strong>ершенст<strong>в</strong>о<strong>в</strong>ание аппаратной базы компьютеро<strong>в</strong>,<br />

<strong>в</strong>недрение со<strong>в</strong>ременных форм организации коллекти<strong>в</strong>ного труда разработчико<strong>в</strong>,<br />

разработка и использо<strong>в</strong>ание но<strong>в</strong>ых информационных технологий и так далее.<br />

Многие полагают, и а<strong>в</strong>тор разделяет это мнение, что одним из ключе<strong>в</strong>ых факторо<strong>в</strong><br />

я<strong>в</strong>ляется со<strong>в</strong>ершенст<strong>в</strong>о<strong>в</strong>ание методо<strong>в</strong> и инструменто<strong>в</strong> <strong>в</strong>изуального моделиро<strong>в</strong>ания<br />

и (<strong>в</strong> перспекти<strong>в</strong>е) конструиро<strong>в</strong>ания законченных приложений. Ожидается, что языки<br />

<strong>в</strong>изуального моделиро<strong>в</strong>ания должны стать такой же абстракцией над языками<br />

программиро<strong>в</strong>ания, какой языки программиро<strong>в</strong>ания я<strong>в</strong>ляются над аппаратной<br />

платформой. Именно эта идея положена <strong>в</strong> осно<strong>в</strong>у инициати<strong>в</strong>ы, наз<strong>в</strong>анной MDA<br />

(Model Driven Architecture) – архитектура, упра<strong>в</strong>ляемая моделью [2]. Разработку на<br />

осно<strong>в</strong>е моделей будем назы<strong>в</strong>ать модельно-ориентиро<strong>в</strong>анной разработкой.<br />

Наиболее многообещающим <strong>в</strong> этой области за последние годы предста<strong>в</strong>ляется поя<strong>в</strong>ление<br />

и распространение унифициро<strong>в</strong>анного языка моделиро<strong>в</strong>ания UML [3]. Разумеется,<br />

UML – это исторически далеко не пер<strong>в</strong>ая попытка <strong>в</strong><strong>в</strong>ести <strong>в</strong> программиро<strong>в</strong>ании<br />

чертежи, понятные <strong>в</strong>сем. В<strong>в</strong>едение же <strong>в</strong> по<strong>в</strong>семестную практику программиро<strong>в</strong>ания<br />

чертежей (именно чертежей, как определяющих документо<strong>в</strong>, а не просто<br />

иллюстраций, относящихся непонятно к чему) я<strong>в</strong>ляется признаком того, что программиро<strong>в</strong>ание<br />

дейст<strong>в</strong>ительно я<strong>в</strong>ляется инженерной областью деятельности. Пока<br />

же, по мнению а<strong>в</strong>тора, термин "инженер-программист" я<strong>в</strong>ляется скорее благим пожеланием,<br />

нежели констатацией к<strong>в</strong>алификации.<br />

1

Эта статья не я<strong>в</strong>ляется апологией UML. Оче<strong>в</strong>идная перегруженность языка, рыхлое<br />

описание и туманная семантика бросаются <strong>в</strong> глаза. Но нельзя отрицать тот факт,<br />

что <strong>в</strong> UML <strong>в</strong> унифициро<strong>в</strong>анном <strong>в</strong>иде удалось аккумулиро<strong>в</strong>ать множест<strong>в</strong>о разнообразных<br />

плодот<strong>в</strong>орных идей, а сообщест<strong>в</strong>о носителей языка да<strong>в</strong>но переросло критическую<br />

отметку из<strong>в</strong>естности. UML я<strong>в</strong>ляется признанным лидером <strong>в</strong> обсуждаемой<br />

области и останется тако<strong>в</strong>ым <strong>в</strong> обозримом будущем. Семантика и нотация UML<br />

считаются здесь данностью, из<strong>в</strong>естной читателю, и не обсуждаются. Нас интересует,<br />

прежде <strong>в</strong>сего, <strong>в</strong>опрос о том, что и как нужно сделать, чтобы потенциальные<br />

достоинст<strong>в</strong>а UML дейст<strong>в</strong>ительно дали ощутимые практические результаты. Наиболее<br />

<strong>в</strong>ажной я<strong>в</strong>ляется инструментальная поддержка UML – чтобы с пользой применять<br />

UML для <strong>в</strong>изуального конструиро<strong>в</strong>ания, нужно иметь адек<strong>в</strong>атные инструментальные<br />

средст<strong>в</strong>а, поддержи<strong>в</strong>ающие UML. В настоящее <strong>в</strong>ремя инструментальная<br />

поддержка UML не <strong>в</strong>полне удо<strong>в</strong>лет<strong>в</strong>орительна. На рынке присутст<strong>в</strong>ует множест<strong>в</strong>о<br />

инструменто<strong>в</strong>, и <strong>в</strong>се <strong>в</strong>ремя поя<strong>в</strong>ляются но<strong>в</strong>ые, но при более пристальном рассмотрении<br />

оказы<strong>в</strong>ается, что нам предлагают еще одно CASE средст<strong>в</strong>о традиционной<br />

архитектуры, поддержи<strong>в</strong>ающее еще одну неудобную нотацию. По мнению а<strong>в</strong>тора,<br />

<strong>в</strong>опрос о разумной поддержке UML не так прост, и требует исследо<strong>в</strong>ания. Именно<br />

из-за плохой инструментальной поддержки UML используется <strong>в</strong> осно<strong>в</strong>ном для рисо<strong>в</strong>ания<br />

(необязательных!) диаграмм, и не более того. Только при наличии адек<strong>в</strong>атной<br />

инструментальной поддержки, можно будет надеяться на распространение<br />

модельно-орентиро<strong>в</strong>анного процесса разработки и получение <strong>в</strong>ыгод, которые обещает<br />

эта идея.<br />

Целью данной работы я<strong>в</strong>ляется исследо<strong>в</strong>ание <strong>в</strong>опроса о принципиальной реализуемости<br />

и о необходимых с<strong>в</strong>ойст<strong>в</strong>ах инструментальных средст<strong>в</strong>, поддержи<strong>в</strong>ающих<br />

модельно-центриро<strong>в</strong>анную разработку приложений на осно<strong>в</strong>е UML.<br />

План статьи состоит <strong>в</strong> следующем. В пер<strong>в</strong>ом разделе обсуждается само понятие<br />

<strong>в</strong>изуального конструиро<strong>в</strong>ания приложений <strong>в</strong> сра<strong>в</strong>нении с традиционными процессами<br />

разработки. Второй раздел пос<strong>в</strong>ящен обсуждению некоторых <strong>в</strong>ажных тенденций<br />

<strong>в</strong> методологии программиро<strong>в</strong>ания и их с<strong>в</strong>язи с UML. В третьем разделе обсуждаются<br />

те общие требо<strong>в</strong>ания к инструменту <strong>в</strong>изуального конструиро<strong>в</strong>ания, которые<br />

<strong>в</strong>ытекают из наблюдений, сделанных <strong>в</strong> пер<strong>в</strong>ых д<strong>в</strong>ух разделах. Последний раздел<br />

пос<strong>в</strong>ящен изложению из<strong>в</strong>естных а<strong>в</strong>тору способо<strong>в</strong> реализации общих требо<strong>в</strong>аний,<br />

<strong>в</strong>ыд<strong>в</strong>инутых <strong>в</strong> третьем разделе.<br />

Визуальное моделиро<strong>в</strong>ание и конструиро<strong>в</strong>ание приложений<br />

Прежде <strong>в</strong>сего, охарактеризуем область применимости дальнейших построений.<br />

Многообразие различных типо<strong>в</strong> приложений необозримо, и нельзя объять необъятное.<br />

Предметная область, характер использо<strong>в</strong>ания, жизненный цикл приложения и<br />

другие факторы оказы<strong>в</strong>ают значительное <strong>в</strong>лияние на характер процесса разработки.<br />

UML – унифициро<strong>в</strong>анный язык моделиро<strong>в</strong>ания, но отнюдь не уни<strong>в</strong>ерсальный, и не<br />

единый. Ут<strong>в</strong>ерждать, что UML я<strong>в</strong>ляется панацеей от <strong>в</strong>сех детских болезней программиро<strong>в</strong>ания<br />

было бы я<strong>в</strong>ным преу<strong>в</strong>еличением – "серебряной пули нет" [4].<br />

Для определения области применимости нужно <strong>в</strong>ыя<strong>в</strong>ить <strong>в</strong>лияние UML на процесс<br />

разработки. Сущест<strong>в</strong>ует множест<strong>в</strong>о <strong>в</strong>зглядо<strong>в</strong> на процесс разработки – разнообразие<br />

подходо<strong>в</strong> и моделей указы<strong>в</strong>ает на то, что инженерия программиро<strong>в</strong>ания (software<br />

2

engineering) я<strong>в</strong>ляется инженерной дисциплиной только по наз<strong>в</strong>анию, а на практике<br />

используются, <strong>в</strong> осно<strong>в</strong>ном, субъекти<strong>в</strong>ные предпочтения и эмпирические пра<strong>в</strong>ила.<br />

Это обстоятельст<strong>в</strong>о поз<strong>в</strong>оляет нам использо<strong>в</strong>ать здесь для формулиро<strong>в</strong>ки тезиса о<br />

<strong>в</strong>лиянии UML с<strong>в</strong>ой <strong>в</strong>згляд на технологию программиро<strong>в</strong>ания, опуская для краткости<br />

детальные обосно<strong>в</strong>ания.<br />

Все процессы, с<strong>в</strong>язанные с разработкой, можно разделить на три группы:<br />

• процессы на уро<strong>в</strong>не организации, то есть порядок про<strong>в</strong>едения типо<strong>в</strong>ого проекта<br />

(отчетность, бюджет, и так далее);<br />

• процессы на уро<strong>в</strong>не проекта, то есть отношения между людьми <strong>в</strong> процессе<br />

разработки (распределение ролей, операти<strong>в</strong>ное планиро<strong>в</strong>ание и так далее);<br />

• процессы на уро<strong>в</strong>не работника, то есть технология программиро<strong>в</strong>ания <strong>в</strong> собст<strong>в</strong>енном<br />

смысле данного термина.<br />

Оцени<strong>в</strong>ать качест<strong>в</strong>о процессо<strong>в</strong> можно с помощью различных показателей – надежность<br />

разрабаты<strong>в</strong>аемого программного обеспечения, затраты на разработку, упра<strong>в</strong>ляемость<br />

процесса и так далее. Для различных типо<strong>в</strong> приложений применяются<br />

разные системы показателей. Здесь мы рассматри<strong>в</strong>аем заказную разработку отчуждаемых<br />

программных продукто<strong>в</strong>, то есть предполагается, что <strong>в</strong> процессе разработки<br />

<strong>в</strong>заимодейст<strong>в</strong>уют, по меньшей мере, д<strong>в</strong>е стороны, которые для простоты мы<br />

обозначим устаре<strong>в</strong>шими, но при<strong>в</strong>ычными терминами "заказчики" и "разработчики".<br />

Кроме того, ограничимся рассмотрением таких проекто<strong>в</strong>, <strong>в</strong> которых <strong>в</strong>ершины<br />

"треугольника качест<strong>в</strong>а" (ресурсы, качест<strong>в</strong>о, функциональность) не я<strong>в</strong>ляются жестко<br />

фиксиро<strong>в</strong>анными. Другими сло<strong>в</strong>ами, мы рассматри<strong>в</strong>аем "типичные" приложения,<br />

<strong>в</strong> которых требо<strong>в</strong>ания я<strong>в</strong>ляются достаточно гибкими <strong>в</strong> определенных пределах:<br />

например, допустимо пожерт<strong>в</strong>о<strong>в</strong>ать некоторыми не приоритетными функциями,<br />

чтобы уложиться <strong>в</strong> заданные ресурсы по <strong>в</strong>ремени, или доба<strong>в</strong>ить трудо<strong>в</strong>ые ресурсы,<br />

чтобы обеспечить приемлемый для заказчика уро<strong>в</strong>ень качест<strong>в</strong>а. Для таких<br />

проекто<strong>в</strong> нас интересует один интегральный показатель – продукти<strong>в</strong>ность, которую<br />

здесь мы упрощенно определим как отношение прибыли к трудозатратам. Образно<br />

го<strong>в</strong>оря, нас интересует процесс разработки достаточно полезного и надежного<br />

приложения за приемлемые деньги. В этих усло<strong>в</strong>иях, по субъекти<strong>в</strong>ным наблюдениям<br />

а<strong>в</strong>тора, рост продукти<strong>в</strong>ности от <strong>в</strong>ложений <strong>в</strong> улучшение процессо<strong>в</strong> трех <strong>в</strong>ыделенных<br />

<strong>в</strong>ыше групп относятся примерно как 1 : 3 : 10. Другими сло<strong>в</strong>ами, рубль<br />

<strong>в</strong>ложений <strong>в</strong> технологию программиро<strong>в</strong>ания на уро<strong>в</strong>не работника дает <strong>в</strong> десять раз<br />

больший прирост продукти<strong>в</strong>ности по сра<strong>в</strong>нению с <strong>в</strong>ложением <strong>в</strong> "стандартный процесс".<br />

Еще раз ого<strong>в</strong>оримся, что <strong>в</strong>се эти ут<strong>в</strong>ерждения не имеют уни<strong>в</strong>ерсального характера<br />

и не я<strong>в</strong>ляются законами природы – это не более чем эмпирическое обобщение<br />

наблюдений а<strong>в</strong>тора, и они <strong>в</strong>ряд ли могут быть распространены за пределы<br />

ого<strong>в</strong>оренных ограничений.<br />

Что же <strong>в</strong>лияет на продукти<strong>в</strong>ность программиро<strong>в</strong>ания на уро<strong>в</strong>не работника? По<br />

убеждению а<strong>в</strong>тора, таких факторо<strong>в</strong> д<strong>в</strong>а:<br />

• сокращение количест<strong>в</strong>а <strong>в</strong>неплано<strong>в</strong>ых изменений артефакто<strong>в</strong>;<br />

• у<strong>в</strong>еличение объема по<strong>в</strong>торно использо<strong>в</strong>анных артефакто<strong>в</strong>.<br />

3

Пер<strong>в</strong>ый фактор, попросту го<strong>в</strong>оря, означает уменьшение количест<strong>в</strong>а грубых ошибок,<br />

допускаемых на фазах анализа и проектиро<strong>в</strong>ания (прочими ошибками можно<br />

пренебречь – стоимость их устранения при использо<strong>в</strong>ании со<strong>в</strong>ременных технологий<br />

незначительна).<br />

Второй фактор означает у<strong>в</strong>еличение по<strong>в</strong>торного использо<strong>в</strong>ания сделанного ранее.<br />

Речь идет о по<strong>в</strong>торном использо<strong>в</strong>ании <strong>в</strong>сех <strong>в</strong>идо<strong>в</strong> артефакто<strong>в</strong>: законченных компоненто<strong>в</strong>,<br />

фрагменто<strong>в</strong> кода, архитектурных решений и так далее. В частности, применение<br />

образцо<strong>в</strong> проектиро<strong>в</strong>ания мы относим к по<strong>в</strong>торному использо<strong>в</strong>анию.<br />

Рассмотрим упрощенную (но не проти<strong>в</strong>оречащую наиболее распространенным моделям,<br />

например, [5]) схему процесса разработки (рис. 1).<br />

Артефакт<br />

[Переданный]<br />

Из<strong>в</strong>лечение<br />

требо<strong>в</strong>аний<br />

Переход<br />

Заказчики<br />

Артефакт<br />

[Разработанный]<br />

Реализация<br />

Анализ<br />

Артефакт<br />

[Заказанный]<br />

Проектиро<strong>в</strong>ание<br />

Разработчики<br />

По<strong>в</strong>торное<br />

использо<strong>в</strong>ание<br />

Артефакт<br />

[Специфициро<strong>в</strong>анный]<br />

Рис. 1. Циклы по<strong>в</strong>ышения продукти<strong>в</strong>ности<br />

Обсуждение последо<strong>в</strong>ательности и наз<strong>в</strong>аний осно<strong>в</strong>ных фаз процесса, а также с<strong>в</strong>язи<br />

между фазами по данным <strong>в</strong> процессе и усло<strong>в</strong>ия переходо<strong>в</strong> между фазами мы оста<strong>в</strong>ляем<br />

<strong>в</strong> стороне, поскольку для наших целей здесь это несущест<strong>в</strong>енно (<strong>в</strong> этой статье<br />

мы не намерены предлагать <strong>в</strong>ниманию читателю но<strong>в</strong>ый "стандартный" процесс).<br />

Выделим д<strong>в</strong>а "боко<strong>в</strong>ых" цикла д<strong>в</strong>ижения артефакто<strong>в</strong> <strong>в</strong> процессе, которые мы назы<strong>в</strong>аем<br />

циклами по<strong>в</strong>ышения продукти<strong>в</strong>ности.<br />

• На стороне заказчика происходит анализ и из<strong>в</strong>лечение требо<strong>в</strong>аний. В нормальной<br />

ситуации требо<strong>в</strong>ания <strong>в</strong>озникают не "из голо<strong>в</strong>ы" заказчика, а <strong>в</strong> результате<br />

анализа предметной области и, <strong>в</strong> частности, анализа использо<strong>в</strong>ания<br />

сущест<strong>в</strong>ующего программного обеспечения. Д<strong>в</strong>ижение артефакто<strong>в</strong> <strong>в</strong> этом<br />

цикле определяет <strong>в</strong>еличину пер<strong>в</strong>ого фактора по<strong>в</strong>ышения продукти<strong>в</strong>ности:<br />

4

неадек<strong>в</strong>атные требо<strong>в</strong>ания порождают ошибки проектиро<strong>в</strong>ания, адек<strong>в</strong>атные<br />

требо<strong>в</strong>ания поз<strong>в</strong>оляют их избежать.<br />

• На стороне разработчика <strong>в</strong>но<strong>в</strong>ь созданные (или модифициро<strong>в</strong>анные) артефакты<br />

подгота<strong>в</strong>ли<strong>в</strong>аются для по<strong>в</strong>торного использо<strong>в</strong>ания: документируются,<br />

обобщаются, помещаются <strong>в</strong> репозиторий и так далее. Д<strong>в</strong>ижение артефакто<strong>в</strong><br />

<strong>в</strong> этом цикле определяет <strong>в</strong>еличину <strong>в</strong>торого фактора по<strong>в</strong>ышения продукти<strong>в</strong>ности:<br />

практика показы<strong>в</strong>ает, что эффекти<strong>в</strong>но по<strong>в</strong>торно использо<strong>в</strong>ать удается<br />

только те решения, которые были для этого специально подгото<strong>в</strong>лены.<br />

Третий (не указанный на рис. 1) цикл д<strong>в</strong>ижения артефакто<strong>в</strong> – это стандартный цикл<br />

<strong>в</strong> процессе разработки: требо<strong>в</strong>ания – проект – реализация – поста<strong>в</strong>ляемый продукт.<br />

Наш осно<strong>в</strong>ной тезис о <strong>в</strong>лиянии UML на процесс разработки состоит <strong>в</strong> том, что UML<br />

поз<strong>в</strong>оляет унифициро<strong>в</strong>ать предста<strong>в</strong>ление <strong>в</strong>сех артефакто<strong>в</strong> <strong>в</strong>о <strong>в</strong>сех циклах, <strong>в</strong> том<br />

числе, прежде <strong>в</strong>сего <strong>в</strong> циклах по<strong>в</strong>ышения продукти<strong>в</strong>ности. (Заметим, что унификация<br />

предста<strong>в</strong>ления артефакто<strong>в</strong> <strong>в</strong> осно<strong>в</strong>ном цикле – это, по нашему мнению, центральная<br />

идея модельно-орентиро<strong>в</strong>анной разработки). Если участникам процесса<br />

разработки приходится знать и применять десяток (а то и д<strong>в</strong>а) различных способо<strong>в</strong><br />

описания артефакто<strong>в</strong> и технологий их создания, то трудно ожидать <strong>в</strong>ысокой продукти<strong>в</strong>ности.<br />

Дейст<strong>в</strong>ительно, преобразо<strong>в</strong>ания формато<strong>в</strong>, изучение специальных<br />

приемо<strong>в</strong>, "ручная заточка" инструменто<strong>в</strong> <strong>в</strong> каждом проекте трудоемки, замедляют<br />

скорость д<strong>в</strong>ижения артефакто<strong>в</strong> и чре<strong>в</strong>аты ошибками. Если же <strong>в</strong> руках участнико<strong>в</strong><br />

процесса есть уни<strong>в</strong>ерсальный инструмент, знакомый <strong>в</strong>сем участникам и адек<strong>в</strong>атный<br />

для <strong>в</strong>сех фаз процесса, то инди<strong>в</strong>идуальная произ<strong>в</strong>одительность (и продукти<strong>в</strong>ность),<br />

оче<strong>в</strong>идно, должны иметь тенденцию к росту. В сущности, наш тезис я<strong>в</strong>ляется<br />

парафразой из<strong>в</strong>естного положения "о пользе чертежей", которое нам предста<strong>в</strong>ляется<br />

бесспорным. Таким образом, UML оказы<strong>в</strong>ает положительное <strong>в</strong>лияние на<br />

продукти<strong>в</strong>ность процесса разработки, если он дейст<strong>в</strong>ительно применяется, причем<br />

<strong>в</strong> соот<strong>в</strong>етст<strong>в</strong>ии со с<strong>в</strong>оим назначением: "для спецификации, документиро<strong>в</strong>ания, конструиро<strong>в</strong>ания<br />

и <strong>в</strong>изуализации <strong>в</strong>сех артефакто<strong>в</strong> <strong>в</strong> процессе разработки программного<br />

обеспечения" [5].<br />

Рассмотрим, как соотносится сегодняшняя практика использо<strong>в</strong>ания UML с деклариро<strong>в</strong>анным<br />

<strong>в</strong>ыше назначением языка.<br />

По мнению а<strong>в</strong>тора, можно <strong>в</strong>ыделить три осно<strong>в</strong>ных <strong>в</strong>арианта использо<strong>в</strong>ания UML<br />

(см. также [9]), предста<strong>в</strong>ленные на рис. 2.<br />

5

Визуализация<br />

диаграмм<br />

«include»<br />

Пользо<strong>в</strong>атель<br />

Соста<strong>в</strong>ление<br />

моделей<br />

«include»<br />

Архитектор<br />

Конструиро<strong>в</strong>ание<br />

приложений<br />

Разработчик<br />

Среда<br />

<strong>в</strong>ыполнения<br />

Рис. 2. Варианты использо<strong>в</strong>ания UML<br />

Вариант использо<strong>в</strong>ания "Визуализация диаграмм" подразуме<strong>в</strong>ает изображение диаграмм<br />

UML с целью обдумы<strong>в</strong>ания, обмена идеями между людьми, документиро<strong>в</strong>ания<br />

и тому подобного. Значимым для пользо<strong>в</strong>ателя результатом <strong>в</strong> этом случае я<strong>в</strong>ляется<br />

само изображение диаграмм. Вообще го<strong>в</strong>оря, <strong>в</strong> этом <strong>в</strong>арианте использо<strong>в</strong>ания<br />

языка поддержи<strong>в</strong>ающий инструмент не очень нужен. Иногда рисо<strong>в</strong>ание диаграмм<br />

от руки фломастером с последующим фотографиро<strong>в</strong>анием цифро<strong>в</strong>ым аппаратом<br />

может оказаться практичнее.<br />

Вариант использо<strong>в</strong>ания "Соста<strong>в</strong>ление моделей" подразуме<strong>в</strong>ает создание и изменение<br />

модели системы <strong>в</strong> терминах тех элементо<strong>в</strong> моделиро<strong>в</strong>ания, которые предусматри<strong>в</strong>аются<br />

метамоделью UML [7]. Значимым результатом <strong>в</strong> этом случае я<strong>в</strong>ляется<br />

машинно-читаемый артефакт с описанием модели. Мы будем для краткости назы<strong>в</strong>ать<br />

такой артефакт просто моделью, деятельность по соста<strong>в</strong>лению модели назы<strong>в</strong>ать<br />

моделиро<strong>в</strong>анием, а субъекта моделиро<strong>в</strong>ания назы<strong>в</strong>ать архитектором (потому<br />

что соот<strong>в</strong>етст<strong>в</strong>ующие сущест<strong>в</strong>ительные – модельщик, модельер – <strong>в</strong> русском<br />

языке уже заняты).<br />

Вариант использо<strong>в</strong>ания "Конструиро<strong>в</strong>ание приложений" подразуме<strong>в</strong>ает детальное<br />

моделиро<strong>в</strong>ание, проектиро<strong>в</strong>ание, реализацию и тестиро<strong>в</strong>ание приложения <strong>в</strong> терминах<br />

UML. Значимым для пользо<strong>в</strong>ателя результатом <strong>в</strong> этом случае я<strong>в</strong>ляется работающее<br />

приложение, которое может быть, например, скомпилиро<strong>в</strong>ано <strong>в</strong>о <strong>в</strong>ходной<br />

язык конкретной системой программиро<strong>в</strong>ания или сразу интерпретиро<strong>в</strong>ано средой<br />

<strong>в</strong>ыполнения инструмента. Этот <strong>в</strong>ариант использо<strong>в</strong>ания наиболее сложен <strong>в</strong> реализации,<br />

но именно он лежит <strong>в</strong> осно<strong>в</strong>е концепции модельно-орентиро<strong>в</strong>анной разработки.<br />

Термин "конструиро<strong>в</strong>ание приложений" означает по сущест<strong>в</strong>у то же самое, что<br />

и "разработка приложений". Мы используем этот но<strong>в</strong>ый термин, чтобы отличать<br />

модельно-орентиро<strong>в</strong>анную разработку от традиционных подходо<strong>в</strong> к разработке.<br />

Кроме того, "конструиро<strong>в</strong>ание приложений" больше похоже по з<strong>в</strong>учанию на термин<br />

"construction", которые используют <strong>в</strong> этом контексте а<strong>в</strong>торы UML.<br />

Однако со<strong>в</strong>ременные инструменты поддержи<strong>в</strong>ают указанные <strong>в</strong>арианты использо<strong>в</strong>ания<br />

далеко не <strong>в</strong> ра<strong>в</strong>ной степени. Все инструменты умеют (плохо или хорошо) <strong>в</strong>и-<br />

6

зуализиро<strong>в</strong>ать <strong>в</strong>се типы диаграмм UML, некоторые инструменты поз<strong>в</strong>оляют построить<br />

модель, допускающую какое-то дальнейшее использо<strong>в</strong>ание, но только немногие<br />

инструменты могут генериро<strong>в</strong>ать исполнимый код и отнюдь не для <strong>в</strong>сех<br />

диаграмм. Имеется множест<strong>в</strong>о практических и организационных причин, по которым<br />

указанные <strong>в</strong>ыше <strong>в</strong>арианты использо<strong>в</strong>ания нера<strong>в</strong>нопра<strong>в</strong>ны и <strong>в</strong> разной степени<br />

поддержаны <strong>в</strong> со<strong>в</strong>ременных инструментах.<br />

Практические причины заключаются <strong>в</strong> том, что <strong>в</strong>изуальное конструиро<strong>в</strong>ание наряду<br />

с оче<strong>в</strong>идными достоинст<strong>в</strong>ами имеет и столь же оче<strong>в</strong>идные недостатки, на которые<br />

не стоит закры<strong>в</strong>ать глаза. В табл. 1 указаны наиболее сущест<strong>в</strong>енные, по нашему<br />

мнению причины.<br />

Таблица 1. Достоинст<strong>в</strong>а и недостатки <strong>в</strong>изуального конструиро<strong>в</strong>ания приложений<br />

Достоинст<strong>в</strong>о<br />

Диаграммы наглядны<br />

Высокий уро<strong>в</strong>ень абстракции<br />

Высокий уро<strong>в</strong>ень формализации<br />

Недостаток<br />

Диаграммы не компактны<br />

Плохо <strong>в</strong>ыразимы некоторые простые<br />

программистские конструкции<br />

Сложная для ос<strong>в</strong>оения нотация<br />

Достоинст<strong>в</strong>а UML не <strong>в</strong>о <strong>в</strong>сех случаях пере<strong>в</strong>еши<strong>в</strong>ают его недостатки, поэтому сущест<strong>в</strong>уют<br />

(и, скорее <strong>в</strong>сего, будут сущест<strong>в</strong>о<strong>в</strong>ать) категории пользо<strong>в</strong>ателей языка, не<br />

заинтересо<strong>в</strong>анные <strong>в</strong> поддержке <strong>в</strong>арианта использо<strong>в</strong>ания "Конструиро<strong>в</strong>ание приложений".<br />

Такие пользо<strong>в</strong>атели не согласны платить за ненужные им (и дорогостоящие!)<br />

<strong>в</strong>озможности. Произ<strong>в</strong>одители инструменто<strong>в</strong> не <strong>в</strong>пра<strong>в</strong>е игнориро<strong>в</strong>ать потребности<br />

рынка. (По чисто субъекти<strong>в</strong>ному <strong>в</strong>печатлению а<strong>в</strong>тора, количест<strong>в</strong>а пользо<strong>в</strong>ателей,<br />

жизненно заинтересо<strong>в</strong>анных <strong>в</strong> трех перечисленных <strong>в</strong>ыше <strong>в</strong>ариантах использо<strong>в</strong>ания,<br />

соотносятся примерно как 10 : 3 : 1). Например, диаграммы <strong>в</strong> этой статье<br />

подгото<strong>в</strong>лены с помощью Microsoft Visio, а этот инструмент и не претендует на <strong>в</strong>изуальное<br />

конструиро<strong>в</strong>ание приложений.<br />

С другой стороны, до<strong>в</strong>ольно распространенным я<strong>в</strong>ляется отношение к UML как к<br />

модной графической надстройке над обычным языком программиро<strong>в</strong>ания "<strong>в</strong>ысокого"<br />

уро<strong>в</strong>ня (речь идет о так назы<strong>в</strong>аемых языках третьего поколения 3GL), которая<br />

имеет (частично) графический, а не только тексто<strong>в</strong>ый синтаксис. Несколько упрощая,<br />

можно сказать, что разработка с<strong>в</strong>одится к рисо<strong>в</strong>анию диаграммы классо<strong>в</strong>, после<br />

чего тела методо<strong>в</strong> <strong>в</strong>писы<strong>в</strong>аются <strong>в</strong>ручную. При таком использо<strong>в</strong>ании UML фактически<br />

оказы<strong>в</strong>ается средст<strong>в</strong>ом а<strong>в</strong>томатического доба<strong>в</strong>ления графических комментарие<strong>в</strong><br />

к программе. Дейст<strong>в</strong>ительно, структура наследо<strong>в</strong>ания (для небольших проекто<strong>в</strong>!)<br />

наглядно <strong>в</strong>идна на диаграмме классо<strong>в</strong>, но, по большому счету, этим <strong>в</strong>изуальное<br />

моделиро<strong>в</strong>ание и ограничи<strong>в</strong>ается. Мы не склонны считать такую практику<br />

<strong>в</strong>изуальным конструиро<strong>в</strong>анием приложений, <strong>в</strong>о <strong>в</strong>сяком случае, рассчиты<strong>в</strong>ать на<br />

значительное по<strong>в</strong>ышение продукти<strong>в</strong>ности точно не стоит. UML можно использо<strong>в</strong>ать<br />

как еще один традиционный язык программиро<strong>в</strong>ания, но, как мы рассчиты<strong>в</strong>аем<br />

показать <strong>в</strong> оста<strong>в</strong>шейся части статьи, делать этого не нужно!<br />

7

Организационные причины заключаются <strong>в</strong> том, что процесс стандартизации UML<br />

неопра<strong>в</strong>данно затянулся (например, стандарт UML 2.0 находится <strong>в</strong> состоянии "финализации"<br />

уже более года). Данную ситуацию нетрудно объяснить. UML был задуман<br />

и определен как язык-оболочка, унифицирующий как можно больше из<strong>в</strong>естных<br />

и зарекомендо<strong>в</strong>а<strong>в</strong>ших себя на практике приемо<strong>в</strong> <strong>в</strong>изуального моделиро<strong>в</strong>ания и<br />

конструиро<strong>в</strong>ания. Такой подход с необходимостью <strong>в</strong>едет к сложности и громоздкости<br />

языка и его описания. Некоторые полагают, что "UML рухнет под собст<strong>в</strong>енной<br />

тяжестью" [10]. Мы надеемся показать ниже, <strong>в</strong> третьем разделе статьи, что хотя<br />

риск такого печального исхода дейст<strong>в</strong>ительно <strong>в</strong>елик, но он распространяется <strong>в</strong> осно<strong>в</strong>ном<br />

на произ<strong>в</strong>одителей инструменто<strong>в</strong>, но не на пользо<strong>в</strong>ателей языка, а потому,<br />

принимая предупредительные меры, есть надежда избежать худшего.<br />

Сложность и громоздкость языка при<strong>в</strong>ели к тому, что пода<strong>в</strong>ляющее большинст<strong>в</strong>о<br />

пользо<strong>в</strong>ателей знакомится с языком не по оригинальным источникам и ут<strong>в</strong>ержденным<br />

спецификациям стандарто<strong>в</strong>, которые слишком сложны для <strong>в</strong>осприятия, а с помощью<br />

популяризаторо<strong>в</strong> и интерпретаторо<strong>в</strong>, среди которых, к сожалению, немало<br />

недобросо<strong>в</strong>естных и некомпетентных людей. Наблюдения а<strong>в</strong>тора показы<strong>в</strong>ают, что<br />

многие пользо<strong>в</strong>атели UML <strong>в</strong>ладеют языком по<strong>в</strong>ерхностно. В результате поста<strong>в</strong>щики<br />

инструменто<strong>в</strong> также не утруждают себя следо<strong>в</strong>анием стандарту – например, не<br />

про<strong>в</strong>еряют пра<strong>в</strong>ила непроти<strong>в</strong>оречи<strong>в</strong>ости, определенные <strong>в</strong> стандарте [11], не поддержи<strong>в</strong>ают<br />

(или хуже того, искажают) стандартные конструкции и канонические<br />

диаграммы – да и зачем напрягаться, если имеется <strong>в</strong> <strong>в</strong>иду только рисо<strong>в</strong>ание необязательных<br />

картинок?<br />

Если сопоста<strong>в</strong>ить нынешние инструменты, поддержи<strong>в</strong>ающие UML, с традиционными<br />

системами программиро<strong>в</strong>ания, то <strong>в</strong>ариант использо<strong>в</strong>ания "Рисо<strong>в</strong>ание диаграмм"<br />

соот<strong>в</strong>етст<strong>в</strong>ует наличию простого тексто<strong>в</strong>ого редактора, <strong>в</strong>ариант использо<strong>в</strong>ания<br />

"Моделиро<strong>в</strong>ание систем" соот<strong>в</strong>етст<strong>в</strong>ует синтаксическому анализатору, <strong>в</strong>ариант<br />

использо<strong>в</strong>ания "Конструиро<strong>в</strong>ание приложений" соот<strong>в</strong>етст<strong>в</strong>ует генерации кода и<br />

наличию администрати<strong>в</strong>ной системы <strong>в</strong>ремени <strong>в</strong>ыполнения. Языки "программиро<strong>в</strong>ания",<br />

которые не подразуме<strong>в</strong>ают <strong>в</strong>ыполнения, иногда используются – например,<br />

для публикации алгоритмо<strong>в</strong>. Однако чаще произ<strong>в</strong>одители систем программиро<strong>в</strong>ания,<br />

зая<strong>в</strong>ляя о поддержке языка, подразуме<strong>в</strong>ают полную поддержку, <strong>в</strong>ключая точное<br />

соот<strong>в</strong>етст<strong>в</strong>ие стандартам и многое с<strong>в</strong>ерх того, например, наличие раз<strong>в</strong>итых<br />

библиотек гото<strong>в</strong>ых к использо<strong>в</strong>анию компоненто<strong>в</strong>. В случае с UML ситуация прямо<br />

проти<strong>в</strong>оположная: зая<strong>в</strong>ляя о поддержке UML некоторые произ<strong>в</strong>одители инструменто<strong>в</strong><br />

не считают себя с<strong>в</strong>язанными серьезными обязательст<strong>в</strong>ами. Дейст<strong>в</strong>ительно,<br />

пра<strong>в</strong>омерно ли ут<strong>в</strong>ерждать, что инструмент поддержи<strong>в</strong>ает описание по<strong>в</strong>едения с<br />

помощью UML, если он поз<strong>в</strong>оляет нарисо<strong>в</strong>ать диаграмму состояний и не более того?<br />

Между тем даже из<strong>в</strong>естнейшие инструменты (например, Rational Rose и Together<br />

Control Center), декларируя поддержку UML различных <strong>в</strong>ерсий, ничего не<br />

умеют делать с упомянутым базо<strong>в</strong>ым средст<strong>в</strong>ом описания по<strong>в</strong>едения <strong>в</strong> UML (то<br />

есть, с конечными а<strong>в</strong>томатами).<br />

Таким образом, сра<strong>в</strong>нение инструменто<strong>в</strong> по критерию степени поддержки языка<br />

расплы<strong>в</strong>чато и субъекти<strong>в</strong>но. Можно предложить следующие объекти<strong>в</strong>ные критерии<br />

того, можно ли считать инструмент полностью поддержи<strong>в</strong>ающим какой-либо <strong>в</strong>ариант<br />

использо<strong>в</strong>ания UML.<br />

8

• Инструмент полностью поддержи<strong>в</strong>ает <strong>в</strong>ариант использо<strong>в</strong>ания "Визуализация<br />

диаграмм", если он поз<strong>в</strong>оляет отобразить <strong>в</strong>се графические конструкции,<br />

предусмотренные описанием нотации <strong>в</strong> стандарте.<br />

• Инструмент полностью поддержи<strong>в</strong>ает <strong>в</strong>ариант использо<strong>в</strong>ания "Соста<strong>в</strong>ление<br />

моделей", если он поз<strong>в</strong>оляет построить объекты и их комбинации для <strong>в</strong>сех<br />

классо<strong>в</strong> метамодели, предусмотренные описанием семантики <strong>в</strong> стандарте.<br />

• Инструмент полностью поддержи<strong>в</strong>ает <strong>в</strong>ариант использо<strong>в</strong>ания "Конструиро<strong>в</strong>ание<br />

приложений", если он поз<strong>в</strong>оляет преобразо<strong>в</strong>ать модель приложения <strong>в</strong><br />

работающее приложение.<br />

Заметим, что <strong>в</strong>арианты использо<strong>в</strong>ания оче<strong>в</strong>идным образом <strong>в</strong>ключают друг друга и<br />

если инструмент полностью поддержи<strong>в</strong>ает разработку, то он, скорее <strong>в</strong>сего, поддержи<strong>в</strong>ает<br />

также моделиро<strong>в</strong>ание и рисо<strong>в</strong>ание. Поста<strong>в</strong>им <strong>в</strong>опрос: как можно определить,<br />

что предложенные критерии <strong>в</strong>ыполнены, и инструмент дейст<strong>в</strong>ительно поддержи<strong>в</strong>ает<br />

тот или иной <strong>в</strong>ариант использо<strong>в</strong>ания? Нетрудно про<strong>в</strong>ерить, что инструмент<br />

умеет рисо<strong>в</strong>ать <strong>в</strong>се, что нужно – для этого х<strong>в</strong>атит получаса при усло<strong>в</strong>ии знания<br />

языка. Можно про<strong>в</strong>ерить, что инструмент создает <strong>в</strong>се элементы модели, предусмотренные<br />

стандартом, хотя это и хлопотно – счет тесто<strong>в</strong>ых сценарие<strong>в</strong> пойдет на<br />

сотни, так как <strong>в</strong> языке много отдельных конструкций. Но с про<strong>в</strong>еркой третьего <strong>в</strong>арианта<br />

использо<strong>в</strong>ания дела обстоят сложнее. Операционная семантика UML туманна,<br />

если не сказать хуже (за что недоброжелатели под<strong>в</strong>ергают язык постоянной и<br />

спра<strong>в</strong>едли<strong>в</strong>ой критике). В то же <strong>в</strong>ремя, по нашему мнению, плохое определение<br />

или даже отсутст<strong>в</strong>ие операционной семантики <strong>в</strong> стандарте UML еще не я<strong>в</strong>ляется<br />

непреодолимым препятст<strong>в</strong>ием для реализации <strong>в</strong>арианта использо<strong>в</strong>ания "Конструиро<strong>в</strong>ание<br />

приложений". Язык устроен таким образом, что семантику можно доопределить<br />

прямо <strong>в</strong> инструменте. Стандартные механизмы расширения и точки <strong>в</strong>ариации<br />

семантики оста<strong>в</strong>ляют достаточный простор. Похожая проблема (но менее остро)<br />

строит и перед разработчиками традиционных систем программиро<strong>в</strong>ания.<br />

Обычно ее решают чисто практически: дого<strong>в</strong>ари<strong>в</strong>аются о предста<strong>в</strong>ительном наборе<br />

примеро<strong>в</strong>, и если прогон примеро<strong>в</strong> дает ожидаемые результаты, то система программиро<strong>в</strong>ания<br />

считается приемлемой. Однако стандартного набора примеро<strong>в</strong> <strong>в</strong>изуальной<br />

разработки пока нет, и приходится их <strong>в</strong>ыбирать и придумы<strong>в</strong>ать.<br />

Традиционно <strong>в</strong> качест<strong>в</strong>е теста для инструмента разработки используют сам этот<br />

инструмент разработки. Например, язык программиро<strong>в</strong>ания хорош, если на этом<br />

языке можно написать хороший компилятор данного языка. Такой прием обычно<br />

назы<strong>в</strong>ают раскруткой (bootstrapping). Мы считаем достаточно предста<strong>в</strong>ительным<br />

примером приложения сам инструмент <strong>в</strong>изуального конструиро<strong>в</strong>ания. Таким образом,<br />

окончательно наш критерий можно сформулиро<strong>в</strong>ать следующим образом: инструмент<br />

полностью поддержи<strong>в</strong>ает UML, если он допускает полную раскрутку.<br />

Другими сло<strong>в</strong>ами, если на <strong>в</strong>ход инструмента подать модель инструмента, созданную<br />

<strong>в</strong> этом инструменте, то на <strong>в</strong>ыходе мы получим тот же инструмент (тот же <strong>в</strong><br />

функциональном смысле, то есть так же работающий). Про<strong>в</strong>ерить это (до некоторой<br />

степени) можно с помощью сценария, при<strong>в</strong>еденного на рис. 3. Здесь предполагается,<br />

что инструмент умеет <strong>в</strong>ыполнять последо<strong>в</strong>ательности команд, и что процесс<br />

построения любой модели можно описать такой последо<strong>в</strong>ательностью команд<br />

(трудно предста<strong>в</strong>ить себе обратное). Тогда если инструменту подать последо<strong>в</strong>ательность<br />

команд, описы<strong>в</strong>ающую построение его модели (на рис. 3 она обозначена<br />

9

M0), то инструмент должен построить некоторую модель самого себя (на рис. 3 она<br />

обозначена M1). Если теперь <strong>в</strong>ыполнить модель М1 (запустить интерпретацию или<br />

же сгенериро<strong>в</strong>ать код и запустить его) и еще раз подать на <strong>в</strong>ход этому сеансу <strong>в</strong>ыполнения<br />

ту же последо<strong>в</strong>ательность команд M0, то должна быть построена еще одна<br />

модель (на рис. 3 она обозначена M2). Если окажется, что М1 и М2 со<strong>в</strong>падают,<br />

то, по нашему мнению, это поз<strong>в</strong>оляет с достаточной степенью у<strong>в</strong>еренности считать,<br />

что инструмент функционально тождест<strong>в</strong>енен с<strong>в</strong>оей модели и <strong>в</strong>ариант использо<strong>в</strong>ание<br />

"Конструиро<strong>в</strong>ание приложений" поддержи<strong>в</strong>ается.<br />

Построение<br />

модели<br />

M1 : Model<br />

M0 : Commands<br />

Выполнение<br />

модели<br />

M2 : Model<br />

Сра<strong>в</strong>нение<br />

моделей<br />

[M1=M2]<br />

[else]<br />

Вариант использо<strong>в</strong>ания<br />

«Конструиро<strong>в</strong>ание приложений»<br />

поддержи<strong>в</strong>ается<br />

Вариант использо<strong>в</strong>ания<br />

«Конструиро<strong>в</strong>ание приложений»<br />

не поддержи<strong>в</strong>ается<br />

Рис. 3. Сценарий про<strong>в</strong>ерки <strong>в</strong>арианта использо<strong>в</strong>ания "Конструиро<strong>в</strong>ание приложений"<br />

Отметим, что <strong>в</strong> настоящее <strong>в</strong>ремя не сущест<strong>в</strong>ует инструменто<strong>в</strong>, полностью поддержи<strong>в</strong>ающих<br />

UML согласно при<strong>в</strong>еденному критерию.<br />

Со<strong>в</strong>ременные тенденции <strong>в</strong> методологии программиро<strong>в</strong>ания<br />

В этом разделе мы рассмотрим некоторые концепции методологии программиро<strong>в</strong>ания,<br />

про которые точно из<strong>в</strong>естно, что их применение <strong>в</strong> практическом программиро<strong>в</strong>ании<br />

положительно <strong>в</strong>лияет на продукти<strong>в</strong>ность. Обозначим их:<br />

• компонентно-ориентиро<strong>в</strong>анное программиро<strong>в</strong>ание;<br />

• предметно-ориентиро<strong>в</strong>анное программиро<strong>в</strong>ание;<br />

10

• аспектно-ориентиро<strong>в</strong>анное программиро<strong>в</strong>ание.<br />

Мы не собираемся детально излагать эти концепции – предполагается, что они хорошо<br />

из<strong>в</strong>естны читателю (<strong>в</strong>озможно, под другими наз<strong>в</strong>аниями, поэтому осно<strong>в</strong>ные<br />

идеи <strong>в</strong>о избежание недоразумений мы <strong>в</strong>се-таки по<strong>в</strong>торим). Наша цель <strong>в</strong> этом разделе<br />

состоит <strong>в</strong> том, чтобы устано<strong>в</strong>ить, насколько адек<strong>в</strong>атен UML, лежит ли этот язык<br />

<strong>в</strong> русле осно<strong>в</strong>ных тенденций или "идет проти<strong>в</strong> течения".<br />

Компонентно-ориентиро<strong>в</strong>анное программиро<strong>в</strong>ание старо как само программиро<strong>в</strong>ание,<br />

если не старо как мир, поскольку я<strong>в</strong>ляется реализацией принципа "разделяй и<br />

<strong>в</strong>ласт<strong>в</strong>уй". Во <strong>в</strong>сяком случае, указать пер<strong>в</strong>оисточник этой идеи затруднительно.<br />

Сама же идея оче<strong>в</strong>идна: целесообразно конструиро<strong>в</strong>ать программы не из мелких<br />

деталей (операторо<strong>в</strong> языка программиро<strong>в</strong>ания), а из более крупных блоко<strong>в</strong> (компоненто<strong>в</strong>).<br />

Выгоды оче<strong>в</strong>идны:<br />

• соста<strong>в</strong>ить большую программу из гото<strong>в</strong>ых компоненто<strong>в</strong> намного легче, чем<br />

написать "с нуля" (такую же по <strong>в</strong>озможностям) программу;<br />

• гото<strong>в</strong>ые компоненты я<strong>в</strong>ляются тем, что можно и нужно по<strong>в</strong>торно использо<strong>в</strong>ать.<br />

Понятие "компонент" до<strong>в</strong>ольно расплы<strong>в</strong>чатое, были предложены и использо<strong>в</strong>аны<br />

многочисленные технологии и механизмы, поддержи<strong>в</strong>ающие компонентное программиро<strong>в</strong>ание,<br />

и компоненты <strong>в</strong> них понимаются и описы<strong>в</strong>аются немного поразному.<br />

Грубо <strong>в</strong>се разнообразие <strong>в</strong>идо<strong>в</strong> программных компоненто<strong>в</strong> можно поделить<br />

на три типа:<br />

• неструктуриро<strong>в</strong>анные фрагменты исходного кода на языке программиро<strong>в</strong>ания;<br />

• структурные части исходного кода программ (их часто назы<strong>в</strong>ают модулями);<br />

• скомпилиро<strong>в</strong>анные исполнимые части программ (например, библиотеки динамического<br />

с<strong>в</strong>язы<strong>в</strong>ания).<br />

В пер<strong>в</strong>ом случае решение прямолинейное и понятное, но многого ожидать от него<br />

не приходится: если текст программы собирается из компоненто<strong>в</strong> путем копиро<strong>в</strong>ания<br />

и <strong>в</strong>ста<strong>в</strong>ки, то очень <strong>в</strong>ероятны ошибки, с<strong>в</strong>язанные с "настройкой по месту" скопиро<strong>в</strong>анного<br />

фрагмента. Впрочем, <strong>в</strong> отношении компонентного программиро<strong>в</strong>ания<br />

методом копиро<strong>в</strong>ания и <strong>в</strong>ста<strong>в</strong>ки инструменты, осно<strong>в</strong>анные на UML, не хуже других:<br />

фрагменты моделей можно также легко копиро<strong>в</strong>ать и <strong>в</strong>ста<strong>в</strong>лять, как и тексты.<br />

Компоненты на уро<strong>в</strong>не модулей исходного кода удобная <strong>в</strong>ещь, если используется<br />

один язык программиро<strong>в</strong>ания с хорошо определенным понятием модуля (например,<br />

Pascal или Java). Если же требуется использо<strong>в</strong>ать компоненты, написанные на<br />

разных языках и для разных платформ, то <strong>в</strong>озникают проблемы. В UML имеется<br />

хорошо определенное понятие модуля (пакет), а поскольку язык по самой с<strong>в</strong>оей<br />

сути претендует на неза<strong>в</strong>исимость от платформы, число и сложность проблем при<br />

сборке моделей из пакето<strong>в</strong> UML оказы<strong>в</strong>аются меньше. Заметим, что при описании<br />

UML 2.0 [8] <strong>в</strong><strong>в</strong>едена и акти<strong>в</strong>но используется для описания самого языка с<strong>в</strong>оеобразная<br />

операция слияния пакето<strong>в</strong> («merge»). Этот <strong>в</strong>ид компонентного программиро<strong>в</strong>а-<br />

11

ния специфичен для модельно-центриро<strong>в</strong>анной разработки. Трудно предста<strong>в</strong>ить<br />

себе столь же избирательную операцию по сборке на уро<strong>в</strong>не тексто<strong>в</strong>. Опуская детали,<br />

можно сказать, что слияние поз<strong>в</strong>оляет использо<strong>в</strong>ать пакет, как компонент,<br />

из<strong>в</strong>лекая из него ро<strong>в</strong>но то, что нужно при сборке модели. Таким образом, компонентное<br />

программиро<strong>в</strong>ание на уро<strong>в</strong>не исходных кодо<strong>в</strong> поддержано <strong>в</strong> UML по<br />

меньшей мере не хуже, чем у конкуренто<strong>в</strong>.<br />

Компонентное программиро<strong>в</strong>ание на уро<strong>в</strong>не исполнимых компоненто<strong>в</strong> имеет наибольшее<br />

практическое применение <strong>в</strong> настоящее <strong>в</strong>ремя. Разрабаты<strong>в</strong>аются и применяются<br />

<strong>в</strong>есьма изощренные механизмы, приз<strong>в</strong>анные обеспечить компонентное программиро<strong>в</strong>ание<br />

на объектном уро<strong>в</strong>не. Наиболее яркий пример последнего <strong>в</strong>ремени<br />

– это, несомненно, .NET [12]. Общая среда <strong>в</strong>ыполнения, обмен метаинформацией<br />

и другие механизмы обеспечи<strong>в</strong>ают достаточно гибкие <strong>в</strong>озможности сборки программ<br />

из компоненто<strong>в</strong>. Заметим, что разработчики .NET были с<strong>в</strong>язаны искусст<strong>в</strong>енным<br />

ограничением, состоящим <strong>в</strong> том, что исходный код компонента считается недоступным<br />

<strong>в</strong>о <strong>в</strong>ремя использо<strong>в</strong>ания компонента.<br />

По мнению а<strong>в</strong>тора, защита интеллектуальной собст<strong>в</strong>енности разработчико<strong>в</strong> путем<br />

сокрытия исходных кодо<strong>в</strong> программ – это укорени<strong>в</strong>шийся, но общест<strong>в</strong>енно <strong>в</strong>редный<br />

анахронизм. Практика сокрытия исходного кода не<strong>в</strong>ыгодна самим разработчикам.<br />

Дейст<strong>в</strong>ительно, сокрытие исходного кода затрудняет его по<strong>в</strong>торное использо<strong>в</strong>ание,<br />

и упущенная <strong>в</strong>ыгода намного пере<strong>в</strong>еши<strong>в</strong>ает ущерб от злонамеренного нарушения<br />

а<strong>в</strong>торских пра<strong>в</strong>. Кстати го<strong>в</strong>оря, <strong>в</strong> со<strong>в</strong>ременной открытой информационной<br />

среде контрафактное использо<strong>в</strong>ание кода программ технически <strong>в</strong>полне <strong>в</strong>озможно<br />

<strong>в</strong>ыя<strong>в</strong>ить и пресечь. В модельно-центриро<strong>в</strong>анной разработке сокрытие моделей –<br />

нонсенс, проти<strong>в</strong>оречащий самой сути подхода. Общест<strong>в</strong>енные д<strong>в</strong>ижения, напра<strong>в</strong>ленные<br />

на расширение публичного доступа к информации экономически обосно<strong>в</strong>аны,<br />

и потому победа будет за ними. В этой с<strong>в</strong>язи, по нашему мнению, особого<br />

упоминания заслужи<strong>в</strong>ает д<strong>в</strong>ижение за открытую проектную документацию [13],<br />

поскольку оно <strong>в</strong> наибольшей степени соот<strong>в</strong>етст<strong>в</strong>ует по духу модельноориентиро<strong>в</strong>анной<br />

разработке.<br />

Воз<strong>в</strong>ращаясь к компонентному программиро<strong>в</strong>анию на UML, отметим следующее.<br />

Диаграммы компоненто<strong>в</strong> UML предоста<strong>в</strong>ляют достаточно наглядные средст<strong>в</strong>а для<br />

описания соста<strong>в</strong>а и структуры <strong>в</strong>заимодейст<strong>в</strong>ия компоненто<strong>в</strong> (особенно с учетом<br />

симметричной нотации для требуемых и предоста<strong>в</strong>ляемых интерфейсо<strong>в</strong>, <strong>в</strong><strong>в</strong>еденной<br />

<strong>в</strong> UML 2.0), а диаграммы <strong>в</strong>заимодейст<strong>в</strong>ия я<strong>в</strong>ляются достаточным ресурсом для описания<br />

самого <strong>в</strong>заимодейст<strong>в</strong>ия. Важным, на наш <strong>в</strong>згляд, я<strong>в</strong>ляется поя<strong>в</strong>ление <strong>в</strong><br />

UML 2.0 специального <strong>в</strong>ида машин состояний, описы<strong>в</strong>ающих протокол <strong>в</strong>заимодейст<strong>в</strong>ия<br />

компоненто<strong>в</strong>.<br />

Мы <strong>в</strong>идим, что применение UML ничуть не проти<strong>в</strong>оречит компонентному программиро<strong>в</strong>анию<br />

<strong>в</strong> любом его толко<strong>в</strong>ании. Более того, мы рискнем предположить,<br />

что применение UML <strong>в</strong> ближайшем будущем поз<strong>в</strong>олит рассматри<strong>в</strong>ать еще одно<br />

толко<strong>в</strong>ание понятия компонента: компонент – это экземпляр образца проектиро<strong>в</strong>ания,<br />

то есть решение задачи путем применения образца проектиро<strong>в</strong>ания <strong>в</strong> конкретном<br />

контексте.<br />

12

Под<strong>в</strong>одя итоги обсуждению компонентного программиро<strong>в</strong>ания, подчеркнем еще<br />

раз, что компонентное программиро<strong>в</strong>ание я<strong>в</strong>но поощряет по<strong>в</strong>торное использо<strong>в</strong>ание,<br />

а потому <strong>в</strong>едет к по<strong>в</strong>ышению продукти<strong>в</strong>ности. Приятно отметить, что <strong>в</strong> качест<strong>в</strong>е<br />

средст<strong>в</strong>а компонентного программиро<strong>в</strong>ания UML не только не отстает, но даже<br />

несколько опережает распространенную на сегодня практику.<br />

Обратимся теперь к предметно-ориентиро<strong>в</strong>анному программиро<strong>в</strong>анию. Осно<strong>в</strong>ная<br />

идея здесь также банальна: программиро<strong>в</strong>ать нужно <strong>в</strong> терминах конкретной предметной<br />

области, тогда программы для этой предметной области будут простыми,<br />

понятными, надежными и хорошими <strong>в</strong>о <strong>в</strong>сех отношениях. Мы не будем обсуждать<br />

здесь предметно-ориентиро<strong>в</strong>анное программиро<strong>в</strong>ание <strong>в</strong>о <strong>в</strong>сех деталях, тем более<br />

что они значительно разнятся у различных а<strong>в</strong>торо<strong>в</strong>. Очень краткий, но емкий обзор<br />

при<strong>в</strong>еден <strong>в</strong> работе [14]. Отметим только одно обстоятельст<strong>в</strong>о, <strong>в</strong>ажное <strong>в</strong> контексте<br />

нашего рассмотрения. Программиро<strong>в</strong>ать <strong>в</strong> терминах предметной области могут и<br />

должны специалисты <strong>в</strong> этой предметной области, которые, хотя, может быть, и не<br />

я<strong>в</strong>ляются профессиональными программистами, но показы<strong>в</strong>ают очень <strong>в</strong>ысокую<br />

продукти<strong>в</strong>ность. Личные наблюдения а<strong>в</strong>тора полностью согласуются с этим тезисом,<br />

более того, у нас есть объяснение: если <strong>в</strong> циклах по<strong>в</strong>ышения продукти<strong>в</strong>ности<br />

(рис. 1) заказчики и разработчики – одно дейст<strong>в</strong>ующее лицо, то д<strong>в</strong>ижение артефакто<strong>в</strong><br />

заметно ускоряется. С других исходных позиций, но к тому же <strong>в</strong>ы<strong>в</strong>оду приходят<br />

экстремальные программисты настаи<strong>в</strong>ая на постоянной <strong>в</strong>о<strong>в</strong>леченности заказчика<br />

<strong>в</strong> процесс разработки.<br />

Чтобы оценить пригодность UML для предметно-ориентиро<strong>в</strong>анного программиро<strong>в</strong>ания,<br />

заметим следующее. Обычно апологеты предметно-ориентиро<strong>в</strong>анного конструиро<strong>в</strong>ания<br />

приложений акцентируют <strong>в</strong>нимание на <strong>в</strong>ыразительности предметноориентиро<strong>в</strong>анных<br />

программ и простоте их соста<strong>в</strong>ления, но это только <strong>в</strong>ерхушка<br />

айсберга! К<strong>в</strong>алифициро<strong>в</strong>анная формализация предметной области, разработка раз<strong>в</strong>итых<br />

пакето<strong>в</strong> прикладных программ для нее, изобретение и реализация специфических<br />

интерфейсных средст<strong>в</strong> остаются как бы за кадром. Системы предметноориентиро<strong>в</strong>анного<br />

программиро<strong>в</strong>ания просты <strong>в</strong> использо<strong>в</strong>ании, но сложны <strong>в</strong> реализации.<br />

Например, из<strong>в</strong>естная программа Excel, которую мы считаем классическим<br />

примером предметно-ориентиро<strong>в</strong>анной системы программиро<strong>в</strong>ания, намного пре<strong>в</strong>осходит<br />

по богатст<strong>в</strong>у <strong>в</strong>озможностей со<strong>в</strong>ременные системы программиро<strong>в</strong>ания на<br />

обычных уни<strong>в</strong>ерсальных языках программиро<strong>в</strong>ания. Сложную задачу по обработке<br />

число<strong>в</strong>ых данных, которую опытный пользо<strong>в</strong>атель Excel решает "<strong>в</strong> д<strong>в</strong>а счета" с помощью<br />

с<strong>в</strong>одных таблиц и многочисленных надстроек Excel (например, надстройка<br />

"поиск решения"), команда обычных профессиональных программисто<strong>в</strong> на С++,<br />

скорее <strong>в</strong>сего, <strong>в</strong>ообще не сможет запрограммиро<strong>в</strong>ать за разумное <strong>в</strong>ремя – не х<strong>в</strong>атит<br />

к<strong>в</strong>алификации <strong>в</strong> предметной области.<br />

Многие спра<strong>в</strong>едли<strong>в</strong>о отмечают, что UML слишком сложный язык, и конечному<br />

пользо<strong>в</strong>ателю – специалисту <strong>в</strong> предметной области – трудно было бы построить<br />

содержательную модель так же легко, как это делается с помощью специализиро<strong>в</strong>анного<br />

предметно-ориентиро<strong>в</strong>анного языка. Критика напра<strong>в</strong>лена мимо цели. Вопер<strong>в</strong>ых,<br />

построить модель предметной области на С++ ничуть не проще. Во<strong>в</strong>торых,<br />

делать этого не нужно. Дейст<strong>в</strong>ительно, зачем насильно <strong>в</strong>тиски<strong>в</strong>ать предметную<br />

область <strong>в</strong> UML? Наоборот, целесообразно <strong>в</strong>оспользо<strong>в</strong>аться гибкостью UML<br />

13

и создать специализиро<strong>в</strong>анный предметно-ориентиро<strong>в</strong>анный язык, <strong>в</strong> котором модель<br />

запишется легко и просто. И здесь UML может, по нашему мнению, соста<strong>в</strong>ить<br />

конкуренцию традиционным подходам. Гла<strong>в</strong>ным конкурентным преимущест<strong>в</strong>ом<br />

UML при этом я<strong>в</strong>ляется <strong>в</strong>озможность метамоделиро<strong>в</strong>ания.<br />

Метамоделиро<strong>в</strong>ание – это <strong>в</strong>озможность изменять метамодель, то есть тот язык<br />

(<strong>в</strong>ключая семантику), на котором пользо<strong>в</strong>атель строит с<strong>в</strong>ои модели. Поскольку мы<br />

дого<strong>в</strong>орились, что рассматри<strong>в</strong>аем инструмент, которому полностью под<strong>в</strong>ластна его<br />

собст<strong>в</strong>енная модель (метамодель), то <strong>в</strong>озможности метамоделиро<strong>в</strong>ания на UML намного<br />

богаче, чем на обычных языках программиро<strong>в</strong>ания. Поясним примером:<br />

обычная система программиро<strong>в</strong>ания, может быть, поз<strong>в</strong>оляет переопределить стандартную<br />

библиотеку <strong>в</strong>строенных функций, меняя до некоторой степени семантику<br />

языку, но <strong>в</strong>ряд ли поз<strong>в</strong>олит <strong>в</strong>меши<strong>в</strong>аться <strong>в</strong> протокол <strong>в</strong>ызо<strong>в</strong>а функций или <strong>в</strong> механизм<br />

про<strong>в</strong>ерки типо<strong>в</strong>. Для инструмента, полностью поддержи<strong>в</strong>ающего UML, <strong>в</strong>се<br />

<strong>в</strong>озможно.<br />

Последняя тенденция, которую мы хотим затронуть – аспектно-ориентиро<strong>в</strong>анное<br />

программиро<strong>в</strong>ание. Это сра<strong>в</strong>нительно но<strong>в</strong>ое изобретение, но <strong>в</strong>се на ту же тему по<strong>в</strong>торного<br />

использо<strong>в</strong>ания кода. Идея, как обычно проста и базируется на следующем<br />

наблюдении: большая часть кода <strong>в</strong> реальных программах имеет рутинный характер<br />

– это по<strong>в</strong>торы практически одинако<strong>в</strong>ых фрагменто<strong>в</strong>, написание которых требует<br />

не глубоких раздумий, а только сугубого <strong>в</strong>нимания. Ярким примером, на котором<br />

часто объясняют аспектно-ориентиро<strong>в</strong>анное программиро<strong>в</strong>ание, я<strong>в</strong>ляется <strong>в</strong>едение<br />

программой протокола с<strong>в</strong>оего <strong>в</strong>ыполнения. Проблема состоит <strong>в</strong> том, похожие<br />

операторы записи <strong>в</strong> файл протокола (или <strong>в</strong>ызо<strong>в</strong> соот<strong>в</strong>етст<strong>в</strong>ующей процедуры)<br />

должны быть помещены <strong>в</strong> сотни разных мест исходной программы. Эти операторы,<br />

может быть, за<strong>в</strong>исят от контекста, <strong>в</strong> котором <strong>в</strong>ыполняется протоколиро<strong>в</strong>ание, но, <strong>в</strong><br />

общем, очень похожи. Идея состоит <strong>в</strong> том, чтобы написать загото<strong>в</strong>ку нужных операторо<strong>в</strong><br />

один раз ("определить аспект"), а также один раз определить пра<strong>в</strong>ило модификации<br />

аспекта <strong>в</strong> соот<strong>в</strong>етст<strong>в</strong>ии с контекстом и один раз определить пра<strong>в</strong>ило<br />

нахождения мест <strong>в</strong> тексте программы, куда эти операторы должны быть <strong>в</strong>ста<strong>в</strong>лены.<br />

Система аспекто-ориентиро<strong>в</strong>анного программиро<strong>в</strong>ания а<strong>в</strong>томатически <strong>в</strong>ста<strong>в</strong>ит<br />

нужные операторы <strong>в</strong>езде, где требуется. Экономия трудозатрат, по<strong>в</strong>ышение надежности,<br />

улучшение читабельности, удобст<strong>в</strong>о по<strong>в</strong>торного использо<strong>в</strong>ания оче<strong>в</strong>идны.<br />

Классические системы программиро<strong>в</strong>ания реализуют идею аспекто<strong>в</strong> с помощью<br />

специального модуля (препроцессора или прохода транслятора), который обычно<br />

назы<strong>в</strong>ают "ткач", поскольку это модуль как бы "<strong>в</strong>плетает" аспекты <strong>в</strong> осно<strong>в</strong>ной код<br />

программы. Насколько же UML приспособлен для реализации этой идеи? Заметим,<br />

<strong>в</strong>о-пер<strong>в</strong>ых, что <strong>в</strong> UML имеется за<strong>в</strong>исимость со стандартным стереотипом «extend»,<br />

которая прямо реализуют идею расширения <strong>в</strong>арианта использо<strong>в</strong>ания "из<strong>в</strong>не".<br />

Пра<strong>в</strong>да, такая за<strong>в</strong>исимость предусмотрена только для <strong>в</strong>арианто<strong>в</strong> использо<strong>в</strong>ания, но<br />

можно определить соот<strong>в</strong>етст<strong>в</strong>ующие стереотипные за<strong>в</strong>исимости и для других элементо<strong>в</strong><br />

моделиро<strong>в</strong>ания. Мы хотели бы обратить <strong>в</strong>нимание на то, что можно пойти<br />

гораздо дальше. В сущности, аспекты – это пример нелокальной операции над текстом<br />

программы (другой пример – так назы<strong>в</strong>аемый "рефакторинг"). Такого рода<br />

нелокальные операции с текстами не слишком широко распространены и применяются<br />

реже, чем они того заслужи<strong>в</strong>ают, из-за сугубой бедности структуры текста<br />

14

программы. В лучшем случае мы можем опираться на дре<strong>в</strong>о<strong>в</strong>идную синтаксическую<br />

структуру. Между тем <strong>в</strong> модели UML, особенно при наличии средст<strong>в</strong> метамоделиро<strong>в</strong>ания,<br />

для формулиро<strong>в</strong>ки пра<strong>в</strong>ил нелокальных преобразо<strong>в</strong>аний модели доступно<br />

значительно больше информации: наряду с отношением <strong>в</strong>ладения между<br />

элементами модели, которое соот<strong>в</strong>етст<strong>в</strong>ует обычной синтаксической иерархии,<br />

можно использо<strong>в</strong>ать причинно-следст<strong>в</strong>енные с<strong>в</strong>язи, <strong>в</strong>ыраженные за<strong>в</strong>исимостями со<br />

стереотипом «refine», строгую типизацию элементо<strong>в</strong>, специфические отношения на<br />

диаграммах и многое другое. Вот пример подобного преобразо<strong>в</strong>ания модели: поиск<br />

и <strong>в</strong>ыделение <strong>в</strong> конечном а<strong>в</strong>томате (диаграмме состояний) соста<strong>в</strong>ных состояний, которые<br />

могли бы объединять состояния исходного а<strong>в</strong>томата. Обсуждение подобных<br />

нелокальных систематических преобразо<strong>в</strong>аний модели только начинается: здесь<br />

пока больше неясных <strong>в</strong>опросо<strong>в</strong>, чем гото<strong>в</strong>ых от<strong>в</strong>ето<strong>в</strong>.<br />

Таким образом, мы <strong>в</strong>идим, что концепции и средст<strong>в</strong>а UML <strong>в</strong> осно<strong>в</strong>ном хорошо согласо<strong>в</strong>аны<br />

с со<strong>в</strong>ременными тенденциями <strong>в</strong> программиро<strong>в</strong>ании, и дело за тем, чтобы<br />

обеспечить должную инструментальную поддержку.<br />

Общие требо<strong>в</strong>ания к инструменту <strong>в</strong>изуального конструиро<strong>в</strong>ания<br />

Пер<strong>в</strong>ое требо<strong>в</strong>ание к инструменту <strong>в</strong>изуального конструиро<strong>в</strong>ания состоит <strong>в</strong> том, что<br />

инструмент должен от<strong>в</strong>ечать с<strong>в</strong>оему наз<strong>в</strong>анию, то есть он должен поз<strong>в</strong>олять конструиро<strong>в</strong>ать<br />

приложения. В пер<strong>в</strong>ом разделе статьи мы сформулиро<strong>в</strong>али критерий того,<br />

что инструмент поддержи<strong>в</strong>ает <strong>в</strong>ариант использо<strong>в</strong>ания "Разработка приложений"<br />

– инструмент должен быть достаточен для <strong>в</strong>оспроиз<strong>в</strong>едения себя самого по<br />

с<strong>в</strong>оей модели. Это требо<strong>в</strong>ание гла<strong>в</strong>ное, но не единст<strong>в</strong>енное.<br />

Другие требо<strong>в</strong>ания <strong>в</strong>ытекают из объекти<strong>в</strong>ных обстоятельст<strong>в</strong> и ограничений. Заметим,<br />

что мы обсуждаем инструменты, поддержи<strong>в</strong>ающие язык UML, который, <strong>в</strong><br />

с<strong>в</strong>ою очередь, я<strong>в</strong>ляется предметом международной стандартизации. Далее, напомним,<br />

что <strong>в</strong>изуальное конструиро<strong>в</strong>ание не только академически интересно, но и нацелено<br />

на по<strong>в</strong>ышение продукти<strong>в</strong>ности разработки, а значит, инструмент должен<br />

быть согласо<strong>в</strong>ан с со<strong>в</strong>ременными тенденциями методологии программиро<strong>в</strong>ания.<br />

Для определения <strong>в</strong>ытекающих требо<strong>в</strong>аний целесообразно использо<strong>в</strong>ать тот же<br />

принцип самоприменимости. Отсюда следует, что инструмент на с<strong>в</strong>оем примере<br />

должен демонстриро<strong>в</strong>ать следо<strong>в</strong>ание принципам компонентного, предметноориентиро<strong>в</strong>анного<br />

и модельно-орентиро<strong>в</strong>анного программиро<strong>в</strong>ания. (Аспектоориентиро<strong>в</strong>анное<br />

программиро<strong>в</strong>ание мы не <strong>в</strong>ключили <strong>в</strong> число осно<strong>в</strong>ных требо<strong>в</strong>аний,<br />

так как оно полезно, но не пер<strong>в</strong>остепенно). Таким образом, наши требо<strong>в</strong>ания<br />

к инструменту суть:<br />

• соот<strong>в</strong>етст<strong>в</strong>ие стандартам;<br />

• компонентная архитектура;<br />

• предметная ориентация;<br />

• модельная ориентиро<strong>в</strong>анность.<br />

Обсудим эти требо<strong>в</strong>ания чуть подробнее. Стандартизация <strong>в</strong>ещь, безусло<strong>в</strong>но, полезная,<br />

а <strong>в</strong> инженерных областях необходимая. Но само по себе формальное соот<strong>в</strong>ет-<br />

15

ст<strong>в</strong>ие стандартам еще не я<strong>в</strong>ляется сущест<strong>в</strong>енной ценностью для пользо<strong>в</strong>ателей инструмента.<br />

Стандарт языка нужен для обеспечения унифициро<strong>в</strong>анного использо<strong>в</strong>ания,<br />

со<strong>в</strong>местимости разных инструменто<strong>в</strong> и переносимости на различные платформы.<br />

Выше мы отметили, что <strong>в</strong>озможность метамоделиро<strong>в</strong>ания <strong>в</strong>едет к <strong>в</strong>ысокой<br />

гибкости инструмента <strong>в</strong>изуального конструиро<strong>в</strong>ания, намного пре<strong>в</strong>осходящей модифицируемость<br />

традиционных систем программиро<strong>в</strong>ания. Особенности (например,<br />

механизмы расширения и точки <strong>в</strong>ариации семантики) и, к сожалению, недого<strong>в</strong>оренности<br />

стандартного определения языка <strong>в</strong>едут к поя<strong>в</strong>лению диалекто<strong>в</strong>. Модели,<br />

созданные разными разработчиками и с помощью различных инструменто<strong>в</strong>,<br />

могут быть со<strong>в</strong>ершенно не похожи друг на друга, и мы не <strong>в</strong>идим <strong>в</strong> таком разнообразии<br />

ничего плохого, если модели от<strong>в</strong>ечают осно<strong>в</strong>ному назначению: <strong>в</strong>изуализации,<br />

спецификации, конструиро<strong>в</strong>анию и документиро<strong>в</strong>анию программных систем.<br />

Применительно к UML разумно <strong>в</strong>ыд<strong>в</strong>инуть требо<strong>в</strong>ание о соот<strong>в</strong>етст<strong>в</strong>ии скорее духу,<br />

нежели бук<strong>в</strong>е стандарта: язык инструмента не должен проти<strong>в</strong>оречить стандарту<br />

(но может быть расширен и доопределен <strong>в</strong> нужных инструменту напра<strong>в</strong>лениях).<br />

Что касается со<strong>в</strong>местимости различных инструменто<strong>в</strong>, то <strong>в</strong>ладелец процесса стандартизации<br />

UML – Object Management Group – уделяет, конечно, <strong>в</strong>нимание этому<br />

<strong>в</strong>опросу, но я<strong>в</strong>но недостаточное. В качест<strong>в</strong>е средст<strong>в</strong>а обеспечение со<strong>в</strong>местимости<br />

предлагается использо<strong>в</strong>ать XMI (XML Metadata Interchange) [Ошибка! Источник<br />

ссылки не найден.] – специальное приложение XML, предназначенное для этой<br />

цели. Но со стандартизацией XMI дело обстоит еще хуже, чем с UML – отста<strong>в</strong>ание<br />

<strong>в</strong>ерсий XMI от UML, несоот<strong>в</strong>етст<strong>в</strong>ие <strong>в</strong>ерсий и так далее. Реальные промышленные<br />

инструменты кое-как понимают друг друга, но с я<strong>в</strong>ными ошибками. Впрочем, произ<strong>в</strong>одителей<br />

инструменто<strong>в</strong> это не очень беспокоит: каждый из них претендует на<br />

то, чтобы стать единст<strong>в</strong>енным нужным пользо<strong>в</strong>ателю поста<strong>в</strong>щиком инструменто<strong>в</strong><br />

моделиро<strong>в</strong>ания. Требо<strong>в</strong>ать не<strong>в</strong>озможного неразумно: достаточно обеспечи<strong>в</strong>ать со<strong>в</strong>местимость<br />

<strong>в</strong> тех пределах, <strong>в</strong> которых (будет) определен XMI. Наконец, многоплатформенность<br />

для самого инструмента необязательна, так как одна из осно<strong>в</strong>ных<br />

идей MDA – это кросс-платформенная генерация кода. Не стоит требо<strong>в</strong>ать, чтобы<br />

инструмент работал <strong>в</strong> любой среде: достаточно, чтобы он работал где-нибудь и<br />

умел конструиро<strong>в</strong>ать приложения для <strong>в</strong>ыполнения <strong>в</strong> нужной среде.<br />

Обратимся теперь к требо<strong>в</strong>анию компонентной архитектуры. Прежде <strong>в</strong>сего, констатируем,<br />

что инструмент компонентного конструиро<strong>в</strong>ания должен быть примером<br />

компонентного конструиро<strong>в</strong>ания, а значит должен быть не "монолитным" программным<br />

продуктом, а конструктором инструменто<strong>в</strong>. Другими сло<strong>в</strong>ами, мы <strong>в</strong>ыд<strong>в</strong>игаем<br />

требо<strong>в</strong>ание не просто компонентной архитектуры, а требо<strong>в</strong>ание компонентой<br />

архитектуры, динамически изменяемой (расширяемой) пользо<strong>в</strong>ателем. В любой<br />

момент компоненты могут быть изменены, удалены или доба<strong>в</strong>лены <strong>в</strong> соот<strong>в</strong>етст<strong>в</strong>ии<br />

с потребностями конкретного случая применения инструмента. Такое требо<strong>в</strong>ание<br />

не я<strong>в</strong>ляется чем-то исключительным: многие со<strong>в</strong>ременные приложения используют<br />

идею надстроек. Надстройка – это компонент, реализующий специфические<br />

функции и <strong>в</strong>ключаемый <strong>в</strong> соста<strong>в</strong> приложения по желанию пользо<strong>в</strong>ателя. Особенностью<br />

<strong>в</strong>ыд<strong>в</strong>игаемого здесь требо<strong>в</strong>ания я<strong>в</strong>ляется то, что инструмент должен я<strong>в</strong>ляться<br />

инструментом разработки с<strong>в</strong>оих надстроек.<br />

Обсудим теперь требо<strong>в</strong>ание предметной ориентации. Предметная ориентация подразуме<strong>в</strong>ает<br />

использо<strong>в</strong>ание специального языка (или языко<strong>в</strong>), ориентиро<strong>в</strong>анного на<br />

16

предметную область. В данном случае предметной областью я<strong>в</strong>ляется метамоделиро<strong>в</strong>ание<br />

и соот<strong>в</strong>етст<strong>в</strong>ующий предметно-ориентиро<strong>в</strong>анный язык – MOF (Meta Object<br />

Facility) [16] – уже предложен той же организацией, что и UML. Однако применительно<br />

к MOF можно по<strong>в</strong>торить сказанное об XMI – ход процесса стандартизации<br />

отстает от потребностей практики. В результате <strong>в</strong>о многих <strong>в</strong>едущих проектах используются<br />

с<strong>в</strong>ои, альтернати<strong>в</strong>ные <strong>в</strong>арианты предметно-ориентиро<strong>в</strong>анных средст<strong>в</strong><br />

метамоделиро<strong>в</strong>ания (см., например, [17]). Поэтому мы не склонны формулиро<strong>в</strong>ать<br />

наше требо<strong>в</strong>ание предметной ориентации <strong>в</strong> жестком формальном <strong>в</strong>иде "MOF Compliant".<br />

Любые средст<strong>в</strong>а метамоделиро<strong>в</strong>ания допустимы, если они достаточны и<br />

удобны. Можно использо<strong>в</strong>ать и с<strong>в</strong>ою метамодель, и с<strong>в</strong>ой язык, даже тексто<strong>в</strong>ый!<br />

Наконец, последнее наше общее требо<strong>в</strong>ание – модельная центриро<strong>в</strong>анность – я<strong>в</strong>ляется,<br />

по-<strong>в</strong>идимому, самым <strong>в</strong>ажным, необычным и трудно <strong>в</strong>ыполнимым требо<strong>в</strong>анием.<br />

Необычность проя<strong>в</strong>ляется даже <strong>в</strong> том, что сама формулиро<strong>в</strong>ка требо<strong>в</strong>ания режет<br />

слух. Мы используем бук<strong>в</strong>альный пере<strong>в</strong>од английского термина model centric,<br />

просто потому, что пока не нашли более подходящего <strong>в</strong>ыражения по-русски. Речь<br />

идет о том, что модель я<strong>в</strong>ляется <strong>в</strong>ажнейшим и (<strong>в</strong> идеале) единст<strong>в</strong>енным абсолютно<br />

необходимым артефактом процесса разработки. Поясним это требо<strong>в</strong>ание проти<strong>в</strong>опоста<strong>в</strong>лением.<br />

При разработке приложения с помощью традиционной системы<br />

программиро<strong>в</strong>ания исходный код программы имеет решающее значение. В процессе<br />

разработки могут использо<strong>в</strong>аться какие-то другие типы артефакто<strong>в</strong> (тексто<strong>в</strong>ые<br />

описания, диаграммы, тесто<strong>в</strong>ые примеры и тому подобное), но исходный код я<strong>в</strong>ляется<br />

гла<strong>в</strong>ным: нет кода – нет и разработанного приложения. И наоборот, есть работающий<br />

код – есть и приложение. Все остальное необязательно. При модельноорентиро<strong>в</strong>анной<br />

разработке роль кода играет модель, наличие исполнимой модели<br />

я<strong>в</strong>ляется необходимым и достаточным усло<strong>в</strong>ием, а исходный код на традиционном<br />

языке программиро<strong>в</strong>ания я<strong>в</strong>ляется только <strong>в</strong>озможным, но необязательным артефактом<br />

разработки. Отсюда следует, что <strong>в</strong>се <strong>в</strong> инструменте должно быть предста<strong>в</strong>лено<br />

<strong>в</strong> форме модели UML, но отнюдь не следует, что <strong>в</strong> этой модели не должно<br />

быть ничего, кроме "стрелочек и к<strong>в</strong>адратико<strong>в</strong>". Так же как и любой другая система<br />

программиро<strong>в</strong>ания, система <strong>в</strong>изуального конструиро<strong>в</strong>ания опирается на набор предопределенных<br />

примити<strong>в</strong>о<strong>в</strong>. По нашему мнению, эти примити<strong>в</strong>ы отнюдь не обязаны<br />

ограничи<strong>в</strong>аться только теми понятиями, через которые (фрагментарно!) определена<br />

операционная семантика UML – их я<strong>в</strong>но недостаточно. В качест<strong>в</strong>е примити<strong>в</strong>о<strong>в</strong><br />

можно использо<strong>в</strong>ать <strong>в</strong>се что угодно, гото<strong>в</strong>ые компоненты любой сложности, лишь<br />

бы они были описаны <strong>в</strong> модели, а реализо<strong>в</strong>аны они могут быть <strong>в</strong>о<strong>в</strong>не произ<strong>в</strong>ольным<br />

образом. В этой с<strong>в</strong>язи заметим, что <strong>в</strong>опрос об алгоритмической полноте UML<br />

<strong>в</strong> контексте нашего рассмотрения предста<strong>в</strong>ляется хотя и любопытным, но достаточно<br />

праздным – напомним, что нашей гла<strong>в</strong>ной целью я<strong>в</strong>ляется по<strong>в</strong>ышение продукти<strong>в</strong>ности<br />

разработки программного обеспечения, а не построение еще одной<br />

модели <strong>в</strong>ычислимости, тем паче "единой теории программиро<strong>в</strong>ания".<br />

Принципы реализации инструмента <strong>в</strong>изуального конструиро<strong>в</strong>ания<br />

Имея поста<strong>в</strong>ленную цель, сформулиро<strong>в</strong>анный критерий ее достижения и требо<strong>в</strong>ания<br />

к решению, попробуем определить, что и как нужно сделать для достижения<br />

цели.<br />

17

Прежде <strong>в</strong>сего, следует определить, что нужно сделать. Мы <strong>в</strong>след за А. Якобсоном<br />

считаем, что соста<strong>в</strong> компоненто<strong>в</strong> (надстроек) должен упра<strong>в</strong>ляться <strong>в</strong>ариантами использо<strong>в</strong>ания.<br />

Например, на рис. 4 предста<strong>в</strong>лена одна из <strong>в</strong>озможных моделей использо<strong>в</strong>ания<br />

инструмента, полученная уточнением исходной модели, показанной<br />

<strong>в</strong>ыше на рис. 2.<br />

Изменение<br />

параметро<strong>в</strong><br />

Написание<br />

скрипто<strong>в</strong><br />

Изменение<br />

метамодели<br />

Настройка<br />

инструмента<br />

Рисо<strong>в</strong>ание<br />

диаграмм<br />

Укладка<br />

диаграмм<br />

Визуализация<br />

диаграмм<br />

Пользо<strong>в</strong>атель<br />

Упра<strong>в</strong>ление<br />

моделями<br />

Соста<strong>в</strong>ление<br />

моделей<br />

Архитектор<br />

Редактиро<strong>в</strong>ание<br />

модели<br />

Конструиро<strong>в</strong>ание<br />

приложений<br />

Разработчик<br />

Верификация<br />

модели<br />

Измерение<br />

модели<br />

Выполение<br />

модели<br />

Обно<strong>в</strong>ление<br />

кода по<br />

модели<br />

Обно<strong>в</strong>ление<br />

модели<br />

по коду<br />

Среда <strong>в</strong>ыполнения<br />

Рис. 4. Уточненная модель использо<strong>в</strong>ания инструмента<br />

По по<strong>в</strong>оду модели использо<strong>в</strong>ания необходимо сделать д<strong>в</strong>а <strong>в</strong>ажных замечания, относящихся<br />

к процессу разработки и специфичных для <strong>в</strong>изуального конструиро<strong>в</strong>ания<br />

приложений.<br />

Во-пер<strong>в</strong>ых, модель использо<strong>в</strong>ания дейст<strong>в</strong>ительно упра<strong>в</strong>ляет процессом <strong>в</strong>изуального<br />

конструиро<strong>в</strong>ания, но отнюдь не обязательно я<strong>в</strong>ляется описанием компонентной<br />

структуры и соста<strong>в</strong>а реализуемых настроек. Может быть так, что <strong>в</strong>ариант использо<strong>в</strong>ания<br />

однозначно соот<strong>в</strong>етст<strong>в</strong>ует отдельному компоненту или надстройке, но ча-<br />

18

ще однозначного соот<strong>в</strong>етст<strong>в</strong>ия не наблюдается: компонент поддержи<strong>в</strong>ает несколько<br />

<strong>в</strong>арианто<strong>в</strong> использо<strong>в</strong>ания, а <strong>в</strong>ариант использо<strong>в</strong>ания реализуется <strong>в</strong> нескольких<br />

компонентах. В этом случае <strong>в</strong>ариант использо<strong>в</strong>ания следует считать скорее описанием<br />

аспекта, "размазанного" по структуре кода.<br />

Во-<strong>в</strong>торых, при <strong>в</strong>изуальном конструиро<strong>в</strong>ании модель использо<strong>в</strong>ания не я<strong>в</strong>ляется<br />

жестко фиксиро<strong>в</strong>анной, подобно тому, как не я<strong>в</strong>ляются жестко фиксиро<strong>в</strong>анными<br />

требо<strong>в</strong>ания <strong>в</strong> традиционном процессе разработки. Собст<strong>в</strong>енно, модель использо<strong>в</strong>ания<br />

– это и есть требо<strong>в</strong>ания. Поэтому не требуется отдельных процессо<strong>в</strong> и инструменто<strong>в</strong><br />

для упра<strong>в</strong>ления требо<strong>в</strong>аниями, поскольку требо<strong>в</strong>ания, по крайней мере,<br />

функциональные, я<strong>в</strong>ляются частью осно<strong>в</strong>ного артефакта – модели приложения – и<br />

упра<strong>в</strong>ляются со<strong>в</strong>местно с остальными элементами модели. По нашему мнению,<br />

итерати<strong>в</strong>ный процесс <strong>в</strong>изуального конструиро<strong>в</strong>ания <strong>в</strong> целом можно предста<strong>в</strong>ить<br />

диаграммой на рис.5Рис. 5.<br />

Моделиро<strong>в</strong>ание<br />

использо<strong>в</strong>ания<br />

Моделиро<strong>в</strong>ание<br />

структуры<br />

Моделиро<strong>в</strong>ание<br />

по<strong>в</strong>едения<br />

[модель<br />

требует<br />

уточнения]<br />

[модель<br />

требует<br />

переработки]<br />

Верификация и<br />

<strong>в</strong>алидация<br />

Рис. 5. Итерати<strong>в</strong>ный процесс <strong>в</strong>изуального конструиро<strong>в</strong>ания<br />

Блоки деятельности на рис. 5 наз<strong>в</strong>аны не со<strong>в</strong>сем при<strong>в</strong>ычно, и это отражает убеждения<br />

а<strong>в</strong>тора: <strong>в</strong>недрение <strong>в</strong>изуального конструиро<strong>в</strong>ания окажет серьезное <strong>в</strong>лияние на<br />

при<strong>в</strong>ычный процесс разработки. Место анализа требо<strong>в</strong>аний займет моделиро<strong>в</strong>ание<br />

использо<strong>в</strong>ания, проектиро<strong>в</strong>ание и реализация сольются <strong>в</strong> моделиро<strong>в</strong>ание, отладка и<br />

19

тестиро<strong>в</strong>ание претерпят радикальные изменения, пре<strong>в</strong>рати<strong>в</strong>шись <strong>в</strong> <strong>в</strong>ерификацию и<br />

<strong>в</strong>алидацию моделей. Но изменятся не только наз<strong>в</strong>ания фаз процесса – это <strong>в</strong>торостепенно.<br />

Важнее то, что кардинально изменится соотношение трудозатрат на разные<br />

фазы <strong>в</strong> процессе. Ль<strong>в</strong>иную долю будет занимать проектиро<strong>в</strong>ание (<strong>в</strong> форме <strong>в</strong>изуального<br />

конструиро<strong>в</strong>ания), а непродукти<strong>в</strong>ные сейчас процессы отладки, тестиро<strong>в</strong>ания<br />

и документиро<strong>в</strong>ания перестанут до<strong>в</strong>леть над менеджерами программных проекто<strong>в</strong>,<br />

систематически недооцени<strong>в</strong>ающих трудозатраты при соста<strong>в</strong>лении плано<strong>в</strong>графико<strong>в</strong>.<br />

Как же построить такой инструмент <strong>в</strong>изуального конструиро<strong>в</strong>ания? Как обычно –<br />

постепенно, итерационно (с помощью "инкрементального" процесса разработки).<br />

Для начала годится что угодно, но лучше сразу начать раскручи<strong>в</strong>ать инструмент,<br />

концептуально ориентиро<strong>в</strong>анный на <strong>в</strong>изуальное конструиро<strong>в</strong>ание приложений, а не<br />

только на рисо<strong>в</strong>ание диаграмм. Многие из "больших" инструменто<strong>в</strong> <strong>в</strong>изуального<br />

моделиро<strong>в</strong>ания и проектиро<strong>в</strong>ания, которые сейчас зая<strong>в</strong>ляют о с<strong>в</strong>оей поддержке<br />

UML 2.0, MDA и <strong>в</strong>изуального конструиро<strong>в</strong>ания, на самом деле изначально не были<br />

ориентиро<strong>в</strong>аны на эти но<strong>в</strong>ые идеи. Конечно, эти инструменты прогрессируют <strong>в</strong><br />

данном напра<strong>в</strong>лении, но лишь с той скоростью, с которой поз<strong>в</strong>оляет богатый (и тяжелый!)<br />

груз унаследо<strong>в</strong>анных компоненто<strong>в</strong>.<br />

Но<strong>в</strong>ые проекты <strong>в</strong>ыглядят динамичнее. Среди последних наибольшего <strong>в</strong>нимания, по<br />

нашему мнению, заслужи<strong>в</strong>ает проект UniMod [18]. А<strong>в</strong>тор наблюдает раз<strong>в</strong>итие проекта<br />

с близкого расстояния, и скорость роста <strong>в</strong>озможностей этого инструмента <strong>в</strong>печатляет.<br />

Проект UniMod опирается на ясную парадигму – а<strong>в</strong>томатное программиро<strong>в</strong>ание<br />

[19, 20]. В соот<strong>в</strong>етст<strong>в</strong>ии с парадигмой а<strong>в</strong>томатного программиро<strong>в</strong>ания приложение<br />

мыслится как со<strong>в</strong>окупность некоторых объекто<strong>в</strong> предметной области и упра<strong>в</strong>ляющих<br />

ими конечных а<strong>в</strong>томато<strong>в</strong>. Объекты упра<strong>в</strong>ления могут <strong>в</strong>ыполнять некоторые<br />

дейст<strong>в</strong>ия и <strong>в</strong> них могут происходить события. А<strong>в</strong>томаты при поступлении событий<br />

<strong>в</strong>ызы<strong>в</strong>ают соот<strong>в</strong>етст<strong>в</strong>ующие дейст<strong>в</strong>ия объекто<strong>в</strong>. Эта простая и ясная парадигма я<strong>в</strong>ляется<br />

необычайно широко применимой. В данной статье а<strong>в</strong>тор не намерен отстаи<strong>в</strong>ать<br />

и разъяснять концепцию а<strong>в</strong>томатного программиро<strong>в</strong>ания (а<strong>в</strong>тору эта идея<br />

предста<strong>в</strong>ляется бесспорной), отсылая читателя за блестящими аргументами и многочисленными<br />

примерами к пер<strong>в</strong>оисточникам [21]. Для нас достаточно того, что<br />

а<strong>в</strong>томатное программиро<strong>в</strong>ание удо<strong>в</strong>лет<strong>в</strong>оряет нашему гла<strong>в</strong>ному критерию полной<br />

раскрутки, <strong>в</strong>ыд<strong>в</strong>инутому <strong>в</strong> пер<strong>в</strong>ом разделе статьи. В качест<strong>в</strong>е показательного примера,<br />

мы предлагаем <strong>в</strong>ниманию читателя а<strong>в</strong>томатную модель интерпретатора а<strong>в</strong>томатных<br />

моделей.<br />

На рис. 6 и 7 показана упрощенная модель интерпретатора моделей UniMod, реализо<strong>в</strong>анная<br />

на UniMod. В качест<strong>в</strong>е исходного материала использо<strong>в</strong>ано описание работы<br />

интерпретатора UniMod, <strong>в</strong>зятое из работы [22]. Для краткости здесь сделаны<br />

сущест<strong>в</strong>енные, но не принципиальные упрощения: не рассматри<strong>в</strong>аются соста<strong>в</strong>ные<br />

состояния и <strong>в</strong>ложенные а<strong>в</strong>томаты (а значит, опущена проблема хранения контекста<br />

<strong>в</strong>ыполнения а<strong>в</strong>томата), интерфейс объекто<strong>в</strong> упра<strong>в</strong>ления унифициро<strong>в</strong>ан (что нетрудно<br />

достичь на практике с помощью соот<strong>в</strong>етст<strong>в</strong>ующей оболочки) и объекты<br />

упра<strong>в</strong>ления немедленно реагируют событиями на упра<strong>в</strong>ляющие <strong>в</strong>оздейст<strong>в</strong>ия.<br />

20

Концептуально модель приложения <strong>в</strong> UniMod состоит из диаграмм д<strong>в</strong>ух типо<strong>в</strong>:<br />

• специализиро<strong>в</strong>анных диаграмм классо<strong>в</strong>, показы<strong>в</strong>ающих участ<strong>в</strong>ующие <strong>в</strong><br />

приложении источники событий, объекты упра<strong>в</strong>ления и а<strong>в</strong>томаты (такие<br />

диаграммы а<strong>в</strong>торы UniMod назы<strong>в</strong>ают диаграммами с<strong>в</strong>язей);<br />

• диаграмм состояний, описы<strong>в</strong>ающих по<strong>в</strong>едение а<strong>в</strong>томато<strong>в</strong>.<br />

На рис. 6 предста<strong>в</strong>лена диаграмма с<strong>в</strong>язей для нашего упрощенного интерпретатора<br />

моделей. Диаграмма <strong>в</strong>ыполнена с использо<strong>в</strong>анием стилистических соглашений UniMod:<br />

сле<strong>в</strong>а источники событий, спра<strong>в</strong>а объекты упра<strong>в</strong>ления, а <strong>в</strong> центре а<strong>в</strong>томаты.<br />

Имена <strong>в</strong>ыбираются <strong>в</strong> соот<strong>в</strong>етст<strong>в</strong>ии с очень жесткой дисциплиной имен, принятой <strong>в</strong><br />

UniMod. Объекты полагается имено<strong>в</strong>ать "о1", "о2" и так далее; упра<strong>в</strong>ляющие <strong>в</strong>оздейст<strong>в</strong>ия<br />

– "z0", "z1"; имена событий начинаются с бук<strong>в</strong>ы "е"; имена функций, участ<strong>в</strong>ующих<br />

<strong>в</strong> стороже<strong>в</strong>ых усло<strong>в</strong>иях на переходах – с бук<strong>в</strong>ы "х".<br />

Такая дисциплина имен кажется непри<strong>в</strong>ычной и даже архаичной, но у нее есть<br />

<strong>в</strong>ажные для <strong>в</strong>изуального конструиро<strong>в</strong>ания достоинст<strong>в</strong>а. Во-пер<strong>в</strong>ых, имена получаются<br />

короткие, а значит, даже сложные <strong>в</strong>ыражения легко размещаются, например,<br />

на стрелках переходо<strong>в</strong> диаграмм состояний. Во-<strong>в</strong>торых, имена типизиро<strong>в</strong>аны на<br />

лексическом уро<strong>в</strong>не, что очень <strong>в</strong>ажно для читабельности диаграмм. Такой стиль<br />

дейст<strong>в</strong>ительно проти<strong>в</strong>оречит якобы общепринятому пра<strong>в</strong>илу обязательного использо<strong>в</strong>ания<br />

длинных содержательных идентификаторо<strong>в</strong>. Заметим, однако, что содержательность<br />

легко достигается комментариями и <strong>в</strong>сплы<strong>в</strong>ающими подсказками,<br />

и при этом не требуется использо<strong>в</strong>ать уродли<strong>в</strong>ых паллиати<strong>в</strong>о<strong>в</strong> наподобие "<strong>в</strong>енгерской<br />

нотации".<br />

21

Рис. 6. Диаграмма с<strong>в</strong>язей интерпретатора<br />

Структура с<strong>в</strong>язей интерпретатора предельно проста: интерпретатору нужен такто<strong>в</strong>ый<br />

генератор, который бы побуждал его работать (на рис. 6 сле<strong>в</strong>а), и д<strong>в</strong>а объекта<br />

упра<strong>в</strong>ления. Пер<strong>в</strong>ый из них предста<strong>в</strong>ляет объект или объекты предметной области<br />

(на рис. 6 обозначен o1), а <strong>в</strong>торой – сам интерпретируемый а<strong>в</strong>томат (на рис. 6 обозначен<br />

o2).<br />

На рис. 7 предста<strong>в</strong>лена диаграмма состояний интерпретатора. Диаграмма сделана<br />

как можно более простой, с тем, чтобы еще раз показать на примере, что интерпретация<br />

моделей не я<strong>в</strong>ляется чем-то запредельно сложным.<br />

22

Рис. 7. Диаграмма состояний интерпретатора<br />

Фактически, на этой диаграмме нет устойчи<strong>в</strong>ых состояний, поскольку <strong>в</strong>се переходы<br />

спонтанны. Таким образом, данная диаграмма может быть прочитана как диаграмма<br />

деятельности, и <strong>в</strong> таком прочтении хорошо <strong>в</strong>идна ее с<strong>в</strong>язь с пер<strong>в</strong>оисточником,<br />

заимст<strong>в</strong>о<strong>в</strong>анным из [22].<br />

Из при<strong>в</strong>еденного примера <strong>в</strong>идно, что для <strong>в</strong>изуального конструиро<strong>в</strong>ания со<strong>в</strong>сем не<br />

обязательно "поддержи<strong>в</strong>ать" <strong>в</strong>есь язык UML. Например, диаграммы с<strong>в</strong>язей UniMod<br />

я<strong>в</strong>ляются <strong>в</strong>есьма узким и к тому же специализиро<strong>в</strong>анным подмножест<strong>в</strong>ом диаграмм<br />

классо<strong>в</strong> UML. С другой стороны, если некоторая концепция поддержи<strong>в</strong>ается,<br />

то она должна поддержи<strong>в</strong>аться <strong>в</strong> полной мере, например, так, как поддержаны диаграммы<br />

состояний <strong>в</strong> UniMod.<br />

Заключение<br />

А<strong>в</strong>тор считает, что предшест<strong>в</strong>ующее изложение я<strong>в</strong>ляется достаточным осно<strong>в</strong>анием<br />

для следующего <strong>в</strong>ы<strong>в</strong>ода.<br />

Визуальное конструиро<strong>в</strong>ание программ <strong>в</strong>озможно, более того, оно реально осущест<strong>в</strong>имо<br />

здесь и сейчас.<br />

Помимо теоретических рассуждений и благих пожеланий имеются конкретные<br />

примеры инструменто<strong>в</strong>, поддержи<strong>в</strong>ающих <strong>в</strong>изуальное конструиро<strong>в</strong>ание приложений.<br />

Самым показательным из из<strong>в</strong>естных примеро<strong>в</strong> а<strong>в</strong>тор считает UniMod. Будучи<br />

с самого начала ориентиро<strong>в</strong>анным на <strong>в</strong>изуальное конструиро<strong>в</strong>ание приложений,<br />

23

данный инструмент сконцентриро<strong>в</strong>ан на гла<strong>в</strong>ном: исполнимой <strong>в</strong>изуальной модели<br />

приложения.<br />

<strong>Статья</strong> подгото<strong>в</strong>лена при поддержке «Лаборатории а<strong>в</strong>томатного программиро<strong>в</strong>ания»,<br />

организо<strong>в</strong>анной корпорацией Borland и Санкт-Петербургским государст<strong>в</strong>енным<br />

уни<strong>в</strong>ерситетом информационных технологий, механики и оптики.<br />

Литература<br />

1. Брауде Э. Технология разработки программного обеспечения. Питер, 2004.<br />

2. http://www.omg.org/mda/<br />

3. Буч Г., Рамбо Д., Якобсон А. UML: специальный спра<strong>в</strong>очник. Питер, 2002.<br />

4. Брукс Ф. Мифический чело<strong>в</strong>еко-месяц. Сим<strong>в</strong>ол, 2000.<br />

5. Якобсон А., Буч Г., Рамбо Дж. Унифициро<strong>в</strong>анный процесс разработки программного<br />

обеспечения. Питер, 2002.<br />

6. Буч Г., Рамбо Д., Якобсон А. Язык UML. Руко<strong>в</strong>одст<strong>в</strong>о пользо<strong>в</strong>ателя. ДМК,<br />

2000.<br />

7. OMG Unified Modeling Language Specification. Version 1.4.<br />

http://www.omg.org<br />

8. http://www.uml.org/#UML2.0<br />

9. Фаулер М., Скотт К. UML. Осно<strong>в</strong>ы. 2-е издание. Сим<strong>в</strong>ол, 2002.<br />

10. Thomas D. UML – Unified or Universal Modeling Language? //Journal of Object<br />

Technology, 1, 2003.<br />

11. Андрее<strong>в</strong> Н.Д. А<strong>в</strong>томатическая <strong>в</strong>ерификация модели UML / IV Международная<br />

молодежная школа-семинар "БИКАМП-2003", СПбГПУ.<br />

12. Уоткинз Д., Хаммонд М., Эйбрамс Б. Программиро<strong>в</strong>ание на платформе<br />

.NET. Вильямс, 2003.<br />

13. Шалыто А. Но<strong>в</strong>ая инициати<strong>в</strong>а <strong>в</strong> программиро<strong>в</strong>ании. Д<strong>в</strong>ижение за открытую<br />

проектную документацию. Мир ПК. 2003, № 9, с.52-57.<br />

http://is.ifmo.ru/works/open_doc/<br />

14. Thomas D., Barry B. Model Driven Development – The Case for Domain Oriented<br />

Programming. http://www.oopsla.org/oopsla2003/files/ddd-sessionvision.html<br />

15. http://www.omg.org/technology/documents/formal/xmi.htm<br />

16. http://www.omg.org/technology/documents/formal/mof.htm<br />

17. http://www.eclipse.org<br />

18. Гуро<strong>в</strong> В.С. , Мазин М.А. , Нар<strong>в</strong>ский А.С., Шалыто A.А. UML. SWITCHтехнология.<br />

Eclipse // Информационно-упра<strong>в</strong>ляющие системы. 2004. № 6,<br />

с.12-17. http://is.ifmo.ru/works/UML-SWITCH-Eclipse.pdf<br />

24

19. Шалыто А.А. SWITCH-технология. Алгоритмизация и программиро<strong>в</strong>ание<br />

задач логического упра<strong>в</strong>ления. СПб.: Наука. 1998, 628 с.<br />

http://is.ifmo.ru/books/switch/1<br />

20. Шалыто А.А. А<strong>в</strong>томатно-ориентиро<strong>в</strong>анное программиро<strong>в</strong>ание / Материалы<br />

IX Всероссийской конференции по проблемам науки и <strong>в</strong>ысшей школы<br />

«Фундаментальные исследо<strong>в</strong>ания <strong>в</strong> технических уни<strong>в</strong>ерситетах». СПбГПУ,<br />

2005, с.44-52. http://is.ifmo.ru/works/_politeh.pdf<br />

21. http://is.ifmo.ru/<br />

22. Гуро<strong>в</strong> В.С. , Мазин М.А. , Шалыто A.А. Операционная семантика UMLдиаграмм<br />

состояний <strong>в</strong> программном пакете UniMod /Труды XII Всероссийской<br />

научно-методической конференции «Телематика – 2005». Т.1, с.74-76.<br />

http://tm.ifmo.ru/tm2005/src/224as.pdf<br />

25

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!