Föreläsning 8 2EMHNWRULHQWHUDG5HDOWLGVSURJUDPPHULQJ UML O2P 2000

Transkript

1 2EMHNWRULHQWHUDG5HDOWLGVSURJUDPPHULQJ UML och lite mer om OOA (och OOD) - Översikt grundläggande diagram - Kravanalys användningsfall samarbetsdiagram sekvensdiagram meddelandestereotyper tillståndsdiagram - Analysfas Hitta objekt och klasser Identifiera relationer och attribut - Analysera tillstånd och händelser Föreläsning 8 Unified Software Development Process (eller Rational Unified Process, RUP) - Use cases->analys->design->implementation - Stereotyper entity boundary control previous next UML Diagram för statiska beskrivningar Klasser, objekt och attribut Relationer Diagram för att beskriva beteende och informationsutbyte Användningsfall Samarbetsdiagram Sekvensdiagram Tillståndsdiagram Aktivitetsdiagram Tidsdiagram en diagramtyp, föreslagen som UML-diagram, vars avsikt är att tydliggöra tillståndsförändringar som svarar mot händelser där tidsperpektivet är mer framträdande än i tex sekvensdiagram previous next 2 Björn Eiderbäck

2 Realtidssystem och UML Vad är speciellt? I realtidssystem är det viktigt att ta hänsyn till tidens påverkan av systemet, vi måste tex genomföra en viss operation inom och/eller före en viss tid det kan vara direkt fel om en operation inte utförs i tid: hårt realtidssystem det är kanske inte så viktigt att en operation utförs i tid men det är en QOS och i medeltal måste operationerna troligen utföras inom givna tider: mjukt realtidssystem. Ett system kan också kombinera hårda och mjuka krav, med tex visst idealt krav och ett annat definitivt krav (hårt): ett system med "firm" deadlines I ett realtidsystem har vi också olika typer av meddelanden (som vi kanske inte har i ett icke realtidssystem) asynkrona, synkrona, blockerande, balking, tidsbestämda osv periodiska respektive icke- periodiska som kommer i skurar previous next 3 Vilka diagram använder vi? Vi använder dom vanliga diagrammen och kanske dom för UML föreslagna tidsdiagrammen Diagrammen brukar dock bli en aningen mer komplicerade då bla olika former av meddelanden, restriktioner (mha OCL) och mer speciella diagramkonstruktioner används I OCTOPUS (och andra metoder) kompletteras också diagrammen med textuella beskrivningar och tabeller som tex beskriver händelsernas signifikans, osv previous next 4 Björn Eiderbäck

3 Kravanalys: Översikt Indata Kravspecifikation Affärsmodell Intervjuver med kunder, slutanvändare, domänexperter Utdata Användningsfallsmodeller Översiktsbeskrivningar och beskrivande dokument Diagram Gloslista (updaterade kravspecar) Aktiviteter Hitta aktörer Sammanställ gloslista Hitta användningsfall Beskriv användningsfall Iterera Granska previous next 5 Kravanalys (med utgångspunkt från användningsfall) Börja med användningsfallsdiagram, man kan göra på tex något av följande sätt 1. Gör en lista över systemets primära funktionalitet, identifiera sen aktörer och därefter scenarier för varje användningsfall 2. Identifiera aktörer samt dom meddelanden dom skickar eller tar emot (scenarier), och gruppera det hela i användningsfall 3. Börja med att konstruera scenarier, identifiera aktörerna som deltar i dem och skapa därefter användningsfall från detta Vissa människor föredrar att tänka i mer abstrakta termer då systemet börjar utformas men dom flesta brukar föredra att börja med scenarier previous next 6 Björn Eiderbäck

4 diskutera med beställare Då vi analyserar kraven kan vi fråga beställaren följande: Vad är systemets primära funktionalitet? Vad är dom sekundära funktionerna i systemet? Varför byggs systemet? Vad ersätter det och varför? För att få hjälp att identifiera Rollerna aktörerna spelar i varje scenarie Nödvändig interaktion som behövs för att utföra ett visst scenarie Nödvändig sekvens av händelser och data för att realisera systemet Variationer för scenariet (andra relaterade scenarier) previous next 7 Exempel 1: narkos (med andningshjälp) Användningsfall för en ett narkossystem Fyra aktörer (som synes inte nödvändigtvis människor) och relationer till användningsfall har identifierats D s 53 previous next 8 Björn Eiderbäck

5 Exempel 2: flygtrafikkontroll Användningsfall för en flygtrafikkontroll Sex aktörer och relationer till användningsfall har identifierats Vidare har relationer mellan användningsfall identifierats D s 52 previous next 9 Relationer mellan användningsfall Aktörer associeras till användningsfall men som vi såg i det sista exemplet kan relationer mellan olika användningsfall också finnas och beskrivas Vi kan tex utvidga (ärva) ett användningsfall eller inkludera ett annat användningsfall previous next 10 Björn Eiderbäck

6 previous next 11 previous next 12 Björn Eiderbäck

7 previous next 13 Restriktioner D s 57 previous next 14 Björn Eiderbäck

8 Exempel: relationer D s 58 previous next 15 Beskrivning av förlopp Scenarier Ett scenarie är en textuell beskrivning av hur ett användningsfall genomförs Dom flesta användningsfall har ett "grundscenarie" som beskriver hur det hela går till om allt går bra. Andra användningsfall kan hantera dom exceptionella situationerna Sekvensdiagram Beskriver hur en sekvens av hur olika objekt skickar meddelanden mellan varandra previous next 16 Björn Eiderbäck

9 Sekvensdiagram previous next 17 previous next 18 Björn Eiderbäck

10 Exampel: Sekvensdiagram D s 63 previous next 19 Meddelanden och meddelandetyper i UML D s 69 previous next 20 Björn Eiderbäck

11 Sekvensdiagram och olika meddelandetyper D s 72 previous next 21 Tillståndsdiagram och användningsfall För att mer detaljerat beskriva vad som skall hända i ett visst användningsfall kan vi utnyttja tillståndsdiagram D s 73 previous next 22 Björn Eiderbäck

12 Hur identifierar vi användningsfall? På OH 5-7 ovan diskuterade vi om hur användningsfall konstrueras Vi kan också som i OCTOPUS klassificera aktörer aktiv/passiv klient/icke klient primär/sekundär och fundera över vad är huvuduppgifterna? när kan dess uppgifter utföras? vilka är undantagen? vad är effekten av att utföra uppgiften? vilka är tidskraven? previous next 23 Exempel: EKG Vi har identifierat fem aktörer och relationer mellan användningsfallen speciellt har extension points använts D s 75 previous next 24 Björn Eiderbäck

13 Relatera användningsfall till objektmodell Användningsfall realiseras i analysen av objektmodeller D s 26, 82 previous next 25 Hur hittas objekt? Det finns många strategier för att söka objekt I stora delar brukar man använda brainstorming-sessioner där man i grupper med hjälp av CRC-kort försöker identifiera objekt, ansvar och relationer En vanlig strategi är att stryka under substantiv i kravspecen/skrivna problemformuleringen Ibland kallad Wirfs-Brocks nominalfras-strategi previous next 26 Björn Eiderbäck

14 Wirfs-Brocks nominalfras-strategi Läs och förstå kravdokumentet. Målet är att hitta en modell som väldigt väl avspeglar den aktuella problemdomänen Läs igenom dokumentet igen. Titta speciellt efter nominalfraser. Skapa en preliminär lista av dessa fraser och ändra alla plural till singular Dela nominalfraserna i tre kategorier: definitivt objekt, nonsensobjekt och möjliga objekt Strunta i nonsenobjekten Diskutera "möjliga objekt" och placera vart ett av dom i någon av dom andra två kategorierna previous next 27 Exempel Vi skall bygga ett datorsystem för ett universitetsbibliotek Några krav Böcker och tidningar. Biblioteket innehåller böcker och tidningar. Det kan finnas flera kopior av en given bok. Vissa böcker kan bara lånas på korttidslån. Alla andra böcker kan lånas av en lånekortsinnehavare i tre veckor. En lånekortsinnehavare kan normalt låna sex saker samtidigt, men anställda kan låna upp till 12 saker på en gång. Endast anställda får låna tidningar. Lån. Systemet måste hålla reda på när böcker och tidningar är lånade och tillbakalämnade under reglerna som beskrevs ovan. previous next 28 Björn Eiderbäck

15 Exempel: hissar D s 85-87, 88 (kravspec + objekt, attribut + viktigaste objekt) previous next 29 Olika strategier för att hitta objekt Man kan också hitta objekt genom att identifiera källorna för aktion, "händelsekällor" och meddelanden identifiera målen för händelser osv identifiera "företeelser" i den reella världen, som gaser, tryck, kemikalier, osv identifiera fysiska enheter som sensorer, monitorer, osv viktiga koncept som bankkonton visuella element För fler exempel och andra strategier se utdelade utdraget ur Douglass avsnitt 3.3. previous next 30 Björn Eiderbäck

16 Relationer och associationer Enkelt klassdiagram D s 35 previous next 31 Relationer mellan klasser, multiplicitet, aggregat D s 36 previous next 32 Björn Eiderbäck

17 Exempel på klassdiagram med relationer D s 37 previous next 33 Beroenden <<bind>> D s 42 previous next 34 Björn Eiderbäck

18 Constraints D s 44 previous next 35 Stereotyper och ikoner D s 46 previous next 36 Björn Eiderbäck

19 Dynamisk modell (OCTOPUS) En översikt av dom olika delarna idag. Mer praktisk, exemplifierad och fördjupad beskrivning sker vid föreläsning 11 då vi går igenom ett stort exempel I den dynamiska modellen beskriver vi operationer och tar hänsyn till realtids och reaktiva aspekter Vi beskriver tex när operationer sker och hur lång tid dom får ta I OCTOPUS utförs följande process: analys av händelser händelselistor, gruppering av händelser och "händelselakan" analys av tillstånd parallella tillståndsdiagram och tabeller som beskriver agerande vidare analys av händelser och tillstånd signifikanstabeller och sammansatta händelser validering av den dynamiska modellen scenarior för komplexa operationer previous next 37 Analysera händelser Logiska inmatningshändelser vi försöker hitta dom händelser som kan inträffa i systemet vi fokuserar på logiska händelser av typen rensa skärmen och inte på mer primitiva som speciell tangent nertryckt Identifiera likheter mellan händelser och gruppera dem Skapa dokument som beskriver händelserna previous next 38 Björn Eiderbäck

20 Analysera tillstånd Från kunskapen då vi analyserade händelserna, "operationslakana" och den fysiska omgivningen försöker vi identifiera objektens tillstånd och övergångar se tex Awad figur 5-20, s 83 Efter att tillståndsdiagrammen identifierats ser vi på hur dom är nästlade och vad som sker parallellt resultatet är flera "parallella" tillståndsdiagram Vi skapar tabeller över tillståndsdiagram, tillstånd och relationer till klasser i objektmodellen se Awad tabell 5-3, s 84 previous next 39 action tables Vi beskriver också tillståndsdiagrammen med hjälp av "action tables" som visar vilka aktiviteter som skall ske vid ingång, utgång, vid speciella händelser eller hela tiden i ett visst tillstånd se Awad tabell 5-4, s 85 jämför UML:s enter-, do- och exithändelser Observera att det också finns ett "collective other state" som beskriver vad som ska ske vid vissa händelser som inte är beskrivna i tillståndsdiagrammet previous next 40 Björn Eiderbäck

21 Analysera signifikans för olika händelser Vi analyserar händelser och undersöker deras signifikans i förhållande till systemets totala tillstånd Vi utgår från dom elementära tillstånden och klassificerar varje händelse i förhållande till det aktuella tillståndet som kritisk viktig ignorerad neutral Denna tabell kan användas för att se vilka kombinationer av tillstånd och händelser som är mer kritiska än andra previous next 41 Analysera vilka händelser som kan slås ihop I vissa fall kan också två eller flera händelser ersättas av bara en händelse se Awad figur 5-21 s 87 Vi tittar på signifikansen och till vilka olika tillstånd dom olika händelserna leder vi kombinerar detta resultat med en signifikansanalys, genom att multiplicera ihop händelser, och ser om händelserna kan kan kombineras Fördelen är att vi får färre händelser att hantera Nackdelen är att betydelsen av en händelse bara är given i kombination med ett visst tillstånd previous next 42 Björn Eiderbäck

22 Konstruera mer detaljerade scenarier Vi konstruerar detaljerade scenarier (som sekvensdiagram) Awad figur 5-22 sid 89 Fungerar som verifiering av mekanismerna, med avseende på beteende, som är framtagna i analysen Bra som diskussionsunderlag mellan designer men även med kunder Dessa diagram konstrueras ofta tidigt i den dynamiska modelleringen används som hjälp för att ta fram information som behövs i andra delar av den dynamiska modellen previous next 43 Hårdvaruwrapper Vi "wrappar" in all hårdvara i klasser som som från tillämpningens synvinkel erbjuder all service, dvs den döljer hårdvaru- och andra detaljer Awad figur 5-23 och 5-24 sid 91 objektmodell, funktionell modell och dynamisk modell skapas också för hårdvaruwrappers previous next 44 Björn Eiderbäck

23 RUP, analys RUP processen är baserad på användningsfall I analysen försöker vi som vanligt bena ut vad systemet ska göra Stereotyper entity boundary control Genom att jobba med dessa stereotyper så blir analysens konceptuella karaktär tydlig previous next 45 Exempel: klassdiagram Ett användningsfall "realiseras" med hjälp av ett klassdiagram RUP s 187 previous next 46 Björn Eiderbäck

24 Exempel: samarbetsdiagram Vi undersöker systemet vidare genom att bland annat identifiera samarbetet mellan objekten ett samarbetsdiagram kan också kompletteras med en textuell beskrivning som mer detaljerat förklarar det hela RUP s 188 previous next 47 Större exempel: hiss previous next 48 Björn Eiderbäck

25 previous next 49 previous next 50 Björn Eiderbäck

26 previous next 51 previous next 52 Björn Eiderbäck

27 previous next 53 previous next 54 Björn Eiderbäck

28 D s 103 previous next 55 D s 110 previous next 56 Björn Eiderbäck