Objektorienterad modellering och diskreta strukturer (EDAF10/EDA061)

Objektorienterad modellering och diskreta strukturer (EDAF10/EDA061) HT1 2014, FÖRELÄSNING 14 (INFÖR TENTAN)

Dagens agenda Admin Tentatid och plats Tillåtet på tentan EDAF10 Föreläsning inför XL-projektet Paketdesign Repetition och demo av verktyg för mätning Sammanfattning Kursens syfte & mål Principer Mönster UML

Tentamenslokal Tentamen är fredagen den 31 oktober kl 14.00 EDAF10 i Vic:1-HELA, Vic:2A (kl 14-19) EDA061 i Vic:1-HELA (kl 14-18)

Tillåten litteratur på tentamen På tentamen får medföras Martin, PPP Föreläsningsbilder F01-06.pdf Andersson, UML Java snabbreferens Andersson, Diskreta strukturer [EDAF10] Sedvanliga anteckningar är OK. Information kopierad från andra dokument får inte förekomma.

XL Introduktion till XL-projektet måndag den 3 november kl. 8 Skapa grupper och anmäl redovisningstid via SAM. Redovisning 1 i v46 (lv2 ht2) Redovisning 2 i v47 (lv3 ht2)

Paketdesign Repetition och demo i Eclipse och CodePro

Designprinciper för paket Sammanhangsprinciper (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.

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.

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å.

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); } } Demo i ECLIPSE och CodePro

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); } } Demo i ECLIPSE och CodePro

Exempel - DIP Policy layer Mechanism Layer Utility Layer

Exempel - DIP Policy layer <<interface> Mech IF Mechanism Layer <<interface> Util IF Utility Layer

Exempel - SDP Policy Policy Layer Mechanism Mechanism Layer Utility Demo i ECLIPSE och CodePro Utility Layer

Exempel - SDP Policy Policy layer Mechanism <<interface> Mech IF Mechanism Layer Utility <<interface> Util IF Demo i ECLIPSE och CodePro Utility Layer

Exempel - SDP Policy Policy layer <<interface> Policy Service Mechanism Mechanism Layer <<interface> Mech Service Utility Demo i ECLIPSE och CodePro Utility Layer

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

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

Sammanfattning

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.

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.

Designprinciper Lokalitetsprincipen Single Responsibilty Principle Open/Closed Principle Dependency Inversion Principle (Abtraktionsprincipen) Integritetsprincipen Liskov Substitution Principle Interface Segregation Principle

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.

Dependency Inversion

Designmönster Command [Computer] Composite [XL] Template Method [Computer] Strategy [Computer, XL] Decorator Singleton Null Object [XL?] Observer [XL] Factory Method [XL]

Command

Kompositmönstret (Composite)

Ni kommer ihåg Comand Nu med Composite

Expr har Composite-struktur

Strategy

Decorator-mönstret i Reader-klasserna reader = new BufferedReader(new FileReader(fileName)); public class BufferedReader extends Reader { private Reader in; // omissions }

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

UML: objekt- och sekvensdiagram

Objektdiagram

Objektdiagram (1 + 2) + 3

Sekvensdiagram

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 1970- talet (och som fortfarande används).