A szoftverfejlesztés és a szoftverarchitektúra-tervezés területén az architekturális döntések olyan tervezési döntések, amelyek az architektúra szempontjából jelentős követelményeket kezelnek; ezeket általában nehéz meghozni és/vagy költséges megváltoztatni.
Jellemzők Az architekturális döntések befolyásolják és meghatározzák egy rendszer nem funkcionális jellemzőit. Minden architekturális döntés egy konkrét, az architektúra szempontjából jelentős tervezési kérdést (tervezési problémát, meghozandó döntést) ír le, amelyre több lehetséges megoldás (opciók vagy alternatívák) létezik. Egy architekturális döntés rögzíti egy tudatos, gyakran együttműködésen alapuló alternatívaválasztási folyamat, és megindokolja a döntés kimenetelét. pl.: hivatkozik egy vagy több architekturális döntés által érintett minőségi attribútumokra, választ ad a tervezéssel és az alternatívák kiválasztásával kapcsolatos „miért” kérdésekre. Az architekturális döntések egy teljes szoftverrendszerre vagy annak egy vagy több alapvető komponensére vonatkoznak. Az architekturális döntések formái az architekturális taktikák és minták, az integrációs technológiák és a köztes szoftverek kiválasztása, valamint a kapcsolódó megvalósítási stratégiák és eszközök (beleértve a kereskedelmi termékeket és a nyílt forráskódú projekteket).
A szoftverarchitektúra-tervezés egy nehéz probléma („wicked problem”), ezért az architekturális döntések nehéz helyesen meghozni. Gyakran nem létezik egyetlen optimális megoldás egy adott architekturális tervezési problémára. Az architekturális döntéshozatal a szoftverarchitekt egyik alapvető felelősségi köre, ezen felül az architekturális döntések kiemelt jelentőségére és a szoftverarchitektúra önálló fogalmaként való kezelésének indokaira további források megtalálhatóak online.
Történet Az indoklás (rationale) már megjelent a szoftverarchitektúra egyik korai definíciójában, amelyet Perry/ Woolf fogalmazott meg, de kevésbé volt kutatva 2004-ig, amikor egy architekturális döntésekkel és az architekturális tudásmenedzsmenttel (Architectural Knowledge Management) foglalkozó workshopot tartottak Groningenben, hollandia. A témában megjelent első publikációk ehhez a rendezvényhez visszavezethető. 2006-tól kezdődően az architekturális tudásmenedzsmenttel és az architekturális döntésekkel foglalkozó kutatói közösségek jelentős fejlődésnek indultak, és számos tanulmány jelent meg olyan vezető szoftverarchitektúra-konferenciákon, mint az European Conference on Software Architecture (ECSA), a Quality of Software Architecture (QoSA) és az International Conference on Software Architecture (ICSA). Springer-kötet foglalta össze a tudományterület akkori állását 2009-ben, és egy szisztematikus feltérképező tanulmány 2013-ban összegyűjtötte és elemezte több és több későbbi kutatási eredményeket is.
A gyakorlati életben a helyes döntések meghozatalának fontosságát mindig is elismerték. Például az olyan szoftverfejlesztési folyamatok, mint az OpenUP, számos sablon és módszer létezik a döntések dokumentálására. Hét különböző sablont össze is lett hasonlítva. Az legújabb szabványa az architektúraleírásoknak, az ISO/IEC/IEEE 42010:2011, van egy külön indoklás elemet definiál, és részletes ajánlásokat fogalmaz meg arra vonatkozóan, hogy mely architekturális döntéseket érdemes rögzíteni és milyen tulajdonságokat egy architekturális döntésnek célszerű dokumentálni a döntési naplóban.
Döntéskezelési lépések Döntések azonosítása
Mielőtt egy döntést meg lehetne hozni, meg kell fogalmazni annak szükségességét: mennyire sürgős és mennyire fontos az adott architekturális döntés? Azonnal meg kell-e hozni, vagy várhat addig, amíg többet tudunk meg a követelményekről és a fejlesztés alatt álló rendszerről? A döntések azonosítását segíthetik a személyes és a közös tapasztalatok, valamint az elismert tervezési módszerek és gyakorlatok; felmerült az a javaslat is, hogy az agilis szoftverfejlesztő csapatok a projekt termék-backlogja mellett egy külön döntési backlogot (decision backlog) is tartsanak fenn.
Döntéshozatal
Az azonosított döntések csak akkor hozhatók meg, ha bizonyos feltételek teljesülnek, amely alkotják az architekturális döntések meghozatalának meghatározását:
Az érintett szereplőket (stakeholdereket) azonosították. Megfelelő az időpont. Az alternatívák (opciók) listázva vannak. A követelményeket és egyéb értékelési szempontokat meghatározták. Kiválasztották az ADR-sablont (Architecture Decision Record).
Számos döntéshozatali technika létezik, beleértve az általános célú és a szoftver- és szoftverarchitektúra-specifikus módszereket is, például a dialogue mapping (párbeszédalapú térképezés). A csoportos döntéshozatal napjainkban is aktív kutatási terület.
Döntések dokumentálása
Számos sablon és eszköz áll rendelkezésre a döntések rögzítésére, mind az agilis közösségekben (pl.: Michael Nygard Architecture Decision Record), mind pedig a szoftvermérnöki és architektúratervezési módszertanokban (pl.: IBM UMF vagy Tyree és Akerman által javasolt táblázatos formátumok). G. Fairbanks az architekturális döntések indoklását (Architecture Haiku) módszerében foglalta össze egyetlen oldalon; ezt a jelölésrendszert később továbbfejlesztették az Y-állításokká (Y-statements). Számos publikáció ismerteti ezek motivációját, példáit és összehasonlítását.
Döntések végrehajtása (érvényesítése)
Az architekturális döntések a szoftvertervezés során kerülnek felhasználásra, ezért azokat közölni kell a rendszer finanszírozásában, fejlesztésében és üzemeltetésében érintett szereplőkkel, és el is kell fogadtatni velük. Architektúrát egyértelműen tükröző programozási stílusok alkalmazása, az architekturális szempontokra és döntésekre fókuszáló kódellenőrzések kapcsolódnak hozzá.
Az architekturális döntéseket figyelembe kell venni a szoftverrendszerek korszerűsítése és szoftver továbbfejlesztése során is.
Döntések megosztása (opcionális lépés)
Az architekturális döntések gyakran ismétlődnek különböző projektekben, ezért a korábbi döntésekből származó tapasztalatok egy strukturált tudásmenedzsment-megközelítés keretében újra felhasználhatók.
Fontos meghatározni azt is, hogy mikor tekinthető egy architekturális döntés lezártnak. Erre egy ötelemű „definition of done” (befejezettségi definíció) modellt javasoltak, bizonyíték, kritérium, egyetértés, dokumentáció, megvalósítás/felülvizsgálat.
Példák Nagy léptékű projektek esetén a meghozandó architekturális döntések száma meghaladhatja a 100-at is. Ilyen döntések például:
Az architekturális rétegzési séma kiválasztása és az egyes rétegek felelősség meghatározása (a Layers architektúraminta alkalmazásakor). Az egyes rétegekhez, komponensekhez és kapcsolatokhoz tartozó megvalósítási technológiák kiválasztása (pl.: programozási nyelvek, interfészszerződés-formátumok, integrációs felületek és üzenetváltások tervezésekor az XML vagy JSON használata). A megjelenítési réteg keretrendszereinek kiválasztása kliensoldalon (pl.: JavaScript-frameworks), illetve szerveroldalon (pl.: Java- vagy PHP-alapú frameworks).
Továbbiak találhatók az Attribute-Driven Design 3.0H. Cervantes, R. Kazman, Designing Software Architectures: A Practical Approach, Addison-Wesley, 2016. tervezési koncepciókatalógusaiban, és az egyes szakterületekre vonatkozó döntéstámogató modellekbenPage 21 in Zimmermann, O., Guidance Models and Decision-Making Tooling for SOA, Cloud, and Outsourcing Solution Design több példák.
Az alábbi egy olyan architekturális döntés példája, amelyet a Y-állítás (Y-statement) sablon szerint fogalmaztak meg:
„A webáruház-szolgáltatás környezetében, szembesülve azzal az igénnyel, hogy a felhasználói munkamenet-adatok több webáruház-példány között is konzisztensek és naprakészek maradjanak, a Database Session State Pattern alkalmazása mellett döntöttünk (és elvetettük a Client Session State és a Server Session State megoldásokat). Ezzel biztosítani kívántuk a felhőalapú rendszer rugalmasságát és skálázhatóságát, elfogadva azt, hogy egy munkamenet-adatbázist meg kell tervezni, implementálni és replikálni kell.”
Sablonok Számos sablont javasoltak mind gyakorló szoftverarchitektek, mind pedig szoftverarchitektúra-kutatók. GitHub-tárhelyek, mint az Architecture Decision Record (ADR) és a Markdown Architectural Decision Records, sokat gyűjtenek össze, valamint hivatkozásokat tartalmaznak különböző eszközökre és dokumentációs útmutatókra is.
Csoportos döntéshozatal a szoftverarchitektúrában Mind a gyakorlati szakemberek, mind a kutatók egyetértenek abban, hogy a szoftverarchitektúrával kapcsolatos döntéshozatal egy csoportos folyamat, amelyben több érdekelt fél vesz részt a megvitatásában, értékelésében és szűkítésében az architekturális döntésekben. A szakmai gyakorlatot vizsgáló kutatások azt mutatták, hogy bár a döntéshozó csoportok mérete általában megfelelő, a döntéshozatal strukturált megközelítése gyakran hiányzik. Különösen:
A döntéshozatal többnyire strukturálatlan módon történik. Ez korlátozza a csoporttagok részvételét. Hiányoznak a megfelelő együttműködési eszközök, amelyek támogatnák az architekteket a döntéshozatali folyamat során. A szoftverarchitektek gyakran késedelmeket és mulasztásokat tapasztalnak a döntéshozatalban a strukturált folyamatok hiánya miatt. Az architektúrával foglalkozó csapatok problémákkal szembesülnek, mint a csoportgondolkodás és a csoportpolarizáció .
Jegyzetek
Fordítás
Kapcsolódó szócikkek Architekturális minta Szoftverarchitektúra
Kategória:Számítógép-programozás