HT1 2015, FÖRELÄSNING 14 (INFÖR TENTAN)

Transkript

1 Objektorienterad modellering och diskreta strukturer (EDAF10/EDA061) HT1 2015, FÖRELÄSNING 14 (INFÖR TENTAN) Dagens agenda Admin DS-föreläsning nästa torsdag 22/10 kl Tentatid och plats Tillåtet på tentan EDAF10 Föreläsning inför XL-projektet Sammanfattning Kursens syfte & mål Principer Mönster UML Paketdesign EDAF10/EDA061 HT2015, Ulf Asklund 1

2 Tentamenslokal Tentamen är onsdagen den 28 oktober kl EDAF10 i Vic:2B-D (kl 08-13) EDA061 i Vic:3A-B (kl 08-12) Tillåten litteratur på tentamen På tentamen får medföras Martin, PPP (ej kopior eller utskrift av bok) Andersson, UML Java snabbreferens Andersson, Diskreta strukturer [EDAF10] Sedvanliga anteckningar är OK. Information kopierad från andra dokument får inte förekomma. EDAF10/EDA061 HT2015, Ulf Asklund 2

3 XL Introduktion till XL-projektet måndag den 2 november kl. 8 Skapa grupper och anmäl redovisningstid via SAM. Redovisning 1 i v46 (lv2 ht2) Redovisning 2 i v47 (lv3 ht2) (PVG-kursens föreläsningar börjar måndag v48 (lv4 ht2) Sammanfattning EDAF10/EDA061 HT2015, Ulf Asklund 3

4 Kursens syfte Kursen ger förmåga till hållbar och resursmedveten utveckling av program som kan återanvändas och modifieras med hänsyn till förändrade krav i ett industriellt sammanhang. Du skall bli en tillgång och inte belastning i din första anställning. Nu ska du lära dig Principer Mönster (Metodik) UML O-O Eclipse Paket Klass Abstrakt klass Arv Gränssnitt Java Objekt Statisk metod Abstrakt metod Metod Virtuell metod Attribut Statiskt attribut Metodanrop Dynamisk bindning Virtulla metoder, polyformism EDAF10/EDA061 HT2015, Ulf Asklund 4

5 Kursens mål Efter genomgången kurs ska studenten kunna lokalisera och känna igen användning av gängse designprinciper och designmönster i givna program, utforma och implementera objektorienterade program med många klasser och några paket, välja och implementera lämpliga designmönster i typiska problem, använda centrala delar av en integrerad utvecklingsmiljö för design, implementering och omstrukturering av program, beskriva programdesign med UML (Unified Modeling Language), utvärdera en programdesign med avseende på designprinciper samt skriva program som är lätta att förstå för den som behöver göra modifieringar. Smells Stelhet Bräcklighet Orörlighet Seghet Paketdesign Stabilitet Metrics Cirkulärt beroende Skapa design Substantivsmetoden Itertivt Tillämpa principer Tillämpa mönster Principer OCP SRP ISP DIP ALP LSP Integrity Text -> UML Java <-> UML Analys & förbättra Java -> Java Java -> UML UML -> Java UML -> UML UML Användningsfall Klassdiagram Objektdiagram Sekvensdiagram Tillståndsdiagram Designmönster (patterns) MVC TM Strategy Decorator Factory Command Composite Null Façade Singleton namngivning EDAF10/EDA061 HT2015, Ulf Asklund 5

6 Designprinciper Lokalitetsprincipen Single Responsibilty Principle Open/Closed Principle Integritetsprincipen Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle (Abtraktionsprincipen) DIP Bero på abstraktion Dependency Inversion Principle High level classes should not depend on low level classes; both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. UML-pilar skall gå mot gränssnitt och abstrakta klasser. EDAF10/EDA061 HT2015, Ulf Asklund 6

7 Dependency Inversion LongWord I vilken klass skall man beräkna summan av de värden som finns i två LongWord-objekt? Är det så här man skall göra? public class Add implements Instruction { private LongWord word1, word2; public void execute() { long value1 = word1.getvalue(); long value2 = word2.getvalue(); LongWord word = new LongWord(value1 + value2); // omissions EDAF10/EDA061 HT2015, Ulf Asklund 7

8 Nej! Det ska göras i den klass där man har tillgång till representationen av värdena. public class LongWord { private long value; public void add(longword word1, LongWordword2) { value = word1.value + word2.value; Varför det? VeryLongWord public class VeryLongWord { private long value1, value2; public void add(verylongwordword1, VeryLongWord word2) { value1 = word1.value1 + word2.value1; value2 = word1.value2 + word2.value2; if (logical_expression) { value1++; EDAF10/EDA061 HT2015, Ulf Asklund 8

9 Designmönster Command [Computer] Composite [XL] Template Method [Computer] Strategy [Computer] Decorator Singleton Null Object [XL?] Observer [XL] Factory Method [XL] Command EDAF10/EDA061 HT2015, Ulf Asklund 9

10 Kompositmönstret (Composite) Ni kommer ihåg Comand Nu med Composite EDAF10/EDA061 HT2015, Ulf Asklund 10

11 Expr har Composite-struktur Strategy EDAF10/EDA061 HT2015, Ulf Asklund 11

12 Decorator-mönstret i Reader-klasserna reader = new new FileReader(fileName) reader = new BufferedReader(reader); public class BufferedReader extends Reader { private Reader in; // omissions Observer-mönstret Metoden state() i modellen är en sorts getter. Det är bra om denna inte avslöjar hur tillståndet representeras. EDAF10/EDA061 HT2015, Ulf Asklund 12

13 Observer-mönstret public class Model extends Observable { private int state; public void changestate() { state++; setchanged(); notifyobservers(); public String state() { return String.valueOf(state); Metoden state() i modellen är en sorts getter. Det är bra om denna inte avslöjar hur tillståndet representeras. Observer-mönstret Metoden state() i modellen är en sorts getter. Det är bra om denna inte avslöjar hur tillståndet representeras. public class View extends JLabel implements Observer { private Model model; public View(Model model) { this.model = model; model.addobserver(this); public void update(observable observable, Object object) { settext(model.state()); Tydlig koppling till modellen. EDAF10/EDA061 HT2015, Ulf Asklund 13

14 Observer-mönstret Metoden state() i modellen är en sorts getter. Det är bra om denna inte avslöjar hur tillståndet representeras. public class View extends JLabel implements Observer { public View(Model model) { model.addobserver(this); public void update(observable observable, Object object) { Model model = (Model) observable; settext(model.state()); Mindre tydlig koppling till modellen. Ihopkoppling av vy och modell Skapa model och vy enligt exemplet ovan: Model model = new Model(); View view = new View(model); EDAF10/EDA061 HT2015, Ulf Asklund 14

15 Factory Method SomeApp <<interface>> Shape Square Circle <<creates>> SomeApp har endast beroende till gränssnittet Shape SomeApp skapar objekt av Square och Circle och blir även beroende till konkreta klasserna Square och Circle. Factory Method SomeApp <<interface>> Shape Factory + makesquare():shape + makecircle():shape <<interface>> Shape ShapeFactory Implementation Square Circle <<creates>> Factory Method tar bort beroendet till de konkreta klasserna EDAF10/EDA061 HT2015, Ulf Asklund 15

16 UML: objekt- och sekvensdiagram Objektdiagram EDAF10/EDA061 HT2015, Ulf Asklund 16

17 Objektdiagram (1 + 2) + 3 Sekvensdiagram EDAF10/EDA061 HT2015, Ulf Asklund 17

18 Om du vill lära dig mer EDA270 Programvaruutveckling i grupp projekt, fokus på utvecklingsprocessen XP med rika tillfällen att göra design. EDAN65 Kompilatorteknik, mycket modellering, aspektorienterad programmering. (NY ersätter EDA180) EDAN40 Funktionsprogrammering, en annan paradigm. EDAN01 Constraint programming, ytterligare en paradigm. EDA031 C++ programmering, för den som vill lära sig ett programspråk för objektorienterad modellering från talet (och som fortfarande används). Paketdesign Repetition och demo i Eclipse och CodePro EDAF10/EDA061 HT2015, Ulf Asklund 18

19 Designprinciper för paket Sammanhangsprinc iper (package cohesion) Common reuse principle (CRP) Reuse-release equivalence principle (REP) Common closure principle (CCP) Stabilitetsprinciper (package coupling) Acyclic dependencies principle (ADP) Stable dependencies principle (SDP) Stable abstractions principle (SAP) Common reuse principle (CRP) Klasserna i paketet är så nära relaterade att om man behöver en av dem så behövs i regel även de övriga. Exempel: Mjukvarupaketet i Computer. Om man behöver en instruktion så behövs också de andra instruktionerna och Program-klassen. Motsvarighet: Principen om enkelt ansvar. EDAF10/EDA061 HT2015, Ulf Asklund 19

20 Reuse-release equivalence principle (REP) The granule of reuse is the granule of release Återanvändning (reuse) innebär att det är paketägaren som underhåller och ger ut (release) paketet. Den som använder paketet skall inte behöva ändra på paketet och inte behöva titta på implementeringen och bestämmer själv när en ny utgåva skall integreras. Exempel: När hårdvarugruppen i det stora Computerprojektet kommer med en ny version av hårdvaran så kan simuleringsgruppen själv bestämma när den skall uppgradera hårdvaran och kan göra det utan att titta på implementeringen. Motsvarighet: Lokalitets- och integritetsprinciperna Common closure principle (CCP) Klasserna i ett paket skall vara stängda resp. öppna tillsammans gentemot samma slags förändringar. Förändringar som påverkar en klass i paketet får påverka andra klasser i paketet men inga klasser utanför paketet. Exempel: När vi vill introducera VeryLongWord i Computerprojektet skall man bara behöva ändra i hårdvarupaketet. Motsvarighet: öppen/sluten-principen. Single-responsibility principen. EDAF10/EDA061 HT2015, Ulf Asklund 20

21 Stabilitetsprinciper Acyclic dependencies principle (ADP) Paket skall ej vara cykliskt beroende. Stable dependencies principle (SDP) Beroenden skall gå mot stabila paket. Stable abstractions principle (SAP) Stabila paket skall vara abstrakta. Cykelproblem Paketstrukturen kan inte byggas top down inte det första man gör i sin systemdesign. Ett paket som ingår i en cykel går inte att återanvända utan att ta med hela cykeln och allt som cykelns paket beror på. EDAF10/EDA061 HT2015, Ulf Asklund 21

22 Med cykel package a; import b.b; public class A { public void methoda(b b) { b.method(); package b; import a.a; public class B { private A a; public void method() { a.methoda(this); Utan cykel package a; public interface AI { public void method(); public class A { public void methoda(ai ai) { ai.method(); package b; import a.*; public class B implements AI { private A a; public void method() { a.methoda(this); EDAF10/EDA061 HT2015, Ulf Asklund 22

23 Stabilitetsprinciper Acyclic dependencies principle (ADP) Paket skall ej vara cykliskt beroende. Stable dependencies principle (SDP) Beroenden skall gå mot stabila paket. Stable abstractions principle (SAP) Stabila paket skall vara abstrakta. Exempel - DIP Policy layer Mechanism Layer Utility Layer EDAF10/EDA061 HT2015, Ulf Asklund 23

24 Exempel - DIP Policy layer <<interface> Mech IF Mechanism Layer <<interface> Util IF Utility Layer Exempel - SDP Policy Policy Layer Mechanism Mechanism Layer Utility Utility Layer EDAF10/EDA061 HT2015, Ulf Asklund 24

25 Exempel - SDP Policy Policy layer Mechanism <<interface> Mech IF Mechanism Layer Utility <<interface> Util IF Utility Layer Exempel - SDP Policy Policy layer <<interface> Policy Service Mechanism Mechanism Layer <<interface> Mech Service Utility Utility Layer EDAF10/EDA061 HT2015, Ulf Asklund 25

26 Stabilitetsprinciper Acyclic dependencies principle (ADP) Paket skall ej vara cykliskt beroende. Stable dependencies principle (SDP) Beroenden skall gå mot stabila paket. Stable abstractions principle (SAP) Stabila paket skall vara abstrakta. Stabilitetsmetrik Paketets stabilitet S = C a / (C e + C a ), där C a är antalet klasser utanför paketet som beror på klasser i paketet. a står för afferent (inåtriktad). C e är antalet klasser i paketet som beror på klasser utanför paketet. e står för efferent (utåtriktad). S=0 innebär inget ansvar S=1 innebär inget beroende Paketets instabilitet I = 1 S = C e / (C e + C a ) I=0 är ett maximalt stabilt paket. Oberoende paket EDAF10/EDA061 HT2015, Ulf Asklund 26

27 Stabilitetsmetrik Paketets Abstrakthet A = N a / N c, där N a är antalet abstrakta klasser (gränssnitt) i paketet. N c är antalet klasser i paketet. A-I grafen A = I = 1 är meningslösa zonen (useless zone) A = I = 0 är problemzonen (zone of pain) A = 0, I =1 och A = 1, I = 0 är önskvärda zoner EDAF10/EDA061 HT2015, Ulf Asklund 27