Begreber og principper Arkitekturframeworket PCMEF. Det er softwarearkitekturen der gør den store forskel mht.

Transkript

1 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 Systemudvikling 1

2 Efter Larman Forår Efter Larman Forår Systemudvikling 2

3 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 Systemudvikling 3

4 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 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 Systemudvikling 4

5 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 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 Systemudvikling 5

6 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 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 C owns D Systemudvikling 6

7 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 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 Systemudvikling 7

8 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 Pak kkeængigheder afhæ Klasseafhængig heder og de deraf afledte pakkeafhængig heder Forår Systemudvikling 8

9 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 Opa ad- og ned dadkald Forår Systemudvikling 9

10 Nedarvningsafhængigheder - runtime Forår Nedarvning uden polymorfi 9-8 Forår Systemudvikling 10

11 Udvidelsesnedarvning Forår Metodeafhængighed Forår Systemudvikling 11

12 Metodeafhængighed Delegering og afhængighed 9-13 Forår Metodeafhængigheder Down-call og Up-call 9-14 Forår Systemudvikling 12

13 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 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 Systemudvikling 13

14 <<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 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 Systemudvikling 14

15 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 Cirkulære afhængigheder 9-2 Forår Systemudvikling 15

16 Eliminering af cirkulære afhængigheder 9-3 Forår Cirkulære afhængigheder 9.18 Forår Systemudvikling 16

17 Brydning af cirkulære afhængigheder 9.18 Forår 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 Systemudvikling 17

18 eksempel Forår Forår Systemudvikling 18

19 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 Forår Systemudvikling 19

20 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 Systemudvikling 20

21 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: 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 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 Systemudvikling 21

22 Model-view-(control): Eksempel Forår 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 Adskillelse af anliggender (separation of concerns Systemudvikling 22

23 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 converting to PCMEF design CControl EEntity PPresentation MMediator FFoundation CControl MMediator PPresentation EEntity FFoundation Forår Systemudvikling 23

24 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 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 Systemudvikling 24

25 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 Reduktion af afhængigheder Hvordan er afhængighederne blevet reduceret? Forår Systemudvikling 25

26 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 cquaintace pakken Brug af ac Forår Systemudvikling 26

27 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 Afrunding Softwarearkitektur Grundlæggende begreber og principper i softwarearkitekturdesign Hovedpointer: Minimering af afhængigheder Lagdeling Arkitekturframeworket PCMEF Arkitekturdesignmønstre Forår Systemudvikling 27

28 Afrunding Jeopardy Forår Systemudvikling 28