Skansholm: Kapitel 4
Se även
UML är inte ett programspråk utan en samling notationer för att beskriva olika aspekter av program och de uppgifter vi vill lösa.
UML konstruerades av Grady Booch, Ivar Jacobson och James Rumbaugh. De tre författarna hade tidigare föreslagit var sitt system. UML är baserat på dessa system.
Man kan se UML som ett försök att strama upp informella konstruktionsskisser. Det beskriver olika typer av diagram för olika situationer. Det liknar mera en verktygslåda än ett verktyg.
UML är stort. Vi har (om jag räknar rätt) 13 typer av diagram. Systemet beskrivs i ett antal läroböcker och manualer. Wikipediaartikeln för UML har ett UML-diagram över de olika typerna av UML-diagram!
Vi kommer att titta på diagram för klasstrukturer och användningsfall (use cases).
Nedan listar jag exempel på några andra typer av UML-diagram. Jag kommer inte att diskutera dessa diagram ytterligare.
Här kom den svenska termen först: användningsfall.
Begreppet uppfannas av Ivar Jacobson 1986. Idén var att beskriva systemkrav i termer av systemets önskade interaktion.
Det är lätt att se flera poänger med den här idén. Vi uttrycker problemet i termer som är förståeliga för kunden, men tillräckligt konkreta för att fungera som guide vid utveckling. Dessutom kan de testas.
På så sätt löser vi delvis det problem som beskrevs i avsnittet om vattenfallsmodellen—use cases ger oss ett sätt att kommunicera problemformuleringen mellan kunder och utvecklare.
Enstaka användningsfall presenteras ofta i textform, utan någon särskild notation. Till exempel:
(kassören repeterar detta steg så länge det finns varor)
Vi kan tänka oss många variationer av scenariot ovan, till exempel:
Ett use-case diagram visar olika användningsfall (ritas som ovaler) och hur de relaterar till aktörer (ritas som streckgubbar).
Exempel 1:
I detta fall har vi tre aktörer; kund, betalningsprocessor samt customer support.
Exempel 2:
Student:
Om ett användningsfall inkluderar ett annat uttrycks detta med en pil mellan användningsfall (i exemplet ovan måste poängtalet kontrolleras vid ansökan om slutbetyg).
är en formalisering av de diagram som vi alla spontant ritar när vi vill resonera om klasser och samband mellan dem, tex att en klass ärver av en annan.
Huvudanvändningar
Ofta utelämnas attribut och metoder för att spara plats eller för att göra modellen tydligare. Å andra sidan definierar UML notation för att beskriva klassen i mer detalj.
(I Java: Att en klass ärver en annan, att den ärvande klassen på nåt sätt är mera specifik)
Noll eller flera böcker associerade till ett visst bibliotek
Associationen kan tillåta både
Ettan vid klassen Bibliotek betyder att varje bok tillhör exakt ett
bibliotek. Vid klassen Bok skriver vi 0..* för att tala om att ett
biblitek har noll eller fler böcker.
Låt oss betrakta ett mera komplext exempel:
Förklaring:
Ett fordon är antingen en bil eller en cykel.
Varje cykel har en associerad person (cyklisten).
Pilen anger att vi kan gå från cykel till cyklist, men ej tvärtom.
Den svarta pilen vid "äger" anger hur associationen ska läsas. I detta fall har vi alltså två namn på relationen.
"Två klasser har nåt att göra med varandra"
Klassen Almanacka använder klassen Datum.
Om inget annat anges är en association (relation) många till många. Bra eller dåligt?
Det kanske är en bra idé att utgå från den mest generella relationen och föra in information om riktning och multiplicitet när vi lär oss mer om problemställningen.
Det visar sig ofta att man vill öka multiplicitet (en person kan ha flera telefonnummer eller adresser, tex).
Det visar sig ofta att man vill kunna gå åt båda hållen.
Varje cykel tillhör en unik ägare.
class Cykel {
private Person ägare;
public Cykel(Person ägare) {
this.ägare = ägare;
...
}
...
}
Exempel: "Alla personer har noll eller en cykel, Varje cykel tillhör en unik ägare."
Ett sätt att se till att relationen alltid har önskad form.
class Person {
private Cykel cykel;
public void nyCykel (Cykel c) {
if (cykel != null) {
"felmeddelande";
}
else {
cykel = c;
}
}
...
}
class Cykel {
private Person ägare;
public Cykel(Person ägare) {
this.ägare = ägare;
ägare.nyCykel(this);
...
}
...
}
Klassen Person definierar en metod nyCykel(). Varje gång en person
skapas anropas metoden. Notera att med denna lösning finns det inte
nåt sätt att ta bort cyklar ur systemet (utan att samtidigt ta bort
ägaren).
Med collection classes är det enkelt att implementera en relation med godtycklig multiplicitet.
class Person {
private Set<Cykel> cyklar = new HashSet<Cykel>();
public void nyCykel (Cykel c) {
cyklar.add(c);
}
...
}