Desig av subsystem
Subsystem Klasser är ett bra sätt att orgaisera små system Klasser är för små eheter för att orgaisera stora system Större eheter behövs för orgaiserige Subsystem Sex priciper diskuteras Tre beskriver kohesio hos subsystem Hjälper till att allokera klasser till subsystem De tre sista beskriver kopplig mella subsystem Beskriver hur subsystem ska relatera till varadra
Subsystem i Java I Java - package E klass C sätts till ett subsystem sub med, package sub; Sätts i börja av file C.java Ma ka aväda e klass C i paket sub geom att Referera till sub.c Referera till C, me först importera klasse sub.c, import sub.c; Referera till C, me först importera alla klasser i sub, import sub.*; Subsystem ka vara hierarkiska Subsystem iaför subsystem package deklaratioera måste motsvara orgaiserige av filer i filsystemet
Desig med subsystem I UML ka subsystem (packages) avädas för att gruppera klasser Med hjälp av subsystem ka ma ka aalysera systemet på e högre abstraktiosivå De ka också hjälpa till att hatera utvecklig och distributio av programmet Målet är att partitioera klassera i systemet eligt ågot kriterium och seda allokera dessa partitioer till paket
Desig med subsystem Klasser beror av varadra Beroede korsar ofta subsystem gräser Subsystem beror därför på varadra Dessa beroede beskriver högivå strukture på applikatioe Följade frågor fis Vilka priciper fis för allokerig av klasser till subsystem? Vilka desig priciper fis för beroede mella subsystem? Ska subsystem desigas före klasser (eller tvärtom)? När subsysteme har skapats, hur ska de avädas?
The reuse-release equivalece priciple (REP) The graule of reuse is the graule of release E ehet som ma återaväder är också e ehet som ma publicerar Klasser ofta oödigt små eheter för återavädig Flera klasser hör ofta ihop Återaväd subsystem Allt som återaväds måste också publiceras och spåras Olika versioer måste hateras Återavädig edast möjlig, om det fis garatier om stöd, uderhåll, meddelade om uppdaterig osv.
The reuse-release equivalece priciple (REP) Ger e pricip för att allokera klasser till subsystem Återavädbarhet baserar sej på subsystem Återavädbara subsystem måste iehålla återavädbara klasser För att få återavädbar kod måste ma ha delar som är lätta att aväda Om ett subsystem är ämat för återavädig så ska det ite iehålla klasser som ite är återavädbara
The commo-reuse priciple (CRP) The classes i a package are reused together. If you reuse oe of the classes i the package, you reuse them all. Klassera i ett subsystem återaväds tillsammas. Om e applikatio återaväder e klass i ett subsystem, återaväds alla klasser i subsystemet Klasser som återaväds tillsammas ska placeras i samma subsystem Klasser som ofta har stark kopplig mella sej Om kod ädras i ett subsystem kommer edast de som verklige behöver fuktioalitete att påverkas Aars påverkar det också avädare som aväder paketet me ite ödvädigtvis fuktioalitete som ädrats
The commo-reuse priciple (CRP) Ger också e pricip är ma ite ska sätta klasser i samma subsystem Exempel: om e applikatio bara aväder e klass ur ett subsystem Applikatioe beror alltså på subsystemet Applikatioe måste valideras (och möjlig omkompilers och avädaras istallatioer uppdateras) på ytt om subsystemet modifieras, också om applikatioe ite aväder klasse.
The commo-reuse priciple (CRP) Ofta har subsystemet e fysisk represetatio JAR fil för java DLL eller.so fil för kompilerade språk (C/C++) Uppdaterig av subsystemet skapar e uppdaterig av JAR, DLL, so-file. Måste distribueras till avädare Om ett subsystem iehåller klasser med hög kohesio miskar ma problem med uppdaterigar Uppdaterigar görs då det är ödvädigt
The commo-closure priciple (CCP) The classes i the package should be closed together agaist the same kid of chages. A chage that affects the package affects all the classes i that package ad o other package Klassera i ett subsystem ska vara sluta för samma typ av ädrigar. E ädrig som påverkar ett subsystem påverkar alla klasser i subsystemet och iga adra subsystem Ett subsystem ska ite ha flera orsaker för att modifieras på grud av förädrade avädarkrav Ofta är uderhållbarhet viktigare ä återavädbarhet Ma vill göra ädrigar på bara ett ställe
The commo-closure priciple (CCP) Om två klasser hör ihop fysiskt eller koceptuellt så att dom ataglige kommer att bli modifierade av samma orsak så hör dom i samma subsystem Pricipe är ära besläktad med Ope-Closed Priciple (OCP) 100% slutehet är ite möjlig Måste välja oga vilke typ av modifikatioer som subsystemet (klasse) är slute för
Priciper för koppligar mella subsystem De tre följade pricipera behadlar koppligar (beroede) mella subsystem Beroede mella subsystem Två fall: Avädig eller arv mella två klasser i olika subsystem X Y X Y A (from X) B (from Y) C (from X) D (f rom Y)
The acyclic-depedecy priciple (ADP) Allow o cycles i the package-depedecy graph. Tillåt iga cykler i subsystemes beroedegraf Problem: Flera utvecklare jobbar med samma system Det blir lätt att modifikatioer och ya fuktioer som sätts till av olika utvecklare är ikompatibla med varadra Mycket tid går åt att itegrera bidrag frå olika persoer Midre tid att sätta till y fuktioalitet
The acyclic-depedecy priciple (ADP) Lösig: dela upp utvecklige i idividuella subsystem Subsysteme utvecklas idividuellt När e versio är klar för avädig publiceras de till adra utvecklare Det ger e stabil versio att jobba mot Utvecklig av subsystemet fortsätter efter seda med e y versio Adra utvecklare ka aväda vilke versio av subsystemet som de öskar Itegrerig av y fuktioalitet går smidigt Det här fugerar bara om det ite fis cykler i subsystemes beroede graf
ADP exempel Beroede mella subsysteme bildar e a-cyklisk graf MyApplicatio MessageW idow TaskW idow MyTasks Database Tasks MyDialogs Widows
ADP exempel Nu e graf med cykliskt beroede MyApplicatio MessageWidow TaskW idow MyTasks Dat abase Tas ks MyDialogs Widows
ADP problem med cykler Ett subsystem i systemet blir lätt beroede av måga adra subsystem Här blir subsystemet MyDialogs beroede av alla subsystem Validerig kräver att vi testar att ett subsystem fugerar då ågot av subsysteme det beror av uppdateras Cykler ökar beroede betydligt Ökade beroede - svårare att göra tester Kompilerigs tider ökar med ökade beroede Speciellt C++ Me också java kompilerig ka få problem
ADP Hur ta bort cykliska beroede? Tillämpa Depedecy Iversio Priciple (DIP) och Abstrakt server desig möstret X (from MyDi alo gs) Y (from M yapplicatio) X (from MyDialogs) XServer (from MyDialogs) Y (from MyApplicatio) MyDialogs MyApplicatio MyDialogs MyApplicatio
ADP Hur ta bort cykliska beroede? Skapa ett ytt subsystem som både MyDialogs och MyApplicatio beror av. Flytta klassera som båda beror av dit.
Idetifierig av subsystem - top-dow desig Ett sätt att hitta subsystem strukture är att dela upp systemet eligt högivå fuktio (top-dow) Logiskt sätt att dela upp systemet i subsystem frå börja Verkar ite riktigt stämma överes med beroedea i grafe tidigare Subsystem har ofta lite att göra med fuktio Beskriver hur systemet ka kompileras/byggas (buildability) Subsystemet beskriver e build map Aväd REP och CCP för att gruppera klasser Aväd CRP för återavädbarhet Aväd ADP för att hatera beroede
The stable-depedecies priciples (SDP) Deped i the directio of stability Beroede pekar mot stabilitet Vissa paket är desigade för att kua modifieras Ska ite bero av subsystem som är svåra att modifiera Måga beroede på ett subsystem som är lätt att modifiera i sej själv ka göra att subsystemet ite ka modifieras uta att störa adra subsystem Subsystem som ska vara lätta att modifiera ska ite bero på subsystem som är svårare att modifiera
Stabilitet Subsystem X asvarig för tre subsystem X är oberoede för X har iga extera orsaker att modifieras X är stabilt (stable) X
Istabilitet Y är ett istabilt subsystem Beror av tre adra subsystem tre orsaker att modifieras Ite asvarigt för ågot aat subsystem Y
Stabilitets mått Stabilitet ka mätas Räka atalet beroede mella klasser iaför och utaför subsystemet (C a ) Affaret coupligs Atalet klasser utaför subsystemet som beror av klasser i subsystemet (C e ) Efferet coupligs Atalet klasser i subsystemet som beror av klasser utaför subsystemet (I) istabilitet I = C a Ce + C e I=1 idikerar istabilt subsystem, och I=0 idikerar stabilt subsystem
SDP Tumregel Stabilitete ökar då ma går eråt i subsystem hierarki Stabila subsystem behöver ite vara lätta att modifiera Måga beroede på dem svårt att modifiera i alla fall Vissa delar av programmet borde ite ädra ofta Högivå arkitektur Desigbeslut Dessa typer av klasser borde vara i stabila subsystem Aväd OCP för att få tillräcklig flexibilitet i systemet
The stable abstractios priciple (SAP) A package should be as abstract as it is stable Ett subsystem ska vara så abstrakt som det är stabilt Relatio mella abstrakthet och stabilitet Ett stabilt subsystem ska också vara abstrakt Stabilitete förhidrar ite att subsystemet utvidgas Ett istabilt subsystem ska ite vara abstrakt - ekelt att modifiera kode ädå DIP ka avädas för att ädra riktig på beroede SAP och SDP för subsystem motsvara DIP för klasser
Exempel: java.soud.sampled Hög abstrakthet Består av grässitt Hög stabilitet Appli katio Aväds av applikatioer Grässitte implemeteras av olika audiosystem Flexibelt system Ekelt att lägga till y fuktioalitet Ekelt att aväda java.sou d.sampl ed Ba cked1 Backed2
Mått på abstrakthet Ma mäter förhålladet mella abstrakta klasser (och grässitt) och valiga klasser N c Atalet klasser i subsystemet N a Atalet abstrakta klasser i subsystemet. E abstrakt klass är e klass ma ite ka skapa istaser av. A - Abstrakthet A = N N a c
Abstrakthet vs Istabilitet Ma ka rita upp abstrakthet och istabilitet (0,1) (1,1) Oavädbar A The mai sequece Svår att modifiera I (1,0)
Abstrakthet vs. Istabilitet Ma vill valige att subsystem ska vara ära lije the mai sequece i diagrammet. Ma ka defiiera ett mått på avstådet Normaliserat avståd D Ger ett värde i itervallet [0,1] D' = A + + I 1 Desige ka utvärderas eligt det här kriteriet Subsystem med stort värde på D ska udersökas ärmare Är ite ett absolut mått på e desigs godhet