OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram

Transkript

1 2EMHNWRULHQWHUDG5HDOWLGVSURJUDPPHULQJ Föreläsning 7 OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram - Kravspecifikationer, användningsfall, systemarkitektur - Analysfas vad är analys? introduktion och grundläggande diagramtyper - Strukturella modeller - Funktionell modell previous next Kravspecifikationer Traditionellt Beskriver kravspecifikationen mjukvaran som ska konstrueras I ett inbäddat system så måste vi också ta hänsyn till hårdvaran Ofta kan man anta att man konstruerar mjukvaran med hjälp av befintlig hårdvara Fast tex kostnads- och prestandakrav kan göra att hårdvaran väsentligt påverkar mjukvaran (möjligheter osv) Vi analyserar kravspecifikationen och försöker bygga en modell över systemet som skall konstrueras Idag brukar man börja med att identifiera aktörer och användningsfall, och konstruera användningsfallsdiagram som beskriver vad systemet skall göra och för vem previous next 2 Björn Eiderbäck

2 Användningsfall Vad är ett användningsfall? Ett användningsfall är en funktion i systemet Vad är ett användningsfallsdiagram? Ett användningsfallsdiagram illustrerar grafiskt relationer mellan aktörer och användningsfall i ett system Varför användningsfallsdiagram? Ger bra (konceptuella) beskrivningar av systemets funktionalitet och dess aktörer Intuitiva, vilket bla gör det enkelt att kommunicera med tänkta användare eller beställare Systematiskt sätt att ett systems funktionalitet och dess aktörer Vilket språk används i användningsfallsbeskrivningar? Jo, kundens eller domänens språkbruk är att föredra previous next 3 Användningsfallsdiagram OCTOPUS Awad 2-4, s 21 UML previous next 4 Björn Eiderbäck

3 Systemomgivningsdiagram Vad? Användningsfall hjälper till att beskriva funktionaliteten för systemet Denna information kan användas för att skapa ett systemomgivningsdiagram, dvs en strukturerad översikt av systemets omgivning Varför? Ger en bild av aktörer och hur systemet är relaterat till dem AWAD f 3-7 i UML framgår systemkontexten direkt i användningfallsdiagrammen (se OH-4) previous next 5 Systemarkitektur Systemarkitekturen behandlar Hårdvara Mjukvara Man kan utveckla båda tillsammans men det brukar bli onödigt komplicerat och bla därför brukar dessa utvecklas separat normalt designas hårdvaran först hårdvaran "drivs" ofta av krav som kostnad och dom olika delarnas energiförbrukning mjukvaran påverkar bara hårdvaran om det visar sig att det inte går att uppfylla givna krav med aktuell hårdvara I OCTOPUS inkapslas hårdvaran med hjälp av så kallade hårdvaruwrappers previous next 6 Björn Eiderbäck

4 Modulärisering Problem Ett system är alldeles för komplext för att hanteras som en (monolitisk) enhet Om vi behandlar systemet som en enhet får vi problem med analys, design, underhåll, anpassning, osv Om systemet är stort och flera utvecklare deltar i systemets utveckling blir det hela inte effektivt... Lösning Dela upp systemet på mindre moduler previous next 7 Uppdelning på delsystem Det är önskvärt att tidigt dela upp systemet på delsystem problemet kan vara att uppdelningen av problemrymden inte i tidigt skede kan delas upp i disjunkta mängder och därför leder till att samma problem löses i flera delsystem försök därför att dela upp systemet så att dom olika delsystemen baseras på olika problemrymder AWAD f 4-3, f4-4, f4-5 previous next 8 Björn Eiderbäck

5 UML och delsystem Paket (med access och import) previous next 9 Inkrementell utveckling Problem Vi kan vanligen inte konstruera ett system enligt en linjär vattenfallsmetod Lösning Utveckla systemet inkrementellt där olika delar av systemutvecklingen påverkar varandra Använd en metod al la Boehms spiralmodell och/eller kanske Becks extreme Programming previous next 10 Björn Eiderbäck

6 Delsystem och gränssnitt AWAD f 4-7 UML Delsystem och gränssnitt previous next 11 Exempel: SLT AWAD 4.6 f 4-8 till f4-10, t4-1, t4-2 previous next 12 Björn Eiderbäck

7 Analysfas Vad är analys? I analysen undersöker vi systemets krav och försöker att omforma och strukturera dem Varför analys? Vi vill få en mer precis förståelse av kraven för att åstadkomma en beskrivning som är enkel att underhålla och hjälper oss att skapa en struktur för hela systemet Ingen kristallklar beskrivning detta heller! Vad skiljer analys från (nästa steg) design och implementation? (Efter RUP) I design måste vi, till skillnad från i analys, forma systemet så att det lever upp till alla krav i form av kodkomponenter, ta hänsyn till prestanda- och distributionskrav, visa hur systemet skall optimeras för att klara av kraven, osv. previous next Vilket språk används? RUP Jo, utvecklarens därför kan vi införa mer formella beskrivningar och därmed får vi möjlighet att i mer detalj resonera om systemet OCTOPUS Jo, domänens troligen därför att hjälpa till att hålla det hela på en abstrakt nivå, ha bra (och naturlig/enkel) spårbarhet och undvika att olika delsystem använder olika namn för samma objekt previous next 14 Björn Eiderbäck

8 ... Speciella problem/frågeställningar Vilken precision har beskrivningarna? Dom skall vara på en konceptuell översiktlig nivå, där tex bara viktiga attribut och metoder visas i klassdiagrammen. I huvudsak används klassdiagram och avsikten är mer att förstå systemet och ge en övergripande struktur än att beskriva hur det skall implementeras Hur omfattande är analysen? 1:5-regeln som säger att analysen är en femtedel så omfattande som designen. Jacobson, Booch och Rumbaugh"The Software Development Process" sidan 177. previous next 15 Från användningsfall till analys Det finns många olika strategier för att hitta klasser, objekt, associationer och andra relationer i analysfasen tex kan man titta på substantiv, verb och adjektiv i kravspecifikationen RUP och även OCTOPUS förordar en användningsfallcentrerad utgångspunkt via användningsfallen hittar vi aktörerna och viktig (yttre) funktionalitet kandidater till andra objekt, attribut och relationer genom att studera kraven vi kan sedan också studera scenarier, konstruera samarbetsdiagram och sekvensdiagram för att se om vi missat några objekt, relationer eller funktionalitet fast med användningsfallen har vi identifierat dom yttre ramarna Spårbarhet En analysmodell av en användningsfallsmodell skall kunna spåras genom att lämpligt dokument upprättas previous next 16 Björn Eiderbäck

9 En jämförelse mellan användningsfall och analys, enligt RUP Användningsfallsmodell Använd kundens språk Extern vy av systemet Struktureras mha användningsfall: ger struktur till den externa vyn Används primärt som kontrakt mellan kund och utvecklare Kan innehålla redundans, inkonsekventa delar osv bland kraven Fångar funktionaliteten för systemet Definierar användningsfall som analyseras vidare i analysmodellen Analysmodell Använd utvecklarens språk Intern vy av systemet Struktureras mha stereotypiska klasser: ger struktur till den interna vyn Används primärt av utvecklare för att förstå hur systemet skall formas Skall inte innehålla redundans, inkonsekventa delar osv bland kraven Ger en skiss över hur funktionaliteten skall realiseras (fungerar också som ett första designsteg) Definierar realisering av användningsfallen previous next 17 Samarbetsdiagram Då vi har identifierat objekt så kan vi konstruera samarbetsdiagram för att beskriva dom meddelanden eller relationer som olika objekt har sinsemellan Samarbetsdiagram finns på olika precisionsnivå Vissa beskriver bara objekt och stimuli som kan utbytas mellan dem ungefär händelseflödesdiagram Andra är mer av klassdiagram med roller och associationer Ytterligare andra beskriver också scenarier, iterationer och liknande previous next 18 Björn Eiderbäck

10 Objektmodeller Vad? en objektmodell beskriver objekt och deras relationer allt med en egen identitet är ett potentiellt objekt men för att komma med i analysens objektmodell måste det ha en meningsfull relation till problemet Består av klassdiagram, objektdiagram och textuella beskrivningar Syfte? Att beskriva systemets övergripande arkitektur samt viktiga objekt och deras relationer previous next 19 Objekt, klasser och klassbeskrivningar Grundläggande är klasser med attribut och operationer För att förtydliga kan vi använda stereotyper eller dela in klassrektangeln i flera delar previous next 20 Björn Eiderbäck

11 ... objekt (dvs instanser av klasser) previous next templates previous next 22 Björn Eiderbäck

12 Generalisering previous next diskriminatorer previous next 24 Björn Eiderbäck

13 Aggregering och komposition Speciell typ av association med "hela-del-av"-relation Aggregering Ett objekt består av andra (mer eller mindre fristående) objekt Komposition Som aggregering fast objekten hårdare knutna till "helheten" Om objektet som består av delarna försvinner så försvinner också delarna Exempel OH-30, 31, 33 och 35 nedan previous next 25 Attribut och associationer Attribut används för att beskriva ett objekts egenskaper Associationer används för att modellera relationer mellan objekt Beroende av vilken typ av nivå (detalj, analys, implementation) kan vi antingen utelämna attribut eller kanske ge dom mer detalj i form av typ och hur dom är åtkomliga Associationer kan ha namn, riktning, arritet och rollnamn associationer kan också gå mellan fler än två objekt till en association kan också knytas ett så kallad associativ klass (tidigare också kallat länkattribut) används då en relation också innehåller information och det inte är naturligt att knyta den till vare sig det ena eller andra associerade objektet ibland kan också en association vara kvalificerad a la uppslagsbok där varje beskrivning associeras via uppslagsordet previous next 26 Björn Eiderbäck

14 ...exempel: olika detaljnivå... previous next 27...exempel: association, arritet och rollnamn... previous next 28 Björn Eiderbäck

15 ...exempel: associativ klass, riktning, notation mm... previous next 29...exempel: aggregering, komposition, mm... previous next 30 Björn Eiderbäck

16 ...exempel: kvalificerade associationer... previous next 31...exempel: tenär association... previous next 32 Björn Eiderbäck

17 ...exempel: olika sätt att visa komposition... previous next 33...exempel: länkar... previous next 34 Björn Eiderbäck

18 ...exempel: härledda attribut och associationer samt constraints... previous next 35 Gränssnitt previous next 36 Björn Eiderbäck

19 Dela upp klassdiagram på olika delar För att hantera klassdiagram så kan vi både dela upp diagram i olika delar samt beskriva olika objekt med olika precision i olika diagram AWAD f 5-10 till f5-13 previous next 37 Iterera och kontrollera objektmodellen Det är viktigt att som vi tidigare sett jobba enligt en iterativ modell, där dom olika stegen fram och tillbaks påverkar varandra men också kontrolleras mot varandra Genom att systematisk gå igenom användningsfallen och fundera över hur objektmodellen skall utföra ett visst användningsfall så kan vi hitta eventuella brister Följande problem kan uppstå (Awad s 71) problem med att se hur ett viss användningsfall skall hanteras eller vilket ansvar dom olika objekten skall ha kan vara en indikation på saknade associationer eller felbenämnda abstraktioner om deltagande objekt inte har några relationer tyder det på att associationer saknas om objekten inte vet hur dom skall reagera så så tyder detta på saknade attribut eller associationer previous next 38 Björn Eiderbäck

20 Funktionell modell Vad? Den funktionella modellen visar mer i detalj vad som skall hända Varför? Vi behöver ibland ge en mer detaljerad beskrivning av tex en algoritm Hur? (OCTOPUS) påminner om användningsfallsbeskrivningar (lakan) fast oftast på en mer detaljerad bseksrivningsnivå Funktionella modellens roll i nyare metoder baserade på UML I nyare modelleringsmetoder, tex RUP, har den funktionella modellen försvunnit anledningen är bland annat att den inte riktigt är objektorienterad, känts lite påklistrad och delvis överlappas av andra beskrivningssätt överlappar delvis med användningsfall, tillståndsdiagram, händelsediagram och aktivitetsdiagram previous next 39 Beskrivning av operationer AWAD s previous next 40 Björn Eiderbäck