Szoftver architektúra, Architektúrális tervezés

Átírás

1 Szoftver architektúra, Architektúrális tervezés Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 11. Roger S. Pressman: Software Engineering, 5th e. chapter 14. Bass, Clements, Kazman: Software Architecture in Practice, Addison- Wesley,

2 Mi a szoftver architektúra? A rendszert felépít! alrendszerek (szoftver komponensek) kerete alrendszerek meghatározása alrendszerek tulajdonságai vezérlési, valamint kommunikációs kapcsolataik 3 Mi még a szoftver architektúra? Magasszint" terv A rendszer átfogó struktúrája több nézet -> több struktúra Komponensek és összeköt!k összesége 4

3 A szoftver architektúra szerepe Az érdekelt szerepl!k kommunikációjának lehet!vé tétele A korai fejlesztási fázisok döntéseinek támogatása a követelmények tükrében Nagylépték" újrafelhasználhatóság el!segítése 5 A szoftver architektúrák forrása Üzleti és technológiai döntések eredménye Meghatározó a környezet szerepe A fejleszt!k céljai és stratégiája által befolyásolt követelmények vezetnek különféle szoftver architektúrákhoz 6

4 Az architektúra kialakítása Min!ségi elvárások Funkcionalitás Rendszer tervezés Architektúra Megjelenítés Alkalmazás 7 Az architektúra ciklus Az architektúra meghatározó a fejleszt! szervezet szerkezetére Az architektúra befolyásolja a fejleszt! szervezet céljait Az architektúra hatással van a követelményekre A fejlesztés során a fejleszt!k tapasztalatokat szereznek architektúráról Bizonyos rendszerek hatással vannak a fejlesztési kultúrára 8

5 Az architektúra ciklus (folyt.) Fejleszt! szervezet Követelmények Szerepl!k Architektúra Technológiai környezet A tervez! tapasztalata Tervez! Rendszer 9 Mit!l jó egy architektúra? Kis számú vezet! tervez! Jól definiált funkcionális követelmények és min!ségi jellemz!k Jól dokumentált az architektúra Az architektúra értékelésében az összes érintett szerepl! részt vesz Kvantitatív min!ségi mértékek Inkrementális architektúra implementáció Kevés er!forrás versenyhelyzet a fejlesztés során 10

6 Architect 11 Struktúrális ökölszabályok Jól definiált modulok információ elrejtés, szeparáció Jól definiált interfészek Kereskedelmi termékekt!l független architektúra Jól ismert architektúrális taktikák alkalmazása Egyszer" interakciós minták 12

7 Architektúra elemek Architektúrális minta típus elemek és kapcsolatok, kényszerek pl. kliens-szerver minta Referencia modell standard funkcionális felosztás és adatfolyam megoldások pl. adatbázis kezel! rendszer Referencia architektúra referencia modell leképezése szoftver elemekre pl. ISO OSI architektúra 13 Architektúra elemek (folyt.) Refrencia modell Referencia architektúra Szoftver architektúra Architektúrális minta 14

8 Architektúrális szerkezetek / nézetek Modul szerkezetek funkcionális felbontás Komponens-és-összeköt! szerkezetek futási idej" komponensek és csatlakoztatások Allokációs szerkezetek szoftver és küls! elemek összerendelése 15 Architektúrális szerkezetek / nézetek (folyt.) Hogyan bontható a rendszer kódegységekre, modulokra? Hogyan struktúrálható a m"köd! rendszer futási id!ben komponensekre, és lépnek egymással interakcióba ezek a komponensek? Milyen kapcsolatban van a rendszer a környezet nem szoftver elemeivel (pl. processzorok, fájlrendszerek, fejleszt! teamek)? 16

9 Szoftver struktúrák Modul szerkezetek Dekompozició Használat Réteg szerkezet Osztályok, generalizálás Komponens és összeköt! szerkezetek Kliens-szerver Folyamat Konkurrencia Osztott adatok Allokációs szerkezetek Telepítési szerkezet Munkakiosztás (fejlesztési) Implementációs szerkezet (konfiguráció mgt.) 17 Architektúrális tervezés A rendszer-tervezés korai fázisa Specifikációs és tervezési fázis összekötése Specifikálással párhuzamosítható F! rendszer-komponensek meghatározása 18

10 Architektúra és a rendszer jellemz!i A rendszer architektúrája hatással van a rendszer min!ségi jellemz!ire Nem funkcionális követelmények szerepe Teljesítmény Biztonság Megbízhatóság Rendelkezésreállás Karbantarthatóság 19 Architektúra, költségek, érték Megbízhatóság Teljesítmény Módosíthatóség Rendelkezésreállás Üzleti célok Architektúra választás Érték Költségek 20

11 Min!ségi jellemz!k 21 Min!ségi jellemz!k Min!ségi jellemz!k meghatározása Stimulus forrás Stimulus Környezet Tárgy Válasz Metrika Stimulus forrás Stimulus Tárgy Környezet Válasz Mérték 22

12 Stratégiák és taktikák Taktikák a min!ségi célok elérésére A taktikák összessége a stratégia A taktikák mint tervezési lehet!ségek A tervezési minták tartalmaznak taktikákat 23 Taktikák (pl.) Magas rendelkezésreállási taktikák Hibadetektálás Ping/echo Heartbeat Kivételkezelés Javítás Szavazás Aktív redundancia Passzív redundancia Visszaállítás Árnyék m"ködés Állapot újraszinkronizálás Megel!zés Kikapcsolás, újraindítás Tranzakció kezelés 24

13 Architektúrális konfliktusok Nagyméret" komponensek jó teljesítmény"ek, de nehezen karbantarthatók A redundancia fokozza rendelkezésreállást, de adatbiztonsági problémákat okoz A biztonsági megoldások általában megnövelt adatmozgatással járnak 25 Architektúrális tervezési kérdések Vannak-e generikus alkalmazás architektúrák? Hogyan kell a rendszert elosztani? Hogyan kell a rendszert modulokra bontani? Milyen legyen az alkalmazás vezérlési szerkezete? Hogyan lehet az architektúrákat értékelni, összehasonlítani? Hogyan kell dokumentálni egy architektúrát? 26

14 Néhány elterjedt architektúrális modell Osztott adatokra épített architektúra pl. CASE eszközök Kliens-szerver architektúra pl. hálózati, kommunikációs szoftverek Réteg szerkezet architektúra pl. hálózati referencia modellek Funkcionális cs!rendszerek Eseményvezérelt rendszerek 27 Osztott adatok Az alrendszerek adatokat cserélnek központi adatbázis saját adatbázisok, explicit adatcsere Közös adatigény" alkalmazások 28

15 Osztott adatok (folyt.) El!nyök nagy mennyiség" adat hatékony megosztása központi adat kezelés lehet!sége Hátrányok minden részrendszerben azonos adatszervezés elosztottság nehézkes 29 Osztott adatok (pl.) Integrált CASE eszköz Tervez! editor Kódeditor Jelentés generátor Projekt adattár RAD generátor Kódgenrátor 30

16 Kliens-szerver modell Elosztott rendszerek adatok feldolgozás Önnálló szolgáltatásokat nyújtó szerverek A szolgáltatásokat igénybevev! több, különböz! kliens Kommunikációs mechanizmus hálózat üzenetkezel! 31 Kliens-szerver modell (folyt.) El!nyök Eloszott rendszer Hálózat kihasználása Olcsóbb hardvermegoldások pl. NC Skálázhatóság Hátrányok Adat reprezentációs problémák Redundáns management Szolgáltatások leírása, megtalálása 32

17 Üzleti alkalmazások klien-szerver megoldásai Megjelenítés Alkalmazás funkció Adat Management Távoli adatkezelés Megjelenítés Alkalmazás funkció Alkalmazás funkció Adat Management Elosztott funkcionalitás Megjelenítés H á l ó z a t Alkalmazás funkció Adat Management Távoli megjelenítés Kliens Megjelenítés Megjelenítés vezérlés Alkalmazás funkció Adat Management Szerver Elosztott megjelenítés Megjelenítés Megjelenítés vezérlés Alkalmazás funkció Adat Management Terminál Emuláció 33 Réteg szerkezet modell Speciális alrendszer elrendezés Rétegekbe szervezett modulok, szolgáltatások Jól definiált interfészek Inkrementálisan, egymástól elkülönülten fejleszthet! rétegek Mesterségesen kialakított rétegek 34

18 Ez függ ezekt!l Sbecoming difficult over time. vides Whileto ments: Module (1) a precise C and hierarchical Module decomposition and (2) explicit control over allowed that Module might exist A between and Module different C. types of D with indicate the many types of relationships they often start well, software projects begin to bog down as enhancements dependency are and disallowed strengths dependencies of 1 and between 2 respectively. devel- subsystems. DSM is ideal for this but but quickly hierarchy becomes is unwieldy key to as scaling the size with DSM. the modules. This might is useful seem for detailed like a design simple example made to meet new demands and as opment teams change. It takes longer Traditionally, to approach because DSM it has provides often a used compact an of the application increases. fix problems because fixes made in one representation that can easily scale up to Hierarchy X to indicate a dependency. Also note that UML diagrams enables provide DSM limited to value conveniently area end up introducing bugs in other tens of thousands of classes or files, in model controlling systems the actual with implementation. thousands of classes. areas. In no time, a project becomes a large so part whereas of DSM conventional literature box-and-arrow reverses diagrams ofbecome how rows unusable and for columns systems com- are the application, developers feel burdened our Indeed, Hierarchy far from is controlling also important the design to ofthe succinct complex that no single engineer convention understands the whole system. As a result, used. orig-theinal design assumptions are lost and the their specify UML models allowed to keep and them disallowed synchro- dependenposed use ofrows even a to few indicate hundred dependencies classes. definition of design rules that are used to when they have to do a round trip back to boundary between various parts and of the columns Understanding to indicate provides. DSM However, nized cies. with Design code. rules Manycan development be used to specify system begins to blur. Systems that we started have found Brief History that our convention is a little more DSM intuitive has traditionally for software been used engineers to model models beyond the initial stages of the teams architectural simply stop maintaining patterns their such UML out as modular become monolithic. as layering, A powerful new approach, based on tasks involved in the development of discrete products. The structure of depend- and Using other matrices dependency in systems engineering patterns between componentization, external library usage, and is also consistent with N-squared diagrams. for encies between tasks helps in understand- has subsystems. a long history. When Systems DSM engineers is have combined with project. using the Dependency Structure Matrix (DSM), has recently been proposed specifying software architectures. This Figure ing 1B which shows tasks can the be DSM done in after parallel partitioning. Partitioning is a special operation input and output flows within their sys- and used design N-squared rules, diagrams they are to model called the approach has been built upon ideas that which have to be performed sequentially. dependency have actually been around for a very long Cyclic dependencies are indicators of possible rework and that regroups may be necessary. modules. Steven The models. tem. Subsequent work by Baldwin and time. The basic notion of divide and that conquer reorders Clark at Harvard Business School [2] has been around since time immemorial. modules Eppinger are ordered at Massachusetts in such a Institute way that of employing Engineers take a large system and decompose it into subsystems; when a subsystem ed the application of DSM within some of Before DSM can be applied to software, we Defining DSM a to Dependence model the evolution Relationship of Technology s Sloan School [1] spearhead- those modules that provide to other modules split are placed at the bottom of the DSM, closer to the engineering of software. the computer industry brought it one step itself becomes too large, it is in turn the largest companies in the world, including Boeing, that General dependmotors, on other Intel, mod- and need The key to ideas define underlying the meaning our approach of the statement up in a process called hierarchical decomposition. The decomposition is done in a like module most ideas is dependent in dependency upon tools, another mod- while modules [3], ules such are a placed many others. at the However, top. Ifapplying there were DSM to no are way that closely coupled subsystems are ule. not new. DSM The is notion a general of inter-module software is new. device that leaves the closer to each other, while loosely dependency coupled cycles, this would yield a lower dependency was articulated by Parnas in Software engineers have always under- matrix, the importance i.e., one ofwithout dependencies any his early papers (most notably [4]), and the choice of the definition of dependency to subsystems are kept farther apart. triangularstood its user. In this case, we are interested in the The alrendszerek problem in software systems dependencies is between above modules. the However, diagonal. függ!ségei they have extraction and exploitation of dependencies architecture has been the of subject the software many more from a developer s that it is very easy for developers to create tended to visualize the modules and their undesirable couplings between subsystems. Partitioning dependencies also as groups directed together graphs, i.e., those boxand-arrow that have diagrams. dependency The cycles. Unified In of the DSM for software was noted by recent projects. The potential significance perspective. This perspective is important if Often this is done without an understanding of the overall system. As a result, this sub- case, Modeling Modules Language A and (UML) C makes depend exten- Sullivan et al. [5] in the context of evaluat- systems we are to keep the design modular and to on systems become tightly coupled over time. sive use of directed graphs, where a variing design tradeoffs. Similarly, Lopes and each other and therefore have been Bajracharya Figure 3 [6] A-D: have also Architecture applied DSM Patterns to in a DSM Figure 1 A-B: A Simple DSM Before grouped and After Partitioning together. This form of the matrix study the value of aspect-oriented modularization. MacCormack et al. [7] have is called block triangular because it has been applied the DSM to analyze the value of split up into three blocks in which there modularity in the architectures of Mozilla are no dependencies above the diagonal. and Linux. Layered systems are naturally expressed as Our approach, however, is the first application of DSM for the explicit management of inter-module dependencies. lower triangular matrices. The grouping of modules can also be More information about DSM and available tools, including those from Lattix, shown in different ways. A new com- Figure 1A Figure 1B can be found at < Réteg szerkezet Hierarchikus dekompozíció szemléltetés: Dependency Structure Matrix pound module can be formed by merging Modules A and C as shown in Figure 2A, after which the matrix becomes lower triangular. Notice also that Module D now depends upon the new Module A-C with dependency strength of 5, which is an aggregation of Module D s dependency on both Module A and Module C. 8 CROSSTALK The Journal of Defense Software Engineering November 2005 A D B C Furthermore, the identities of the basic modules can still be retained by introducing a hierarchy, as in Figure 2B, in which the grouping of A and C is shown by their indentation. The hierarchical of Module A needs to know about the behavior of Module B. The good thing about this definition for software engineering is that, except in a few cases, this can generally be deduced by automatic analysis directly from source code of languages such as Ada, C/C++, and Java. The automatic analysis can be accomplished by utilizing commercially available programs to extract the dependencies. For newer languages such as Java and C#, the dependencies can even be extracted from byte code. For example, in Java we define a Class A as being dependent on Class B if the following occurs: 1. Class A inherits from Class B (implements in the case of an interface). 2. Class A calls a method or a constructor in Class B. 3. Class A refers to a data member in Class B. 4. Class A refers to Class B (e.g., as in an argument in a method). The dependency strength can be calculated in a variety of ways. One is to look at 3A: Layered Pattern 3B: Strictly Layered Pattern 3C: Imperfectly Layered Pattern 3D: Component Pattern November Réteg szerkezet (pl.) :39 Windows NT Workstation service User mode Server service Integral subsystems Win32 Application POSIX Application Environment subsystems OS/2 Application Security Win32 POSIX OS/2 Executive Services I/O Manager Security Reference Monitor IPC Manager Virtual Memory Process Manager Manager (VMM) PnP Manager Power Manager Window Manager GDI Object Manager Executive Kernel mode drivers Microkernel Hardware Abstraction Layer (HAL) Kernel mode Hardware 36 Page 1 of 1

19 Funkcionális cs!rendszerek Adatfolyam orientált megközelítés Cs!, sz"r! modell Szekvenciális, kötegelt feldolgozás Nem interaktív alkalmazások 37 Cs!rendszer modell jellemz!i Transzformációk újrafelhasználása Intuitiven kialakítható szerkezet Könnyen b!víthet! új transzformációkkal Konkurrens rendszerek is kialakíthatók szinkronizáló cs!rendszerek Kötött adatformátum a csövekben 38

20 UNIX pipe Cs!rendszer (pl.) ps -ax more cat /etc/passwd sort>fil.txt 39 Cs!rendszer (pl.) Labview virtuális m"szerek 40

21 Eseményvezérelt rendszerek A rendszer vezérlésén kívülr!l érkez! események határozzák meg a viselkedést Eseményvezérelt modellek broadcast modell interrupt modell 41 Broadcast modell Elosztott alrendszerek integrálása Az alrendszerek el!fizetnek az!ket érdekl! eseményekre az eseménykezel!nél Eseménytovábbitó mechanizmus eseménysor Az eseményekhez eseménykezel!ket definiálnak Események id!beli bekövetkezte ismeretlen Alrendszer 1 Alrendszer 2 Alrendszer 3 Esemény diszpécser Események 42

22 Interrupt modell Valósidej" rendszerek Definiált interrupt típusok és típusonkénti kezel! eljárások Interrupt vektor Gyors m"ködés, nehéz tesztelés Kezel! 1 Folyamat 1 Kezel! 2 Interrupt vektor Kezel! 3 Folyamat 2 Kezel! 4 Folyamat 3 43 Architektúrális minták kombinációja Réteg szerkezet + cs!rendszer + megosztott adatok Alkalmazás réteg Alk. 1 Alk. 2 Alk. 3 Alk. 4 Adattárolási réteg DB 1 DB 2 DB 3 DB 4 DB 5 Mag réteg (OR, hardver) OR szolg. 1 OR szolg. 2 OR szolg. 3 44

23 Összefoglalás A szoftver architektúra fogalma Architektúrális nézetek modul szerkezetek komponens-és-összeköt! szerkezetek allokáció szerkezetek Architektúrális taktikák szerepe Néhány klasszikus architektúra osztott adatok, kliens-szerver, réteg szerkezet, eseményvezérelt 45