Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Модельдік архитектура аясындағы екі жақты инжиниринг (RTE) – бағдарламалық жасақтаманы әзірлеу құралдарының функционалдығы болып табылады, ол екі немесе одан көп байланысты бағдарламалық артефакттарды – мысалы, бастапқы кодты, модельдерді, конфигурациялық файлдарды, құжаттаманы және т.б. – бір-бірімен синхрондауды қамтамасыз етеді. Екі жақты инжиниринг қажеттілігі бірдей ақпарат бірнеше артефактта болғанда және кейбір артефакттар жаңартылған кезде сәйкессіздік туындау мүмкіндігі болғанда пайда болады. Мысалы, қандай да бір ақпарат тек бір артефактқа (бастапқы кодқа) қосылса немесе өзгертілсе, нәтижесінде ол басқа артефакттарда (модельдерде) жоқ болып қалуы немесе олармен сәйкес келмей қалуы мүмкін.
Round trip engineering (RTE) in the context of model driven architecture is a functionality of software development tools that synchronizes two or more related software artifacts, such as, source code, models, configuration files, documentation, etc. between each other. The need for round trip engineering arises when the same information is present in multiple artifacts and when an inconsistency may arise in case some artifacts are updated. For example, some piece of information was added to/changed in only one artifact (source code) and, as a result, it became missing in/inconsistent with the other artifacts (in models).
Шолу
Round trip инженериясы бағдарламалық қамтамасыз етудің дәстүрлі салаларымен тығыз байланысты: алдыңғы инженерия (спецификациялардан бағдарламалық қамтамасыз ету құру), кері инженерия (қолданыстағы бағдарламалық қамтамасыз етуден спецификацияларды құру) және қайта инженерия (қолданыстағы бағдарламалық қамтамасыз етуді түсіну және оны өзгерту). Round trip инженериясы көбінесе тек алға және кері инженерияны қолдайды деп қате түсіндіріледі. Шындығында, оны алға және кері инженериядан ерекшелейтін Round trip инженериясының басты ерекшелігі – бір уақытта дамыған артефакттарды, бір-біріне енгізілген өзгерістерді көрсету үшін әр артефақты бірте-бірте жаңарту арқылы синхрондау мүмкіндігі. Сонымен қатар, алдыңғы инженерияны тек спецификация ғана бар Round trip инженериясының ерекше жағдайы ретінде қарастыруға болады, ал кері инженерияны тек бағдарламалық қамтамасыз ету ғана бар Round trip инженериясының ерекше жағдайы ретінде қарастыруға болады. Көптеген қайта инженериялық шараларды, бағдарламалық қамтамасыз ету бұрын кері инженерияланған спецификацияға енгізілген өзгерістерді көрсету үшін жаңартылған кезде Round trip инженериясы ретінде қарастыруға болады.
Round trip engineering is closely related to traditional software engineering disciplines: forward engineering (creating software from specifications), reverse engineering (creating specifications from existing software), and reengineering (understanding existing software and modifying it). Round trip engineering is often wrongly defined as simply supporting both forward and reverse engineering. In fact, the key characteristic of round trip engineering that distinguishes it from forward and reverse engineering is the ability to synchronize existing artifacts that evolved concurrently by incrementally updating each artifact to reflect changes made to the other artifacts. Furthermore, forward engineering can be seen as a special instance of RTE in which only the specification is present and reverse engineering can be seen as a special instance of RTE in which only the software is present. Many reengineering activities can also be understood as RTE when the software is updated to reflect changes made to the previously reverse engineered specification.
Автоматты қадамдастыру
Сапар-сапар инженерлігінің тағы бір ерекшелігі – автоматты түрде анықталған қарама-қайшылықтарға жауап ретінде артефактілерді автоматты түрде жаңарту. Осы тұрғыдан алғанда, ол алға және кері инженерліктерден өзгеше, олар қолмен (дәстүрлі түрде) немесе автоматты түрде (артефактілерді автоматты түрде жасау немесе талдау арқылы) жүзеге асырылуы мүмкін. Автоматты жаңарту дереу немесе сұраныс бойынша болуы мүмкін. Дереу сапар-сапар инженерлігінде барлық байланысты артефактілер олардың біреуінде жасалған әр өзгерістен кейін бірден жаңартылады. Сұраныс бойынша сапар-сапар инженерлігінде артефактілердің авторлары бір уақытта артефактілерді жаңарта алады (таратылған ортада да) және белгілі бір сәтте қарама-қайшылықтарды анықтау үшін сәйкестікті тексеруді, олардың кейбіреулерін таратуды және мүмкін болатын қайшылықтарды шешуді таңдай алады.
Another characteristic of round trip engineering is automatic update of the artifacts in response to automatically detected inconsistencies. In that sense, it is different from forward and reverse engineering which can be both manual (traditionally) and automatic (via automatic generation or analysis of the artifacts). The automatic update can be either instantaneous or on demand. In instantaneous RTE, all related artifacts are immediately updated after each change made to one of them. In on demand RTE, authors of the artifacts may concurrently update the artifacts (even in a distributed setting) and at some point choose to execute matching to identify inconsistencies and choose to propagate some of them and reconcile potential conflicts.
Итерациялық тәсіл
Кері инженерлік итеративті даму процесін қамтуы мүмкін. Моделіңізді жаңартылған кодпен синхрондағаннан кейін, жұмыс істеудің ең жақсы жолын таңдауға, кодқа қосымша өзгерістер енгізуге немесе моделіңізге өзгерістер енгізуге толық құқығыңыз бар. Кез келген уақытта екі бағытта да синхрондауға болады және қажет болғанша циклді қайталауға болады.
Round trip engineering may involve an iterative development process. After you have synchronized your model with revised code, you are still free to choose the best way to work – make further modifications to the code or make changes to your model. You can synchronize in either direction at any time and you can repeat the cycle as many times as necessary.
Бағдарламалық жасақтама
Көптеген коммерциялық құралдар мен зерттеу прототиптері осы түрдегі RTE-ні қолдайды; 2007 жылғы кітап Rational Rose, Micro Focus Together, ESS Model, BlueJ және Fujaba сияқты құралдардың мұндай мүмкіндікке ие екенін көрсетеді, ал Fujaba дизайн үлгілерін де анықтай алады делінеді.
Many commercial tools and research prototypes support this form of RTE; a 2007 book lists Rational Rose, Micro Focus Together, ESS Model, BlueJ, and Fujaba among those capable, with Fujaba said to be capable to also identify design patterns.
Шектеулер
Мысалы, 2005 жылғы Visual Studio туралы кітапта RTE құралдарының жиі кездесетін мәселесі – құралдарға бастапқы кодта еңбекті түсіндірмелер қалдыру арқылы көмектеспесе, кері инженерияланған модель бастапқы модельден өзгеше болады делінген. UML-дің мінез-құлқына қатысты бөлімдері RTE үшін одан да көп қиындықтар туғызады. Әдетте UML сынып диаграммалары белгілі бір деңгейде қолдау көрсетіледі; алайда, қауымдастырулар және қамту сияқты кейбір UML ұғымдары көптеген бағдарламалау тілдерінде тікелей бейнеленбейді, бұл жасалған кодтың пайдалануын және кодты талдау/кері инженерияның дәлдігін шектейді (мысалы, кодта қамтуды анықтау қиын). Айналымды инженерияның оңайырақ түрі фреймворк қолданбалық бағдарламалау интерфейстері (API) контекстінде жүзеге асырылады, онда қолданбамен фреймворк API-нің қолданылуын сипаттайтын модель, сол қолданбаның кодымен синхрондалады. Мұндай жағдайда API фреймворктің қолданбаларда қолданылуының барлық дұрыс жолдарын анықтайды, бұл кодтағы API қолданылуын дәл және толық анықтауға, сондай-ақ дұрыс API қолданысын іске асыратын пайдалы кодты жасауға мүмкіндік береді. Бұл санаттағы екі маңызды RTE жүзеге асыруы – фреймворкке қатысты модельдеу тілдері және Spring Roo (Java). Round trip инженериясы Object Management Group (OMG) модельге негізделген архитектурасында бірнеше модельдер арасындағы және модельдер мен код арасындағы үйлесімділікті сақтау үшін маңызды. OMG MDA үшін қажетті модельдік түрлендірулерді жүзеге асыру үшін QVT (сұрау/көрініс/трансформация) стандартын ұсынды. Қазіргі таңдағы күні стандарттың бірнеше іске асырылған нұсқалары бар. (РТЭ-ге қатысты МДА тәжірибесін көрсету қажет).
A 2005 book on Visual Studio notes for instance that a common problem in RTE tools is that the model reversed is not the same as the original one, unless the tools are aided by leaving laborious annotations in the source code. The behavioral parts of UML impose even more challenges for RTE. Usually, UML class diagrams are supported to some degree; however, certain UML concepts, such as associations and containment do not have straightforward representations in many programming languages which limits the usability of the created code and accuracy of code analysis/reverse engineering (e. g., containment is hard to recognize in the code). A more tractable form of round trip engineering is implemented in the context of framework application programming interfaces (APIs), whereby a model describing the usage of a framework API by an application is synchronized with that application's code. In this setting, the API prescribes all correct ways the framework can be used in applications, which allows precise and complete detection of API usages in the code as well as creation of useful code implementing correct API usages. Two prominent RTE implementations in this category are framework specific modeling languages and Spring Roo (Java). Round trip engineering is critical for maintaining consistency among multiple models and between the models and the code in Object Management Group's (OMG) Model driven architecture. OMG proposed the QVT (query/view/transformation) standard to handle model transformations required for MDA. To date, a few implementations of the standard have been created. (Need to present practical experiences with MDA in relation to RTE).
Кодты құру туралы дау
Модельдерден код жасау (түйіндеме инженериясы) дегеніміз – пайдаланушы шешімдерді абстрактілі түрде модельдейді, бұл шешімдер кейбір модельдік деректермен сипатталады, содан кейін автоматтандырылған құрал модельдерден бағдарламалық жүйе үшін кодтың бөліктерін немесе толық бастапқы кодты тудырады. Кейбір құралдарда пайдаланушы бағдарламаның бастапқы кодының қаңқасын, бастапқы код үлгісі түрінде ұсына алады, онда код жасау процесінде алдын ала анықталған элементтер бағдарламаның бастапқы кодының бөліктерімен алмастырылады. UML (егер MDA үшін қолданылса) диаграммаларының сипаттамасы, бағдарламалық кодта қамтылғандай бірдей ақпаратты қамтуға қажетті егжей-тегжейлілік жетіспегендігі үшін сынға ұшырады. Кейбір дамытушылар тіпті "Код – бұл дизайн" деп мәлімдейді.
Code generation (forward engineering) from models means that the user abstractly models solutions, which are connoted by some model data, and then an automated tool derives from the models parts or all of the source code for the software system. In some tools, the user can provide a skeleton of the program source code, in the form of a source code template where predefined tokens are then replaced with program source code parts during the code generation process. UML (if used for MDA) diagrams specification was criticized for lack the detail which is needed to contain the same information as is covered with the program source. Some developers even claim that "the Code is the design".
Кемшіліктер
Шығарылған кодтың модельден тез өзгешеленуіне, кері инженерияланған модельдің кодты шағылыстыру қабілетін жоғалтуына немесе циклдік қайта инженериялау әрекеттері нәтижесінде осы екі проблеманың араласуына қатысты айқын тәуекел бар. UML-дің мінез-құлқымен/динамикалық бөлігіне қатысты, мысалы, күй диаграммалары сияқты мүмкіндіктерге бағдарламалау тілдерінде тікелей баламалары жоқ. Кодты генерациялау кезінде оларды аудару ортақ бағдарламалау операторларының (мысалы) жоқтығына немесе қате түсіндірілуіне әкелуі мүмкін. Егер түзетілгеннен кейін қайта импортталса, нәтижесінде өзгеше немесе толық емес модель пайда болуы мүмкін. Бұл, үлгіні іске асыру және пайдаланушыға арналған логика үшін кодты генерациялау кезеңінде қолданылатын код фрагменттеріне де қатысты: олар араласып кеткен жағдайда кері инженериялау арқылы оңай қалпына келтіру қиын болуы мүмкін. Сонымен қатар, жалпы мақсаттағы және салалық тілдер үшін қазіргі заманғы IDE-лерге (тестілеу, түзету, навигация және т.б.) теңдес келетін модельдеуге арналған жетілдірілген құралдар жетіспейді.
There is a serious risk that the generated code will rapidly differ from the model or that the reverse engineered model will lose its reflection on the code or a mix of these two problems as result of cycled reengineering efforts. Regarding behavioral/dynamic part of UML for featues like statechart diagram there is no equivalents in programming languages. Their translation during code generation will result in common programming statement (. e. g ) being either missing or misinterpreted. If edited and imported back may result in different or incomplete model. The same goes for code snippets used for code generation stage for the pattern implementation and user specific logic: intermixed they may not be easily reverse engineered back. There is also general lack of advanced tooling for modelling that are comparable to that of modern IDEs (for testing, debugging, navigation, etc.) for general purpose programming languages and domain specific languages.