Szoftver architektúra

A szoftverarchitektúra a  szoftverrendszer felépítésével kapcsolatos legfontosabb döntések összessége. Az építészet a következőket tartalmazza:

• a szerkezeti elemek és felületeik megválasztása, amelyek segítségével a rendszer összeáll, valamint viselkedésük a szerkezeti elemek együttműködésének keretében;
• a struktúra és a viselkedés kiválasztott elemeinek összekapcsolása egyre nagyobb rendszerekbe;
• olyan építészeti stílus, amely az egész szervezetet irányítja – minden elemet, azok felületeit, együttműködését és kapcsolatát [1] [2] .

A szoftverarchitektúra (SW) dokumentálása leegyszerűsíti a fejlesztők közötti kommunikáció folyamatát, lehetővé teszi a meghozott tervezési döntések rögzítését, és azokról tájékoztatást a rendszer kezelő személyzete számára [ 3] , a komponensek és projektsablonok újrafelhasználását másokban.

A "szoftver architektúra" fogalmának nincs általánosan elfogadott meghatározása. Tehát a Szoftverfejlesztési Intézet oldala több mint 150 definíciót ad erre a fogalomra [4] [5] .

Áttekintés

A számítástechnika területe megalakulása óta a szoftverrendszerek összetettségével kapcsolatos kihívásokkal néz szembe. Korábban a komplexitási problémákat a fejlesztők a megfelelő adatszerkezetek kiválasztásával, algoritmusok fejlesztésével és a hatalmi ágak szétválasztásának alkalmazásával oldották meg. Bár a „szoftverarchitektúra” kifejezés viszonylag új a szoftverfejlesztési iparban, a terület alapelveit a szoftverfejlesztés úttörői az 1980-as évek közepe óta válogatás nélkül alkalmazzák. Az első próbálkozások egy rendszer szoftverarchitektúrájának megértésére és magyarázatára tele voltak pontatlanságokkal, és a szervezettség hiányától szenvedtek, gyakran csak vonalakkal összekapcsolt blokkok diagramja. Az 1990-es években kísérlet történt e tudományág főbb szempontjainak meghatározására és rendszerezésére. Ez idő alatt a tervezési minták , tervezési stílusok, bevált gyakorlatok, leírási nyelvek és formális logika kezdeti készletét fejlesztették ki [6] .

A szoftverarchitektúra alapgondolata a rendszer összetettségének csökkentése absztrakción és a hatalmi ágak szétválasztásán keresztül. A mai napig még mindig nincs megállapodás a „szoftverarchitektúra” fogalmának egyértelmű meghatározásáról.

Mint egy jelenleg fejlődő tudományág, amelyben nincsenek egyértelmű szabályok a rendszer felépítésének "helyes" módjára vonatkozóan, a szoftverarchitektúra tervezése még mindig a tudomány és a művészet keveréke. A "művészeti" szempont az, hogy minden kereskedelmi rendszer magában foglal egy alkalmazást vagy küldetést. A szoftverarchitektúra felhasználója szemszögéből a szoftverarchitektúra irányt ad az egyes felhasználók szakterületéhez kapcsolódó problémák elmozdulásához, megoldásához, például érdekelt fél, szoftverfejlesztő, szoftvertámogató csapat, szoftverkarbantartó, szoftvertelepítési szakember, tesztelő, és a végfelhasználók is. Ebben az értelemben a szoftverarchitektúra valójában a rendszer különböző perspektíváit egyesíti. Az a tény, hogy ez a több különböző nézőpont egy szoftverarchitektúrában kombinálható, érv a szoftverarchitektúra létrehozásának szükségessége és célszerűsége mellett, még a szoftverfejlesztési szakasz előtt [7] [8] [9] .

Történelem

A szoftverarchitektúra mint koncepció Edsger Dijkstra 1968-ban és David Parnassus kutatómunkájával kezdődött az 1970-es évek elején. Ezek a tudósok hangsúlyozták, hogy a szoftverrendszer felépítése fontos, és a megfelelő struktúra felépítése kritikus. E terület tanulmányozása az 1990-es évek eleje óta egyre népszerűbb az építészeti stílusok (mintázatok), építészeti leírási nyelvek, építészeti dokumentáció és formai módszerek kutatásával.

A kutatóintézetek fontos szerepet játszanak a szoftverarchitektúra, mint tudományág fejlesztésében. Mary Shaw és David Garlan, a Carnegie Mellon Egyetemről írt egy könyvet "Szoftverarchitektúra: Egy új diszciplína perspektívái 1996-ban" címmel, amelyben olyan szoftverarchitektúra-koncepciókat mutatnak be, mint az összetevők, csatlakozók, stílusok stb. A Kaliforniai Egyetem Irvine Szoftverkutató Intézete elsősorban építészeti stílusokat, építészetleíró nyelveket és dinamikus architektúrákat kutat.

Az első szoftverarchitektúra-szabvány az IEEE 1471: ANSI/IEEE 1471-2000: Útmutató a túlnyomórészt szoftverrendszerek leírásához. 2007-ben fogadták el ISO ISO/IEC 42010:2007 néven.

Az építészet leírásának nyelvei

Az architektúraleíró nyelvek (ADLS) a szoftver architektúrájának leírására szolgálnak. Számos különböző ADLS-t fejlesztettek ki különböző szervezetek, beleértve az AADL-t (SAE szabvány), a Wrightot (a Carnegie Mellon Egyetemen fejlesztették ki), az Acme-t (a Carnegie Mellon Egyetemen fejlesztették), az xADL-t (a UCI-n fejlesztették), a Darwint (a londoni Imperial College-ban fejlesztették ki) , DAOP-ADL (a Malagai Egyetemen fejlesztették ki) és ByADL (University of L'Aquila, Olaszország). Ezeknek a nyelveknek a közös elemei a komponens, a csatlakozó és a konfiguráció fogalma. Ezenkívül a speciális nyelvek mellett az UML egységes modellezési nyelvet is gyakran használják az architektúra leírására .

Megtekintések

A szoftverarchitektúra általában több nézetet tartalmaz, amelyek hasonlóak az épületek építésénél használt különböző típusú rajzokhoz. Az ANSI/IEEE 1471-2000 által meghatározott ontológiában a nézetek nézőpont-példányok, ahol létezik egy nézőpont az architektúra leírására az érintettek adott csoportja szempontjából.

Az építészeti nézet 2 összetevőből áll:

• Elemek
• Az elemek közötti kapcsolatok

Az építészeti nézetek 3 fő típusra oszthatók [10] :

1. Moduláris nézetek (eng. modul view ) - a rendszert különböző szoftverblokkok struktúrájaként mutatják be.
2. Komponensek és csatlakozók (angol. komponens-és csatlakozó nézetek ) – a rendszert párhuzamosan futó elemek (összetevők) szerkezeteként és azok egymásra hatását (csatlakozók) mutatják be.
3. Allocation (eng. allocation views ) - a rendszerelemek külső környezetben való elhelyezését mutatja.

Példák a moduláris nézetekre:

• Dekompozíció (angol. dekompozíciós nézet ) - modulokból áll az "egy almodul" összefüggésben
• Használat (angol. uses view ) – a „use” kapcsolat keretében modulokból áll (azaz az egyik modul egy másik modul szolgáltatásait használja)
• Szintnézet (angol réteges nézet ) - olyan struktúrát mutat, amelyben a funkcionalitás szerint összefüggő modulok csoportokba (szintekbe) vannak kombinálva
• Osztály/általánosító nézet (angol. c lass / generalization view ) – az „inherited from” és „is an instance” kapcsolaton keresztül kapcsolódó osztályokból áll

Példák alkatrész- és csatlakozótípusokra:

• Folyamatnézet (eng. process view ) - kommunikációs, szinkronizálási és/vagy kizárási műveletekkel összekapcsolt folyamatokból áll
• Párhuzamos nézet (ang. concurrency view ) - komponensekből és csatlakozókból áll, ahol a csatlakozók "logikai folyamok"
• Adatcsere típusa (eng. shared-data (repository) view ) - olyan összetevőkből és csatlakozókból áll, amelyek állandó adatokat hoznak létre, mentenek és fogadnak
• Kliens-szerver nézet (angol. kliens-szerver nézet ) - interakcióban lévő ügyfelekből és szerverekből, valamint a köztük lévő összekötőkből áll (például protokollok és általános üzenetek)

Példák szállástípusokra:

• Telepítés (angol. deployment view ) - szoftverelemekből, azok fizikai adathordozón való elhelyezéséből és kommunikációs elemekből áll
• Implementáció (angol implementáció nézet ) - programelemekből és azok fájlstruktúráinak való megfeleléséből áll különböző környezetekben (fejlesztés, integráció stb.)
• Munkafeladat (angol. munkafeladat nézet ) - modulokból és annak leírásából áll, hogy ki a felelős ezek végrehajtásáért

Bár több nyelvet fejlesztettek ki a szoftverarchitektúra leírására, jelenleg nincs megállapodás arról, hogy melyik nézetkészletet érdemes referenciaként elfogadni. Az UML nyelvet szabványként hozták létre "szoftverrendszerek (és nem csak) modellezéséhez".

Építészeti minták

Különféle építészeti mintákat alkalmaznak, hogy a tervezett rendszert különböző minőségi jellemzőkkel kielégítsék. Minden sablonnak megvannak a maga céljai és hátrányai.

Példák az építészeti mintákra:

• Réteges minta. A rendszer szintekre van felosztva, amelyek a diagramon egymás felett láthatók. Minden szint csak az alatta lévő 1-es szintet tudja megidézni. Így az egyes szintek fejlesztése viszonylag önállóan végezhető, ami növeli a rendszer módosíthatóságát. Ennek a megközelítésnek a hátránya a rendszer bonyolultsága és a teljesítmény csökkenése.
• Bróker minta. Ha nagyszámú modul van a rendszerben, akkor egymással való közvetlen interakciójuk túl bonyolulttá válik. A probléma megoldására egy közvetítőt (például adatbusz) vezetnek be, amelyen keresztül a modulok kommunikálnak egymással. Így a rendszermodulok átjárhatósága megnövekszik. Minden hátrány a közvetítő jelenlétéből fakad: csökkenti a teljesítményt, elérhetetlensége elérhetetlenné teheti az egész rendszert, támadás tárgyává, rendszer szűk keresztmetszetévé válhat.
• Minta "Modell-View-Controller" (Model-View-Controller minta). Mert Mivel a felülettel szemben támasztott követelmények a leggyakrabban változnak, ezért gyakran kell módosítani az adatokkal való megfelelő interakció (olvasás, mentés) megőrzése mellett. Ehhez a Model-View-Controller (MVC) mintában az interfész el van választva az adatoktól. Ez lehetővé teszi az interfészek megváltoztatását, valamint különböző verziók létrehozását. Az MVC-ben a rendszer a következőkre oszlik:
  • Az adatokat tároló modell
  • Egy adatot megjelenítő nézet, amely interakcióba lép a felhasználóval
  • A nézetek és a modell között közvetítő vezérlő

Az MVC koncepciónak azonban vannak hátrányai is. Különösen az interakció bonyolultsága miatt csökken a rendszer sebessége.

• Kliens-szerver minta (Client-Server minta). Ha korlátozott számú erőforrás van, amelyhez nagyszámú fogyasztó korlátozott hozzáférése szükséges, akkor célszerű a kliens-szerver architektúrát megvalósítani. Ez a megközelítés növeli a rendszer méretezhetőségét és elérhetőségét. Ugyanakkor a szerver a rendszer szűk keresztmetszetévé válhat, ha nem elérhető, akkor az egész rendszer elérhetetlenné válik.

Alapvető keretrendszerek a szoftverarchitektúrához

A következő keretrendszerek ( angol  szoftverarchitektúra keretrendszerek ) kapcsolódnak a szoftverarchitektúra területéhez:

• 4+1
• RM-ODP (a nyílt elosztott feldolgozás referenciamodellje)
• Szolgáltatásorientált modellezési keretrendszer (SOMF)

Az olyan architektúra példák, mint a Zachman-keretrendszer, a DoDAF és a TOGAF, a vállalati architektúrák tartományába tartoznak.

Lásd még

• Rendszer Felépítés

Jegyzetek

1. ↑ Kruchten, Philippe . The Rational Unified Process – An Introduction, Addison-Wesley, 1998
2. ↑ Rumbaugh, J. , Jacobsen, I. és Booch, G. The Unified Modeling Language Reference Manual. Reading, Mass.: Addison-Wesley, 1999
3. ↑ Szoftverarchitektúrák dokumentálása: Views and Beyond, 2010 , P.1.1. Áttekintés.
4. ↑ Szoftverarchitektúrák dokumentálása: Views and Beyond, 2010 , P.1.2. Építészet és minőségi jellemzők.
5. ↑ Szoftverarchitektúra: Szószedet archiválva : 2013. január 5., a Wayback Machine , Software Engineering Institute
6. ↑ Mi a szoftverarchitektúra  meghatározása ? resources.sei.cmu.edu. Letöltve: 2019. október 23. Az eredetiből archiválva : 2020. február 28.
7. ↑ ISO/IEC/IEEE 42010: Az "architektúra" meghatározása . www.iso-architecture.org. Letöltve: 2019. október 23. Az eredetiből archiválva : 2017. április 7.. (határozatlan)
8. ↑ M. Fowler. Tervezés – Kinek van szüksége építészre?  // IEEE szoftver. — 2003-9. - T. 20 , sz. 5 . — S. 11–13 . - doi : 10.1109/MS.2003.1231144 . Archiválva az eredetiből: 2019. október 23.
9. ↑ Bevezetés a szoftverarchitektúrába . Letöltve: 2019. október 23. Az eredetiből archiválva : 2021. május 6.. (határozatlan)
10. ↑ Len Bass, Paul Clements, Rick Kazman. Szoftverarchitektúra a gyakorlatban (3. kiadás) (SEI Series in Software Engineering). - 3. kiadás (2012. október 5.). - 2012. - 640 p. — ISBN 978-0321815736 .

Irodalom

• Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paul Merson; Robert North; Judith Stafford. Szoftverarchitektúrák dokumentálása: Views and Beyond. - Második kiadás. - Addison-Wesley Professional, 2010. - ISBN 978-0-13-248861-7 .
• Len Bass, Paul Clements, Rick Kazman:  Szoftverarchitektúra a gyakorlatban, harmadik kiadás . Addison Wesley, 2012,  ISBN 978-0321815736  (Ez a könyv, immár harmadik kiadásban, ékesszólóan fedi le a tudományág alapvető fogalmait. A téma a rendszer minőségi jellemzőinek elérése köré összpontosul.)

Linkek

• A szoftverarchitektúrák visszatekintése
• Szoftverarchitektúra: Szószedet , Software Engineering Institute  
• Építészet: Publikációk , Szoftvermérnöki Intézet