Ugrás a tartalomhoz

Szoftverarchitektúra

A Wikipédiából, a szabad enciklopédiából

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.[1][2]

A szoftverrendszer architektúrája egy metafora, analóg egy épület architektúrájával.[3] 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:[4][5]

  1. Minden egy kompromisszum
  2. "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.[6]

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.[7]:29–35

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.[5]

A szoftverarchitektúra idővel bonyolultabbá válik. A szoftvertervezőknek fitneszfüggvényeket(wd) kell használniuk az architektúra folyamatos ellenőrzése érdekében.[5]

Szoftverarchitektúra-tevékenység

Hatály

[szerkesztés]

A szoftverarchitektúrák terjedelmével kapcsolatban megoszlanak a vélemények:[8]

  • 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.[9]
  • 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.[10]
  • 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ő.[10]
  • É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.[11] Ez a betekintés jelentős kutatásokhoz vezetett a szoftverarchitektúra tudásmenedzsment terén.[12]

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.[13]:18

Karakterisztikák

[szerkesztés]

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.[7]:29–31 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.[14] 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és[7]:26–28Az, 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,[13]:273–277 taktika,[7]:70–72 referenciaépítészet és építészeti minta.[15][16][7]:203–205

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.[17]:41–50

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.[18] 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ó

[szerkesztés]

A szoftver architektúra egy összetett rendszer "intellektuálisan megragadható" absztrakciója.[7]:5–6Ez 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.[3] 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.[19] 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.[3][7]:35 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.[7]:31A 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.[7]:29–31A 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.[13]:18
  • 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.[20]

Történelem

[szerkesztés]

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,[21] de a "szoftverarchitektúra" kifejezést csak a 90-es években használták széles körben.[22] A számítástechnika területe megalakulása óta a komplexitáshoz kapcsolódó problémákkal szembesült.[23] 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.[24]

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.[25]

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).[14]

Míg az IEEE 1471- ben a szoftverarchitektúra a „szoftverintenzív rendszerek” architektúrájáról szólt, amelyet úgy határoztak meg, mint „minden olyan rendszert, ahol a szoftver alapvetően befolyásolja a rendszer egészének tervezését, felépítését, telepítését és fejlődését”, a 2011-es kiadás. tovább megy az ISO/IEC 15288 és az ISO/IEC 12207 rendszerdefiníciók beépítésével, amelyek nemcsak hardvert és szoftvert foglalnak magukban, hanem „emberek, folyamatok, eljárások, létesítmények, anyagok és természetben előforduló entitások”. Ez tükrözi a szoftver-architektúra, a vállalati architektúra és a megoldás-architektúra közötti kapcsolatot.

Építészeti / tervezői tevékenységek

[szerkesztés]

A szoftvertervező számos tevékenységet végez. A szoftvertervező általában projektmenedzserekkel dolgozik, építészetileg jelentős követelményeket vitat meg az érdekelt felekkel, szoftverarchitektúrát tervez, kiértékeli a tervet, kommunikál a tervezőkkel és az érdekelt felekkel, dokumentálja az építészeti tervet és így tovább.[26]

A szoftvertervező felelőssége az felépülési jellemzők (más néven nem funkcionális követelmények) és az üzleti követelmények összehangolása. Például:[5]

  • A magas ügyfél-elégedettség megköveteli a rendelkezésre állást, a hibatűrést, a biztonságot, a tesztelhetőséget, a helyreállíthatóságot, az agilitást és a rendszer teljesítményét.
  • A fúziók és felvásárlások (M&A) bővíthetőséget, méretezhetőséget, alkalmazkodóképességet és interoperabilitást igényelnek
  • A korlátozott költségvetés és idő megköveteli a megvalósíthatóságot és az egyszerűséget
  • A gyorsabb forgalomba hozatalhoz karbantarthatóság, tesztelhetőség és elkeseríthetőség szükséges.

A szoftverarchitektúra tervezésének négy fő tevékenysége van.[27] Ezeket az alapvető architektúra tevékenységeket iteratív módon hajtják végre a kezdeti szoftverfejlesztési életciklus különböző szakaszaiban, valamint a rendszer fejlődése során.

Az építészeti elemzés a környezet megértésének folyamata, amelyben a javasolt rendszer működni fog, és meghatározza a rendszer követelményeit. Az elemzési tevékenység bemenete vagy követelményei tetszőleges számú érdekelttől származhatnak, és olyan elemeket tartalmazhatnak, mint például:

  • mit fog csinálni a rendszer működés közben (a funkcionális követelmények)
  • mennyire teljesíti a rendszer az ISO/IEC 25010 :2011 szabványban[28] meghatározott futásidejű, nem funkcionális követelményeket, mint például megbízhatóság, működőképesség, teljesítmény-hatékonyság, biztonság, kompatibilitás.
  • az ISO 25010:2011 szabványban meghatározott nem funkcionális követelmények, például a karbantarthatóság és az átruházhatóság fejlesztési ideje[28]
  • egy rendszer üzleti követelményei és környezeti összefüggései, amelyek idővel változhatnak, például jogi, társadalmi, pénzügyi, verseny- és technológiai vonatkozások[29]

Az elemzési tevékenység kimenetei azok a követelmények, amelyek mérhető hatással vannak a szoftverrendszer architektúrájára, ezeket építészetileg jelentős követelményeknek nevezzük.[30]

Az építészeti szintézis vagy tervezés az építészet létrehozásának folyamata. Figyelembe véve az elemzés által meghatározott építészetileg jelentős követelményeket, a tervezés jelenlegi állását és az esetleges értékelési tevékenységek eredményeit, a terv elkészítésre és fejlesztésre kerül.[27][7]:311–326

Az architektúra értékelése annak meghatározása, hogy a jelenlegi terv vagy annak egy része mennyire felel meg az elemzés során levezetett követelményeknek. Az értékelés történhet, amikor egy építész tervezési döntést fontolgat, történhet a terv bizonyos részének befejezése után, történhet a végleges terv elkészülte után vagy a rendszer felépítése után. A rendelkezésre álló szoftverarchitektúra-értékelési technikák közé tartozik az Architecture Tradeoff Analysis Method (ATAM) és a TARA.[31] A technikák összehasonlításának kereteit olyan keretek tárgyalják, mint a SARA Jelentés[19] és az Architecture Reviews: Practice and Experience.[32]

Az architektúra evolúciója egy meglévő szoftverarchitektúra karbantartásának és adaptálásának folyamata, hogy megfeleljen a követelmények és a környezet változásainak. Mivel a szoftverarchitektúra egy szoftverrendszer alapvető struktúráját adja, ennek evolúciója és karbantartása szükségszerűen hatással lesz az alapvető szerkezetére. Mint ilyen, az architektúra evolúciója új funkciók hozzáadásával, valamint a meglévő funkciók és a rendszer viselkedésének fenntartásával foglalkozik.

Az építészet kritikus támogató tevékenységeket igényel. Ezek a támogató tevékenységek az alapszoftver-architektúra folyamata során teljesülnek. Ide tartozik a tudásmenedzsment és kommunikáció, a tervezési érvelés és döntéshozatal, valamint a dokumentáció.

Építészetet támogató tevékenységek

[szerkesztés]

A szoftverarchitektúrát támogató tevékenységeket az alapvető szoftverarchitektúra tevékenységek során végzik. Ezek a támogató tevékenységek segítik a szoftvertervezőt az elemzés, szintézis, értékelés és evolúció elvégzésében. Például egy építésznek tudást kell gyűjtenie, döntéseket hoznia és dokumentálnia kell az elemzési szakaszban.

  • A tudásmenedzsment és -kommunikáció a tudás feltárásának és menedzselésének művelete, amely elengedhetetlen a szoftverarchitektúra megtervezéséhez. A szoftvertervező nem elszigetelten dolgozik. Inputokat, funkcionális és nem funkcionális követelményeket, valamint tervezési összefüggéseket kapnak a különböző érdekelt felektől; és eredményeket nyújtson az érdekelt feleknek. A szoftverarchitektúrával kapcsolatos ismeretek gyakran hallgatólagosak, és az érintettek fejében maradnak meg. A szoftverarchitektúra tudásmenedzsment tevékenysége a tudás megtalálásáról, kommunikálásáról és megőrzéséről szól. Mivel a szoftverarchitektúra tervezési kérdései bonyolultak és kölcsönösen függenek egymástól, a tervezési érvelésben lévő tudáshiány helytelen szoftverarchitektúra-tervezéshez vezethet.[26][33] A tudásmenedzsment és kommunikációs tevékenységek példái közé tartozik a tervezési minták keresése, prototípus készítés, tapasztalt fejlesztők és építészek megkérdezése, hasonló rendszerek terveinek értékelése, tudás megosztása más tervezőkkel és érdekelt felekkel, valamint a tapasztalatok dokumentálása egy wiki oldalon.
  • A tervezési érvelés és döntéshozatal a tervezési döntések értékelésének tevékenysége. Ez a tevékenység alapvető mindhárom alapvető szoftverarchitektúra-tevékenységhez.[11][34] Ez magában foglalja a döntési összefüggések összegyűjtését és társítását, a tervezési döntési problémák megfogalmazását, a megoldási lehetőségek megtalálását és a kompromisszumok értékelését a döntések meghozatala előtt. Ez a folyamat a döntési granularitás különböző szintjein megy végbe, miközben értékeli a jelentős építészeti követelményeket és a szoftverarchitektúrával kapcsolatos döntéseket, valamint szoftverarchitektúra elemzést, szintézist és értékelést végez. Az érvelési tevékenységek közé tartozik például egy követelmény vagy egy terv minőségi jellemzőkre gyakorolt hatásának megértése, a tervezés által okozott problémák megkérdőjelezése, a lehetséges megoldási lehetőségek felmérése és a megoldások közötti kompromisszumok értékelése.
  • A dokumentáció a szoftverarchitektúra folyamata során keletkezett terv rögzítésének aktusa. A rendszertervezést számos nézet segítségével írják le, amelyek gyakran tartalmaznak egy statikus nézetet, amely a rendszer kódszerkezetét mutatja, egy dinamikus nézetet, amely a rendszer műveleteit mutatja a végrehajtás során, és egy telepítési nézetet, amely bemutatja, hogy a rendszer hogyan kerül végrehajtásra a hardverre. Kruchten 4+1 nézete a szoftverarchitektúra dokumentálására általánosan használt nézetek leírását javasolja;[35] Szoftverarchitektúrák dokumentálása: A Views and Beyond tartalmazza a nézet leírásában használható jelölések típusainak leírását.[1] A dokumentációs tevékenységek példái közé tartozik a specifikáció írása, a rendszertervezési modell rögzítése, a tervezési indoklás dokumentálása, a nézőpont kialakítása, a nézetek dokumentálása.

Szoftverarchitektúra témák

[szerkesztés]

Szoftverarchitektúra leírása

[szerkesztés]

A szoftverarchitektúra leírása magában foglalja az architektúrák modellezésének és ábrázolásának alapelveit és gyakorlatait, olyan mechanizmusok használatával, mint az architektúraleíró nyelvek, architektúra nézőpontok és architektúra-keretrendszerek.

Az architektúraleíró nyelv (ADL) bármely kifejezési eszköz, amelyet egy szoftverarchitektúra leírására használnak (ISO/IEC/IEEE 42010). Az 1990-es évek óta számos speciális célú ADL-t fejlesztettek ki, köztük az AADL-t (SAE szabvány), a Wrightot (a Carnegie Mellon fejlesztette), az Acme-t (a Carnegie Mellon fejlesztette), az xADL-t (a UCI fejlesztette), a Darwint (az Imperial College London fejlesztette), DAOP-ADL (a Málagai Egyetem fejlesztette), SBC-ADL (a National fejlesztette Sun Yat-Sen Egyetem), és ByADL (University of L'Aquila, Olaszország).

Építészeti nézőpontok

[szerkesztés]
4+1 építészeti nézetmodell

A szoftverarchitektúra leírásait általában nézetekbe rendezik, amelyek hasonlóak az épületépítészetben készült különböző típusú tervrajzokhoz. Minden nézet a rendszer egy adott problémakörét kezeli, követve a hozzá tartozó nézőpont konvencióit. A nézőpont egy olyan specifikáció, amely meghatározza az alkalmazandó jelöléseket, modellezési és elemzési technikákat egy nézetben, amely az érintett architektúrát az adott érintetti csoport és az ő szempontjaik szerint mutatja be (ISO/IEC/IEEE 42010).

A nézőpont nemcsak azokat a problémaköröket határozza meg, amelyeket kezelni kell, hanem azt is, hogyan kell azokat bemutatni, milyen modelleket és konvenciókat kell alkalmazni, valamint azokat a szabályokat is, amelyek biztosítják a nézet konzisztenciáját más nézetekkel.

Építészeti keretrendszerek

[szerkesztés]

Az architektúra-keretrendszer rögzíti "az architektúrák leírására vonatkozó konvenciókat, elveket és gyakorlatokat, amelyeket egy adott alkalmazási területen és/vagy az érintettek közösségében hoztak létre" (ISO/IEC/IEEE 42010). A keretrendszert általában egy vagy több nézőpont vagy ADL alapján valósítják meg.

Építészeti stílusok és minták

[szerkesztés]

Az építészeti minta egy általános, újrafelhasználható megoldás a szoftverarchitektúrában egy adott környezetben gyakran előforduló problémára. Az építészeti mintákat gyakran szoftvertervezési mintákként dokumentálják.

A hagyományos épületépítészetet követve a „szoftverépítészeti stílus” egy sajátos építési mód, amelyet az azt figyelemre méltó jellemzők jellemeznek".

An architectural style defines: a family of systems in terms of a pattern of structural organization; a vocabulary of components and connectors, with constraints on how they can be combined.[36]

Az architekturális stílus meghatározza:

  • A rendszerek egy családját a strukturális szerveződés mintázata alapján.
  • Egy komponensekből és csatlakozókból álló szókészletet, valamint az ezek kombinálására vonatkozó korlátozásokat.
Architectural styles are reusable 'packages' of design decisions and constraints that are applied to an architecture to induce chosen desirable qualities.[37]

Az architekturális stílusok újrahasználható „csomagok” tervezési döntésekből és korlátozásokból, amelyeket egy architektúrára alkalmaznak annak érdekében, hogy elérjenek bizonyos kívánatos tulajdonságokat.

Számos elismert építészeti minta és stílus létezik, köztük:

Vannak, akik az építészeti mintákat és az építészeti stílusokat azonosként, vannak, akik a stílusokat minták specializációjaként kezelik. Közös bennük, hogy mind a minták, mind a stílusok az építészek által használt idiómák, „közös nyelvet” vagy „szókincset” biztosítanak, amellyel rendszerosztályokat írhatnak le.

Szoftverarchitektúra és agilis fejlesztés

[szerkesztés]

Az is aggodalomra ad okot, hogy a szoftverarchitektúra túlságosan nagy tervezéshez vezet, különösen az agilis szoftverfejlesztés hívei körében. Számos módszert fejlesztettek ki az előzetes tervezés és az agilitás közötti kompromisszumok kiegyensúlyozására[38], beleértve az agilis DSDM- módszert, amely előírja az "Alapok" fázist, amely során "éppen elég" építészeti alapokat raknak le. Az IEEE Software külön témakört szentelt az agilitás és az architektúra közötti kölcsönhatásnak.

Szoftver architektúra eróziójaEzenkívül az architektúra erózió kezelésére használt intézkedések két fő típusra oszthatók: megelőző és helyreállító intézkedésekre.

[szerkesztés]

A szoftverarchitektúra eróziója a szoftverrendszer tervezett és megvalósított architektúrája közötti fokozatos szakadékra utal az idő múlásával.[39] A szoftverarchitektúra eróziójának jelenségét 1992-ben hozták napvilágra Perry és Wolf a szoftverarchitektúra meghatározása mellett.[3]

A szoftverarchitektúra eróziója a szoftverfejlesztési életciklus minden szakaszában előfordulhat, és eltérő hatással van a fejlesztés sebességére és a karbantartási költségekre. A szoftverarchitektúra eróziója különféle okok miatt következhet be, mint például az architektúra megsértése, a technikai adósság felhalmozódása és a tudás elpárologtatása.[40] Az architektúra eróziójának híres esete a Mozilla webböngésző meghibásodása. A Mozilla a Netscape által létrehozott alkalmazás, összetett kódbázissal, amelyet a folyamatos változtatások miatt nehezebbé vált a karbantartása. A kezdeti rossz tervezés és a növekvő architektúra-erózió miatt a Netscape két évet töltött a Mozilla webböngésző újrafejlesztésével, bemutatva, milyen fontos az architektúra eróziójának kezelése a kiterjedt javítási erőfeszítések, idő- és költségveszteségek elkerülése érdekében.

Az architektúra eróziója csökkentheti a szoftver teljesítményét, jelentősen növelheti a fejlesztési költségeket, és rontja a szoftver minőségét. Számos megközelítést és eszközt javasoltak az architektúra eróziójának felismerésére. Ezeket a megközelítéseket négy fő kategóriába sorolják: konzisztencián alapuló, evolúció-alapú, hibákra fókuszáló és döntéseken alapuló megközelítés.[39] Ezenkívül az architektúra erózió kezelésére használt intézkedések két fő típusra oszthatók: megelőző és helyreállító intézkedésekre.[39]

Szoftver architektúra helyreállítása

[szerkesztés]

A szoftverarchitektúra helyreállítása (vagy rekonstrukciója vagy visszafejtése) magában foglalja azokat a módszereket, technikákat és folyamatokat, amelyek segítségével a szoftverrendszer architektúrája a rendelkezésre álló információkból feltárható, beleértve a megvalósítást és a dokumentációt. Az építészet helyreállítása gyakran szükséges megalapozott döntések meghozatalához az elavult vagy elavult dokumentációval és az architektúra eróziójával szemben: a megvalósítási és karbantartási döntések eltérnek az elképzelt architektúrától. Léteznek gyakorlatok a szoftverarchitektúra statikus programelemzésként történő helyreállítására. Ez a szoftverintelligencia gyakorlat tárgykörébe tartozik.

Kapcsolódó mezők

[szerkesztés]

Tervezés

[szerkesztés]

Az építészet tervezés, de nem minden tervezés építészeti.[1] A gyakorlatban az építész az, aki meghúzza a határt a szoftverarchitektúra (építészeti tervezés) és a részletes tervezés (nem építészeti tervezés) között. Nincsenek olyan szabályok vagy irányelvek, amelyek minden esetre megfelelnének, bár voltak próbálkozások a megkülönböztetés formalizálására. Az Intension/Locality Hypothesis[41] szerint az építészeti és a részlettervezés közötti különbséget a Locality Criterion határozza meg,[41] amely szerint a szoftvertervezésre vonatkozó állítás akkor és csak akkor nem lokális (architektúra), ha egy program, kielégíti, ki lehet bővíteni olyan programmal, amely nem. Például a kliens-szerver stílus architekturális (stratégiai), mivel egy ezen az elven felépített program egy nem kliens-szerver programmá bővíthető, például peer-to-peer csomópontok hozzáadásával.

Mérnöki követelmények

[szerkesztés]

A követelménytervezés és a szoftverarchitektúra egymást kiegészítő megközelítéseknek tekinthető: míg a szoftverarchitektúra a „ megoldási teret ” vagy a „hogyan”-t célozza meg, addig a követelménytervezés a „ problémateret ” vagy a „mit”.[42] A követelmények tervezése magában foglalja a követelmények meghatározását, egyeztetését, specifikációját, érvényesítését, dokumentálását és kezelését. Mind a követelmények tervezése, mind a szoftverarchitektúra az érdekelt felek aggályai, szükségletei és kívánságai körül forog.

Jelentős átfedés van a követelmények tervezése és a szoftverarchitektúra között, amint azt például egy öt ipari szoftverarchitektúra módszerrel foglalkozó tanulmány is bizonyítja, amely arra a következtetésre jutott, hogy "a bemenetek (célok, korlátok stb.) általában rosszul definiáltak, és csak felfedezhetők vagy jobbak. úgy értendő, ahogy az architektúra kezd kialakulni”, és hogy bár „a legtöbb építészeti aggály a rendszer követelményeiként jelenik meg, ezek magukban foglalhatnak kötelező tervezési döntéseket is”.[27] Röviden, a szükséges viselkedés hatással van a megoldás architektúrájára, ami viszont új követelményeket vezethet be.[43] Az olyan megközelítések, mint a Twin Peaks modell[44] a követelmények és az architektúra közötti szinergikus kapcsolat kihasználását célozzák.

Más típusú „architektúra”

[szerkesztés]
Számítógép-architektúra
A számítógép-architektúra a számítógépes rendszer belső struktúráját célozza meg az együttműködő hardverelemek, például a CPU – vagy processzor – a busz és a memória tekintetében.
Szerver nélküli architektúra
A szerver nélküli architektúra egy felhőalapú számítástechnikai paradigma, amelyet gyakran félreértenek szervermentességként. Lényegében a szerverkezelési feladatokat a fejlesztőkről a felhőszolgáltatókra helyezi át. Ez lehetővé teszi a vállalkozások számára, hogy felhőinfrastruktúrán futtassák háttérkódjukat, így nincs szükség fizikai szerverkezelésre. A kiszolgáló nélküli architektúra eseményvezérelt megközelítése kicsi, feladat-specifikus funkciókra támaszkodik, amelyeket igény szerint hajtanak végre. Ezeket a funkciókat Function as a Service (FaaS) néven ismerik, és költséghatékonyságot kínálnak a felosztó-kirovó számlázási modellen és az alkalmazásigényen alapuló dinamikus erőforrás-skálázáson keresztül.[45] </link>[ jobb forrás szükséges ]
Rendszer architektúra
A rendszerarchitektúra kifejezést eredetileg a hardverből és szoftverből álló rendszerek architektúrájára használták. A rendszerarchitektúra által kezelt fő probléma a szoftver és a hardver integrálása egy teljes, megfelelően működő eszközbe. Egy másik elterjedt – jóval tágabb – jelentésben a kifejezés bármely összetett rendszer architektúrájára vonatkozik, amely lehet technikai, szociotechnikai vagy társadalmi jellegű.
Vállalati architektúra
A vállalati architektúra célja, hogy "az üzleti jövőképet és stratégiát hatékony vállalkozássá alakítsa". A vállalati architektúra keretrendszerei, például a TOGAF és a Zachman-keretrendszer általában különbséget tesznek a különböző vállalati architektúra rétegek között. Bár a terminológia keretrendszerenként eltérő, sok esetben legalább különbséget tesznek az üzleti réteg, az alkalmazási (vagy információs) réteg és a technológiai réteg között. A vállalati architektúra többek között az e rétegek közötti igazítással foglalkozik, általában felülről lefelé irányuló megközelítésben.

Hivatkozások

[szerkesztés]
  1. Ugrás ehhez: a b c Clements, Paul. Documenting Software Architectures: Views and Beyond, Second Edition (amerikai angol nyelven). Boston: Addison-Wesley (2010). ISBN 978-0-321-55268-6 
  2. Software Architecture (amerikai angol nyelven). www.sei.cmu.edu. (Hozzáférés: 2018. július 23.)
  3. Ugrás ehhez: a b c d Perry (1992). „Foundations for the study of software architecture”. ACM SIGSOFT Software Engineering Notes 17 (4), 40. o. DOI:10.1145/141874.141884. 
  4. Head First Software Architecture. O'Reilly Media (2024). ISBN 978-1098134358 
  5. Ugrás ehhez: a b c d Fundamentals of Software Architecture: An Engineering Approach. O'Reilly Media (2020). ISBN 978-1492043454 
  6. Fundamentals of Software Architecture An Engineering Approach. O'Reilly Media (2020). ISBN 9781492043423 
  7. Ugrás ehhez: a b c d e f g h i j Bass, Len. Software Architecture in Practice, Third Edition. Boston: Addison-Wesley (2012). ISBN 978-0-321-81573-6 
  8. SEI: How do you define Software Architecture?, 2006. (Hozzáférés: 2012. szeptember 12.)
  9. Garlan & Shaw: An Introduction to Software Architecture, 1994. (Hozzáférés: 2012. szeptember 13.)
  10. Ugrás ehhez: a b Fowler (2003). „Design – Who needs an architect?”. IEEE Software 20 (5), 11–44. o. DOI:10.1109/MS.2003.1231144. 
  11. Ugrás ehhez: a b Jansen, A.. Software Architecture as a Set of Architectural Design Decisions, 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05), 109. o.. DOI: 10.1109/WICSA.2005.61 (2005). ISBN 978-0-7695-2548-8 
  12. Ali Babar, Muhammad. Software Architecture Knowledge Management. Dordrecht Heidelberg London New York: Springer (2009). ISBN 978-3-642-02373-6 
  13. Ugrás ehhez: a b c George Fairbanks. Just Enough Software Architecture. Marshall & Brainerd (2010) 
  14. Ugrás ehhez: a b ISO/IEC/IEEE: ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description, 2011. (Hozzáférés: 2012. szeptember 12.)
  15. Muller: A Reference Architecture Primer. Gaudi site, 2007. augusztus 20. [2011. december 19-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. november 13.)
  16. Angelov, S.. A classification of software reference architectures: Analyzing their success and effectiveness, 2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture. IEEE, 141–150. o.. DOI: 10.1109/WICSA.2009.5290800 (2009). ISBN 978-1-4244-4984-2. Hozzáférés ideje: 2023. december 15. 
  17. Brooks, Frederick P. Jr.. The Mythical Man-Month – Essays on Software Engineering. Addison-Wesley (1975. december 19.). ISBN 978-0-201-00650-6 
  18. Conway: Conway's Law. Mel Conway's Home Page. [2019. szeptember 29-i dátummal az eredetiből archiválva]. (Hozzáférés: 2019. szeptember 29.)
  19. Ugrás ehhez: a b Obbink: Software Architecture Review and Assessment (SARA) Report, 2002. február 6. (Hozzáférés: 2015. november 1.)
  20. Poort (2012. szeptember 1.). „RCDA: Architecting as a risk- and cost management discipline”. Journal of Systems and Software 85 (9), 1995–2013. o. DOI:10.1016/j.jss.2012.03.071. 
  21. Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968. NATO, Scientific Affairs Division, 1969. [2003. június 7-i dátummal az eredetiből archiválva]. (Hozzáférés: 2012. november 16.)
  22. P. Kruchten (2006). „The past, present and future of software architecture”. IEEE Software 23 (2), 22. o. DOI:10.1109/MS.2006.59. 
  23. University of Waterloo: A Very Brief History of Computer Science, 2006. (Hozzáférés: 2006. szeptember 23.)
  24. (2006) „Introduction to the Special Issue on Software Architecture”. DOI:10.1109/TSE.1995.10003. 
  25. Garlan & Shaw: An Introduction to Software Architecture, 1994. (Hozzáférés: 2006. szeptember 25.)
  26. Ugrás ehhez: a b Kruchten (2008). „What do software architects really do?”. Journal of Systems and Software 81 (12), 2413–2416. o. DOI:10.1016/j.jss.2008.08.025. 
  27. Ugrás ehhez: a b c Christine Hofmeister (2007). „A general model of software architecture design derived from five industrial approaches”. Journal of Systems and Software 80 (1), 106–126. o. DOI:10.1016/j.jss.2006.05.024. 
  28. Ugrás ehhez: a b ISO/IEC: ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models, 2011. (Hozzáférés: 2012. október 8.)
  29. Osterwalder and Pigneur. An Ontology for e-Business Models, Value Creation from E-Business Models, 65–97. o.. DOI: 10.1016/B978-075066140-9/50006-0 (2004). ISBN 9780750661409 
  30. Chen (2013). „Characterizing Architecturally Significant Requirements”. IEEE Software 30 (2), 38–45. o. DOI:10.1109/MS.2012.174. 
  31. Woods (2012). „Industrial architectural assessment using TARA”. Journal of Systems and Software 85 (9), 2034–2047. o. DOI:10.1016/j.jss.2012.04.055. 
  32. Maranzano (2005). „Architecture Reviews: Practice and Experience”. IEEE Software 22 (2), 34. o. DOI:10.1109/MS.2005.28. 
  33. Babar, M.A.. Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition. Springer (2009). ISBN 978-3-642-02373-6 
  34. Tang (2009). „Software Architecture Design Reasoning: A Case for Improved Methodology Support”. IEEE Software 26 (2), 43. o. DOI:10.1109/MS.2009.46. 
  35. Kruchten (1995). „Architectural Blueprints – The '4+1' View Model of Software Architecture”. IEEE Software 12 (6), 42–50. o. DOI:10.1109/52.469759. 
  36. Software architecture: perspectives on an emerging discipline. Prentice Hall (1996. december 19.). ISBN 978-0-13-182957-2 
  37. UCI Software Architecture Research – UCI Software Architecture Research: Architectural Styles. Isr.uci.edu. Retrieved on 2013-07-21.
  38. Boehm, Barry. Balancing Agility and Discipline. Addison-Wesley (2004). ISBN 978-0-321-18612-6 
  39. Ugrás ehhez: a b c Li (2022). „Understanding software architecture erosion: A systematic mapping study”. Journal of Software: Evolution and Process 34 (3), e2423. o. DOI:10.1002/smr.2423. 
  40. Li, Ruiyin. Understanding architecture erosion: The practitioners' perceptive, The 29th IEEE/ACM International Conference on Program Comprehension (ICPC), 311–322. o.. DOI: 10.1109/icpc52881.2021.00037 (2021) 
  41. Ugrás ehhez: a b Amnon H. Eden: Architecture Design Implementation, 2003. [2007. szeptember 28-i dátummal az eredetiből archiválva].
  42. C. Shekaran. The role of software architecture in requirements engineering, Proceedings of IEEE International Conference on Requirements Engineering, 239–245. o.. DOI: 10.1109/ICRE.1994.292379 (1994). ISBN 978-0-8186-5480-0 
  43. Remco C. de Boer, Hans van Vliet (2009). „On the similarity between requirements and architecture”. Journal of Systems and Software 82 (3), 544–550. o. DOI:10.1016/j.jss.2008.11.185. 
  44. Bashar Nuseibeh (2001). „Weaving together requirements and architectures”. Computer 34 (3), 115–119. o. [2012. szeptember 7-i dátummal az eredetiből archiválva]. DOI:10.1109/2.910904. 
  45. Company: How to Use Serverless Architecture | DashDevs (angol nyelven). How to Use Serverless Architecture | DashDevs. (Hozzáférés: 2023. augusztus 28.)

Fordítás

[szerkesztés]

Ez a szócikk részben vagy egészben a Software architecture című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További olvasnivalók

[szerkesztés]

További információk

[szerkesztés]
Commons:Category:Szoftverarchitektúra
A Wikimédia Commons tartalmaz Szoftverarchitektúra témájú médiaállományokat.