Vi har... Diskuterat olika objektorienterade mekanismer. Ha också tagit upp några krav på hur dom här mekanismerna ska användas

Transkript

1 Desig priciper

2 Vi har... Diskuterat olika objektorieterade mekaismer Nedärvig Delegerig Typ-parametriserig Kotrakt baserad desig Ha också tagit upp ågra krav på hur dom här mekaismera ska avädas Hur ska ma då desiga mjukvara?

3 Vad är bra desig Är e bra desig Lätt att förstå och implemetera? Uderlättar återavädig, och är lätta att få e överblick över? Lätt att återaväda? Full med desig möster, måga kommetarer? Åtföljs av måga sygga diagram?...

4 Bra desig Eligt Coad ad Yourdo 1991 A good desig is oe that balaces trade-offs to miimize the total cost of the system over its etire lifetime Och Järvi har att tillägga [Järvi 2005]...ad mitigates developmet ad busiess risks, promotes ew busiess opportuities ad cotributes to future high level reuse Det fis ite e eda korrekt desig. Det fis bara mera och midre avädbara desiger

5 Desig mål Måga olika mäskor som prioriterar olika saker kommer att ha att göra med systemet uder dess livstid Till exempel Vi vill spara tid och pegar, miska itroduktioe av ya defekter och miska börda för utvecklara Vi desigar då systemet för att miimera effektera av ädrigar Alltså behöver systemet vara löst kopplat Desigar för att hatera all möjlig variatio

6 Modularitet Mjukvarusystem är för stora för att kua förstås i si helhet Måste delas upp i midre delar E metod som stöder detta behövs Objekt orieterad programmerig Modulär utvecklig eligt Meyer [Meyer 1997]...method is modular, the if it helps desigers produce software systems made of autoomous elemets [modules] coected by coheret, simple structure.

7 Typisk desig Dela upp systemet i kompoeter Defiiera beroede mella kompoeter (asvarsområde, beroede och kommuikatio) Specificera grässitt Beskriv kompoeteras grässitt Måga defiitioer på kompoet eller modul, måga kriterier för uppdelig

8 Dekompositio / Modularitet Ett modulärt system är uppdelat i idetifierbara abstraktioer som kallas moduler moduler ska ha hög kohesio och lite kopplig till varadra Moduler ska ha väldefiierade abstrakta grässitt Fördelar med e välgjord modulär desig Lätt att utvidga systemet Återavädbarhet pga. hög kohesio och låg kopplig Uppdelig av asvar Uppdelig av utvecklig parallell utvecklig Haterig av komplexitet Viktigt för e bra desig Meyer ger 5 kriterier, 5 regler och 5 priciper som täcker de viktigaste krave för e modulär desig metod [Meyer 1997] Krave ite specifika för objektorieterig

9 Fem kriterier: Modular decomposability Metode delar upp problemet i midre problem som också har midre komplexitet Subprobleme är kopplade med e ekel struktur Miimalt och explicit beroede mella olika delproblem Subprobleme ka lösas idividuellt med samma metod Till exempel traditioell top-dow desig

10 Fem kriterier: Modular composability Metode producerar moduler modulera ka fritt kombieras med varadra för att producera ya system modulera ka fritt avädas äve i omgivigar som de ite var plaerade för modulera bör vara tillräckligt autooma (delar ka återavädas för adra ädamål) Till exempel mjukvarubibliotek

11 Fem kriterier: Modular uderstadability Metode uppmutrar skapadet av moduler som också mäskor förstår Beskrivige av e modul ka förstås uta beskrivig av adra moduler (eller i värsta fall edast ågra adra ärliggade moduler) Nödvädigt för effektivt uderhålla ett mjukvarusystem Atar att det fis ett gemesamt språk och termiologi, gör systemet lättare att uderhålla

12 Fem kriterier: Modular cotiuity Metode producerar strukturer av moduler så att e lite ädrig i problemspecifikatioe kräver edast små ädrigar i ågra (ärliggade)moduler Atar delig av asvar. Gör det möjligt att utvidga systemet Exempel 1: Symboliska kostater Exempel 2: Uified access priiciple

13 Fem kriterier: Modular protectio Om ett oormalt tillståd (fel) uppstår uder exekverig så ska effektera av de staa iaför module (eller i värsta fall hållas iom de ärmaste graara) Fel måste upptäckas och isoleras (hårdvarufel, resursbrister ) Exempel 1: Validerig av iput data vid källa

14 Fem regler: Direct mappig Varje mjukvarusystem försöker lösa problem frå ågo problemdomä Strukture för implemetatioe av systemet ska vara likade till strukture på modelle som skapats för att modellera problemdomäe Problem och lösig har likade struktur Följer frå: cotiuity ad decomposability

15 Fem regler: Few iterfaces Varje modul ska kommuicera med så få adra moduler som möjligt Följder av ädrigar och fel propagerar edast geom grässittet Följer frå: cotiuity och protectio Också till e del frå de adra

16 Fem regler: Small iterfaces Om två moduler kommuicerar så ska dom utbyta så lite iformatio som möjligt Följer frå: Cotiuity och protectio

17 Fem regler: Explicit iterfaces Om två moduler kommuicerar med varadra så måste detta vara klart syligt frå programkode för modulera Måste vara lätt se vad för moduler e ädrig påverkar E modul ka ite förstås om de beror på ågo aa på ågot märkligt ej syligt sätt Följer frå: Decomposability, Composability, Cotiuity och Uderstadability

18 Fem regler: Iformatio hidig E modul måste erbjuda e delmägd av sia egeskaper som officiell iformatio om module Modules grässitt De officiella iformatioe är tillgäglig för alla adra moduler Klietmoduler ska ite bero på de icke-officiella iformatioe Publicera bara desigbeslut som är stabila ite såa som ma äu ädrar Följer frå: Cotiuity

19 Fem priciper: Liguistic modular uit Moduler ska motsvara sytaktiska eheter i språket Förhidrar mauell översättig och strukturerig Java har klasser och paket (packages) Implemetera objekt orieterad desig i t. ex. C är ite ödvädigtvis e bra idé

20 Fem priciper: Self-documetatio priciple All iformatio om module är del av module själv Det fis ige begräsig på hur iformatioe är represeterad eller hur ma kommer åt de Viktigt för modular uderstadability Viktigt för att hålla kod och dokumetatio sykroiserad

21 Fem priciper: Uiform access Varje service i e modul måste vara åtkomliga med e ehetlig otatio Ska ite vara ågo skillad om resultatet åstadkoms geom beräkig eller om det fas lagrat Varje service döljer iformatio som ite är del av dess grässitt

22 Fem priciper: Ope-closed Moduler ska vara både öppa och sluta Det ska vara möjligt att utvidga moduler (öppa) Moduler ska vara tillgägliga för adra moduler. Alltså behöver modulera väldefiierade och stabila grässitt (sluta) Detta är e mycket viktig pricip för objektorieterade system

23 Fem priciper: Sigle choice När systemet måste stöda e mägd alterativ, ska exakt e modul käa till de kompletta lista alterativ Att sätta till ett alterativ kräver då (förhoppigsvis) ädrigar i bara e modul De här type av problem uppstår ofta då det fis ett atal alterativ Lista på alterativ kommer ataglige att förädras Desige ska ite påverkas av detta

24 SCP - Exempel class Publicatio{ eum Type {joural, book, proceedigs}; public Type type;... } Vilka typer av publikatioer det fis måste käas till överallt... switch (p.type){ case joural: //hatera tidskrifter case book: //hatera böcker case proceedigs: //hatera koferespublikatioer... }

25 Ett sceario Du börjar kostruera systemet. Det är väldesigat och de första versioe släpps Då börjar det gå fel... Ädrigar och ya fuktioer blir svårare och svårare att göra De ursprugliga desige måste överges Också små ädrigar orsakar ovätade fel Till slut skrivs hela systemet om frå grude Ädå var allt gjort eligt bästa förmåga. Så vad gick fel?

26 Tecke på dålig desig Rigidity Det är svårt att göra ädrigar i systemet eftersom ädrigar propagerar till måga moduler Motvillighet till att göra ädrigar då ma ite vet på förhad vad som behöver ädras Fragility Ädrigar i systemet orsakar fel i moduler som ite har ågot koceptuellt förhållade till de ädrade module Lösigar på dom första probleme skapar ya problem på adra ställe Ige vill göra ädrigar eftersom resultatet är omöjligt att förutsäga

27 Tecke på dålig desig Immobility Modulera i systemet är så hårt kuta till varadra att det är omöjligt att återaväda dem Omöjligt att förstå på grud av alla beroede Viscosity (två typer) Viskositet i systemet Att göra saker på rätt sätt är svårare ä att göra dom fel Att göra saker så att desige bevaras är svårare ä att göra sabba hacks Viskositet i omgivige Utveckligsmiljö lågsam och ieffektiv Låga kompilerigstider, dålig källkodshaterig

28 Tecke på dålig desig Needless complexity Systemet har strukturer som ite tillför ågo ytta Resultat av att ha försökt förutsäga vad som behövs i framtide till e för stor utsträckig Needless repetitio Systemet iehåller repeterade strukturer Opacity Kode är svår att läsa och förstå. Meige framgår ite klart Kode blir mera komplicerad och svårhaterlig med tide

29 Orsaker till dålig desig... Ädrade krav har ite tagits i beaktade Sabba hacks förstör de uderliggade strukture Om desige ite är ekel att förstå, kommer de att bli förstörd Beroede mella kompoeter är ite haterade Det är e aturlag för utvecklig av mjukvara?

30 Exempel på ruttade desig Ett mycket ekelt program som kopierar tecke frå tagetbordet till e priter Illustrerar poäge char Read Keybord Copy char Write priter void copy(){ it c; while( (c=rdkbd())!=eof ) WrtPrt(c); }

31 Exempel (forts.) Krave förädras Programmet ska u också kua läsa frå e pappersbadläsare (?) Grässittet till Copy fuktioe ka ite ädras Har reda måga öjda avädare Aväd globala variabler! bool ptflag=false //kom ihåg att sätta de här flagga void Copy(){ it c; while( (c=(ptflag? RdPt() : RdKdb()))!= EOF) WrtPrt(c); }

32 Exempel (forts.) Krave ädras äu mera Nu ska ma också kua skriva till e paper tape puch bool ptflag=false; bool puchflag=false; //kom ihåg att sätta flaggora void Copy(){ it c; while( (c=(ptflag? RdPt() : RdKdb()))!= EOF) puchflag? WrtPuch(c) : WrtPrt(c); }

33 Exempel desig Desige var ekel och bra för orgialproblemet Förädrigar gjorde att programmet började visa alla tecke på dålig desig Förädrigar måste beaktas

34 Objektorieterad desig iterface Reader{ it read(); } iterface Writer{ write(it c); } class KeyboardReader implemets Reader{ it read(){ retur RdKbd(); } } class TapeReader implemets Reader{... } void Copy(Reader r, Writer w){ it c; while( (c=r.read())!=eof) w.write(c); }

35 Hur motverka ruttade desiger Måga olika utveckligsprocesser Agile methods (Extreme programmig, etc...) RUP Skapa desige med take på att systemet kommer att modifieras Krave ädras Ny fuktioalitet kommer sättas till Refaktoriserig Omstrukturerig av kode som bevarar futioalitet me förbättrar strukture Kvalitete på desige ska alltid hållas hög uder systemets utvecklig Det är omöjligt att desiga ett perfekt system på första försöket