Inginerie dus-întors
Această intrare sau secțiune despre subiectul ingineriei software nu menționează sursele necesare sau cei prezenți sunt insuficienți . |
În ingineria software , Ingineria Round-Trip (RTE) (care ar putea fi tradusă în italiană ca „Inginerie Round-Trip”) este o metodologie care, bazându-se pe instrumentele adecvate de dezvoltare software, asigură sincronizarea tuturor software-urilor artefacte, precum cerințele de sistem , specificația modelului software , fișierele de configurare sau documentația însoțitoare.
Necesitatea de a opera în conformitate cu metodologia RTE apare atunci când aceleași informații sunt conținute în mai multe artefacte și dezvoltarea ar pierde consistența dacă, atunci când o caracteristică a anumitor artefacte se schimbă, această variație nu este propagată în mod adecvat tuturor celorlalte. Un caz tipic este în care adăugarea unei caracteristici, de exemplu în cod, nu se reflectă în modelul la nivel arhitectural. Prin urmare, în acest caz, modelul nu va mai reflecta implementarea acestuia și invers.
RTE este strâns legat de ingineria software tradițională, deoarece este alcătuită dintr-un „mers” și un „return” care este inginerie directă , care implică crearea de software pornind de la specificații și inginerie inversă , care prevede în schimb definiția de specificații pornind de la software-ul existent. Tehnica de reinginerie este utilizată ca ghid și suport în aceste două căi, adică înțelegerea intimă a unui software existent și capacitatea de a-l modifica în fața nevoilor care apar atât în partea cerințelor din caietul de sarcini, cât și în implementarea software-ului.
Dar RTE nu este o tehnică care oferă pur și simplu posibilitatea de a merge înainte și înapoi de-a lungul liniei dezvoltării software-ului: este mai degrabă capacitatea de a sincroniza artefacte existente care evoluează incremental într-o condiție competitivă. Cu alte cuvinte, fiecare artefact este modificat împotriva modificării altui. Ingineria directă poate fi văzută ca o instanță specifică a RTE în care este prezentă doar specificația, în timp ce ingineria inversă este instanța în care este prezent doar software-ul. Multe activități de reinginerie pot fi la rândul lor interpretate ca RTE de fiecare dată când software-ul este modificat pentru a se adapta la modificările făcute în specificațiile deduse dintr-o activitate de inginerie inversă.
RTE se caracterizează și prin instrumente care permit o modificare automată a artefactelor în fața unei inconsecvențe interceptate într-un mod la fel de automat. Această caracteristică o deosebește și de abordarea clasică în care atât înainte cât și înapoi pot fi gestionate atât manual, cât și automat. În RTE, pe de altă parte, automatizarea este esențială chiar dacă poate fi „instantanee” sau „la cerere” în sensul că este sincronă sau asincronă cu variațiile făcute pe diferitele artefacte. În cazul asincronicității, diferiții actori pot lucra concomitent asupra artefactelor individuale și pot solicita o verificare a coerenței la momente definite și apoi pot alege cum să gestioneze eventualele conflicte care au apărut.
Exemple de inginerie dus-întors
Cel mai frecvent exemplu de RTE este sincronizarea între modelele Unified Modeling Language (UML) și codul sursă al acestora.
Multe instrumente comerciale și prototipuri de cercetare (de exemplu, FUJABA: „De la UML la Java și înapoi”) implementează acest tip de RTE. Diagramele de clasă UML sunt de obicei acceptate la un anumit nivel. Dar, în general, unele concepte UML precum „asociere” și „izolare” nu au o reprezentare directă în multe limbaje de programare, ceea ce limitează gradul de utilizare și crearea codului, precum și precizia semnificativă în analiza codului (de exemplu, „izolare” nu este ușoară de identificat în cod). Probleme suplimentare pentru RTE sunt date de părțile descrierii comportamentale din UML
O formă mai accesibilă de RTE este implementată în contextul interfețelor de programare a aplicației (API), unde un model care descrie utilizarea unei aplicații a unui cadru API este sincronizat cu codul aplicației respective. În acest caz, API-ul „prescrie” toate modurile corecte în care acel cadru particular poate fi utilizat. Acest lucru permite identificarea precisă și completă a locului în care API-ul este utilizat în cod și, în același timp, crearea unui cod care implementează o utilizare corectă a API-ului în sine. Două implementări importante aparțin acestei categorii: limbaje de modelare specifice cadrului și Spring Roo