A szoftverkárosodás , más néven szoftvererózió a szoftver architektúrája és a megvalósítás közötti egyensúlyhiány . A "szoftver öregedése" kifejezést a szoftverek során tapasztalt hibákra is utalják. Lehetetlennek tűnik az öregedés megakadályozása, de vannak módok ennek lelassítására, ezért érdeklik a különböző szoftverarchitektúrák.
A szoftverarchitektúra annak leírására, hogy a szoftvert hogyan kell megtervezni, hogy megfeleljen annak specifikációinak . A szoftver megvalósításának meg kell egyeznie a tervezési szakaszban gyártott építészeti modellel. A gyakorlatban nem mindig könnyű betartani ezt a szabályt. Az eltérések eredete többféle: szoftverfejlesztés, implementációs hibák, ellentmondások a tervezett architektúrában, amelyeket a fejlesztés előtt nem lehetett előre látni, stb. Ezzel a problémával megoldható szoftvertervezési koncepciók alkalmazása .
Az építészet fontosságának megértéséhez ismerni kell a projekt végrehajtása során követendő különféle lépéseket. Bármely projekt szükségletből fakad. A jövőbeni felhasználók kielégítéséhez a megoldás kidolgozása előtt meg kell vizsgálni az igényeiket. Ennek köszönhetően lehetővé válik egy adaptált szoftverarchitektúra meghatározása annak érdekében, hogy az elvárthoz közeli eredményt érjünk el. Egy jól definiált architektúrával a megoldás megvalósítása könnyebb lesz, és jobban megfelel az ügyfél elvárásainak, ha nincs különbség a kettő között.
A szoftverarchitektúra lehetővé teszi a szoftver teljes elméleti formában történő megvalósítását, mielőtt gyakorlati módon megvalósítja. Ez lehetővé teszi a technikai korlátok előrejelzését, a fejlesztések adaptált figyelembevételét és a szoftver minőségének garantálását. Ennek eredményeként a költségek csökkennek, és a szoftver lényegesen jobb minőségű. A szoftverarchitektúra fontos szerepet játszik a szoftverfejlesztés következő hat aspektusában:
Az architektúra és a megvalósítás közötti kapcsolat létrehozásához szabályokat kell meghatározni. Ezek lehetővé teszik annak észlelését, ha a megvalósítás eltér az architektúrától.
Kétféle szabályt lehet megkülönböztetni: a strukturális szabályokat és az interakciós szabályokat. A strukturális szabályok ugyanazon entitások létezésére és a közöttük fennálló kapcsolatokra vonatkoznak, míg az interakciós szabályok elsősorban a metódushívások azonos sorrendben való jelenlétére vonatkoznak.
Ezzel a szabálykészlettel az elemzés során háromféle lehetséges eredmény létezik:
Most elég minden egyes eltérést és hiányt egyesével kezelni. A leggyakoribb gyakorlat az, hogy a kódot úgy módosítják, hogy megfeleljen az architektúrának. Lehetséges azonban, hogy a fejlesztés során felmerülő technikai nehézségek miatt módosítani kell a projekt felépítését.
A szoftverromlás fő okai a kódban, a dokumentációban végrehajtott módosítások, az építészeti szabályok be nem tartása miatt. Ezekre a változtatásokra a következő okok miatt van szükség.
Az architektúrák romlásának egyik fő oka a vásárlói igények alakulása. Az ügyfél nem mindig tudja, mire számíthat, amíg meg nem rendelkezik a termék első verziójával. Ezután megpróbálja módosítani a specifikációkat . Ez a probléma akkor is tapasztalható, ha a specifikációk nem elég pontosak. Ez a két pont határozza meg a szoftverek öregedésének két fő típusát: a termék tulajdonosainak a követelmények megváltozása következtében bekövetkezett változásaiból eredő hibákat, valamint a mindkét fél (termék vevője / tervezője) félreértése nyomán végrehajtott változtatások eredményét. szoftver) a termék tervezése és fejlesztése során.
A szoftver leépülésének másik oka az a hardver, amelyhez a szoftver csatlakozik. A szoftverarchitektúrákat a hardvertől tervezik, amelytől a szoftver függ. Idővel a hardver hajlamos a változásokra, ez instabilitást okozhat, és veszélyeztetheti a tervezett architektúrát .
A szoftver élettartama alatt végrehajtott változtatások memóriaelosztási problémát okoznak. Valójában minél több változás történik a kódban, annál inkább nő a program mérete, és minél inkább nő a program mérete, annál inkább következik a rendszerből kért memória. Nehéz előre meghatározni a memóriát a lefoglaláshoz.
A szoftver degradációjának kezelésére számos olyan megoldás létezik, amely lehetővé teszi az öregedés lassítását, ugyanakkor garantálja a minőséget, miközben megpróbálja egyensúlyt tartani az architektúra és a megvalósítás között . Bizonyos (alább említett) technológiák lehetővé teszik a degradáció kezelését. A szoftver minőségének fenntartása érdekében azonban vannak gyakorlati elemek.
A tervezési szakasz célja egy olyan terv létrehozása, amely képes elfogadni a jövőbeli változtatások iránti kérelmeket.
Ez ellentmond sok fejlesztési módszer iteratív jellegének (extrém programozás, gyors prototípus készítés stb.), Mivel ezek a módszertanok általában új követelményeket tartalmaznak, amelyek építészeti hatással lehetnek, a fejlesztés során, míg a jó tervezéshez előre meg kell ismerni ezeket a követelményeket.
Ezért továbbra is fontos olyan architektúrákat tervezni, amelyek alkalmazkodnak a változásokhoz, de kompatibilisek az alkalmazott fejlesztési módszertanokkal is. Így lehetségesnek tűnik agilis architektúrákról beszélni az agilis fejlesztésekhez, és alkalmazni őket a szoftver élettartamának jobb garantálása érdekében.
Ha változtatni kell a szoftveren, úgy tűnik, hogy könnyebb (olcsóbb) alkalmazni ezeket a módosításokat a kódban. Az öregedés késleltetéséhez elengedhetetlen az architektúra és a dokumentáció karbantartása . Valójában a kód minden változtatásakor garantálni kell, hogy az architektúra szabályait betartják és a dokumentációt frissítik. Ez lehetővé teszi az esetleges késések elkerülését a megvalósítás és a szoftverarchitektúra között.
A megfelelő szoftver-karbantartás meghosszabbíthatja a szoftver élettartamát. A karbantartási folyamatok általában iteratív fejlesztéseken vagy a teljes újrafelhasználási modellen alapulnak. Az újrafelhasználás időt takarít meg, csökkenti a költségeket, de veszélyes lehet. Ezért fontos:
A karbantartás során fontos az építészeti szabályok betartása, különösen az új alkatrészek integrálásakor.
Az alábbiakban gyakorlati elemeket találunk, amelyek biztosítják az egyensúlyt a szoftver architektúrája és megvalósítása között .
A kártyát Claire Dimech és Dharini Balasubramaniam, a St Andrews Egyetem Számítástudományi Karának fejlesztette ki.
A Card egy eszköz az architektúra és a megvalósítás közötti megfelelés ellenőrzésére , beépülő modulként van beépítve az Eclipse programba . Az ellenőrzést statikusan végzik az UML-ben található architektúra-leírás és a Java-ban történő megvalósítása között . Ez a keretrendszer két előfeldolgozó modult tartalmaz: az egyik az UML 2.0 diagramokhoz , a másik a Java forráskódhoz. A Card felelős az UML és Java fájlok megtalálásáért az Eclipse projekt faszerkezetében, majd annak előprocesszorait használja az építészeti tulajdonságok kinyerésére. Ezeket a tulajdonságokat az elvégzendő megfelelőségi elemzéshez alkalmas adatstruktúrákban tárolják.
A kártya a "Master Slave" koncepción, az előíró architektúrán (Master) és a leíró architektúrán (Slave) alapul, amelyekre a szabályok hivatkoznak. A Card lehetővé teszi a felhasználó által definiált beállításokat a követelmények három szintjén (Magas, Közepes, Alacsony), ellenőrzi az adatstruktúrákat és a szabálysértéseket visszaküldi a rabszolgának. A fejlesztők statikus módban (offline) vagy dinamikusan (a beállításokban kiválaszthatják) ellenőrizhetik kódjuk és modelljük megfelelőségét.
A kártyát számos projekten tesztelték, és soha nem tárt fel semmilyen hamis jogsértést vagy mulasztást. Nincs azonban hivatalos bizonyíték.
A SAVE-t a Fraunhofer IESE (Kísérleti Szoftvertechnikai Intézet) fejlesztette ki a németországi Kaiserslauternben és a Fraunhofer Center Maryland (Kísérleti Szoftvertechnikai Központ) Marylandben, az Egyesült Államokban.
A SAVE egy olyan fejlesztési eszköz, amely vázlatosan bemutatja a projekt két entitása közötti konvergenciákat és eltéréseket. Ez az eszköz Eclipse bővítményként érhető el, ezért teljes mértékben integrálva van vele. Java , C / C ++ és Delphi fejlesztésű projekteken használható .
A statikus változatot a TESTO vállalatnál három éven keresztül tesztelték egy tucat termék fejlesztése érdekében, és a tanulmány meggyőző eredményeket mutat be.
Van egy plugin (LiFe) is, amely elvégzi az ellenőrzést az alkalmazás kódjának írásakor. Ezt a bővítményt egy diák promócióján is tesztelték, ahol egyes csoportok rendelkeztek a SAVE Life pluginnal, a többieknél pedig nem volt ellenőrző eszköz. A tanulmány azt mutatja, hogy néhány hét múlva a pluginnel fejlesztő diákcsoportok sokkal kevesebb végrehajtási hibát követtek el . Végül a projekt közelebb állt a várt eredményhez, mint a többi csoporté.
Az ArchJava az egyik első megoldás, amelyet az építészet és a megvalósítás közötti kohézió ellenőrzésére fejlesztettek ki . Ezt a megoldást 2002-ben vezették be az Egyesült Államokban.
Az ArchJava a Java kiterjesztett nyelve, amely lehetővé teszi az építészeti korlátok felállítását a megvalósítás során. Ezeket a korlátozásokat a kód kifejezetten meghatározza, a port nevű entitások hozzáadásával az osztályokba. Ezekkel a portokkal lehet meghatározni, hogy mely objektumok kommunikálhatnak egymással, és mely módszerek engedélyezettek ezen a porton.
Tanulmányt végeztek a következő pontok igazolására:
Az összes pontot sikeresen ellenőrizték, és a tesztelt projekt kódjának megértése jelentősen javult, mivel a kommunikáció egyszerűbbé vált.