Инфраструктура для трансформации XML-моделей
Предложен вариант упрощенной инфраструктуры для модель-ориентированной разработки больших программных систем. База построения – первичное представление модели в виде доменно-зависимого XML-формата. Модель имеет максимально компактное представление, допускает использование развитых средств изменения...
Gespeichert in:
| Datum: | 2011 |
|---|---|
| Hauptverfasser: | , |
| Format: | Artikel |
| Sprache: | Russian |
| Veröffentlicht: |
Інститут програмних систем НАН України
2011
|
| Schlagworte: | |
| Online Zugang: | http://dspace.nbuv.gov.ua/handle/123456789/50970 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Zitieren: | Инфраструктура для трансформации XML-моделей / Н.Н. Глибовец, В.М. Федорченко // Пробл. програмув. — 2011. — № 3. — С. 52-57. — Бібліогр.: 13 назв. — рос. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| id |
irk-123456789-50970 |
|---|---|
| record_format |
dspace |
| spelling |
irk-123456789-509702013-11-08T03:08:47Z Инфраструктура для трансформации XML-моделей Глибовец, Н.Н. Федорченко, В.М. Модельно-орієнтована розробка програмних систем Предложен вариант упрощенной инфраструктуры для модель-ориентированной разработки больших программных систем. База построения – первичное представление модели в виде доменно-зависимого XML-формата. Модель имеет максимально компактное представление, допускает использование развитых средств изменения и расширения, позволяет легко определить трансформации для преобразования созданных доменно-зависимых моделей в любые другие модели (например, UML). Использование XSL для описания трансформаций дает возможность эффективно организовывать как вертикальные трансформации с произвольным количеством слоев абстракции, так и горизонтальные; создает оптимальные условия для командной работы. 2011 Article Инфраструктура для трансформации XML-моделей / Н.Н. Глибовец, В.М. Федорченко // Пробл. програмув. — 2011. — № 3. — С. 52-57. — Бібліогр.: 13 назв. — рос. 1727-4907 http://dspace.nbuv.gov.ua/handle/123456789/50970 004.4'242 ru Інститут програмних систем НАН України |
| institution |
Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| collection |
DSpace DC |
| language |
Russian |
| topic |
Модельно-орієнтована розробка програмних систем Модельно-орієнтована розробка програмних систем |
| spellingShingle |
Модельно-орієнтована розробка програмних систем Модельно-орієнтована розробка програмних систем Глибовец, Н.Н. Федорченко, В.М. Инфраструктура для трансформации XML-моделей |
| description |
Предложен вариант упрощенной инфраструктуры для модель-ориентированной разработки больших программных систем. База построения – первичное представление модели в виде доменно-зависимого XML-формата. Модель имеет максимально компактное представление, допускает использование развитых средств изменения и расширения, позволяет легко определить трансформации для преобразования созданных доменно-зависимых моделей в любые другие модели (например, UML). Использование XSL для описания трансформаций дает возможность эффективно организовывать как вертикальные трансформации с произвольным количеством слоев абстракции, так и горизонтальные; создает оптимальные условия для командной работы. |
| format |
Article |
| author |
Глибовец, Н.Н. Федорченко, В.М. |
| author_facet |
Глибовец, Н.Н. Федорченко, В.М. |
| author_sort |
Глибовец, Н.Н. |
| title |
Инфраструктура для трансформации XML-моделей |
| title_short |
Инфраструктура для трансформации XML-моделей |
| title_full |
Инфраструктура для трансформации XML-моделей |
| title_fullStr |
Инфраструктура для трансформации XML-моделей |
| title_full_unstemmed |
Инфраструктура для трансформации XML-моделей |
| title_sort |
инфраструктура для трансформации xml-моделей |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2011 |
| topic_facet |
Модельно-орієнтована розробка програмних систем |
| url |
http://dspace.nbuv.gov.ua/handle/123456789/50970 |
| citation_txt |
Инфраструктура для трансформации XML-моделей / Н.Н. Глибовец, В.М. Федорченко // Пробл. програмув. — 2011. — № 3. — С. 52-57. — Бібліогр.: 13 назв. — рос. |
| work_keys_str_mv |
AT glibovecnn infrastrukturadlâtransformaciixmlmodelej AT fedorčenkovm infrastrukturadlâtransformaciixmlmodelej |
| first_indexed |
2025-07-04T12:52:15Z |
| last_indexed |
2025-07-04T12:52:15Z |
| _version_ |
1836720886710796288 |
| fulltext |
Модельно-орієнтована розробка програмних систем
© Н.Н. Глибовец, В.М. Федорченко, 2011
52 ISSN 1727-4907. Проблеми програмування. 2011. № 3
УДК 004.4'242
Н.Н. Глибовец, В.М. Федорченко
ИНФРАСТРУКТУРА
ДЛЯ ТРАНСФОРМАЦИИ XML-МОДЕЛЕЙ
Предложен вариант упрощенной инфраструктуры для модель-ориентированной разработки больших
программных систем. База построения – первичное представление модели в виде доменно-зависимого
XML-формата. Модель имеет максимально компактное представление, допускает использование
развитых средств изменения и расширения, позволяет легко определить трансформации для
преобразования созданных доменно-зависимых моделей в любые другие модели (например, UML).
Использование XSL для описания трансформаций дает возможность эффективно организовывать как
вертикальные трансформации с произвольным количеством слоев абстракции, так и горизонтальные;
создает оптимальные условия для командной работы.
Введение
Как способ формализации описания
разнообразных процессов программирова-
ние, по определению, зависит от конкрет-
ных технических ограничений и инфра-
структуры, в рамках которой собственно
эта формализация проводится. Прогресс в
этой области привел к тому, что для
многих типов задач приоритет программи-
рования сместился c максимально эффек-
тивного (в контексте используемых техни-
ческих ресурсов) кодирования на макси-
мально быструю (в контексте человече-
ских ресурсов) и одновременно качествен-
ную (quality) разработку [1–4].
Модель-ориентированная разра-
ботка. Концепция MDD (Model Driven
Development) построена на доменно-зави-
симом языке моделирования и трансфор-
мации моделей [5, 6]. В контексте MDD,
модель – это абстракция программной сис-
темы или/и ее окружения. Согласно этому
определению, программный код также
является моделью как абстракция над
машинным кодом, генерируемым компи-
лятором. Метамодель определяет синтак-
сис и семантику DSM-языка через опреде-
ление понятий и их отношений в конкрет-
ном домене (процесс создания DSML
называют метамоделированием).
Трансформация моделей (model
transformations) играет ключевую роль в
MDD и отвечает за преобразование
моделей, определенных с помощью DSML,
в другие программные артефакты и формы
представления. Например, модель можно
трансформировать в комбинацию исход-
ных текстов, ресурсов и XML-конфигура-
ций (поскольку в контексте MDA про-
грамма в любой форме является собст-
венно моделью).
Консорциум OMG предложил свой
вариант такой технологии под названием
модель-ориентированная архитектура
(MDA, model driven architecture) в виде
ряда спецификаций и стандартов [7].
Существующие подходы к транс-
формации входной модели условно
разделяют на генерирующие исходную
модель в виде текста (обычно текста
программы на языке программирования
общего назначения: Java, C++) или струк-
турированной формы (например, XML),
отвечающей некоторой метамодели.
Поскольку программный код также
является моделью, отличие в подходах
заключается лишь в использовании исход-
ной метамодели. Когда генерируется текст,
трансформатору не обязательно опериро-
вать структурой метамодели языка про-
граммирования (побочным эффектом
такого упрощения является вероятность
генерации некорректного кода).
Достаточно распространена прак-
тика определения трансформаторов, осно-
ванных на сочетании нескольких подхо-
дов; типичный пример – стандарт QVT, на
основе которого можно определять тран-
сформации в MDA [7]. Другим обще-
Модельно-орієнтована розробка програмних систем
доступным и мощным трансформатором
является реализация стандарта XSLT,
поскольку любую модель можно предста-
вить в виде XML с помощью формата XMI
(XML Metadata Interchange [8]). Однако
ввиду достаточной громоздкости формата
XMI (для разработчика трансформации)
приходим к сложным для разработки и
поддержки XSL-правилам.
Для успешного внедрения MDD
необходима инфраструктура, поддержи-
вающая модель-ориентированную разра-
ботку и удовлетворяющая следующим
требованиям: гибкое манипулирование
параметрами жизненного цикла, определе-
ние и расширение моделей цели при необ-
ходимости (by demand), использование
одновременно разных уровней абстракции,
интеграция с уже существующими
программными системами, минимизация
расходов на интеграцию и поддержку
MDD инфраструктуры.
Упрощенная инфраструктура.
Рассмотрим вариант такой упрощенной
инфраструктуры для модель-ориентиро-
ванной разработки. Идея состоит в воз-
вращении к первичному представлению
модели в виде доменно-зависимого XML-
формата, который избавляет от неостатков
варианта XMI+XSL: модель имеет
максимально компактное представление,
причем читать и изменять модель можно
без использования программистами
специализированных инструментов (ре-
дакторов, визуализаторов). Это свойство
приобретает первоочередное значение,
когда доменная метамодель существенно
меняется в процессе разработки. При этом
сохраняется возможность быстро изменять
и расширять метамодель, а когда доменно-
специфическая метамодель стабилизи-
руется, также определять трансформации
для преобразования созданных доменно-
зависимых моделей в любые другие
модели (например, UML).
На практике также можно свести
определение метамодели к созданию
XML-схемы (XSD) доменно-зависимой
модели (метамодели). Этот язык известен
программистам и имеет инструменталь-
ную поддержку в любой современной
платформе; при этом можно обеспечить
приемлемый на практике уровень валида-
ции моделей с минимальными расходами
времени на расширение метамодели.
Конечно, XSD имеет весьма ограниченные
возможности для описания метамодели, но
когда речь идет о максимально упрощен-
ной инфраструктуре этот вариант прием-
лем как компромисс, поскольку в прин-
ципе есть возможность добавлять собст-
венные метаданные к XML-схеме. Когда и
этого будет недостаточно, определить
метамодель можно с помощью стандарта
MOF (MetaObject Facility) [7], допускаю-
щего определение любой метамодели.
В данном случае использование
XSL для описания трансформаций более
приемлемо, поскольку этот язык является
мощным инструментом (содержит
тьюринг-полный набор функций), особен-
но когда выходную модель можно также
представить в формате XML. Это позволит
организовывать как вертикальные транс-
формации с произвольным количеством
слоев абстракции, так и горизонтальные.
Широкая распространенность и обще-
известность этого языка создает условия
для действительно командной работы,
когда определение метамодели и одновре-
менное создание моделей на ее основе
выполняет одна команда разработчиков.
Это важно для современного процесса
разработки, когда необходимо обеспечить
минимальный промежуток времени между
началом разработки и первыми результа-
тами (feedback).
Последний шаг формирования для
модель-ориентированной разработки –
определение формата модели низшего
уровня, доступного в рамках инфраструк-
туры. Желательно, чтобы модель имела
естественное представление в формате
XML, при этом была достаточно простой
для превращения в машинный код и одно-
временно достаточно удобной для выра-
жения концептов из моделей более высо-
ких уровней абстракции (безусловно, эти
два условия противоречивы).
XML-представление (SpringFrame-
work [9], Winter.NET [10]) обычно имеет
конфигурация IoC-контейнера, реализуе-
мого как паттерн программирования «ин-
версия управления» (inversion of control),
53
Модельно-орієнтована розробка програмних систем
также известного как «инстанциация зави-
симостей» (dependency injection) [11]. Суть
этого паттерна состоит в абстракции
создания и инициализации одних объектов
другими, путем делегирования действий
особым типам объектов (IoC-контейне-
рам). При этом все другие объекты лишь
декларируют минимально необходимые
для функционирования зависимости (через
интерфейсы). Создание графа объектов и
соответственно определения зависимостей
в виде конкретных экземпляров объектов,
реализующих нужные интерфейсы, пола-
гается также на IoC-контейнер. В контек-
сте MDD эта специфика дает уникальную
возможность выполнить оба условия для
модели низшего уровня, поскольку способ
связывания объектов фиксирован (и чрез-
вычайно прост), а сами объекты могут
реализовать достаточно сложные кон-
цепты. Создание такого графа по XML-
конфигурации является достаточно быст-
рой и тривиальной задачей [9, 10].
В терминах MDA IoC-конфигура-
ция – это PSM самого низкого уровня
(поскольку состоит из ссылок на классы и
свойства вполне конкретной платформы),
а доменно-зависимые XML модели, если
они не имеют привязки к особенностям
платформы, относятся к PIM. Конечно,
такое деление достаточно условно. В этом
варианте можно регулировать уровень
абстракции модели от PSM, в зависимости
от конкретной ситуации.
Пример создания упрощенной
MDD инфраструктуры. Для иллюстрации
рассмотрим создание упрощенной MDD
инфраструктуры для трансформации
моделей из домена автоматизации бизнес
процессов.
Определение базовых понятий для
такой модели можно позаимствовать из
многочисленных вариантов «корпоратив-
ной онтологии» (enterprise ontology),
например Core Enterprise Ontology (CEO
[12]), как одной из самых простых. Резуль-
тат трансформации – конфигурация Winter
IoC контейнера [10] для применения на
платформе Microsoft .NET.
CEO предложена как домен для
описания бизнес-процессов и моделиро-
вания в виде информационной системы
(ИС). В упрощенном виде (минимально
необходимом для построения метамодели)
эта онтология состоит из таких базовых
понятий [12]:
• пассивные сущности (passive
entity) – представляют бизнес-объекты,
пассивные элементы корпоративной
среды, которые создаются, изменяются,
пересматриваются с целью получения
информации. Их важное свойств – иденти-
фицируемость как необходимое условие
включения пассивных сущностей в опре-
деление домена данных ИС;
• активные сущности (active entity) –
активные элементы из корпоративной
среды, которые собственно принимают
решения и инициируют те или иные
действия. Это могут быть как люди, так и
более сложные образования (офис, депар-
тамент и т. п.). По отношению к активным
сущностям определяются обязанности и
права доступа;
• трансформации (transformation) –
любые действия, операции и процессы в
корпоративной среде, отображенные в ИС.
Обычно в трансформациях участвуют как
пассивные, так и активные сущности;
• условия – сложные выражения,
которые могут быть вычислены с целью
определения, выполняются ли они. На
этом базовом концепте базируются такие
понятия, как «цель», «правило», «огра-
ничение», «состояние».
Отметим, что метамодель на основе
этих понятий позволяет описать разнооб-
разные бизнес-процессы. При этом даже
простейшее описание этих понятий доста-
точно объемно, поэтому для иллюстрации
упрощенного подхода к трансформации
моделей в деталях, рассмотрим лишь
определение понятия «сущности».
<xsd:element name="entity">
<xsd:complexType>
<xsd:sequence
maxOccurs="unbounded">
<xsd:element name="storage">
<xsd:complexType>
<xsd:sequence
maxOccurs="unbounded">
<xsd:element
name="sourcename"
type="xsd:string" minOccurs="1"/>
54
Модельно-орієнтована розробка програмних систем
</xsd:sequence>
<xsd:attribute
name="versions"
type="xsd:boolean" use="optional"
default="false" />
</xsd:complexType>
</xsd:element>
<xsd:element name="schema">
<xsd:complexType>
<xsd:sequence
maxOccurs="unbounded">
<xsd:element name="field"
minOccurs="1">
<xsd:complexType>
<xsd:attribute name="uid"
type="xsd:boolean" use="optional"
default="false" />
<xsd:attribute
name="name" type="xsd:string"
use="required"/>
<xsd:attribute
name="type" type="xsd:string"
use="required"/>
<xsd:attribute
name="nullable"
type="xsd:boolean" use="optional"
default="false" />
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="name"
type="xsd:string" use="required"
/>
</xsd:complexType>
</xsd:element>
На основе этой метамодели модель
некоторой сущности, например, «заказ»,
является:
<entity name="purchaseOrder">
<storage versions="true">
<sourcename>purchase_orders</sour
cename>
</storage>
<schema>
<field uid="true" name="id"
type="int"/>
<field name="contact_id"
type="int"/>
<field name="sum"
type="decimal"/>
<field name="delta"
type="decimal"/>
<field name="expired_date"
type="dateTime" nullable="true"/>
</schema>
</entity>
Итак, информационная система
(ИС) пополняется еще одной пассивной
сущностью «purchaseOrder» с характери-
стиками «id» (уникальный идентифика-
тор), «contact_id», «sum», «delta» и
«expired_date». Эти характеристики нахо-
дятся в хранилище данных (например, БД)
под именем «purchase_orders». Эту сущ-
ность по определению также можно
сохранять, изменять и загружать из храни-
лища данных; более того, маркировка
versions=«true» обязывает ИС хранить все
версии этой сущности.
Для определения трансформации
этой модели к конфигурации компонентов
IoC-контейнера необходимо представить
концепт пассивной сущности с описанным
выше набором свойств в виде одного или
больше связанных объектов. Допустим, в
классе, в соответствии с паттерном
«активная запись» (Active Record [13])
реализованы свойства хранения, загрузки
и изменения записи в хранилище данных
(C#):
public interface IActiveRecord {
string XmlSchema { get; set;
}
string SourceName { get;
set; }
bool VersionsEnabled { get;
set; }
bool IsPersisted { get; }
object[] Uid {get; set;}
object this[string
fieldName] { get; set; }
void Save();
void Load(object[] uid);
void Delete();
void Disconnect();
}
Допустим, имеем класс
DbActiveRecord (реализующий интерфейс
IActiveRecord), для функционирования
которого необходимо инициализировать
свойства XmlSchema, SourceName и
VersionsEnabled, причем XmlSchema пред-
55
Модельно-орієнтована розробка програмних систем
ставлена в формате, необходимом классу
System.Data.DataSet (ReadXmlSchema).
Тогда трансформация модели сущности к
IoC-конфигурации класса ActiveRecord
будет иметь такой такой вид (XSL):
<xsl:template match='entity'>
<component name="{@name}"
type="LightweightTransformSample.
DbActiveRecord"
singleton="false">
<property name="XmlSchema">
<xml>
<xsl:apply-templates
select="schema"/>
</xml>
</property>
<property name="SourceName">
<value>
<xsl:value-of
select="storage/sourcename"/>
</value>
</property>
<property
name="VersionsEnabled">
<value>
<xsl:value-of
select="storage/@versions"/>
</value>
</property>
</component>
</xsl:template>
Последний шаг – определение
конфигурации IoC-контейнера, чтобы
трансформация выполнялась автомати-
чески при загрузке конфигурации
контейнера (пусть модели сущностей
сохранены в файле entityModel.xml.config,
а описание XSL-трансформации – в
entityModelToIoCTransform.xsl):
<components>
<import
file="config/entityModel.xml.conf
ig"
xsl-
file="config/xslt/entityModelToIo
CTransform.xsl"/>
</components>
Теперь определение «заказа» до-
ступно для связывания с другими компо-
нентами (которое, например, также можно
сгенерировать из модели активности).
Этот пример иллюстрирует про-
стейшее превращение доменно-зависимой
PIM (описывает абстрактную пассивную
сущность «заказа») к PSM в виде конфигу-
рации Winter IoC-контейнера (полный
набор исходных текстов этого примера см.
http://www.winter4.net/down-
load/LightweightTransformSample.zip).
Аналогично строятся более слож-
ные превращения, например, класс
DbActiveRecord мог бы и не иметь свой-
ства VersionsEnabled; тогда этот аспект
необходимо было бы отобразить через
определение еще одной сущности для
сохранения версий, и генерации конфигу-
рации для соответствующего триггера,
который бы создавал новую версию при
каждом изменении сущности
purchaseOrder. То есть общая стратегия
заключается в конфигурации сложных
концептов из метамодели PIM в виде
композиции более примитивных концеп-
тов, доступных в PSM.
Выводы
Предложенный вариант упрощен-
ной инфраструктуры для модель-ориенти-
рованной разработки выполняет совре-
менные требования создания больших
программных систем. Базой построения
есть возврат к первичному представлению
модели в виде доменно-зависимого XML-
формата, избавленного от недостатков
варианта XMI+XSL: модель имеет макси-
мально компактное представление, при
этом просмотр и изменение модели до-
ступны программистам без использования
специальных инструментов. Сохраняется
возможность быстро изменять и расши-
рять метамодель. Когда доменно-специфи-
ческая метамодель стабилизируется,
можно также определить трансформации
для преобразования созданных доменно-
зависимых моделей в любые другие
(стандартизированные) модели (например,
UML).
Использование XSL для описания
трансформаций приемлемо, поскольку
этот язык – мощный инструмент с
56
http://www.winter4.net/down-load/LightweightTransformSample.zip
http://www.winter4.net/down-load/LightweightTransformSample.zip
Модельно-орієнтована розробка програмних систем
тьюринг-полным набором функций.
Эффект достижим, когда выходную
модель можно представить в формате
XML и организовать как вертикальные
трансформации с произвольным количе-
ством слоев абстракции, так и горизон-
тальные.
Распространенность XML создает
условия для командной работы, когда
определение метамодели и одновременное
создание моделей на ее основе выполняет
одна команда разработчиков. Последний
фактор чрезвычайно важен для современ-
ного процесса разработки, когда необхо-
димо обеспечить минимальный проме-
жуток времени между началом разработки
и первыми результатами (feedback).
Предложенный подход к модель-
ориентированной разработке апробирован
в фирме “NewtonIdeas”
(http://www.newtonideas.com), специали-
зирующейся на создании большого объема
схожих веб-проектов (custom development)
для систем управления бизнес-процессами
(BPMS, Business Process Management Sys-
tems). Позитивный эффект получен уже
после первых двух месяцев внедрения, в
течение которых сформированы основные
доменно-специфические концепты в виде
метамоделей и определения трансфор-
маций (на данный момент определено
около 900 понятий, повторно используе-
мых в разных проектах; для реализации
этих понятий используется библиотека из
более 1000 классов). В целом за полтора
года использования вышеописанный
подход полностью подтвердил свою
эффективность: без существенных затрат
на внедрение, а коэффициент повторного
использования кода (и трансформаций)
увеличился до 10 раз.
1. Dijkstra, Edsger W. On the role of scientific
thought", in Dijkstra, Edsger W., Selected
writings on Computing: A Personal
Perspective. – New York, NY, USA: Springer-
Verlag New York, Inc., 1982. – Р. 60–66.
2. Перевозчикова О.Л. Основи системного
аналізу об’єктів і процесів комп’ютеризації.
– К.: Вид. Дім Києво-Могилянської
академії, 2003.
3. Andrew Hunt, David Thomas. Pragmatic
Programmer, The: From Journeyman to
Master. – Addison Wesley, 1999.
4. ДСТУ 3918-99 (ISO/IEC 12207:1995)
Інформаційні технології. Процеси
життєвого циклу програмного забезпе-
чення.
5. Krzysztof Czarnecki. Model-Driven Software
Development: Technology, Engineering,
Management. – Wiley, 2006.
6. Dragan Gasevic, Dragan Djuric, Vladan
Devedzic. Model Driven Architecture and
Ontology Development .– Springer, 2006.
7. Anneke Kleppe, Jos Warmer, Wim Bast. MDA
Explained: The Model Driven Architecture™:
Practice and Promise. – Addison Wesley,
2006.
8. ISO/IEC 19503:2005 Information technology –
XML Metadata Interchange (XMI).
9. Craig Walls, Ryan Breidenbach. Spring in
Action, Second Edition. – Manning, 2007.
10. Lightweight .NET "Inversion of Control"
container – Winter4Net, 2006. –
http://www.winter4.net/
11. Martin Fowler. Inversion of Control
Containers and the Dependency Injection
pattern, 2004. –
http://martinfowler.com/articles/injection.html
12. Bertolazzi P., Krusich C., Missikoff M. An
Approach to the Definition of a Core
Enterprise Ontology: CEO, OES-SEO 2001,
Int. Workshop on Open Enterprise Solutions:
Systems, Experiences, and Organizations,
Rome, September 14–15, 2001.
13. Martin Fowler, David Rice, Matthew
Foemmel, Edward Hieatt, Robert Mee, Randy
Stafford. Patterns of Enterprise Application
Architecture. – Addison Wesley, 2002.
Получено 31.03.2011
Об авторах:
Глибовец Николай Николаевич,
доктор физико-математических наук,
профессор,
декан факультета информатики,
Федорченко Виталий Михайлович,
аспирант.
Место работы авторов:
Национальний университет
«Киево-Могилянская Академия».
04071, Киев, ул. Г. Сковороды, 2.
Тел.: (067) 209 0740
glib@ukma.kiev.ua
57
http://www.informit.com/safari/author_bio.asp@ISBN=032119442X
http://www.informit.com/safari/author_bio.asp@ISBN=032119442X
http://www.informit.com/safari/author_bio.asp@ISBN=032119442X
http://www.winter4.net/
http://martinfowler.com/articles/injection.html
mailto:glib@ukma.kiev.ua
ИНФРАСТРУКТУРА ДЛЯ ТРАНСФОРМАЦИИ XML-МОДЕЛЕЙ
Введение
Выводы
|