Punct mort (tehnologia informației)
Această intrare sau secțiune despre programare nu citează sursele necesare sau cei prezenți sunt insuficienți . |
În informatică , termenul englezesc dead end (redat în italiană cu expresia „ dead end ”) denotă un anti-model .
Caracteristici generale
Anti-modelul „impasului” apare atunci când, în cursul dezvoltării unei aplicații, este modificată o componentă reutilizabilă din afara proiectului. Deoarece modificarea este locală pentru proiect, costul și responsabilitatea menținerii componentei modificate sunt transferate dezvoltatorilor de aplicații sau celor responsabili de întreținerea acesteia. Odată modificate, toate problemele legate de utilizarea componentei pot fi încărcate, mai mult sau mai puțin corect, asupra modificărilor.
Costuri și dezavantaje
Impasul expune proiectul la costuri suplimentare de întreținere. Ori de câte ori furnizorul actualizează componenta și distribuie o nouă versiune, adoptarea actualizării face necesară reintegrarea modificărilor locale în componenta actualizată. Noile versiuni ale componentei pot fi uneori incompatibile cu modificările locale, astfel încât integrarea poate necesita eforturi semnificative pentru reproiectarea și reimplementarea modificărilor. În unele cazuri, fluctuația personalului și limitarea costurilor fac imposibilă alegerea de a integra modificările. Când se întâmplă acest lucru, aplicația este blocată cu o versiune învechită a componentei: impasul.
Atunci când vânzătorul este extern companiei care dezvoltă aplicația și produce componente software disponibile comercial, anti-modelul fără fund este cunoscut și sub numele de Personalizare COTS .
Cauze și motive
Alegerea de a aduce modificări componentei reutilizabile poate apărea din motive puternice. Este posibil ca dezvoltatorii responsabili de integrarea unui sistem software să fie nevoit să compenseze limitările sau caracteristicile inadecvate ale produsului original. Pe termen scurt, schimbările locale contribuie la dezvoltarea rapidă a aplicației. Pe termen lung, însă, costul întreținerii, necesar atât cu fiecare nouă versiune a aplicației, cât și cu fiecare nouă revizuire a componentei de către furnizor, devine inacceptabil.
Excepții
În unele cazuri, practicile care conduc în mod normal la un punct mort pot fi valabile și recomandabile. Acesta este cazul în care managerul de schimbare a făcut aranjamente cu furnizorul pentru ca modificările să fie încorporate în viitoarele recenzii de produse. Această situație este mai frecventă atunci când dezvoltatorii de aplicații sunt companii care stabilesc contracte și contracte de aprovizionare „personalizate”.
Un alt caz frecvent este acela în care componenta reutilizabilă nu este un produs comercial vândut de un furnizor, ci un software open source . În aceste cazuri, nu este neobișnuit ca modificările locale, dacă sunt valabile, să fie integrate în versiunea oficială de către autorul componentei sau de o comunitate de dezvoltatori voluntari. În unele cazuri, editorii înșiși fac parte din această comunitate sau li se permite să integreze modificările în versiunea oficială a componentei, astfel încât practicile care pot duce în mod normal la un impas devin o contribuție valoroasă la un produs open source.
Nicio modificare nu este absolut greșită. Relația dintre beneficiile oferite de modificarea componentei și costul probabil al lucrărilor de întreținere trebuie întotdeauna luată în considerare. Dacă modificările sunt mici și simple, în timp ce beneficiile sunt substanțiale, alegerea poate fi acceptabilă.
În cele din urmă, modificările locale ale componentelor exterioare reutilizabile pot fi acceptabile (deoarece nu dau naștere la costuri și probleme discutate) atunci când aplicația dezvoltată este un prototip sau un instrument de cercetare care nu necesită întreținere și actualizare pe termen lung.
Soluții
Cel mai extrem caz al acestui anti-model, personalizarea COTS sau modificările aduse componentelor reutilizabile care fac parte din produsele comerciale, trebuie evitat cu orice preț.
Riscul de a ajunge într-un punct mort poate fi limitat prin adoptarea unor platforme de dezvoltare standard utilizate pe scară largă, utilizând componente disponibile comercial ( COTS, Commercial Off-The-Shelf ) care sunt actualizate de furnizor în mod regulat și frecvent. În aceste cazuri, unele dintre limitările componentelor pot fi eliminate prin actualizări.
Dacă modificarea unei componente reutilizabile este o alegere necesară, este cel puțin recomandabil să creați un strat de abstractizare care să izoleze componenta originală de modificări ( strat de izolare ) și să separe dependențele dintre majoritatea aplicației și interfețele introduse de modificări. Stratul de abstractizare poate fi implementat folosind, de exemplu, modelul de proiectare a adaptorului .
