Softwarearkitektur Begreber og principper Arkitekturframeworket PCMEF Arkitekturdesignmønstre Indledning Det er softwarearkitekturen der gør den store forskel mht. Forståelighed, dvs hvor let det er at analysere og forstå softwarens interne struktur og adfærd mindre risiko for selv at gøre noget galt andre kan overtage udvikling og vedligehold Vedligeholdelse, dvs. hvor let det er at reparere softwaren (rette fejl og mangelfuldheder) at ændre funktionaliteten at torbedre softwarens kvalitet når der kommer nye krav eller ændringer i den underliggende teknologi Skalerbarhed, dvs at softwaren kan bruges i en større målestok flere brugere flere maskiner flere SUPPORTAB BILITET Forår 2009 2 Systemudvikling 1
Efter Larman Forår 2009 3 Efter Larman Forår 2009 4 Systemudvikling 2
Softwarearkitektur Grundlæggende begreber og principper Spørgsmål Hvad er softwarearkitektur? Hvad er et sundt arkitekturdesign betinget af? Hvad er en UML-pakke (package)? Hvad er afhængighed hvad indebærer afhængighed mellem pakker? Hvad er en afhængigheds-brandmur (dependency firewall)? Hvordan kan en sådan etableres? Hvilke forskellige typer af afhængigheder har vi? Hvilken indvirkning har de forskellige afhængigheder på arkitekturen? Er der ikke bare problematiske men også neutrale måske ligefrem nyttige indvirkninger? Hvilken afhængighedstype er særligt problematisk? Kan den undgås? En god lagdelt arkitektur har tre kritiske mål. Hvilke? Hvorfor/hvordan kan interfacer bruges til minimering af afhængigheder? Forår 2009 6 Systemudvikling 3
Hvad er softwarearkitektur? Softwarearkitektur Systemopdeling: organisering i af softwaremoduler i et system med det sigte at opnå et eller andet formål Adressering af problemstillinger (concerns): organisering af specifikke softwaremoduler (klasser, pakker, komponenter) fordeling af ansvar (adfærd) mellem softwaremodulerne sammenkoblinger mellem softwaremodulerne softwaremodulers skalerbarhed beslutning om arkitektur-mønstre og principper Fordele ved opdeling af et system Lettere at forstå systemet Mindre udviklingsenheder Større mulighed for genbrug Bedre håndtering af kompleksitet Forbedring af vedligehold Større flytbarhed Forår 2009 7 Hvad er arkitekturdesign? softwarearkitekturdesign er den mængde beslutninger, der har til sigte at skabe en ydedygtig (efficient) og målrettet (effektiv) softwarearkitektur og rationalet bag disse beslutninger, fx softwareløsningens supportabilitet = forståelighed + vedligeholdelsesevne + skalerbarhed af andre problemstillinger af betydning for arkitekturdesign, kan nævnes, at det primært har sammenhæng med de ikke-funktionelle krav omfatter fundamentale beslutninger der handler om forhold i stor skala og er på systemniveau (Wide-and-Shallow) takler modulers indbyrdes afhængigheder og trade-offs frembringer generering og evaluering af alternative løsninger Forår 2009 8 Systemudvikling 4
Hvad er et sundt arkitekturdesign? Et sundt arkitekturdesign er betinget af en hierarkisk lagdeling af softwaremodulerne, som reducerer kompleksitet forbedrer forståeligheden af systemet og afhængigheder mellem systemets moduler en gennemtvingning af standarder, som minimerer afhængigheder gør afhængigheder mellem softwaremoduler synlige Forår 2009 9 Proaktiv - reaktiv To tilgange: Proaktiv tilgang forward engineering Arkitekturdesignet definerer lagdeling og afhængighedsfirewalls Implementeringen overholder designet Reaktiv tilgang reverse engineering Hvis implementeringen ikke overholder det ønskede arktitekturdesign: Sammenligning med den målte værdi for afhængigheden i softwaren med den værdi som den ønskede arkitektur ville have leveret To formål med den reaktive tilgang: Opretholde arkitekturen Sammenligning af forskellige implementeringer Forår 2009 10 Systemudvikling 5
Hvad er en UML-pakke? en pakke i UML er en gruppe modelleringselementer, der har fået tildelt et fælles navn en pakke kan indeholde andre pakker en pakke ejer sine medlemmer (elementer) fjerner man pakken fra modellen, fjerner man også dens medlemmer et medlem (sædvanligvis en klasse) kan kun tilhøre en pakke en pakke kan have pakke-import p fra andre pakker, dvs. at pakke A eller elementer i pakke A kan referere til pakke B eller til elementer i pakke B klasser ejes kun af en pakke, men kan altså importeres i andre pakker Forår 2009 11 Pakkenotation dependency relationship B owns X A depends on B Package A Package B Class X Package E package with no members revealed + circle-plus notation Package C Package D E owns F F owns Y and Z Package F + Class Y Class Z 9-1 Forår 2009 12 C owns D Systemudvikling 6
Arkitekturdesign og afhængighed Samhørighed (cohesion) måler afhængighed internt mellem elementerne i en pakke/et modul Høj samhørighed: elementerne i pakkerne udfører opgaver, der ligner hinanden, og hænger sammen indbyrdes (via associationer) Lav samhørighed: Masser af diverse- og hjælpeelementer og ingen indbyrdes sammenhæng (via associationer) Kobling (coupling) måler afhængighed mellem pakker/moduler Høj kobling mellem to pakker: Ændringer i den ene pakke vil få høj indflydelse på den andet pakke Pakker bør have så stor samhørighed og så lille kobling som mulig Forår 2009 13 Arkitekturdesign og Afhængighed Afhængighed er det samme som kobling Afhængighed Modul A afhænger af modul B, hvis Forandringer i modul B nødvendiggør forandringer i modul A Afhænger af modul kan betyde afhænger af klasser i modul B afhænger af metoder i modul B afhænger af hændelser i modul B arver noget fra modul B Forår 2009 14 Systemudvikling 7
Hvad er en afhængighedsbrandmur? Fire symptomer på råddenskab i design Stivhed (ufleksibel) vanskeligt at ændre ændringer et sted giver en kaskade af afledte ændringer Skrøbelighed softwaren går i stykker når den ændres Immobilitet softwaren kan ikke genbruges har for meget bagage den skal have med Viskositet Flere måder at gennemføre forandringer på: Nogle bevarer designet andre (hacks) ødelægger det Høj viskositet: Nemt at gøre det forkerte - svært at gøre det rigtige Årsager til råddenskab Ændrede krav! Når de medfører forandringer, som der ikke er taget højde for og som dermed skaber nye afhængigheder Afhængighedsstyring består i etablering af afhængighedsbrandmure En afhængighedsbrandmur er noget der forhindrer afhængigheder i at forplante sig Eksempel: en lagdelt arkitektur, hvor der er regler for adgang mellem lagene, og hvor hvert enkelt lag yderligere kan sikres ved at etablere en enkelt indgang (Martin, 2000) Forår 2009 15 Pak kkeængigheder afhæ Klasseafhængig heder og de deraf afledte pakkeafhængig heder Forår 2009 16 Systemudvikling 8
9-6 Potentiel Run-time afhængighed (objekterne es interaktion) Comp pile-time afhængighed (neda arvning i klassestruktur) Nedarvningsafhængighed på compile-time Forår 2009 17 Opa ad- og ned dadkald Forår 2009 18 Systemudvikling 9
Nedarvningsafhængigheder - runtime Forår 2009 19 Nedarvning uden polymorfi 9-8 Forår 2009 20 Systemudvikling 10
Udvidelsesnedarvning Forår 2009 21 9-9 Metodeafhængighed Forår 2009 22 Systemudvikling 11
Metodeafhængighed Delegering og afhængighed 9-13 Forår 2009 23 Metodeafhængigheder Down-call og Up-call 9-14 Forår 2009 24 Systemudvikling 12
Interfacer mm Interface en erklæring af en mængde egenskaber I UML: attributter operationer Java: konstanter (datamedlemmer som er static og final) Metoder nestede klasser og interfacer kan ikke instantieres direkte Abstrakt klasse en klasse som ikke kan instantieres, fordi den har mindst én abstrakt metode,dvs. en metode som ikke er implementeret. Klassearv er arv af fimplementering i Typearv arv af et interface, dvs en type I Java: klasser kan kun arve (extende) én basisklasse (superklasse) klasser kan implemente flere interfaces Det giver en enorm praktisk forskel Forår 2009 25 Implementering af interfacer 9-16 public interface Interface1 { private int a1; public void o1(); } a1 o1() Interface1 Interface2 a2 o2() public class Class1 implements Interface1, Interface2 { public void o1() { //implementation code } public void o2() { //implementation code } } Class1 Class2 Forår 2009 26 Systemudvikling 13
<<uses>>-afhængighed This is permitted in UML 2.0, but not in Java, which only allows extension inheritance between interfaces Interface1 a1 o1() <<uses>> Interface2 a2 o2() <<uses>> public class Class1 { Interface1 myinterface; Class1 public void do1() { myinterface.o1(); do1() } } Forår 2009 27 9-17 Lagdeling og partitionering Store systemer opdeles sædvanligvis i pakker både vha. lagdeling li og vha. partitionering ii i Lagdeling (horisontal deling) Lag: beskriver en komponents ansvar ved hvilke operationer, der tilbydes opad og hvilke der udnyttes nedefra Hierarkisk organiserede pakker Partitionering (vertikal deling) To eller flere dele, som yder tjenester i samme lag, men hvorimellem der ingen væsentlig interaktion er Netværksorganiserede pakker Forår 2009 28 Systemudvikling 14
Lagdeling Tre kritiske mål: Hierarkisk struktur må ikke udvandes til en netværksstruktur Hierarkiet skal opbygges så det minimerer afhængigheden mellem pakker Hierarkiet udgør en stabil struktur i hele systemets udviklingstid. Bemærk at stabiliteten øges jo længere man kommer ned i lagene Layer n Layer n-1 Forår 2009 29 9-4 Cirkulære afhængigheder 9-2 Forår 2009 30 Systemudvikling 15
Eliminering af cirkulære afhængigheder 9-3 Forår 2009 31 Cirkulære afhængigheder 9.18 Forår 2009 32 Systemudvikling 16
Brydning af cirkulære afhængigheder 9.18 Forår 2009 33 Afhængigheders betydning? Særligt problematiske afhængigheder? Cirkulære afhængigheder mellem lag og pakker Problematiske afhængigheder Afhængigheder mellem lag og pakker Klasseafhængigheder implementeringsarv Neutrale afhængigheder? Metodeafhængigheder Tydelige klasseafhængigheder (associationsafhængigheder) Hjælpsomme afhængigheder? Interface afhængigheder interfacearv Forår 2009 34 Systemudvikling 17
eksempel Forår 2009 35 Forår 2009 36 Systemudvikling 18
P: presentation D: domain PSC: ProcessSaleConsole ING: InitNextGen R: Register IPSC: IProcessSaleConsole Overvej løsningerne hvilken er bedst? Ved løsning 2: Kan vi undgå at domaine-laget alligevel - i sidste ende skal kende den konkrete klasse her ProcessSaleConsole? Hvorfor hvorfor ikke? Hvordan eller hvad så? Forår 2009 37 Forår 2009 38 Systemudvikling 19
Arkitekturframework Spørgsmål Hvad er et framework? Hvad er MVC-arkitekturen? Hvad er PCMEF? Hvilke principper er der i Hvad er Acquaintance-pakken i PCMEF+arkitekturen Hvilken særlig rolle spiller hvert af fde beskrevne GOF-mønstre spiller i PCMEF+arkitekturen? Forår 2009 41 Systemudvikling 20
Framework Generelt A software framework is a reusable design for a software system (or subsystem). a set of abstract classes and the way their instances collaborate for a specific type of software all software frameworks are object-oriented designs (uddrag fra: http://encyclopedia.thefreedictionary.com/software+framework) Her Framework is a construction ti on which h the solution to a problem is built. In Object technology, a framework is a reuse technology Framework provides a skeleton solution to the problem, which needs to be customized and extended to serve useful function (Maciaszek) Forår 2009 42 Model-View-Controller (MVC) MVC-frameworket stammer fra smalltalk, hvor der (I smalltalk 80) opereredes med tre grupper af klasser som var specialiseringer af de abstrakte klasser Model, View og Controller: Modelobjekter repræsenterer dataobjekter dvs. forretningsentiteter og forretningsregler i domænet View-objekter repræsenterer brugergrænseflade-objekter og præsenterer modellens tilstand på den måde som brugerne forventer det typisk på et grafisk skærmbillede Controller-objekter repræsenterer proceslogik (giver mening til brugerinteraktioner via mus og tastatur) Bemærk: dette er ansvarsfordeling på arkitekturniveau også kaldet Adskillelse af anliggender (Separation of Concerns) Application Program View Database and Web Services Model Persistent Data Controller Forår 2009 43 Systemudvikling 21
Model-view-(control): Eksempel Forår 2009 44 PCMEF arkitekturframework PCMEF layers entity presentation control domain foundation mediator Præsentationslaget (presentation) danner en grænseflade mellem systemet og dets omgivelser, dvs. håndterer interaktionen med brugerne (og med andre edb-systemer?) indeholder klasser som definerer (G)UIobjekter, fx klasser baseret på Java Swing biblioteket Kontrollaget (control) håndterer forespørgsler fra præsentationslaget og er ansvarlig for at behandle brugernes interaktioner. Kontrollaget er ansvarlig for en stor del af programmets logik og for at holde styr på sessionstilstanden for hver af brugerne Domænelaget (domain): Entitetspartitionen (entity) Har ansvaret for at holde styr på de objekter, som repræsenterer problemområdet (domænet). Når der sker noget relevant i problemområdet skal objekterne i entitetspartitionen skifte tilstand i overensstemmelse hermed. Mediatorpartitionen (mediator) Har ansvaret for at etablere en kommunikationskanal mellem Entitetsklasser og klasserne i den Teknisk Platform (Foundation) Tekniske platform (foundation) er ansvarlig for al kommunikation med databaser og netværk Forår 2009 45 Adskillelse af anliggender (separation of concerns Systemudvikling 22
on PCMEF arkitektur PCMEF layers presentation Package imports; ----------------------------------------- package presentation; import control.* ery cy ms, entity control domain mediator ----------------------------------------- package control; import domain.entity.* import domain.mediator.* ----------------------------------------- package entity; ---------------------------------------- package mediator import entity; import foundation.*; ----------------------------------------- ices foundation package foundation; Forår 2009 46...converting to PCMEF design CControl EEntity PPresentation MMediator FFoundation CControl MMediator PPresentation EEntity FFoundation Forår 2009 47 Systemudvikling 23
PCMEF arkitektur PCMEF layers entity presentation control domain mediator PCMEF principper Downward Dependency Principle (DDP) Upward Notification Principle (UNP) Neighbor Communication Principle (NCP) Explicit Association Principle (EAP) Cycle Elimination Principle (CEP) Class Naming Principle (CNP) (Acquaintance Package Principle (APP)) foundation Forår 2009 48 PCMEF arkitektur PCMEF layers entity presentation control domain mediator PCMEF principper Downward Dependency Principle (DDP) Upward Notification Principle (UNP) Neighbor Communication Principle (NCP) Explicit Association Principle (EAP) Cycle Elimination Principle (CEP) Class Naming Principle (CNP) (Acquaintance Package Principle (APP)) foundation Forår 2009 49 Systemudvikling 24
Acquaintance - Bekendtskab Bekendtskab definerer en situation hvor et objekt bliver videregivet til et andet objekt som et argument i et metodekald. Hvor er bekendtskabet? Og Hvilke arkitekturmæssige svagheder er der i designet? Forår 2009 53 Reduktion af afhængigheder Hvordan er afhængighederne blevet reduceret? Forår 2009 54 Systemudvikling 25
PCMEF+ (med bekendtskabspakke - Acquaintance) Acquaintance Package Principle (APP) Adskilt pakke Understøtter objektkommunikation mellem ikke-nabo-lag Indeholder interfacer - og KUN interfacer Interfacer bruges til at opretholde lav kobling når der kommunikeres mellem bekendte Forår 2009 56 cquaintace pakken Brug af ac Forår 2009 57 Systemudvikling 26
Opsummering softwarearkitektur organisering af et systems elementer lagdel l systemet, t hold afhængigheder mellem objekter så lavt som muligt Arkitekturframework Anbefalet arkitekturframework PCMEF+ Mønstre Benyt designmønstre til at understøtte softwarearkitekturen, fx Façade, Abstract t Factory, Chain of Responsibility, Observer, og Mediator Forår 2009 77 Afrunding Softwarearkitektur Grundlæggende begreber og principper i softwarearkitekturdesign Hovedpointer: Minimering af afhængigheder Lagdeling Arkitekturframeworket PCMEF Arkitekturdesignmønstre Forår 2009 90 Systemudvikling 27
Afrunding Jeopardy Forår 2009 91 Systemudvikling 28