A szoftverarchitektúra olyan struktúrák összessége, amelyek szükségesek egy szoftverrendszerről való gondolkodáshoz, valamint az ilyen struktúrák és rendszerek létrehozásának szabályaihoz. Mindegyik struktúra szoftverelemeket, köztük lévő kapcsolatokat, valamint az elemek és kapcsolatok tulajdonságait tartalmazza.
A szoftverrendszer architektúrája egy metafora, analóg egy épület architektúrájával. Ez a rendszer és a fejlesztési projekt tervrajzaként funkcionál, amelyből a projektmenedzsment később extrapolálhatja az érintett csapatok és személyek által elvégzendő feladatokat.
A szoftverarchitektúra olyan alapvető strukturális döntések meghozataláról szól, amelyek megváltoztatása költséges, ha egyszer megvalósul. A szoftverarchitektúra választási lehetőségei a szoftver tervezési lehetőségei közül konkrét strukturális lehetőségeket tartalmaznak. A szoftverarchitektúrának két alapvető törvénye van:
Minden egy kompromisszum "A miért fontosabb, mint a hogyan"
Az "Architectural Kata" egy csapatmunka, amivel az igényeknek megfelelő építészeti megoldást lehet készíteni. Minden csapat kivonja és rangsorolja az építészeti jellemzőket (más néven nem funkcionális követelményeket), majd ennek megfelelően modellezi az összetevőket. A csapat használhatja a C4 Modellt, amely egy rugalmas módszer az architektúra modellezésére. Vegye figyelembe, hogy az építészeti elemek közötti szinkron kommunikáció összefonja őket, és ugyanazokkal az építészeti jellemzőkkel kell rendelkezniük.
A szoftverarchitektúra dokumentálása megkönnyíti az érdekelt felek közötti kommunikációt, rögzíti a magas szintű tervezéssel kapcsolatos korai döntéseket, és lehetővé teszi a tervezési összetevők projektek közötti újrafelhasználását.
A szoftverarchitektúra tervezését általában a szoftveralkalmazások tervezésével állítják szembe. Míg az alkalmazástervezés a szükséges funkcionalitást támogató folyamatok és adatok (a rendszer által kínált szolgáltatások) tervezésére összpontosít, addig a szoftverarchitektúra tervezése annak az infrastruktúrának a megtervezésére összpontosít, amelyen belül az alkalmazás funkcionalitása megvalósítható és végrehajtható úgy, hogy a funkcionalitás egy olyan módon, amely megfelel a rendszer nem funkcionális követelményeinek.
A szoftverarchitektúrák két fő típusba sorolhatók: monolit és elosztott architektúra, mindegyiknek megvan a maga alkategóriája.
A szoftverarchitektúra idővel bonyolultabbá válik. A szoftvertervezőknek fitneszfüggvényeket kell használniuk az architektúra folyamatos ellenőrzése érdekében. bélyegkép|Szoftverarchitektúra-tevékenység
Hatály A szoftverarchitektúrák terjedelmével kapcsolatban megoszlanak a vélemények:
Makroszkópos rendszerstruktúra: Ez a szoftverrendszer architektúrájára utal, mint egy magasabb szintű absztrakció, amely számítási komponensek gyűjteményéből áll, valamint a komponensek közötti interakciókat leíró csatlakozókból. A fontos dolog – bármi legyen is az: ez arra utal, hogy a szoftvertervezőknek foglalkozniuk kell azokkal a döntésekkel, amelyek nagy hatással vannak a rendszerre és annak érdekelt feleire. Ami alapvető a környezetében lévő rendszer megértéséhez Dolgok, amelyeken az emberek nehezen változtathatók: mivel az architektúra tervezése a szoftverrendszer életciklusának kezdetén történik, az építésznek azokra a döntésekre kell összpontosítania, amelyeknek első alkalommal helyesnek kell lenniük. Ezt a gondolatmenetet követve az építészeti tervezési kérdések nem építészeti jellegűekké válhatnak, amint visszafordíthatatlanságuk leküzdhető. Építészeti tervezési döntések halmaza: a szoftverarchitektúrát nem szabad csupán modellek vagy struktúrák halmazának tekinteni, hanem magában kell foglalnia azokat a döntéseket, amelyek ezekhez a konkrét struktúrákhoz vezetnek, és az ezek mögött meghúzódó indokokat. Ez a betekintés jelentős kutatásokhoz vezetett a szoftverarchitektúra tudásmenedzsment terén.
Nincs éles különbség a szoftverarchitektúra és a tervezés és a követelmények tervezése között (lásd a kapcsolódó területeket alább). Mindannyian a „intencionalitás láncának” részét képezik a magas szintű szándékoktól az alacsony szintű részletekig.
Karakterisztikák A szoftver architektúra a következőket mutatja be:
Érintettek sokasága: a szoftverrendszereknek számos érintett igényeit kell kielégíteniük, például üzleti vezetőkét, tulajdonosokét, felhasználókét és üzemeltetőkét. Ezek az érintettek mind saját szempontjaikkal rendelkeznek a rendszerrel kapcsolatban. Az ezek közötti egyensúly megteremtése és annak bemutatása, hogy a szempontjaikat figyelembe vették, a rendszer tervezésének része. Ez azt jelenti, hogy az architektúra számos különböző nézőpontot és érintettet kezel, valamint multidiszciplináris jelleget ölt.
A aggályok szétválasztása: az építészek számára a bonyolultság csökkentésének bevett módja az, hogy szétválasztják a tervezést irányító szempontokat. Az architektúra dokumentációja azt mutatja, hogy az érdekelt felek minden aggályát kezelik az architektúra modellezése és leírása a különböző érdekelt felek aggályaihoz kapcsolódó különböző nézőpontokból. Ezeket a külön leírásokat építészeti nézeteknek nevezzük (lásd például a 4+1 építészeti nézet modellt).
Minőségvezérelt: a klasszikus szoftvertervezési megközelítéseket (pl. Jackson Structured Programming) a szükséges funkcionalitás és a rendszeren keresztüli adatáramlás vezérelte, de a jelenlegi betekintésAz, hogy egy szoftverrendszer architektúrája szorosabban kapcsolódik a minőségi jellemzőihez, mint például a hibatűrés, a visszamenőleges kompatibilitás, a bővíthetőség, a megbízhatóság, a karbantarthatóság, a rendelkezésre állás, a biztonság, a használhatóság és más hasonló szolgáltatások. Az érdekelt felek aggodalmai gyakran ezekre a minőségi jellemzőkre vonatkozó követelményekben fogalmazódnak meg, amelyeket más néven nem funkcionális követelményeknek, extrafunkcionális követelményeknek, viselkedési követelményeknek vagy minőségi attribútum követelményeknek neveznek.
Ismétlődő stílusok: az épületarchitektúrához hasonlóan a szoftverarchitektúra is szabványos módszereket dolgozott ki a visszatérő problémák kezelésére. Ezeket a "szabványos módokat" különféle neveken nevezik az absztrakció különböző szintjein. Az ismétlődő megoldások gyakori kifejezései az építészeti stílus, taktika, referenciaépítészet és építészeti minta.
Fogalmi integritás: ezt a kifejezést Fred Brooks vezette be 1975-ös The Mythical Man-Month című könyvében, azzal az elképzeléssel jelölve, hogy egy szoftverrendszer architektúrája egy átfogó víziót képvisel arról, hogy mit és hogyan kell csinálnia. Ezt az elképzelést el kell választani a megvalósításától. Az építész vállalja a "látás őrzőjének" szerepét, ügyelve arra, hogy a rendszer kiegészítései összhangban legyenek az architektúrával, megőrizve ezzel a koncepcionális integritást.
Kognitív megszorítások: Melvin Conway számítógép-programozó 1967-es tanulmányában tett megfigyelés először, miszerint a rendszereket tervező szervezetek olyan terveket készítenek, amelyek e szervezetek kommunikációs struktúráinak másolatai. Fred Brooks bemutatta a szélesebb közönségnek, amikor a The Mythical Man-Month -ban idézte az újságot és az ötletet, és Conway törvényének nevezte el.
Motiváció A szoftver architektúra egy összetett rendszer "intellektuálisan megragadható" absztrakciója.Ez az absztrakció számos előnnyel jár:
Alapot ad a szoftverrendszerek viselkedésének elemzéséhez a rendszer felépítése előtt. Az a képesség, hogy ellenőrizni tudjuk, hogy egy jövőbeli szoftverrendszer kielégíti-e az érdekelt felek igényeit anélkül, hogy ténylegesen meg kellene építeni, jelentős költségmegtakarítást és kockázatcsökkentést jelent. Számos technikát fejlesztettek ki az ilyen elemzések elvégzésére, mint például az ATAM vagy a szoftverrendszer vizuális megjelenítésének létrehozása. Alapot ad az elemek és döntések újrafelhasználásához. A teljes szoftverarchitektúra vagy annak egyes részei, például az egyedi architektúra-stratégiák és döntések, újra felhasználhatók több olyan rendszerben, amelyekben érdekelt felek hasonló minőségi tulajdonságokat vagy funkcionalitást igényelnek, így tervezési költségeket takarítanak meg, és csökkentik a tervezési hibák kockázatát. Támogatja a korai tervezési döntéseket, amelyek befolyásolják a rendszer fejlesztését, telepítését és karbantartási élettartamát.A korai, nagy hatású döntések helyes meghozatala fontos az ütemezés és a költségvetés túllépésének megelőzése érdekében. Megkönnyíti a kommunikációt az érdekelt felekkel, hozzájárulva egy olyan rendszer kialakításához, amely jobban megfelel az igényeiknek.A komplex rendszerekről az érintettek szemszögéből történő kommunikáció segít megérteni a megfogalmazott követelményeik következményeit és az ezeken alapuló tervezési döntéseket. Az architektúra lehetővé teszi a tervezési döntések kommunikációját a rendszer bevezetése előtt, amikor még viszonylag könnyen adaptálhatóak. Segít a kockázatkezelésben. A szoftverarchitektúra segít csökkenteni a kockázatokat és a meghibásodás esélyét. Költségcsökkentést tesz lehetővé. A szoftverarchitektúra egy eszköz a kockázatok és költségek kezelésére összetett informatikai projektekben.
Történelem A szoftvertervezés és a (polgári) architektúra összehasonlítása először az 1960-as évek végén merült fel, de a "szoftverarchitektúra" kifejezést csak a 90-es években használták széles körben. A számítástechnika területe megalakulása óta a komplexitáshoz kapcsolódó problémákkal szembesült. A korábbi komplexitási problémákat a fejlesztők a megfelelő adatszerkezetek kiválasztásával, algoritmusok fejlesztésével és az aggodalmak szétválasztásának koncepciójával oldották meg. Bár a „szoftverarchitektúra” kifejezés viszonylag új az iparban, a terület alapelveit a szoftverfejlesztés úttörői az 1980-as évek közepe óta szórványosan alkalmazzák. A rendszer szoftverarchitektúrájának rögzítésére és magyarázatára tett korai kísérletek pontatlanok és szervezetlenek voltak, gyakran doboz- és vonaldiagramok jellemezték.
A szoftverarchitektúra mint fogalom Edsger Dijkstra 1968-as és David Parnas 1970-es évek elején végzett kutatásából ered. Ezek a tudósok hangsúlyozták, hogy a szoftverrendszer felépítése számít, és a struktúra megfelelő kialakítása kritikus fontosságú. Az 1990-es években összehangolt erőfeszítések folytak a tudományág alapvető aspektusainak meghatározására és kodifikálására, az építészeti stílusokra (mintázatokra), építészeti leírási nyelvekre, építészeti dokumentációra és formai módszerekre összpontosítva.
A kutatóintézetek kiemelkedő szerepet játszottak a szoftverarchitektúra, mint tudományág továbbfejlesztésében. Mary Shaw és David Garlan (Carnegie Mellon) 1996-ban könyvet írt Software Architecture: Perspectives on an Emerging Discipline címmel, amely olyan szoftverarchitektúra koncepciókat hirdetett, mint az összetevők, csatlakozók és stílusok. A Kaliforniai Egyetem (Irvine 's Institute for Software Research) szoftverarchitektúra-kutatási erőfeszítései elsősorban az építészeti stílusokra, az architektúraleíró nyelvekre és a dinamikus architektúrákra irányulnak.
Az IEEE 1471-2000, "A szoftverintenzív rendszerek architektúrájának leírása javasolt gyakorlat" volt az első formális szabvány a szoftverarchitektúra területén. 2007-ben fogadta el az ISO ISO/IEC 42010:2007 szabványként. 2011 novemberében az IEEE 1471–2000 szabványt felváltotta az ISO/IEC/IEEE 42010:2011, "Rendszer- és szoftverfejlesztés – Architektúra leírása" (az IEEE és az ISO közösen publikálta).