Введение
Подход к разработке программного обеспечения
Model Driven Architecture (MDA) — это методология разработки программных систем. Она предоставляет набор рекомендаций по структурированию спецификаций, выраженных в виде моделей. Model Driven Architecture является разновидностью предметно-ориентированной инженерии и поддерживает модель-ориентированную разработку программных систем. Она была представлена организацией Object Management Group (OMG) в 2001 году.
Model Driven Architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model Driven Architecture is a kind of domain engineering, and supports model driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.
Обзор
Model Driven Architecture® (MDA®) "представляет собой подход к получению выгоды от моделей и архитектуры в поддержку полного жизненного цикла физических, организационных и ИТ-систем". Модель – это абстракция (представление) системы. MDA® обеспечивает ценность, создавая модели на различных уровнях абстракции, от концептуального представления до мельчайших деталей реализации. В документации OMG упоминаются три таких уровня абстракции, или архитектурные точки зрения: вычислительно-независимая модель (CIM), платформенно-независимая модель (PIM) и платформенно-зависимая модель (PSM). CIM описывает систему концептуально, PIM описывает вычислительные аспекты системы, не привязываясь к технологиям, которые могут быть использованы для её реализации, а PSM предоставляет технические детали, необходимые для реализации системы. В руководстве OMG также отмечается, что эти три архитектурные точки зрения полезны, но являются лишь тремя из множества возможных. Организация OMG предоставляет спецификации, а не реализации, часто в ответ на запросы предложений (RFP). Реализации разрабатываются частными компаниями или сообществами с открытым исходным кодом.
Сопутствующие стандарты
Модель MDA связана с рядом стандартов, включая Unified Modeling Language (UML), Meta Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), Software Process Engineering Metamodel (SPEM) и Common Warehouse Metamodel (CWM). Важно отметить, что термин «архитектура» в Model Driven Architecture относится не к архитектуре моделируемой системы, а к архитектуре самих стандартов и модельных форм, которые составляют технологическую основу MDA. Исполняемый UML был профилем UML, использовавшимся на заре развития MDA. В настоящее время OMG продвигает fUML. (Языком действий для fUML является ALF.)
Торговая марка
The Object Management Group владеет зарегистрированными товарными знаками на термин Model Driven Architecture и его аббревиатуру MDA, а также товарными знаками для терминов, таких как: Разработка приложений на основе моделей (Model Based Application Development), Разработка приложений с использованием моделей (Model Driven Application Development), Разработка приложений на основе моделей (Model Based Application Development), Программирование на основе моделей (Model Based Programming), Моделируемые системы (Model Driven Systems) и другие.
Подход MDA
OMG фокусирует Model Driven Architecture® на прямой разработке, то есть на генерации кода из абстрактных, разработанных человеком модельных диаграмм (например, диаграмм классов). Группа OMG ADTF (Analysis and Design Task Force – рабочая группа по анализу и проектированию) возглавляет эту работу. С некоторой иронией группа выбрала аббревиатуру ADM (MDA, написанная наоборот) для обозначения изучения обратной инженерии. ADM расшифровывается как Architecture Driven Modernization (модернизация под управлением архитектуры). Цель ADM – разработка стандартов для обратной инженерии устаревших систем на основе моделей. Метамодель обнаружения знаний (KDM) – наиболее продвинутый из этих проектов, описывающий информационные системы в терминах различных ресурсов (программ, спецификаций, данных, тестовых файлов, схем баз данных и т.д.). Поскольку концепции и технологии, используемые для реализации дизайна, и концепции и технологии, используемые для реализации архитектуры, развиваются с разной скоростью, их разделение позволяет разработчикам систем выбирать наилучшие и наиболее подходящие решения в обеих областях. Дизайн отвечает функциональным (вариантам использования) требованиям, а архитектура предоставляет инфраструктуру для реализации нефункциональных требований, таких как масштабируемость, надежность и производительность. MDA предполагает, что платформенно-независимая модель (PIM), представляющая собой концептуальный дизайн, реализующий функциональные требования, переживет изменения в технологиях реализации и архитектуре программного обеспечения. Особое значение для Model Driven Architecture имеет понятие трансформации моделей. OMG разработала специальный стандартный язык для трансформации моделей под названием QVT.
Проблемы с MDA
Некоторые ключевые концепции, лежащие в основе подхода MDA (запущенного в 2001 году), впервые были сформулированы методом Шлеера-Меллора в конце 1980-х годов. Фактически, ключевой отсутствующий технический стандарт подхода MDA (синтаксис языка действий для исполняемого UML) был преодолен некоторыми поставщиками путем адаптации оригинального языка действий Shlaer Mellor (модифицированного для UML). Однако за этот период подход MDA не получил широкого признания в отрасли: Gartner Group по-прежнему определяла MDA как "восходящую" технологию в своем "Цикле шумихи" 2006 года, а Forrester Research объявила MDA "мертвой" (D.O.A.) в 2006 году. Потенциальные проблемы, связанные с подходом MDA OMG, включают:
Incomplete Standards: The MDA approach is underpinned by a variety of technical standards, some of which are yet to be specified (e. g. an action semantic language for xtUML), or are yet to be implemented in a standard manner (e. g. a QVT transformation engine or a PIM with a virtual execution environment). Vendor Lock in: Although MDA was conceived as an approach for achieving (technical) platform independence, current MDA vendors have been reluctant to engineer their MDA toolsets to be interoperable. Such an outcome could result in vendor lock in for those pursuing an MDA approach. Idealistic: MDA is conceived as a forward engineering approach in which models that incorporate Action Language programming are transformed into implementation artifacts (e. g. executable code, database schema) in one direction via a fully or partially automated "generation" step. This aligns with OMG's vision that MDA should allow modelling of a problem domain's full complexity in UML (and related standards) with subsequent transformation to a complete (executable) application. This approach does, however, imply that changes to implementation artifacts (e. g. database schema tuning) are not supported This constitutes a problem in situations where such post transformation "adapting" of implementation artifacts is seen to be necessary. Evidence that the full MDA approach may be too idealistic for some real world deployments has been seen in the rise of so called "pragmatic MDA". Pragmatic MDA blends the literal standards from OMG's MDA with more traditional model driven approaches such as round trip engineering that provides support for adapting implementation artifacts (though not without substantial disadvantages). Specialised Skillsets: Practitioners of MDA based software engineering are (as with other toolsets) required to have a high level of expertise in their field. Current expert MDA practitioners (often referred to as Modeller/Architects) are scarce relative to the availability of traditional developers. OMG Track Record: The OMG consortium who sponsor the MDA approach (and own the MDA trademark) also introduced and sponsored the CORBA standard which itself failed to materialise as a widely utilised standard. Uncertain Value Proposition (UVP): As discussed, the vision of MDA allows for the specification of a system as an abstract model, which may be realized as a concrete implementation (program) for a particular computing platform (e. g. NET). Thus an application that has been successfully developed via a pure MDA approach could theoretically be ported to a newer release NET platform (or even a Java platform) in a deterministic manner – although significant questions remain as to real world practicalities during translation (such as user interface implementation). Whether this capability represents a significant value proposition remains a question for particular adopters. Regardless, adopters of MDA who are seeking value via an "alternative to programming" should be very careful when assessing this approach. The complexity of any given problem domain will always remain, and the programming of business logic needs to be undertaken in MDA as with any other approach. The difference with MDA is that the programming language used (e. g. xtUML) is more abstract (than, say, Java or C#) and exists interwoven with traditional UML artifacts (e. g. class diagrams). Whether programming in a language that is more abstract than mainstream 3GL languages will result in systems of better quality, cheaper cost or faster delivery, is a question that has yet to be adequately answered. MDA was recognized as a possible way to bring various independently developed standardized solutions together. For the simulation community, it was recommended as a business and industry based alternative to yet another US DoD mandated standard.
Неполнота стандартов: подход MDA опирается на ряд технических стандартов, некоторые из которых еще предстоит специфицировать (например, семантический язык действий для xtUML) или реализовать стандартным образом (например, движок преобразований QVT или PIM с виртуальной средой исполнения). Зависимость от поставщика: хотя MDA задумывалась как подход к достижению (технической) платформенной независимости, текущие поставщики MDA неохотно разрабатывают свои инструменты MDA для обеспечения совместимости. Это может привести к зависимости от конкретного поставщика для тех, кто использует подход MDA. Идеалистичность: MDA рассматривается как подход прямого проектирования, в котором модели, включающие программирование на языке действий, преобразуются в артефакты реализации (например, исполняемый код, схему базы данных) в одном направлении посредством полностью или частично автоматизированного этапа "генерации". Это соответствует видению OMG, согласно которому MDA должна позволять моделировать полную сложность предметной области в UML (и связанных стандартах) с последующим преобразованием в полное (исполняемое) приложение. Однако этот подход подразумевает, что изменения в артефактах реализации (например, оптимизация схемы базы данных) не поддерживаются. Это создает проблему в ситуациях, когда такая "адаптация" артефактов реализации после преобразования считается необходимой. Свидетельством того, что полный подход MDA может быть слишком идеалистичным для некоторых реальных сценариев, стало распространение так называемого "прагматичного MDA". Прагматичный MDA сочетает в себе строгие стандарты OMG MDA с более традиционными подходами, основанными на моделях, такими как двунаправленная инженерия, которая обеспечивает поддержку адаптации артефактов реализации (хотя и не без существенных недостатков). Специализированные навыки: специалисты по разработке программного обеспечения на основе MDA (как и для других инструментов) должны обладать высоким уровнем экспертизы в своей области. Квалифицированных специалистов MDA (часто называемых моделировщиками/архитекторами) в настоящее время не хватает по сравнению с количеством традиционных разработчиков. Опыт OMG: консорциум OMG, который спонсирует подход MDA (и владеет товарным знаком MDA), также представил и спонсировал стандарт CORBA, который сам не стал широко используемым стандартом. Неопределенное ценностное предложение (UVP): Как обсуждалось, концепция MDA позволяет специфицировать систему как абстрактную модель, которая может быть реализована в виде конкретной реализации (программы) для определенной вычислительной платформы (например, .NET). Таким образом, приложение, успешно разработанное с использованием чистого подхода MDA, теоретически может быть портировано на новую версию платформы .NET (или даже на платформу Java) детерминированным образом, хотя остаются существенные вопросы относительно практической реализации во время перевода (например, реализации пользовательского интерфейса). Является ли эта возможность значительным ценностным предложением, остается вопросом для конкретных пользователей. В любом случае, пользователи MDA, стремящиеся получить ценность через "альтернативу программированию", должны быть очень осторожны при оценке этого подхода. Сложность любой предметной области всегда будет сохраняться, и программирование бизнес-логики необходимо выполнять в MDA, как и при любом другом подходе. Отличие MDA заключается в том, что используемый язык программирования (например, xtUML) более абстрактный (чем, скажем, Java или C#) и существует в сочетании с традиционными артефактами UML (например, диаграммами классов). Вопрос о том, приведет ли программирование на языке, более абстрактном, чем основные языки 3GL, к системам более высокого качества, меньшей стоимости или более быстрой поставке, пока не получил адекватного ответа. MDA рассматривалась как возможный способ объединения различных независимо разработанных стандартизированных решений. Для сообщества моделирования она была рекомендована как альтернатива, основанная на бизнесе и промышленности, еще одному стандарту, предписанному Министерством обороны США.
Incomplete Standards: The MDA approach is underpinned by a variety of technical standards, some of which are yet to be specified (e. g. an action semantic language for xtUML), or are yet to be implemented in a standard manner (e. g. a QVT transformation engine or a PIM with a virtual execution environment). Vendor Lock in: Although MDA was conceived as an approach for achieving (technical) platform independence, current MDA vendors have been reluctant to engineer their MDA toolsets to be interoperable. Such an outcome could result in vendor lock in for those pursuing an MDA approach. Idealistic: MDA is conceived as a forward engineering approach in which models that incorporate Action Language programming are transformed into implementation artifacts (e. g. executable code, database schema) in one direction via a fully or partially automated "generation" step. This aligns with OMG's vision that MDA should allow modelling of a problem domain's full complexity in UML (and related standards) with subsequent transformation to a complete (executable) application. This approach does, however, imply that changes to implementation artifacts (e. g. database schema tuning) are not supported This constitutes a problem in situations where such post transformation "adapting" of implementation artifacts is seen to be necessary. Evidence that the full MDA approach may be too idealistic for some real world deployments has been seen in the rise of so called "pragmatic MDA". Pragmatic MDA blends the literal standards from OMG's MDA with more traditional model driven approaches such as round trip engineering that provides support for adapting implementation artifacts (though not without substantial disadvantages). Specialised Skillsets: Practitioners of MDA based software engineering are (as with other toolsets) required to have a high level of expertise in their field. Current expert MDA practitioners (often referred to as Modeller/Architects) are scarce relative to the availability of traditional developers. OMG Track Record: The OMG consortium who sponsor the MDA approach (and own the MDA trademark) also introduced and sponsored the CORBA standard which itself failed to materialise as a widely utilised standard. Uncertain Value Proposition (UVP): As discussed, the vision of MDA allows for the specification of a system as an abstract model, which may be realized as a concrete implementation (program) for a particular computing platform (e. g. NET). Thus an application that has been successfully developed via a pure MDA approach could theoretically be ported to a newer release NET platform (or even a Java platform) in a deterministic manner – although significant questions remain as to real world practicalities during translation (such as user interface implementation). Whether this capability represents a significant value proposition remains a question for particular adopters. Regardless, adopters of MDA who are seeking value via an "alternative to programming" should be very careful when assessing this approach. The complexity of any given problem domain will always remain, and the programming of business logic needs to be undertaken in MDA as with any other approach. The difference with MDA is that the programming language used (e. g. xtUML) is more abstract (than, say, Java or C#) and exists interwoven with traditional UML artifacts (e. g. class diagrams). Whether programming in a language that is more abstract than mainstream 3GL languages will result in systems of better quality, cheaper cost or faster delivery, is a question that has yet to be adequately answered. MDA was recognized as a possible way to bring various independently developed standardized solutions together. For the simulation community, it was recommended as a business and industry based alternative to yet another US DoD mandated standard.