Transcript Use Case - Webbkurs

UML
Unified Modeling Language
•1
UML – kort historik
 1980-talet: Många OO-metoder
 Stora skillnader inom
 Notation
 Begrepp
 Omfång
 Svåra att jämföra
 Unified Modeling Language
 enad eller likriktad
•2
UML – kort historik
 Kortfattat kan UML beskrivas så här:
 UML är ett visuellt språk för att specificera, konstruera och
dokumentera ingående delar i ett system.
 UML är ett generellt modelleringsspråk i den mening att det går
att använda för olika verksamhetsområden och för olika tekniska
plattformar.
 Historik:
 UML 2.0 – utökning som lanserades stegvis mellan 2003 och
2005
 De som mest aktivt deltog i framtagande av UML var:
 Grady Booch
 Jim Rumbaugh
 Ivar Jacobson
 Ansvaret för vidareutveckling har OMG (Object Management
Group) där vidare specifikationsarbete sker i form av en
community.
•3
UML – kort historik
 Målet är att UML ska




Kunna beskriva alla typer av system
Kunna utökas vid behov
Kunna tolkas entydigt av en maskin
Kombinera styrkorna från tidigare OO-notationer
•4
UML – kort historik
 Några egenskaper hos UML som modelleringsspråk:
 UML är ett visuellt modelleringsspråk.
 UML består av en stor uppsättning element och regler för
hur elementen kopplas samman.
 14 olika diagramtyper finns identifierade i UML 2.2,
tidigare var det 9 stycken.
 Elementen har en definierad syntax och semantik, vilket
gör att det kan kallas för ett språk.
 UML är utökningsbart
•5
Genomgång av UML
 UML är ingen metod
 Beskriver därför inte
 Arbetssteg (omfattning / ordning)
 Projektfaser
 Rollfördelning (ansvar)
 Leveransobjekt
 Övrig dokumentation
 Stödjer alla faser i mjukvaruutveckling
 Metodoberoende
•6
Elementen i UML
 Språket UML byggs upp av ett antal element och
regler för hur dessa element kopplas samman.
•7
Diagram i UML 2.2
•8
Allmän UML-notation
 En notering kan göras var som helst i ett diagram.
Antingen som en fristående notering eller kopplad till
ett element via en streckad linje.
•Note
•Note
 Använd noteringar för att:
 Förklara och informera läsaren.
 Förklara det som inte är uppenbart.
 Skriva kodfragment eller text som beskriver ett beteende
eller en begränsning.
•9
Allmän UML-notation
 Ramar (Frames) är en nyhet i UML 2.0.
 De används för att rama in grupper av samverkande
element eller för att att referera till andra sådana
grupper.
 rama in hela diagram.
 rama in delar av diagram, exempelvis sekvensdiagram.
•10
•Så här ritas en klass
•Klassnamn
•instansvariabler
•metoder
•Klass utan
•instansvariabler
•Klassnamn
•metoder
•Så här ritas en
instans
•Klass på designnivå
•Djur
•namn
•fördelseår
•hämtaNamn
•hämtaÅlder
•Klass på implementationsnivå
•Djur
•private String namn
•private int födelseår
•public String hämtaNamn()
•public int hämtaÅlder()
•:Klassnamn
•variabelnamn = värde
•11
Klassdiagram
 Klassdiagrammet är ett strukturbeskrivande diagram som
används för att visa en statisk bild över modellelement
och deras inbördes relationer.
 Klassdiagram är det mest centrala diagrammet i UML
 Visar klasserna som ingår i systemet
 Visar relationer mellan klasser (arv, aggregat, associationer)
 Beskriver systemets statiska struktur
 Vad används det till?
 Definiera vilka data som systemet ska hantera
 Definiera hur data kan modifieras
 Vad uppnås?
 Verksamhetsförståelse
 Ansvarsfördelning mellan klasser
•12
Klassdiagram
 Klassdiagram kan användas i många olika sammanhang
där strukturelement och deras relation ska modelleras.
 Kodgenerering och kodvisualisering:
 Objektorienterad kod och klassdiagram har mycket gemensamt
och historiskt sett är den kopplingen kärnan i de verktyg som
stödjer UML. Objektorienterad kod kan visualiseras med UML
och från klassdiagram kan kod genereras.
 Verksamhetsmodellering:
 Konceptuella modeller för att beskriva verksamheter är lämpliga
att beskriva i form av klassdiagram.
•13
Klassdiagram
Class
Generalization
Association
Dependency
ClassName
Interface
<<interface>>
InterfaceName
Interface
Realization
Aggregation
Composition
•14
Klassdiagram
 Klass
 Företeelse i verksamheten
 Ritas som en tredelad rektangel
 Namn, attribut och operationer skrivs ut
 Första rutan i rektangeln får inte vara tom. (Klass Namn)
Person
-name : String
-age : int
 Attribut
 Egenskap för en klass
 Har en datatyp
 Värden sätts i objekt av klassen
 Exempel: sträng, heltal
 Namnet bör spegla vilka data som lagras
 Synlighet (prefix före namn):
 Public (+)
 Private (-)
 Protected (#)
•15
Klassdiagram
 Operation
 Kan vara
 Kommando – ändrar objektets tillstånd
 Fråga – returnerar data om tillståndet (get)
 Kan ha en eller flera parametrar med varsin datatyp
•VisibilityForOperationsClass
+ publicOperation()
- privateOperation()
# protectedOperation()
 Objekt
 Förekomst av en klass
person : Person
name : String = Alex Jones
age : int = 25
•16
Association
 Association (A har/använder B)
 Visar att klasserna känner till varandra
 Statisk relation mellan två eller fler klasser
 Rak linje innebär obestämd eller dubbelriktad association.
Innebörd bestäms i projektet.
 Enkelriktad association ritas som en pil
 Associationens namn bör spegla relationens syfte
 Placeras nära linjen
 Inte obligatoriskt
 Verb
 Roll




Visar hur en klass uppfattas av en annan klass
Kan namnges (substantiv)
Varje association har två roller (en för varje riktning)
Skriv namnet nära klassen som rollen avser (på en
associationslinje)
 Exempel: Ägare, Kund, Lärare
•17
Ex Roller
Person
Bil
äger
1
Ägare
*
Egendom
Person
Mor
1
1
Far
Föräldraskap
•18
Association
•ClassA
•ClassC
•ClassE
•ClassG
•ClassI
•ClassK
•ClassB
•ClassD
•ClassF
•ClassH
•ClassJ
•ClassL
 Exempel på diverse relationer mellan klasser





ClassA är beroende av ClassB.
ClassC har en ospecificerad koppling till ClassD.
ClassE känner till ClassF
Båda klasserna känner till varandra.
Aggregat används för att visa på en struktur med “whole/part”-relation. ClassJ är
en del av klassen ClassI
 Påminner om aggregat men vid komposition kan inte ClassL existera om inte ClassK
finns.
•19
Association
 Multiplicitet
 Visar hur många objekt av en klass som kan kopplas ihop
med objekt av en annan klass
 Anges vid associationslinje
Employee
Multiplicitet
 Asterix (*) = godtyckligt många
 <min>..<max> = intervall
1
 Exempel:





*
0..*
2, 3, 7
1..7
4..*
1..2
Computer
•20
Aggregat
 Aggregering (är en del av)
 Visar att ett modellelement (en klass) är en del av ett
annat modellelement (en annan klass)
 Starkare form än association mellan klasser
 Samma notationsmöjligheter (multiplicitet, roller, etc)
 Visas som en streck med diamant
Work Team
1
1..10
-member
Person
•21
Aggregat
 Ifylld diamant (komposition) avser att ett objekt av
en klass kan endast existera som del av ett objekt av
en annan klass. Förstörs huvudobjektet förstörs även
delarna (composition)
1
1
Chassi
Bil
1
1
Motor
1
4
Hjul
•22
Aggregat
 Exempel på komposition
Listbox
*
Window
1
*
Button
*
Menue
•23
Generalisering /Specialisering (Arv)
 Specialisering /Generalisering (är)
 Visar att en klass ärver egenskaper och beteenden från en
annan klass
Animal
 Specialfall av association
 Abstrakta klasser: saknar instanser
Mammal
Fordon
Cat
Bil
Horse
Buss
Grundregel för pilar: Den som pekar är den som utför en aktiv handling.
•24
Klassdiagram
 Exempel
Hinge
Door
-Passage
Room
-size
*
*
-isOpen : bool
-color : String
+open()
+close()
+isOpen()
+getColor()
+setColor(in color : String)
*
1
-
1
Lock
-isLocked : bool
*
+lock()
+unlock()
+isLocked()
Glass Door
-isBreakable : bool
+isBreakable() : bool
•25
Klassdiagram
 Mål / Ideal
 Visar hur användarna tänker kring sin verksamhet
 Beskriver användarnas språk
(jämför med begreppsmodellering)
 Visar hur centrala begrepp hänger ihop
•26
Klassdiagram
 Objektdiagram




Instanciering av ett klassdiagram
Visar en ögonblicksbild över tillståndet i ett system
Kan klargöra komplicerade klasstrukturer
Behöver inte alltid tas fram
•27
Tillståndsdiagram
 Vad är det?
 Beskriver totala dynamiken för en klass (beteende)
 Behövs inte för enkla klasser
 Händelseorienterat
 Vad används det till?
 Hitta alla tillstånd för objekt av klassen
 Beskriva klassens levnadscykel över samtliga
användningsfall
 Identifiera alla giltiga övergångar mellan tillstånd
 Vad uppnås?
 Hantering av komplicerad dynamik
•28
Tillståndsdiagram
 Tillståndet hos bok objektet kan ändras när en kopia av
boken lånas.
 Tillståndet kan ändras från att vara utlåningsbar (det
finns en kopia i biblioteket) till ej utlåningsbar (alla
kopiorna är utlånade eller reserverade). Vi kan visa detta
med ett tillståndsdiagram.
•29
Tillståndsdiagram
•30
Ex. tillståndsdiagram - kontantuttag
sätt in kort
Kort insatt
begär kod
Väntan på kod
förkasta
betalning
mata in kod
Kod inmatad
avbryt
Belopp godkänt
Kod accepterad
godkänn belopp
Väntan på belopp
Belopp valt
välj belopp
Belopp ej godkänt
•31
Ex. tillståndsdiagram - telefon
Active
TimeOut
lift receiver / getDialTone
DialTone
do/ playmessage
dial digit(n)[incomplete]
do/ playdial tone
dial digit(n)
Dialing
dial digit(n)[invalid]
Idle
Invalid
do/ playmessage
Connecting
Pinned
Busy
busy
connected
caller hangsup / disconnect
do/ playbusytone
Talking
Ringing
do/ playringingtone
•32
Övning klassdiagram
 Böcker och tidskrifter
 Biblioteket innehåller böcker och tidskrifter.
 Det kan finnas flera kopior av samma bok.
 Endast biblioteksanställda får låna tidskrifter.
•33
Lösningsförslag
•34
Use Case
 Use Case är användarfall som





visar systemet ur användarnas synvinkel
beskriver en bestämd uppgift som görs i ett system
består av ett diagram och en textbeskrivning
ska skapa ett mervärde för systemets aktörer
lätt modell att komma igång med
 Use Case-Diagrammet
 visar relationen mellan olika
användningsfall
 visar hur aktörerna använder användningsfall
•35
Use Case
 Vad används det till?




Hitta systemets användare
Identifiera användarnas krav
Definiera systemets funktioner
Identifiera delsystem
•36
Use Case
•37
Use Case
Notation:
•Primär aktör
Informationsflöde
(dubbelriktat)
•Sekundär aktör
Informationsflöde
(enkelriktat)
<Actor>
<Actor>
Funktionsnamn
•Ett användningsfall
(Use Case)
•Include
Nyttjande av användningsfallet
Systemets namn
•Systemet
•Extends
Utökning av användningsfall
•38
Use Case
 Aktör
 Primär aktör i förhållande till systemet
 Motsvarar en roll som användaren spelar
 En användare kan ha många roller
 Flera användare kan ha samma roll




<Actor>
Använder systemet direkt
Erhåller värden från systemet
Behöver inte vara en person
Exempel: Kund, Tidrapporteringssystem
 Sekundär aktör
 Underhåller eller övervakar systemet
 Gör systemet tillgängligt för primära aktörer
 Exempel: Lagerpersonal, systemklocka
<Actor>
•39
Use Case
 Användningsfall (Use Case)
 Ett användningsfall är en specificerad uppgift en aktör kan
utföra i systemet
 Uppbyggt av ett antal scenarier
 Scenario: dialog mellan aktör och systemet
 Normalfall / undantag
 Tillsammans utgör alla användningsfall systemets
funktionalitet
 System
 Definierar omfånget (gränsen) för systemet
 Kan vara vilken sorts system som helst
 Exempel: Lagerhanteringssystem
•40
Use Case
 Informationsflöde (dubbelriktat)
 En ömsesidig påverkan mellan en aktör och ett
användningsfall (relation)
 Funktionen är beroende av de data som användaren matar
in
 Exempel: Aktörens val avgör vilka skärmbilder som visas
och vilken information som presenteras, därefter gör
aktören nya val, etc.
 Informationsflöde (enkelriktat)
 Informationsflöde från ett användningsfall till en aktör
(eller omvänt)
 Symbolen används för att visa att informationen är
enkelriktad
 Exempel: Rapport skrivs ut till kund (info)
•41
Use Case
•A include B
 Beroende (include)
 Ett including användningsfall inkluderar
ett annat användningsfall
 Beroende (extend)
•A extend B
 Används för att utvidga ett
användningsfall med innehållet i ett
annat användningsfall
 Notationen används ofta för att
beskriva undantag och felhantering i
modellen
•42
Use Case-diagram
Varuleverans (system)
Uses
Beräkna kostnad
Fakturering
Extends
Registrera order
Kund
Plocka ihop
beställning
Registrera
förstagångsanvändare
Leverera varor
Budfirma
Lagerarbetare
Uses kan ses i gamla diagram, i de nyare heter relationen <<include>>
•43
Use Case-diagram
•44
Use Case-diagram
 Realiseras av systemets klasser
 Genom samarbete
 Realiseringen visas i övriga UML-diagram
 Hur användningsfall ska dokumenteras i detalj
beskrivs inte i UML
•45
Use Case-diagram
 Fallgropar?
 Göra ostrukturerade / tvetydiga textbeskrivningar
 Klassiska fällor: synonymer, homonymer, syftningsfel
 För många användningsfall
 Beskriva användningsfall som inte levererar mervärde till
någon aktör
•46
Övning 1 - Use Case
 Vid en bensinstation kan man tanka sin bil och betala
i en automat, antingen med kontokort eller kontant.
 Vilka aktörer och användningsfall kan finnas i detta
system.
•47
Övning 2 - Use Case
 Vilka scenarier kan du hitta för systemet i övning 1?
Beskriv något av scenarierna närmare.
•48
Lösningsförslag
 Övning 1
 Aktörer: kund, bensinbolag (det datorsystem hos
bensinbolaget som kontrollerar bensinkort och
registrerar köp). Eventuellt en administratör till
bensinbolagets system.
 Användningsfall: Tankning med kontant betalning,
tankning med kontokortsbetalning. Ett eller flera
användningsfall som hanterar administration av
systemet.
•49
Lösningsförslag
Tanka med kort
Kund
Bensinbolag
Tanka kontant
Sätta bensinpris
Admin
•50
Lösningsförslag








Övning 2
Två vanliga scenarier:
En kund betalar kontant och tankar
En kund betalar med kort och tankar.
Mer ovanliga scenarier:
En kund betalar kontant och glömmer att tanka
En kund betalar med kort men har glömt sin PIN-kod
En kund vill betala kontant men automaten
accepterar inte sedeln, o.s.v.
 Det finns fler av dessa mer ovanliga scenarier
beroende på alla faktorer som kan gå fel.
•51
Lösningsförslag
 Noggrannare beskrivning av tanka med kontokort:
 En kund anländer till bensinstationen. Textfönstret i
bensinautomaten visar ”Välkommen, sätt in ditt kort”.
 Kunden sätter in sitt kort i automaten.
 Automaten läser kortet, visar ”Ange PIN-kod” i
textfönstret.
 Kunden trycker in sin kod.
 Automaten läser koden, kontrollerar kortet och koden
hos bensinbolaget och finner att de är giltiga.
 Automaten visar ”Tag ditt kort och tanka” i textfönstret.
 Kunden väljer oktantal vid bensinpumpen och tankar.
 Automaten får uppgifter om tankningen från
bensinpumpen och registrerar köpet hos Bensinbolaget.
•52
Sekvensdiagram
 Vad är det?
 Visar hur objekt samarbetar för att lösa en uppgift
 Motsvarar vanligtvis ett användningsfall
 Operationerna visas i tidsordning
 Vad används det till?
 Beskriva systemets beteende (dynamik)
 Skapa arbetsfördelning mellan klasser (ansvar)
 Identifiera saknade klasser
53
Sekvensdiagram
 Vad uppnås?
 Överblick
 Händelser
 Meddelande-flöden (mönster)
 Samarbete mellan komponenter
 Verksamhetsförståelse
 Fallgropar?
 Göra för komplicerade sekvensdiagram
•54
Sekvensdiagram
 Objekt
window
 Deltar i samarbete för att lösa
arbetsuppgift
 Klassnamnet kan skrivas ut
 Exempel: fönster : Fönster
 Livslinje för objektet (lifeline)
 Tidsaxel
 Meddelande
open()
 Skickas mellan objekten
 Metodnamn obligatoriskt
 Kan ha parametrar (inom parentes)
•55
Sekvensdiagram
 Aktivitet
recordPlayer
 Ritas som vertikal rektangel längs livslinjen
 Anges då ett objekt utför arbete i flödet
 Resultatet av ett meddelande-anrop
 Villkor
 Måste gälla för att meddelandet ska sändas
[unlocked]
open()
 Retur-meddelande
valuesOK()
 Retur tillbaka till anroparen
 Visa bara returvärde om det förtydligar
beskrivningen
•56
Sekvensdiagram
 Objektet upphör (destruktion)
 Anger att objektet slutar existera
 Görs på eget initiativ eller resultat av anrop
 Visas som ett kors längs livslinjen
close()
 Asynkront meddelande
 Anroparen väntar inte på retur
 Meddelande (vanligt anrop)
•57
Sekvensdiagram
:Klass1
:Klass2
:Klass3
1. metodnamn
2. metodnamn
3. * metodnamn
•58
Ex. Sekvensdiagram – vad händer när man klickar
på en sökknapp i ett fönster
:Användare
:Sökknapp
:KnappKommando
:Söktextruta
:Modell
:Fönster
•klick
•actionPerformed
•getText
•sökData
•visaSökresultat
•59
Ex. Sekvensdiagram -öppna dörr med en kod
Keypad
Door Control Unit
Security System
Lamp Controller
Door
key pressed(1)
key pressed(5)
key pressed(3)
key pressed(enter)
verify code(153)
code accepted()
light()
open()
•60
•61
Aktivitetsdiagram
 Aktivitetsdiagram beskriver en följd av händelser i ett system, med
hjälp av aktiviteter. Aktivitetsdiagram är en speciell form av
tillståndsdiagram, som bara (eller i huvudsak) innehåller aktiviteter.
 Aktivitetsdiagram liknar procedurella flödesdiagram, med skillnaden
att alla aktiviteter är klart länkade till objekt.
 Aktivitetsdiagram hör alltid ihop med en klass, en operation eller
ett användningsfall.
 Aktivitetsdiagram stöder sekvens- samt parallella aktiviteter.
Parallell körning representeras med ikonen Dela upp/samla ihop,
och det är inte viktigt för aktiviteter som kör parallellt i vilken
ordning de utförs (de kan köras samtidigt eller en i taget).
 Aktivitet
 En aktivitet är ett enda steg i en process. En aktivitet är ett tillstånd i
systemet med intern aktivitet och åtminstone en utgående
övergång. Aktiviteter kan också ha mer än en utgående övergång,
om de har olika villkor.
•62
Några andra typer av diagram


Samarbetsdiagram
Samarbetsdiagram visar växelverkan mellan objekt som deltar i en speciell
situation. Det här är mer eller mindre samma information som visas i
sekvensdiagram, men där läggs vikten vid hur växelverkan sker i tiden, medan
samarbetsdiagram lägger vikten vid sambanden mellan objekten och deras
topologi.


Komponentdiagram
Komponentdiagram visar programkomponenter (antingen komponentteknologier
som Kparts, CORBA-komponenter eller Java Beans eller bara delar av systemet som
är klart urskiljbara) och artefakterna de består av, som källkodsfiler,
programbibliotek eller relationsdatabastabeller.
Komponenter kan ha gränssnitt (dvs. abstrakta klasser med operationer) som
tillåter association mellan komponenter.



Utplaceringsdiagram (deployment diagram)
Utplaceringsdiagram visar komponentinstanserna vid körning och deras
associationer. De omfattar noder, som är fysiska resurser, typiskt en enskild dator.
De visar också gränssnitt och objekt (klassinstanser).
•63