Кіріспе
Бағдарламалық жасақтаманы жобалау тәсілі. Модельге бағытталған архитектура (MDA) – бағдарламалық жүйелерді дамытуға арналған бағдарламалық жасақтаманы жобалау тәсілі. Ол үлгілер түрінде берілген талаптарды құрылымдау бойынша нұсқаулар жиынтығын ұсынады. Модельге бағытталған архитектура – домендік инженерияның бір түрі және бағдарламалық жүйелерді модельдеу арқылы жасауды қолдайды. Ол 2001 жылы Object Management Group (OMG) ұйымымен енгізілді.
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 моделі бірнеше стандарттармен байланысты, соның ішінде Бірыңғай модельдеу тілі (UML), Метаобъектілер құрылғысы (MOF), XML метадеректер алмасуы (XMI), Enterprise Distributed Object Computing (EDOC), Бағдарламалық процестерді жобалау метамоделі (SPEM) және Ортақ дерек қойма метамоделі (CWM). Модельге бағытталған архитектурадағы "архитектура" термині модельденетін жүйенің архитектурасын емес, MDA үшін технологиялық негіз болып табылатын әртүрлі стандарттар мен модельдердің архитектурасын білдіреді. Орындалатын UML, MDA пайда болған кезде қолданылған UML профилі болды. Қазіргі таңдағыда OMG оның орнына fUML-ді қолдауға бағытталған. (fUML үшін қолданылатын іс-қимыл тілі ALF.)
Тауар белгісі
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 (Анализ және жобалау жөніндегі жұмыс тобы) осы жұмысты жетекшілік етеді. Әзіл-қалжыңмен, топ кері инженерияны зерттеуді атау үшін ADM (MDA-ның керісінше) таңдады. ADM – «Архитектураға негізделген модернизация» деп аударылады. ADM-нің мақсаты – модельге негізделген, ескі жүйелердің кері инженериясы үшін стандарттар құру. Білімді ашу метамоделі (KDM) осы бағыттағы ең жетілген жұмыс болып табылады және ақпараттық жүйелерді әртүрлі активтер (бағдарламалар, спецификациялар, деректер, тест файлдары, деректер базасының схемалары және т.б.) арқылы сипаттайды. Дизайнды іске асыруға қолданылатын түсініктер мен технологиялар және архитектураны іске асыруға қолданылатын түсініктер мен технологиялар өз темпімен өзгеретіндіктен, оларды бөліп қарау жүйе дамытушыларына екі саланың да ең жақсы және сәйкес келетін нұсқаларын таңдауға мүмкіндік береді. Дизайн функционалдық (пайдалану сценарийлері) талаптарын қанағаттандырса, архитектура масштабталу, сенімділік және өнімділік сияқты функционалдық емес талаптарды іске асыратын инфрақұрылымды қамтамасыз етеді. MDA платформаға тәуелсіз модельдің (PIM), функционалдық талаптарды іске асыратын тұжырымдамалық дизайнды білдіретінін, іске асыру технологиялары мен бағдарламалық архитектурадағы өзгерістерге төтеп бере алады деп есептейді. Модельді басқару архитектурасы үшін ерекше маңызды концепция – модельді трансформациялау. OMG модельді трансформациялау үшін арнайы стандартты тілді, QVT деп аталатын тілді анықтады.
MDA мәселесі
MDA әдісін қолданатын кейбір негізгі түсініктер (2001 жылы іске қосылды) алғаш рет 1980-жылдардың соңында Шлаер-Меллор әдісімен түсіндірілді. Шындығында, MDA әдісінің (Executable UML үшін әрекет тілінің синтаксисі) маңызды жоқ техникалық стандарты кейбір жеткізушілердің бастапқы Shlaer Mellor Action Language (UML үшін өңделген) бейімделуі арқылы шешілді. Дегенмен, осы кезеңде MDA тәсілі кеңінен қабылданып, танылмады; Gartner Group 2006 жылғы «Hype Cycle» технологиясында MDA-ны әлі де «дамып келе жатқан» технология ретінде көрсетсе, Forrester Research 2006 жылы MDA-ны «D.O.A.» деп жариялады. OMG 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.
Толық емес стандарттар: MDA тәсілі әртүрлі техникалық стандарттарға негізделген, олардың кейбіреулері әлі де нақтыланбаған (мысалы, xtUML үшін әрекет семантикалық тілі) немесе стандартты түрде іске асырылмаған (мысалы, QVT түрлендіру машинасы немесе виртуалды орындау ортасы бар PIM). Жеткізушіге тәуелділік: MDA техникалық платформадан тәуелсіздікке қол жеткізу үшін жасалғанмен, қазіргі MDA жеткізушілері өздерінің MDA құралдарының өзара үйлесімділігін жасауға құлшынбайды. Мұндай нәтиже MDA тәсілін қолданушылардың жеткізушіге тәуелді болуына әкелуі мүмкін. Идеалды көзқарас: MDA – бұл алдын ала жобалау тәсілі, онда әрекет тілімен бағдарламалауды қамтитын модельдер толық немесе жартылай автоматтандырылған «өндіру» қадамы арқылы іске асыру артефактілеріне (мысалы, орындалатын код, деректер базасының схемасы) айналады. Бұл OMG-нің MDA көзқарасына сәйкес келеді, ол MDA мәселелік доменнің толық күрделілігін UML-де (және оған байланысты стандарттарда) модельдеуге және кейіннен толық (орындалатын) қосымшаға түрлендіруге мүмкіндік беруі керек. Алайда, бұл тәсіл іске асыру артефактілеріне өзгерістер енгізуді (мысалы, деректер базасының схемасын жақсарту) қолдамайды. Бұл іске асыру артефактілерін түрлендіруден кейін «реттеу» қажет болған жағдайларда мәселе тудырады. MDA тәсілінің кейбір нақты жағдайларда тым идеалды болуы мүмкін екендігінің дәлелі «прагматикалық MDA» деп аталатын тәсілдің пайда болуында көрінеді. Прагматикалық MDA OMG MDA-дан алынған нақты стандарттарды, іске асыру артефактілерін бейімдеуге қолдау көрсететін дәстүрлі модельге негізделген тәсілдермен (бірақ маңызды кемшіліктерсіз емес) біріктіреді. Арнайы білімдер жиынтығы: MDA негізіндегі бағдарламалық инженериямен айналысатын мамандар (басқа құралдар жиынтығы сияқты) өз саласында жоғары біліктілікке ие болуы керек. Қазіргі кезде тәжірибелі MDA мамандары (көбінесе модельдеушілер/архитекторлар деп аталады) дәстүрлі бағдарламашыларға қарағанда аз. OMG-нің тәжірибесі: MDA тәсілін демеушілік еткен OMG консорциумы (және 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.