RE SD PD I UT IT ST AT Mjukvarudesign System Requirement Specification Inkrementell och iterativ! Konceptuell design (VAD) Systemdesign (OOA) Arkitekturell (grovkornig, UML) Teknisk design (HUR) Programdesign (OOD) Detaljerad design (moduldesign, lågnivådesign) System Design Description 2 Konceptuell design Berättar för kund och utvecklare vad systemet kommer att kunna göra Svarar exempelvis på följande frågor Var kommer data att komma ifrån? Vad händer med datat i systemet? Hur kommer systemet se ut för användaren? Vilka val har användaren? God konceptuell design fås genom att Beskriva systemets funktionalitet Fristående från implementation Kopplat till kraven Teknisk design Berättar för utvecklare hur systemet kommer att se ut och bete sig Innefattar Hiearki och funktion hos komponenter Datastrukturer (listor, relationstabeller, objekt) Dataflöden (funktioner, gränssnitt, use cases) Kan angripas på olika sätt, exempelvis Decomposition Objektorienterat Datastrukturbaserat Händelseorienterat Dataflödesbaserat Aspektorienterat 3 4
Datastrukturbaserad design Ett programs struktur ska spegla strukturen hos de data som programmet hanterar Exempel: ckson Structured Programming Dataflödesbaserad design Följer datats flöde genom systemet Kan ofta baseras på use cases identification check id withdrawal order withdraw money money Visar komponenterna hos ett system Och deras relationer 5 6 Objektorienterad design Principer för objektorienterad design Substantiv ger objekt Verb ger metoder Basen för objektorientering Arv Inkapsling Polymorfism Huvudpoäng: Återanvändning 7 God teknisk design Hög självständighet hos komponenter Koppling och kohesion Undantagsidentifiering och hantering Feltolerans och förebyggande av fel Error (mänskligt) Fault (uppstår av errors, buggar) Failure (konsekvensen som användaren märker) Aktiv felhantering (koda för att förhindra fel) Passiv felhantering (fånga upp fel) 8
Koppling (coupling, interdependence) Beroenden mot andra komponenter Referenser, dataflöden, kontroll över andra komponenter, komplexitet i interface mellan komponenter Hög koppling är dåligt Eftersom komponenter blir mycket svåra att ändra, dvs. får kass underhållbarhet Undantag: klasser som aldrig ändras (va.util) 9 Kohesion (cohesion, intradependence) Klister inom komponenter eller system Hög Låg - Funktionell (väl relaterade funktioner) - Sekventiell (output -> input) - Kommunikativ (gemensam dataaccess) - Procedurell (ordningsbaserad) - Tidsrelaterad - Logisk - Slumpmässig 10 Att avgöra kohesionstyp Kan modulerna ses som något som bara ska utföra en sak? Hur är aktiviteterna i modulerna relaterade? Varken eller Tillhör aktiviteterna samma generella kategori? Data Flödeskontroll Är sekvensen viktig? Är sekvensen viktig? 11 Funktionell Sekventiell Kommunikativ Procedurell Tidsrelaterad Logisk Slumpmässig Strategi Övergripande tänk Heuristiker Tumregler, anpassningsregler, mönster Notation En uppsättning notationer (informell) Diagram eller matematisk form (formell) SRS Konceptuell - Strategi - Heuristik - Notation Teknisk - Strategi - Heuristik - Notation 12 SDD
Strategi Divide et impera (Alexander den store) Dela upp i delproblem Lös delproblemen Sätt ihop fullständig lösning av de lösta delproblemen Functional decomposition Decomposition trees Top-down Bottom-up Middle-out Heuristik Designprinciper Designmönster Omfaktorisering (refactoring) Effektivisera, optimera och öka läsbarhet utan att ändra funktionalitet Förbereder för och förenklar återanvändbarhet Ökar flexibiliteten i arkitekturen, vilket bidrar till okomplicerad design och en enkelhet att lägga till eller ändra krav Ökar underhållbarheten 13 14 Unken kod är skäl för omfaktorisering Duplicerad kod Långa metoder Stora klasser Utspridda ändringar Switch/Case-satser Onödig generalitet Primitiva tvångstankar Kommentarer 15 Exempel på omfaktoriseringar Encapsulate data En variabel görs private och enda sättet att ändra den är genom en public-funktion. Detta för att man ska vet exakt vem som ändrar den och hur Extract Method Ett antal rader kod gör något som hör ihop. Ta dessa rader och ge dem ett eget namn genom att lägga dem i en egen metod Inline Method En metods namn är precis lika tydligt som metodens kod. Byt ut anropet till koden Replace Data Value with Object En klass har ett enkelt datavärde som behöver extra data eller beteende. Gör datavärdet till en egen klass 16
Notation UML En samling diagram och notationer för att förenkla kommunikationen Mer eller mindre standardiserat Pseudokod Programfunktionalitet fast i naturligt språk Programspråksoberoende Kommunikationsförenklande Referenser Software engineering for students, kapitel 6, 8, 9, 10, 11 Designmönster för programmerare, Bilting, kapitel 8 Refactoring, Martin Fowler RUT 7.1, 7.3 17 18