GES :OOS Objektorienterad analys och design Föreläsning1och 2

GES :OOS Objektorienterad analys och design Föreläsning1och 2
Erik Perjons

Agenda Introduktion till modeller och modelleringsspråk
UML en översikt UML Klassdiagram Modelleringspraktik för klassdiagram UML Aktivitetsdiagram

Introduktion till modeller och modelleringsspråk

Verkligheten – tre nivåer
Människor utför manuella aktiviteter Människor interagerar med datorer Denna bild ska föreställa verkligheten. Notera att egentligen är det en slags modell av verkligheten, men låt oss alltså för resonemangets skull tänka oss att det är verkligheten, det vill säga företeelser som finns i verkligheten och som vi kan uppfatta med våra sinnen. Vi uppfattar att i verkligheten finns till exempel fabriker, hus, människor, datorer, datornätverk, människor som arbetar med datorer, människor som kommunicerar med andra människor, datorer som utför beräkningar eller datorer som skickar data till andra mottagande datorer. Vi kan med ett informellt, förenklat, och systemmässigt synsätt dela in denna verklighet i tre nivåer. De tre nivåerna definierar vi så här: - på den övre nivån utför människor manuella aktiviteter, - på den mellersta nivån interagerar människor med gränssnitten till olika typer av datoriserad utrustning – notera att det egentligen också är en form av manuella aktiviteter, det vill säga människor skriver ord och meningar med hjälp av tangentbordet, läser på skärmen och kanske laddar datorn med en CD-skiva, - på den undre nivån utför datoriserad utrustning automatiska aktiviteter. Datorer utför automatiserade aktiviteter

Verkligheten och modeller – tre nivåer
Verksamhetsprocesser (i aktivitetsdiagram) Domänmodell (i klassdiagram) Interaktion med datorer (i användningsfall) Nu har vi lagt till ytterligare en del, till höger i bilden. Vi kallar den delen för grafiska modeller/diagram, medan den vänstra delen benämns ”verkligheten”. Notera än en gång att är det vi ser till vänster är en slags modell av verkligheten, men för resonemangets skull ska vi alltså tänka oss att det är verkligheten. Till höger ser vi modeller eller diagram av det som finns i verkligheten. Man bruka säga att dessa modeller/diagram ska representera eller avbilda företeelser i verkligheten. Modellerna/diagrammen till höger är skapade i modelleringsspråket UML. Enligt UML:s specifikation är det olika diagram och inte modeller som vi ser till höger i bilden. Dessa diagram skapar tillsammans en modell av det vi vill representera. De olika diagrammen ger med andra olika aspekter eller perspektiv på modellen. Notera dock att olika författare har olika syn på relationen mellan modell och diagram. Hos en del författare används modell, eller snarare grafisk modell, och diagram som synonymer. Notera också att en modell behöver inte vara grafisk, den kan till exempel formuleras i textform eller som en formel. Om vi då tittar på den högra delen av bilden kan vi notera följande: - på övre nivån finns aktivitetsdiagram för att modellera verksamhetsprocesser, sekvensdiagram för att modellera kommunikation mellan människor och i klassdiagram för att modellera verksamhetsbegrepp, det vill säga de begrepp som används i verksamheten när människor kommunicerar muntligt eller genom att skicka dokument, - på mellersta nivån finns användningsfallsdiagram för att modellera interaktionen mellan människor och datorer, - på undre nivån finns aktivitetsdiagram för att modellera mjuk- och hårdvaruprocesser i datorsystem, sekvensdiagram för att modellera kommunikation inom och mellan mjukvara såväl som för hårdvara, och klassdiagram för att modellera de informationselement som används av datorer. Som vi ser kan några typer av UML-diagram användas på fler än en nivå, till exempel används klassdiagram, aktivitetsdiagram och sekvensdiagram både på den övre och nedre nivån. Interaktion mellan objekt (i sekvensdiagram) Systemmodell (i klassdiagram) Verkligheten Grafiska modeller/diagram

Vad är en grafisk modell?
- En grafisk modell är en förenklad och visualiserad beskrivning av en företeelse (oftast ett system) Vad är då en grafisk modell? En grafisk modell är en förenklad och visualiserad beskrivning av en företeelse, som oftast är ett system. Systemet kan till exempel vara en verksamhet eller ett informationssystem. Systemet kan också vara ett flygplan och de krafter som verkar på planet, eller det kan vara ett telefonväxelsystem. En grafisk modell görs alltid i ett visst syfte, till exempel kan den användas som grund för att bygga ett informationssystem eller för att ge en överblick över en organisations sätt att arbeta.

Varför använda grafiska modeller?
Grafiska modeller reducerar komplexiteten genom att abstrahera bort mindre intressanta detaljer och visualisera de viktiga egenskaperna. Grafiska modeller ger därför överblick och struktur – vilket är centralt för att analysera och förstå företeelser i verkligheten. Grafiska modeller underlättar därför kommunikation mellan människor, till exempel mellan olika intressenter (organisationsledning, systemutvecklare, användare av systemet, kunder, beställare av systemet). Grafiska modeller kan vara ett effektivt verktyg för att enas kring problem och lösningar De grafiska modellerna reducerar komplexiteten genom att abstrahera bort mindre intressanta detaljer och visualisera de viktiga egenskaperna. Grafiska modeller ger därför överblick och struktur, vilket är centralt för att analysera och förstå företeelser i verkligheten. Även relativt små system kan vara komplexa, vilket gör att modeller utvecklas och används för att förstå dessa system. Grafiska modeller underlättar också kommunikation mellan människor, till exempel mellan olika intressenter, som exempelvis kan vara organisationsledning, systemutvecklare, användare av systemet och kunder. Grafiska modeller kan vara ett effektivt verktyg för att enas kring problem och lösningar. Inom systemutveckling är det inte ovanligt att man får oprecist formulerade problem att lösa. Att skapa modeller över problemet är ett sätt att precisera problemet och att enas om en gemensam tolkning av problemet. Modeller är också ett effektivt sätt att kommunicera och diskutera alternativa lösningar på problemet.

Hur kan grafiska modeller stödja systemutveckling?
- Analysredskap – underlättar analys av en verksamhet för att identifiera problem/behov/krav - Designbeskrivningar – ritningar över systemet som ska byggas eller förändras - Valideringsinstrument – det vill säga validera systemet mot användare och uppdragsgivare med hjälp av grafiska modeller så att systemet får rätt egenskaper innan det byggs klart - Kontrakt – mellan beställare och utförare Inom systemutveckling kan grafiska modeller ha följande funktioner: De grafiska modellerna kan fungera som ett analysredskap, det vill säga de underlättar analys av en verksamhet. Det kan till exempel handla om att precisera problem och identifiera orsaker till problem. De grafiska modellerna kan också fungera som designbeskrivningar, det vill säga modellerna kan fungera som ritningar över systemet som ska byggas eller förändras. Vidare kan modellerna fungera som ett valideringsinstrument, det vill säga med hjälp av modellerna kan systemet valideras gentemot beställare och användare så att systemet får de egenskaper som beställare och användare vill att systemet ska ha. Det är också vanligt att de grafiska modellerna fungerar som ett kontrakt, eller del av ett kontrakt, mellan beställare och utförare. Modeller klargör vad som ska byggas, det vill säga modellerna fungerar som en slags kravspecifikation som utföraren lovar att bygga. När systemet är färdigutvecklat kan beställaren stämma av resultatet, det vill säga systemet, mot modellerna för att kontrollera att han eller hon fått vad som beställts.

Struktur- och beteendemodeller
Strukturella modeller / strukturdiagram specificerar statiska aspekter av systemet mer precist: vilka är objekten i systemen och hur är de relaterade - svarar på frågan: “vad finns i systemet?”. Beteendemodeller / beteendediagram Modeller kan delas in i två kategorier- strukturella modeller/strukturdiagram och beteendemodeller/beteendediagram. Strukturella modeller eller strukturdiagram specificerar de statiska aspekterna av systemet, det vill säga de statiska relationerna mellan systemets termer. Beteendemodeller eller beteendediagram specificerar dynamiska (beteendemässiga) aspekter av systemet, det vill säga de specificerar manipuleringen eller förändringen av de statiska relationerna och i vilken ordning det sker. Vad som menas med detta kommer att bli tydligare längre fram i momentet. Som vi nämnt tidigare i denna presentation så skiljer UML-specifikationen på diagram och modeller medan hos andra författare är modell och diagram synonymer. specificerar dynamiska (beteendemässiga) aspekter av systemet mer precist: hur systemet förändras (det vill säga: skapa och ta bort objekt, ändra värden hos objektens egenskaper, skapa och ta relationer mellan objekt . svarar på frågan: “hur förändras systemet?

Struktur- och beteendemodeller
Strukturella modeller/ strukturdiagram Verksamhetsprocesser (i aktivitetsdiagram) Domänmodell (i klassdiagram) Beteendemodeller/ beteendediagram Interaktion med datorer (i användningsfall) Av de diagram som vi tidigare beskrivit är det endast klassdiagrammen som är strukturdiagram, resten är beteendediagram. Interaktion mellan objekt (i sekvensdiagram) Systemmodell (i klassdiagram) Modeller/diagram

Modeller skrivs i ett språk
Begrepp i ett UML aktivitetsdiagram: aktion flöde förgrening samgående Begrepp i ett UML klassdiagram: klass attribut operation association Språk Språk är skrivet i ett är skrivet i ett Beteendediagram Begrepp i ett beteendediagram: ta emot order kontrollera order leverera order Strukturdiagram Begrepp i ett strukturdiagram: kund order ordernummer Ett system brukar oftast beskrivas med både strukturdiagram och beteendediagram. I bilden ser vi ett beteendediagram till vänster och ett strukturdiagram till höger. Båda dessa diagram har ett antal begrepp som kan finnas representerade i verkligheten, till exempel aktionen att ordern mottas eller själva ordern, det vill säga beställningen. Men det som intresserar oss nu är inte vad elementen representerar i verkligheten utan vilka symboler som används för att modellera ”motta order” och ”order” samt vad dessa symboler betyder. I beteendediagrammet kan vi till exempel se att en rektangel med runda hörn och pilar som går mellan rektanglarna. Dessa symboler har betydelse och får kombineras enligt vissa regler. Rektanglarna med runda hörn representerar aktioner, medan pilarna representerar flödet mellan aktionerna, det vill säga pilarna anger i vilken ordning som aktionerna ska genomföras. Symbolerna, reglerna för hur de får kombineras, och deras betydelse är centrala egenskaper hos modelleringsspråket. beskrivs av beskrivs av System [Kleppe et al, 2003]

UML-diagram baseras på ett enda språk
UML:s strukturdiagram och beteendediagram skrivs i samma språk Språk är skrivet i ett är skrivet i ett Beteendediagram Begrepp i ett beteendediagram: ta emot order, kontrollera order leverera order Strukturdiagram Begrepp i ett strukturdiagram: kund, order, ordernummer Notera att UML har ett gemensamt språk för alla diagramtyperna. Till exempel kan ett och samma begrepp, som till exempel ”aktion”, finnas i flera olika diagramtyper. beskrivs av System beskrivs av [Kleppe et al, 2003]

Språkets notation vs semantik
Grafiska modelleringsspråk består av: Konkret syntax /notation – anger vilka symboler som finns i språket och hur de ser ut, hur de får kombineras, samt hur de relateras till språkets begrepp, till exempel att en pil representerar begreppet flöde Abstrakt syntax (språkets semantik/metamodell) – definierar modelleringsspråkets begrepp (som flöde, klass, attribut). Begreppen i modelleringsspråket brukar definieras i form av en konceptuell modell som kallas metamodell Språk är skrivet i ett Ett grafískt modelleringsspråk består av notation/syntax och semantik. Det är dock inte klart var gränsen mellan dessa begrepp går och olika författare har olika syn på vad som ingår i notationen/syntaxen och vad som ingår i semantiken. En tolkning är att notationen/syntaxen anger vilka symboler som finns i språket och hur de ser ut, hur de får kombineras, samt hur de relateras till språkets begrepp, till exempel att en pil representerar begreppet flöde. Semantiken definierar då språkets begrepp som aktion, flöde, klass och attribut. Dessa begrepp brukar definieras i form av en metamodell. Diagram

Modeller, språk och metamodeller
Begrepp i språket UML: klass, association aktion, flöde Begrepp i UML:s metamodell klass, association aktion, flöde Metamodell Språk Begrepp i diagram: kund, order, ordernummer attribut är skrivet i ett definieras av klass Ett modelleringsspråks semantik, det vill säga dess begrepp, som ”aktion” och ”flöde”, kan, som nämnts, modelleras i form av en begreppsmodell som kallas metamodell. Den specificerar hur modelleringsbegreppen förhåller sig till varandra och hur de får kombineras. UML har till exempel en metamodell. Notera dock att metamodellen vanligtvis inte specificerar vilka symboler som representerar de olika begreppen i metamodellen. Detta görs vanligen i notationen/syntaxen. UML:s specifikation består till exempel av en notation (syntaxen) och en metamodell (semantiken). Diagram har specificerat Notation beskrivs av En metamodell är en modell som beskriver (definierar) ett språks modelleringsbegrepp System [Kleppe et al, 2003]

Modelleringsbegrepp – en jämförelse
Klassdiagram E(A)R-diagram Databasdiagram Klass Entitetstyp (entitet) Tabell Association Relationstyp (relation) Främmande nyckel Attribut Attribut Kolumn Multiplicitet Avbildningsregler Avbildningsregler Objekt Instans (”entity occurence”) Rad eller post Den här bilden visar en översikt över hur tre av de nämnda modelleringsspråken förhåller sig till varandra. Vi ser i tabellen vilka modelleringselement som är jämförbara, ibland gränsande till synonymer. Vi kan se jämförbarhet mellan: klass, entitet och tabell, association, relation och främmande nyckel, attribut och kolumn, multiplicitet och avbildningsregler, objekt, instans och rad eller post. När man till exempel pratar om ett objekt i ett UML-klassdiagram, så menar man ofta i stort sett samma sak som en instans i ett E(A)R-diagram och en rad eller post i ett databasdiagram. Observera dock att termerna inte alltid beskriver exakt samma begrepp!

Relationen begrepp och term
Att förstå distinktionen mellan begrepp och term är viktigt vid analys av verksamheter och design av system. Olika avdelningar på ett och samma företag kan till exempel ha olika termer för ett och samma begrepp eller en och samma term för olika begrepp. Om detta inte uppfattas kommer det att försvåra kommunikationen mellan avdelningarna och försvåra designen av ett gemensamt system för de olika avdelningarna. På samma sätt kan två informationssystem använda olika termer för samma begrepp och samma term för olika begrepp, vilket försvårar integration av systemen. Term ”Dator”

Begrepp Ett begrepp är en tankeenhet, en mental föreställning av en eller flera företeelser i verkligheten Begrepp Term ”Dator” Begrepp är en tankeenhet, det vill säga en mental representation eller föreställning av en eller flera företeelser i verkligheten, som till exempel föremål, aktioner, händelser, relationer, positioner och kvalitet. Ett begrepp kan representera endast en företeelse, som till exempel ”Nisse”, eller via abstraktion täcka alla företeelser som har vissa gemensamma särdrag, som till exempel ”Student”. [Hedin et al, 2000]

Term En term är en mer eller mindre godtycklig symbol för ett begrepp Begrepp En term kan bestå av artikulerade ljud, ett ord i form av bokstäver, en ordgrupp, eller en grafisk symbol Term ”Dator” Term och ord kan ses som synonymer En term är en mer eller mindre godtycklig symbol för ett begrepp. En term kan bestå av artikulerade ljud, ett ord i form av bokstäver, en ordgrupp, eller en grafisk symbol. Det senare är en central byggkloss när grafiska modeller ska byggas. Term och ord kan ses som synonymer, men vissa författare menar att ett ord blir en term då det definierats som en beståndsdel i ett terminologiskt system. Ett fackområdes termer utgör ett terminologisk system (terminologi). [Hedin et al, 2000]

För att använda ett begrepp måste man ha en term för det Begrepp Sambandet mellan begrepp och term bör vara så entydigt som möjligt, annars uppstår tolkningsproblem, som: - Synonymi - Polysemi Term ”Dator” Distinktionen mellan begrepp och term kan ibland vara svår att förstå eftersom det inte går att kommunicera ett begrepp om man inte har en term och alla termer representerar begrepp. Term och begrepp kan med andra ord inte vara utan varandra. Sambandet mellan begrepp och term bör vara så entydlig som möjligt, annars uppstår tolkningsproblem, som: - Synonymi, - Polysemi, - Homonymi. [Hedin et al, 2000]

Termer x Synonym A Olika termer hänvisar till samma begrepp (”UML” och ”Unified Modeling Language” hänvisar till samma sak) y z Polysem A Samma term hänvisar till olika begrepp. Det beror ofta på att det stipuleras nya betydelser för gamla termer. (”demokrati”, ”tjänstebaserad utveckling”) x Två eller flera termer kan vara synonyma om de hänvisar till samma begrepp. Till exempel är termerna ”UML” och ”Unified Modeling Language” synonymer då de hänvisar till samma sak, samma tankeelement, det vill säga till samma begrepp. Om två eller flera termer som är synonymer inte uppfattas som synonymer kan detta försvåra kommunikation. Polysemi innebär att en och samma term hänvisar till olika begrepp. Ett typiskt exempel är termen ”demokrati” som kan ha olika betydelse beroende på i vilket land man befinner sig. Detta kan också försvåra kommunikation. Homonym innebär att likalydande eller likastavade termer har olika betydelse. ”Gift” i form av ”förenad i äktenskap” och ”giftigt ämne” är egentligen två olika termer fast de stavas lika. Det blir tydligt när de ska översättas till ett annat språk som engelska. Även homonymer kan orsaka kommunikationsproblem. B [Hedin et al, 2000]

Ogdens triangel (”Meaning triangle”)
Charles Ogden ( ) intresserade sig för sambandet mellan: - termen (det språkliga uttrycket, ”symbol”) - begreppet (den mentala föreställningen, intensionen, ”meaning”) - referenten (företeelsen i verkligheten, extensionen, ”object”) Begrepp En engelsk språkforskare, Charles Ogden, gjorde inte bara en distinktion mellan termen och begreppet utan han skiljde också på referenten och begreppet samt referenten och termen. Han konstruerade Ogdens triangel som ett instrument för att analysera relationerna mellan term, begrepp och referent. Referenten motsvarar den företeelse som finns i verkligheten. Referenten brukar kallas termens extension medan begreppet brukar kallas termens intension. Extensionen kan ses som alla de företeelser som finns verkligheten. Till exempel så kan termen ”dator” ha extensionen ”alla datorer som finns”. Intensionen är då en slags definition av termen ”dator” till exempel ”maskin för behandling av data”. En term kan sakna referent, till exempel termen enhörning. Notera att begrepp, term och referent ska ses ur en persons perspektiv. Denna person har därför placerats i mitten av triangeln. Referent Term Ogdens triangel ”Dator” [Sowa, 2000]

Ogdens triangel Ogdens triangel (”meaning triangel”) visar att en person har en mental föreställning (begrepp) om en företeelse i verkligheten (referent) och för att kommunicera med andra använder han/hon en symbol (term) Notera också att för att kommunicera en företeelse i verkligheten (referent) kan vi antingen försöka förmedla vår föreställning om referenten med hjälp av termer eller så kan vi peka på den. Begrepp Ogdens triangel visar att en person har en mental föreställning (begrepp) om en företeelse i verkligheten (referent) och för att kommunicera med andra använder han/hon en symbol (term) Notera också att för att kommunicera en företeelse i verkligheten (referent) kan vi antingen peka på den eller försöka förmedla vår föreställning om referenten via språket – till exempel med hjälp av en begreppsdefinition. Referent Term Ogdens triangel ”Dator”

Problem att tolka verkligheten
Samma företeelse i verkligheten (referent) kan ge upphov till olika mentala föreställningar (begrepp) på grund av olika förförståelse Klassiskt exempel är planeten Venus som kan tolkas som två olika begrepp: ”Morgonstjärna” och ”Aftonstjärna”. Se även figur nedan Begrepp Ett problem vid kommunikation är att en och samma företeelse i verkligheten, det vill säga referenten, kan ge upphov till olika mentala föreställningar. Till exempel får kanske experten och lekmannen olika mentala föreställningar när de tittar på en dator. Ett annat exempel på detta är att planeten Venus, som kan ge upphov till två mentala föreställningar, det vill säga två begrepp, nämligen morgonstjärnan och aftonstjärnan. Referent Ogdens triangel ”Server” ”Skärm” Term

Ogdens triangel – ett användbart verktyg
Begrepp Problem begrepp - referent: Verkligheten tolkas olika på grund av olika förförståelse Problem begrepp - term Synonym Polysem Den här bilden visar att problem med synonymer, homonymer och polysemer har med relationen ”begrepp – term” att göra, medan problemet att verkligheten tolkas olika på grund av olika förförståelse har med relationen ”begrepp – referent” att göra Term Referent ”Dator” ”Server” ”Skärm”

Ogdens triangel – ett användbar verktyg
Begrepp - Begreppsdefinition - Begreppsmodell Ogdens triangel kan också användas för att klargöra vad det är för skillnad på terminologi och begreppsmodell. Vi har försökt placera ut orden på den högra sidan av Ogdens triangel, det vill säga på relationen ”begrepp – term”. En terminologi skulle då kunna tolkas som en lista med ord, medan en begreppsmodell också definierar vad orden betyder, det vill säga klargör ordens intension. Notera dock att flera författare använder termen ”terminologi” i samma betydelse som en mängd begreppsdefinitioner. - Terminologi Term Referent ”Dator” ”Server” ”Skärm”

Vad gör vi när vi begreppsmodellerar?
En begreppsmodell (konceptuell modell) utgår från en mental föreställning och försöker återge en del av verkligheten i en grafisk beskrivning Begreppsmodellering är ett instrument för att : - specificera begrepp oavsett vilka termer vi använder - specificera vilka termer som ska användas Att använda begreppsmodeller är vanligt i analysfasen av ett systemutvecklingsprojekt. En begreppsmodell, det vill säga en konceptuell modell, utgår från en mental föreställning och försöker återge en del av verkligheten i form av en grafisk föreställning. Begreppsmodeller används för att dels analysera och definiera begreppen oavsett vad vi kallar dem (det vill säga oberoende av vilka termer vi använder), dels för att slå fast en terminologi, det vill säga klargöra vilka termer som ska användas. 1..* Kund Bankkonto 1..* Samma begrepp, olika termer 1..* Anställd Lönekonto 1..* 1..* Customer Bank account 1..* [Hedin et al, 2000]

x gift med ”gift med” y Den här bilden visar att en modell, som finns uppe i högra hörnet, består av både begrepp och termer. Låt oss tänka oss att de två referenterna nere till vänster är gifta och att denna företeelse ska modelleras. De två referenterna kan modelleras till exempel i form av ovaler och relationen mellan referenterna modelleras i form av streck mellan ovalerna. Ovalerna och strecken kan också se som termer. Termer som ”Nisse”, ”Anna” och ”gift med” används i kombination till symbolerna. Om vi inte vet namnet på de två personer som är gifta kan de få tillfälliga termer, som till exempel x och y, vilka kan bytas ut till namnen när de blir kända. Notera att modellen, som vi tidigare nämnt, definierar begreppen oavsett vad vi kallar dem (det vill säga oberoende av vilka termer vi använder). Term ”Nisse” Anna x Referent Nisse ”gift med” y ”Anna”

Anna gift med ”gift med” Nisse Nu har termerna x och y byts ut mot Anna och Nisse. Detta exempel får avsluta denna introducerande föreläsning om modeller och modelleringsspråk. Term ”Nisse” Anna x Referent Nisse ”gift med” y ”Anna”

UML en översikt

UML – en översikt Vad är UML? Vad är UML inte?
Från början en kombination av Objectory (Jacobson), Object Modelling Technique (OMT, Rumbaugh) och Booch method (Booch) UML är en akronym för Unified Modeling Language (sv. enat modelleringsspråk) Det är ett hjälpmedel, ett språk, för kommunikation inom systemutveckling. Består av en mängd diagram med grafiska notationer som används för att modellera ett system från olika perspektiv. Baseras på en bakomliggande modell, kallad metamodell. Metamodellen, kan i allt väsentligt sägas vara liktydig med språket UML. Beskrivs i två officiella publikationer (på sammanlagt 928 sidor), utgivna av Object Management Group (OMG). [1] OMG, 2003, UML 2.0 Infrastructure Specification, [2] OMG, 2003, UML 2.0 Superstructure Specification, ”The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems” [1]. Artefakt kan översättas ”arbetsprodukt”. Vad är UML inte? UML är inte en metod i sig, och inte heller liktydigt med objektorienterad utveckling. Välkommen till denna översiktliga presentation av UML. Vad är då UML? UML står för Unified Modeling Language som på svenska blir ensat modelleringsspråk. Den organisation som ansvarar för UML, the Object Management Group, som förkortas OMG, beskriver UML så här: ”The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems” [1]. UML är alltså i grunden ett hjälpmedel, ett språk, för att utveckla och beskriva olika typer av system. Största användningen, åtminstone hittills, är för mjukvarusystem, och då främst mjukvarusystem utvecklade med hjälp av objektorienteringens principer. UML beskrivs officiellt i några publika specifikationer [1], [2]. Det består av en mängd diagram och därmed en mängd grafiska notationer. Dessa diagram och notationer används för att göra modeller av system. Modellerna visar systemet ur ett antal olika perspektiv. Men UML är också en metamodell och det är denna metamodell som ligger till grund för hur diagrammen, det vill säga den grafiska notationen, ska förstås och tolkas, både syntaktiskt och semantiskt. För det mesta kan vi förenkla och säga att metamodellen är liktydigt med språket UML. Vad är UML inte? Vi ska dock inte förledas att tro att UML är en metod i sig själv, och det är också viktigt att påpeka att UML inte är begränsat till objektorienterad mjukvaruutveckling även om dess största användningsområde är just där. Referenser: [1] OMG, 2003, UML 2.0 Infrastructure Specification, ’ ’, [2] OMG, 2003, UML 2.0 Superstructure Specification, ’ ’.

Hur används UML? UML som skiss
- idén är att använda UML för en selektiv, mer informell beskrivning av systemet eller domänen - beskriva tänkbara/existerbara lösningar på problem eller för en domän UML som ritning - idén här är att använda UML för en komplett, formell beskrivning av systemet - beskriva systemet på ett sätt som en programmerare kan använda UML som exekverbart system - idén är att undvika programmeringssteget mellan modell och kod - UML är programmeringsspråket och kompileras direkt till körbar kod - relativt omogen angreppssätt, och ännu för tidigt att se om det blir allmänt använt UML kan användas på olika sätt. Vi brukar skilja på tre olika sätt. Vi kan använda UML som skiss (eng. sketch). Det gör vi för att beskriva delar av tänkbara lösningar på problem, eller för att delvis dokumentera existerande lösningar för att kunna kommunicera dem med kollegor eller intressenter. Huvudidén är att UML används mer informellt och selektivt för att beskriva valda delar av ett system ur något eller några perspektiv. Vi kan använda UML som ritning (eng. blueprint). Här beskrivs systemet på ett sätt som en programmerare kan använda för att implementera modellen till kod, eller för att dokumentera befintliga systemlösningar eller kod för mer definitiv användning, till exempel som underlag för offerter, eller som ingångskunskap för kommande systemprojekt. Huvudidén här är att använda UML för en mer komplett och formell beskrivning av systemet. Slutligen kan vi använda oss av exekverbar UML (eng. executable) Här tar vi steget fullt ut och låter UML vara själva programmeringsspråket. Det vill säga, modellerna kompileras direkt till körbar kod. Huvudidén är förstås dels att undvika programmeringssteget mellan modell och kod, dels för att undvika den direkta programmeringskostnaden, och dels för att minska risken till införande av fel i koden. Detta sätt verkar dock ännu inte vara helt moget för allmän användning inom systemutveckling. Svårigheten tycks bero på i huvudsak hur man ska modellera dynamiska beteenden på ett sätt som automatiska verktyg kan förstå. Den gren av systemutvecklingsbranschen som arbetar med att utveckla och använda exekverbar UML återfinns inom Model Driven Development, förkortat MDD.

När i utvecklingsprocessen används UML?
Före kodning - modellerna används som underlag för kodning - eng. forward engineering Efter kodning - modellerna används som dokumentation av koden efter att koden utvecklats - eng. reverse engineering Rundtur - bägge ovanstående användningsområdena används - eng. round-trip engineering UML har också ett antal olika användningsområden. Vi kan urskilja fyra sådana områden. Vi kan använda UML före kodning. Om vi använder UML i början av utvecklingsskedet för att först modellera delarna av systemet, och sedan använda modellerna för att koda implementationen, kallas det med en engelsk term att göra forward engineering. Alternativt kan vi använda UML efter kodning. Om vi istället enbart i efterhand utnyttjar UML för att skapa beskrivningar och dokumentation av vår, eller någon annans kod, kallas det med en engelsk term att göra reverse engineering. Ett annat användningsområde kan vi kanske kalla rundtur på svenska. Ofta använder man UML:s modeller både före kodning och efter kodning. Vi kan säga att man gör en sorts rundturer fram och till baks mellan kod och modell. Detta kallas med en engelsk term för round-trip engineering. Slutligen finns också möjligheten att använda UML som ett tittvyhjälpmedel. Här är koden hela tiden det centrala. När man vid behov behöver presentera delar av koden grafiskt använder man lämpliga UML-diagram. Detta kallas tripless engineering.

UML – en diagramöversikt
UML 2.0 har 13 diagramtyper, med olika fokus, och typerna delas in i två huvudgrupper. Strukturdiagram beskriver statiska (strukturella) förhållanden. Beteendediagram beskriver dynamiska förhållanden. Strukturdiagram (6 st) De allra flesta som kommer i kontakt med UML gör det genom att använda dess diagram på något sätt, antingen genom att själv skapa modeller, eller genom att studera domäner, eller system, som andra ha r modellerat. Från och med version 2.0 har UML 13 diagramtyper. Diagramtyperna har fokus på olika delar av domänen, eller systemet, som modelleras. De 13 typerna delas in i två huvudgrupper. Dessa grupper är dels strukturdiagram (eng. Structure Diagrams), som används för att beskriva koncept och andra statiska, eller strukturella, aspekter av domänen eller systemet, och dels beteendediagram (eng. Behavior Diagrams), som beskriver de beteenden som finns i en domän eller system. Diagram (13 st) Beteendediagram (7 st)

Kompositstrukturdiagram
UML – strukturdiagram Klassdiagram Objektdiagram Paketdiagram Strukturdiagram Komponentdiagram Kompositstrukturdiagram Utplaceringsdiagram Här ger vi nu en introducerande beskrivning av de sex olika typerna av strukturdiagram som finns i UML. Vi börjar med klassdiagrammet (eng. Class Diagram). Klassdiagrammet används för att beskriva de olika typer av objekt som finns i en domän eller ett system. Det beskriver också relationerna mellan dessa typer av objekt. Klassdiagrammet är det utan jämförelse mest förekommande UML-diagrammet. Objektdiagrammet (eng. Object Diagram) visar beskrivningar av objekt, till skillnad från klassdiagrammet som beskriver klasser, eller typer, av objekt. Objekten beskrivs som de ter sig, och förhåller sig till andra objekt, vid vissa bestämda tidpunkter under livstiden. I ett paketdiagram (eng. Package Diagram) grupperar vi UML-element, som till exempel klasser i ett klassdiagram, i en hierarkisk struktur för att visa att de hör ihop på något väsentligt sätt. Paket kan ingå i andra paket. Komponentdiagrammet (eng. Component Diagram) används för att beskriva samverkande delar av mjukvara (oftast klasser) som kan användas som sammansatta enheter, komponenter, i ett större system. Gränssnittsbeskrivningar ges stor vikt eftersom dessa komponenter ska vara enkla att placera ut i systemet. Kompositstrukturdiagrammet (eng. Composite Structure Diagram) är ett nytt diagram i UML 2.0. Det används för att bryta ner en komplex klass i dess interna delar. Utplaceringsdiagrammet (eng. Deployment Diagram) åskådliggör ett systems fysiska utseende, eller design. Det visar vilka delar av mjukvaran som är installerade, och på vilka delar av hårdvaran som mjukvaran körs.

UML – beteendediagram Aktivitetsdiagram Användningsfallsdiagram
Tillståndsmaskinsdiagram Interaktionsdiagram Beteendediagram Sekvensdiagram Kommunikationsdiagram Interaktionsöversiktsdiagr. På samma sätt ger vi nu en introducerande beskrivning av de sju olika typerna av beteendediagram som finns i UML. Aktivitetsdiagrammen (eng. Activity Diagram) beskriver procedurell logik, affärsprocesser och arbetsflöden. Viktigt att notera är att de stödjer parallellt beteende. Aktivitetsdiagrammen var i tidigare UML-versioner specialfall av tillståndsmaskinsdiagram. Från UML 2.0 är den kopplingen borttagen. UML tillhandahåller notation för användningsfallsdiagram (eng. Use Case Diagram). Dessa diagram visar kraftigt förenklat systemets användningsfall, och hur de är relaterade till varandra. Noterbart är att UML dock inte klargör hur de textuella användningsfallsbeskrivningarna ska se ut. Mer om detta i föreläsningen om användningsfall. Tillståndsmaskinsdiagram (eng. State Machine Diagram,) upprättas för en klass för att visa dess instansers generaliserade beteende under livstiden. Diagrammen är mycket vanliga speciellt inom utveckling av realtidssystem och fanns även långt innan UML kom till. Observera att bara beteendet hos en (anonym) instans modelleras, men den instansens diagram visar alla möjliga varianter för alla presumtiva instanser. Ett av de allra vanligast förekommande UML-diagrammen är sekvensdiagrammet (eng. Sequence Diagram). Det är normalt så, att minst ett sekvensdiagram upprättas för varje användningsfall, för att beskriva det interaktiva beteendet i ett scenario, normalt huvudscenariot. Det som då beskrivs är exempel på alla ingående objekt och alla meddelanden, det vill säga interaktionen, som förekommer i scenariot. Fokus ligger på det sekvensiella skeendet. Kommunikationsdiagrammen (eng. Communication Diagram) kallades tidigare kollaborationsdiagram (eng. Collaboration Diagram). De innehåller samma information, och har samma användningsområde, som sekvensdiagrammen, men deras fokus är mer på länkarna mellan objekten istället för på det sekvensiella skeendet. Interaktionsöversiktsdiagrammet (eng. Interaction Overview Diagram) är en ny diagramtyp i UML Det är ett specialfall av aktivitetsdiagrammet och fokuserar på någon mängd interaktioner i form av sekvensdiagram, och det kontrollflöde som styr när dessa interaktioner ska ske. Interaktionerna, det vill säga sekvensdiagrammen, är aktionsnoderna i interaktionsöversiktsdiagrammet. Synkroniseringsdiagram (eng. Timing Diagram) är också en ny diagramtyp i UML 2.0, även om sådana funnits länge inom speciellt elektronikbranschen. Synkroniseringsdiagrammen fokuserar på restriktioner inom tidsdomänen på en mängd objekt, speciellt mellan tillståndsförändringar. Sekvensdiagram, kommunikationsdiagram, interaktionsöversiktsdiagram och synkroniseringsdiagram, kallas också med ett gemensamt namn för interaktionsdiagram. Synkroniseringsdiagram

Tillståndsmaskinsdiagram
I fokus för denna kurs Strukturdiagram: - Klassdiagram - Paketdiagram Beteendediagram: - Aktivitetsdiagram - Användningsfallsdiagram - Tillståndsmaskinsdiagram - Sekvensdiagram Klassdiagram Strukturdiagram Paketdiagram Nu har vi genomfört en översikt av UML:s diagramtyper och placerat ut dem i sina sammanhang. I denna kurs ska vi i fortsättningen nu gå igenom sex av UML-diagrammen grundligare. Av strukturdiagrammen ska vi gå igenom klassdiagram noggrant, och i samband med den genomgången tar vi också upp lite om objektdiagram. Vi ska även titta på paketdiagram mer detaljerat. När det gäller beteendediagrammen är det: aktivitetsdiagram, användningsfallsdiagram eller egentligen användningsfall rent generellt, tillståndsmaskinsdiagram, och sekvensdiagram, som vi ska beskriva djupare. Diagram Aktivitetsdiagram Användningsfall Beteendediagram Tillståndsmaskinsdiagram Sekvensdiagram

UML:s huvudelement Tre huvudsakliga element i UML:
Begrepp – modellerade begrepp/koncept (som klassen ”kund” eller aktionen ”motta order”) Relationer – bindande begrepp (som associationer mellan klasser, flöden mellan aktioner) Diagram – gruppering av begrepp och relationer. (som klassdiagram och aktivitetsdiagram).

UML Klassdiagram

UML klassdiagram Klass Association och lite om objektdiagram
Välkommen till denna presentation av klassdiagram, UML:s kanske viktigaste diagramtyp. Klassdiagram används för att modellera statiska delar av vår verklighet. Bilden vi ser visar ett mycket förenklat klassdiagram med fyra tomma klasser representerat av rektanglar, som alla har tre avdelningar. Varför rektanglarna har dessa avdelningar återkommer vi till. Vi ser dessutom några streck mellan vissa av rektanglarna. Dessa streck modellerar associationer mellan klasser. Vi kommer att återkomma till även vad detta innebär i ett klassdiagram. Notera att färgen inte har någon signifikans och det hade lika gärna gått bra med exempelvis vit bakgrund. Klasserna, som är de centrala delarna i klassdiagrammen, skapas genom att vi observerar att vissa företeelser i verkligheten är likartade på något sätt. Detta utnyttjar vi för att gruppera företeelserna i klasserna. Exakt hur grupperingen går till, vilka grupperingsregler som används, är ofta helt upp till den som modellerar. Under presentationen kommer vi också att kort beröra UML:s objektdiagram, som till en del liknar klassdiagrammen och dessutom är relaterade till dem på ett sätt vi ska förklara närmare senare i presentationen.

Verkligheten och modeller – tre nivåer
Verksamhetsprocesser (i aktivitetsdiagram) Domänmodell (i klassdiagram) Interaktion med datorer (i användningsfall) Nu har vi lagt till ytterligare en del, till höger i bilden. Vi kallar den delen för grafiska modeller/diagram, medan den vänstra delen benämns ”verkligheten”. Notera än en gång att är det vi ser till vänster är en slags modell av verkligheten, men för resonemangets skull ska vi alltså tänka oss att det är verkligheten. Till höger ser vi modeller eller diagram av det som finns i verkligheten. Man bruka säga att dessa modeller/diagram ska representera eller avbilda företeelser i verkligheten. Modellerna/diagrammen till höger är skapade i modelleringsspråket UML. Enligt UML:s specifikation är det olika diagram och inte modeller som vi ser till höger i bilden. Dessa diagram skapar tillsammans en modell av det vi vill representera. De olika diagrammen ger med andra olika aspekter eller perspektiv på modellen. Notera dock att olika författare har olika syn på relationen mellan modell och diagram. Hos en del författare används modell, eller snarare grafisk modell, och diagram som synonymer. Notera också att en modell behöver inte vara grafisk, den kan till exempel formuleras i textform eller som en formel. Om vi då tittar på den högra delen av bilden kan vi notera följande: - på övre nivån finns aktivitetsdiagram för att modellera verksamhetsprocesser, sekvensdiagram för att modellera kommunikation mellan människor och i klassdiagram för att modellera verksamhetsbegrepp, det vill säga de begrepp som används i verksamheten när människor kommunicerar muntligt eller genom att skicka dokument, - på mellersta nivån finns användningsfallsdiagram för att modellera interaktionen mellan människor och datorer, - på undre nivån finns aktivitetsdiagram för att modellera mjuk- och hårdvaruprocesser i datorsystem, sekvensdiagram för att modellera kommunikation inom och mellan mjukvara såväl som för hårdvara, och klassdiagram för att modellera de informationselement som används av datorer. Som vi ser kan några typer av UML-diagram användas på fler än en nivå, till exempel används klassdiagram, aktivitetsdiagram och sekvensdiagram både på den övre och nedre nivån. Interaktion mellan objekt (i sekvensdiagram) Systemmodell (i klassdiagram) Verkligheten Grafiska modeller/diagram

Klassdiagram – centralt i UML
Klassdiagrammen är vanligast förekommande – har blivit nästan synonymt med UML. Klassdiagram beskriver den statiska strukturen hos en domän eller system. De består av klasser (begrepp) och associationer mellan klasserna. Klassdiagram visar också klassernas attribut och operationer. Student personnr namn epostadress registreraFörKurs() Kurs kursID kursnamn är registrerad vid kurs När vi pratar om UML brukar vi ofta associera till just en viss speciell diagramtyp, nämligen klassdiagram. Det är inte så konstigt eftersom majoriteten av alla UML-diagram vi ser i böcker och artiklar är just klassdiagram. Klassdiagrammet är en central del av användningen av UML. Klassdiagrammet beskriver vilka klasser som finns i en domän eller ett system, och vilka statiska associationer som existerar mellan dessa klasser. Klassdiagrammen visar också vilka attribut och operationer klasserna har. Diagrammet nere till vänster har två klasser: Student och Kurs. Mellan dessa två klasser finns en association i form av ett streck som förbinder de två klasserna. Klassen Student har attributen personnr, namn och epostadress samt operationen registreraFörKurs(). Klassen Kurs har attributen kursID och kursnamn. Det finns dock inte angivet någon operation för Kurs. Här kan vara värt att påpeka några saker om vissa av de nämnda begreppen. Ibland ser vi begreppet typ användas synonymt med klass. Typ är dock inte helt synonymt med klass. Klass är det korrekta UML-begreppet. Använd detta. Ofta används begreppet relation som synonymt med association, och det är oftast riktigt. Association är dock det korrekta UML-begreppet. Använd detta. Begreppet strukturell kan vi ibland se användas istället för begreppet statisk. Även om vi i UML-sammanhang kan anse strukturell och statisk som synonymer, rekommenderar vi att använda begreppet statisk.

Klassdiagram – notation
UML-notationen för en klass är en rektangel med (normalt) tre avdelningar: klassens namn (använd susbstanttv och starta med stor bokstav) attribut (använd substantiv och starta med liten bokstav) operationer (använd verb och börja liten bokstav) Klassens namn Student studentnummer namn epostadress RegistreraVidKurs() Student studentnummer namn epostadress Student Det finns en speciell notation i UML för klassdiagram. Vi ritar en klass i form av en rektangel med tre avdelningar, eller utrymmen (eng. compartments): utrymmet högst upp innehåller klassens namn i fet stil och med stor första bokstav, mellanutrymmet innehåller namnen på klassens attribut, och bottenutrymmet innehåller namnen på klassens operationer. Notera också sättet att skriva klassens namn, namnet på attributen och namnet på operationerna. Klassens namn börjar med stor bokstav, medan klassens attributnamn börjar med liten bokstav, liksom operationernas namn. Innehåller attributnamnen eller operationsnamnen mer än ett ord börjar vi varje nytt ord med stor bokstav. Se till exempel namnet på operationen registreraFörKurs() som innehåller tre ord. Orden har inget utrymme mellan sig, och varje ord, utom det första, börjar med stor bokstav. Observera att ord som redan är sammansatta av andra ord har enbart små bokstäver, se till exempel attributnamnet epostadress. Det ska här påpekas att det sätt att skriva attribut och operationer som vi visar här bara är en konvention, även om den är mycket vanlig. Notera att stor bokstav kan finnas mitt i texten om attribut och operation består av flera ord Operation (eller ”metodhuvud”) Attribut

Klasser representerar ofta grupperingar av ting i verkligheten
Student personnr namn epostadress registreraFörKurs() Kurs kursID kursnamn Här ser vi ett klassdiagram med tre utritade klasser som har några attribut och några associationer. Attribut och associationer kallas med ett gemensamt UML-begrepp för egenskaper (eng. properties). Egenskaperna beskriver klassers statiska (strukturella) särdrag eller kännetecken.

Associationer representerar roller mellan dessa grupperingar av ting
är registrerad vid Student Kurs studentnummer namn epostadress kursD kursnamn har avslutat är huvudstad i Stad Land Här ser vi ett klassdiagram med tre utritade klasser som har några attribut och några associationer. Attribut och associationer kallas med ett gemensamt UML-begrepp för egenskaper (eng. properties). Egenskaperna beskriver klassers statiska (strukturella) särdrag eller kännetecken. namn tillhör namn Associationer beskriver roller som de två relaterade klasserna spelar mot varandra. För att underlätta tolkning av associationer bör man ge associationerna namn

Tre sätt att ge associationer namn
Tre alternativa sätt att ge associationer namn: 1) använda verb nära klassen (notera hur detta ska läsas) är registrerad vid kurs Student Kurs har registrerade 2) använda verb med fylld pil är registrerad vid Här ser vi ett klassdiagram med tre utritade klasser som har några attribut och några associationer. Attribut och associationer kallas med ett gemensamt UML-begrepp för egenskaper (eng. properties). Egenskaperna beskriver klassers statiska (strukturella) särdrag eller kännetecken. Student Kurs 3) Använda substantiv nära klassen (notera hur detta ska läsas) kurs Student Kurs student

Associationer har riktningar
Association med två riktningar Student Kurs Association med enriktning Student Kurs Här ser vi ett klassdiagram med tre utritade klasser som har några attribut och några associationer. Attribut och associationer kallas med ett gemensamt UML-begrepp för egenskaper (eng. properties). Egenskaperna beskriver klassers statiska (strukturella) särdrag eller kännetecken. Kan tolkas som: association med två riktningar, eller att man inte visar riktningen/riktningarna Student Kurs

Attribut & associationer är egenskaper
Student Kurs studentnummer namn epostadress kursID kursnamn Student Kurs Här ser vi ett klassdiagram med tre utritade klasser som har några attribut och några associationer. Attribut och associationer kallas med ett gemensamt UML-begrepp för egenskaper (eng. properties). Egenskaperna beskriver klassers statiska (strukturella) särdrag eller kännetecken. studentnummer namn epostadress kurs kursID Kursnamn student Associationer och attribut är båda egenskaper, det vill säga, det är baserade på samma begrepp (i UML:s metamodell). Associationer och attribut är dock olika terms/symboler/notationer.

Student Kurs studentnummer namn epostadress kursID kursnamn Här ser vi ett klassdiagram med tre utritade klasser som har några attribut och några associationer. Attribut och associationer kallas med ett gemensamt UML-begrepp för egenskaper (eng. properties). Egenskaperna beskriver klassers statiska (strukturella) särdrag eller kännetecken. Student Kurs studentnummer namn epostadress kursID Kursnamn Fråga: Vad händer om associationen bara har en riktning?

pilen på associationen reprensenterar navigerbarhet Student Kurs studentnummer namn epostadress kursID kursnamn Student Kurs Här ser vi ett klassdiagram med tre utritade klasser som har några attribut och några associationer. Attribut och associationer kallas med ett gemensamt UML-begrepp för egenskaper (eng. properties). Egenskaperna beskriver klassers statiska (strukturella) särdrag eller kännetecken. studentnummer namn epostadress kursID kursnamn student attribut reprensenterar navigerbarhet Svar: Attribut läggs i klassen Kurs som då representerar associationen och dess riktning (navigerbarhet)

Klass och objekt När vi klassificerar så grupperar vi objekt i en klass För att kunna klassificerar måste vi ta bort de egenskaper som differentierar objekt så att vi kan se likheten hos dem Detta är ett sätt att hantera verklighetems komplexiteten. Vi behöver inte räkna upp alla objekt när vi vill tala om dem, utan vi kan använda ett begrepp som representerar en gruppering. ”Student” Begrepp/Tankeenhet Vi börjar alltså med klassificering. När vi klassificerar applicerar vi begrepp på objekt. I denna presentation kallar vi sådana begrepp för objekttyper. Objekttyp och klass kan något förenklat ses som synonymer. Klassificering innebär att vi tar bort egenskaper som skiljer objekt åt, och visualiserar andra egenskaper som är gemensamma. Därmed kan vi se likheter hos objekt. Nu tittar vi på en bild av Ogdens triangel, som vi redogjort för i presentationen ”Introduktion till modeller och modelleringsspråk. Ogdens triangel kan ses som ett instrument för att analysera relationerna mellan term, begrepp och referent. Referent, till vänster i Ogdens triangel, motsvarar företeelser som finns i verkligheten. I figuren ser vi Anna Svan och Nisse Hall, som ska ses som fysiska personer som finns i verkligheten. Begrepp, i topp i Ogdens triangel, är mentala representationer eller föreställningar av företeelser i verkligheten. Anna Svan och Nisse Hall som begrepp ska ses som mentala representationer hos den person som har en föreställning om Anna Svan och Nisse Hall. Denna person, som finns i mitten av Ogdens triangel, kan gruppera ihop Anna Svan och Nisse Hall genom att ta bort de egenskaper som skiljer dem åt, och lyfta fram dem som är gemensamma, till exempel att de båda studerar. Genom denna gruppering skapas en objekttyp, som namnges med en term, i det här fallet ”student”. Utan dessa objekttyper skulle vi bara veta att alla saker är olika. Utan objekttyper skulle vi bara kunna resonera kring objekt, det vill säga i stället för att tala om ”studenter” skulle vi tvingas räkna upp alla objekt och informera om att dessa går till exempel vid Stockholms Universitet. ”Nisse Hall” ”Anna Svan” Referent Symbol/Term ”Anna Svan” ”Nisse Hall” ”Student” ”Nisse Hall” ”Anna Svan”

Klass och objekt Klasser (Enititetstyper) Objekt (Instanser/
Kvinna Student Man Cecilia Björk Här är ett annat sätt att åskådliggöra klassificering, nämligen i form av ett mängddiagram. Cecilia Björk och Anna Svan tillhör objekttypen Kvinna, Anna Svan och Nisse Hall tillhör objekttypen Student, och Nisse Hall och Zlatan tillhör objekttypen Man. Anna Svan Nisse Hall Objekt (Instanser/ Entity occurences) Zlatan

Klass och objekt - igen Verkligheten Klass Objekt (instans) Car Car
regnr=ABC123 Car regnr Car regnr=EBC234 Klassificering Tar bort de egenskaper som skiljer tingen Instansiering: Från en klass (en mall) kan objekt skapas

Klass- och objektdiagram
Objekt (instanser) Student :Student :Student studentnummer namn epostadress studentnummer= ” ” namn = ”Anna Cecilia Svan” epostadress = studentnummer= ” ” namn = ”Nils Erik Hall” epostadress = Kurs :Kurs kursID kursnamn kursID=””2I400” kursnamn=”Data Base Design” Företeelser i verkligheten, till exempel studenter, kan alltså grupperas ihop och bilda en klass. Klassen till vänster innehåller ett antal attribut: personnr, namn, bostadsadress och epostadress. Låt oss säga att vi nu har två studenter: Nils Hall och Anna Svan. Dessa två kan alltså grupperas ihop i klassen Student. För att visa objekt (instanser), kan vi inte använda klassdiagram. En klass och ett objekt är ju inte samma sak. En klass är en abstraherad beskrivning av ett eller, oftast, många likartade objekt. För att visa objekt använder vi istället UML:s objektdiagram, som ibland också kallas instansdiagram. Notationen för objektdiagram framgår om vi tittar på hur vi har beskrivit våra två studenter. Vi ser att notationen är lik den för klassdiagram. Det som skiljer sig är att i objektdiagrammet finns förutom klassnamnet också ett objektnamn i det övre utrymmet. Objektnamnet skrivs till vänster och det finns ett kolon mellan objektnamnet och klassnamnet. Objektnamnet skrivs ofta med små bokstäver, men det är inte något krav. Allt i övre utrymmet är understruket. Studenterna har fått värden tilldelade sina attribut. Attributen skrivs till vänster och värdena till höger, omgivna av citationstecken. Attribut och värde separeras med tilldelningstecken. Till exempel har Anna Svan har fått ett värde för personnr ( XXXX), ett namnvärde (Anna Cecilia Svan), ett bostadsadressvärde (Ekvägen 10) och ett epostadressvärde Vi har dock stor frihet när vi ritar objektdiagram. Vi behöver bara ta med sådant som är av intresse för just det tillfället vi ritar diagrammet. Om vi tar med klassnamnet måste vi dock alltid föregå det med ett kolon. Alla associationer i klassdiagrammet följer med till objektdiagrammet och varje objekt. Ett objektdiagram kan ses som ett snapshot, ett foto, av ett antal objekt vid en viss tidpunkt. Det kan till exempel hända att Anna Svan flyttar och då får attributet bostadsadress ett annat värde. Attributvärden kan ju förändras under ett objekts livscykel. Värden Objektdiagram: Klassens attribut har värden Klassens associationer har länkar Länkar (”relationship occurrences”)

Multiplicitet för associationer
Kund Order 0..* är lagd av kundnr namn epostadress orderID datum totalsumma 1..1 har lagt minsta antal maximalt antal Multiplicitetför en association beskriver hur många objekt (som minimum och maximum ) i den ena klassen som kan länkas till objekt i den andra klassen - minsta antalet obejkts är 0 (”noll”) eller 1 (”ett”) - maximalt antal är 1 (”ett”) or * (”många”) Ett tips Du kan säga: ”Ett objekt av klassen Kund kan länkas till minimalt ”noll ”och maximalt ”många” objekt av klassen Order” – och i andra riktningen: : ”Ett objekt av klassen Order kan länkas till minimalt ”ett”och maximalt ”ett” objekt av klassen Kund Alla egenskaper, både attribut och associationer, har en multiplicitet. Multipliciteten för en egenskap, det vill säga ett attribut eller en association, indikerar hur många olika objekt (eller värden) som kan uppfylla egenskapen. Här har vi angett multiplicitet för alla attribut och associationer. Det är förstås bara ett exempel. Det finns säkert flera andra möjligheter till val av multiplicitet för bildens klassdiagram. Notera att multiplicitet för associationer anges vid var och en av de associerade klasserna för sig. Det fullständiga sättet att skriva multiplicitet på, är att: - det minsta möjliga (eller tillåtna) antalet anges först, - det största möjliga (eller tillåtna) antalet anges sist, - två punkter skrivs ut mellan antalen.

Multiplicitet – klass- och objektdiagram
Kund Order 0..* är lagd av kundnamn namn epostadress orderID datum totalsumma 1..1 har lagt :Customer :Order kundnummer=”23122” namn=”Anna-Maria Lenngren” orderID=” datum=” ” totalsumma=”5124” Vi förtydligar multiplicitet hos associationer ytterligare. Högst upp i bilden syns det bekanta klassdiagrammet, men nu med enbart klassnamnen utritade. Under klassdiagrammet för vi nu in ett objektdiagram för detta klassdiagram, motsvarande någon viss punkt i tiden. I objektdiagrammet finns tre studenter, tre registreringar och tre kurser. Studenterna är Anna, Nils och Tove. Registreringarna benämns 9, 2 och 6, respektive. De tre kurserna är oop, oos och jök. Om vi tittar från vänster i bilden ser vi att studenten Anna har en association till registreringen 9. Studenten Nils har en association till registreringen 2, och dessutom en till registreringen 6. Tittar vi nu från höger i bilden ser vi att kursen oop har en association till registreringen 6. Kursen oos har en association till registreringen 9, och dessutom en till registreringen 2. Om vi nu granskar bilden, kan vi då säga att klassdiagrammets associationer med multiplicitet, och de faktiska associationerna mellan objekten i objektdiagrammet inte motsäger varandra? Ja, det kan vi. Om vi börjar med studenterna ser vi att Anna har en registrering, Nils har två registreringar, och Tove saknar registreringar. Detta stämmer ju helt överens med klassdiagrammet, som säger att en student kan ha mellan noll och obegränsat antal registreringar. Nu tittar vi på kurserna. Vi ser att oop har en registrering, oos har två registreringar, och att jök saknar registreringar. Även detta stämmer med klassdiagrammet; en kurs kan ha mellan noll och obegränsat antal registreringar. Så till registreringarna. Enligt klassdiagrammet ska varje registrering ha en, och endast en, student. Dessutom ska varje registrering ha en, och endast en, kurs. Detta stämmer. Registreringen 9 associeras till studenten Anna och till kursen oos. Registreringen 2 associeras till studenten Nils och till kursen oos. Slutligen associeras registreringen 6 till studenten Nils och kursen oop. :Customer :Order kundnummer=”11145” name=”Zlatan” orderID=” datum=” ” totalsumma=”456”

Multiplicitet – en övning
Hitta felen i objektdiagrammet – och/eller korrigera multipliciteten i klassdiagrammet så det blir korrekt 1..* Ägare personnummer Bil regnr 1..1 :Ägare personnummer=“771134” :Bil regnr=“UML123” Vi förtydligar multiplicitet hos associationer ytterligare. Högst upp i bilden syns det bekanta klassdiagrammet, men nu med enbart klassnamnen utritade. Under klassdiagrammet för vi nu in ett objektdiagram för detta klassdiagram, motsvarande någon viss punkt i tiden. I objektdiagrammet finns tre studenter, tre registreringar och tre kurser. Studenterna är Anna, Nils och Tove. Registreringarna benämns 9, 2 och 6, respektive. De tre kurserna är oop, oos och jök. Om vi tittar från vänster i bilden ser vi att studenten Anna har en association till registreringen 9. Studenten Nils har en association till registreringen 2, och dessutom en till registreringen 6. Tittar vi nu från höger i bilden ser vi att kursen oop har en association till registreringen 6. Kursen oos har en association till registreringen 9, och dessutom en till registreringen 2. Om vi nu granskar bilden, kan vi då säga att klassdiagrammets associationer med multiplicitet, och de faktiska associationerna mellan objekten i objektdiagrammet inte motsäger varandra? Ja, det kan vi. Om vi börjar med studenterna ser vi att Anna har en registrering, Nils har två registreringar, och Tove saknar registreringar. Detta stämmer ju helt överens med klassdiagrammet, som säger att en student kan ha mellan noll och obegränsat antal registreringar. Nu tittar vi på kurserna. Vi ser att oop har en registrering, oos har två registreringar, och att jök saknar registreringar. Även detta stämmer med klassdiagrammet; en kurs kan ha mellan noll och obegränsat antal registreringar. Så till registreringarna. Enligt klassdiagrammet ska varje registrering ha en, och endast en, student. Dessutom ska varje registrering ha en, och endast en, kurs. Detta stämmer. Registreringen 9 associeras till studenten Anna och till kursen oos. Registreringen 2 associeras till studenten Nils och till kursen oos. Slutligen associeras registreringen 6 till studenten Nils och kursen oop. :Ägare personnummer=“871211” :Bil regnr=“OMG766” :Ägare Personnummer=“691223” :Bil regnr=“MDA446"

Multiplicitet – en till övning
Hitta felen i objektdiagrammet – och/eller korrigera multipliciteten i klassdiagrammet så det blir korrekt Student Registrering Kurs 1..1 0..* 0..* 1..1 anna:Student oop:Kurs 9:Registrering Vi förtydligar multiplicitet hos associationer ytterligare. Högst upp i bilden syns det bekanta klassdiagrammet, men nu med enbart klassnamnen utritade. Under klassdiagrammet för vi nu in ett objektdiagram för detta klassdiagram, motsvarande någon viss punkt i tiden. I objektdiagrammet finns tre studenter, tre registreringar och tre kurser. Studenterna är Anna, Nils och Tove. Registreringarna benämns 9, 2 och 6, respektive. De tre kurserna är oop, oos och jök. Om vi tittar från vänster i bilden ser vi att studenten Anna har en association till registreringen 9. Studenten Nils har en association till registreringen 2, och dessutom en till registreringen 6. Tittar vi nu från höger i bilden ser vi att kursen oop har en association till registreringen 6. Kursen oos har en association till registreringen 9, och dessutom en till registreringen 2. Om vi nu granskar bilden, kan vi då säga att klassdiagrammets associationer med multiplicitet, och de faktiska associationerna mellan objekten i objektdiagrammet inte motsäger varandra? Ja, det kan vi. Om vi börjar med studenterna ser vi att Anna har en registrering, Nils har två registreringar, och Tove saknar registreringar. Detta stämmer ju helt överens med klassdiagrammet, som säger att en student kan ha mellan noll och obegränsat antal registreringar. Nu tittar vi på kurserna. Vi ser att oop har en registrering, oos har två registreringar, och att jök saknar registreringar. Även detta stämmer med klassdiagrammet; en kurs kan ha mellan noll och obegränsat antal registreringar. Så till registreringarna. Enligt klassdiagrammet ska varje registrering ha en, och endast en, student. Dessutom ska varje registrering ha en, och endast en, kurs. Detta stämmer. Registreringen 9 associeras till studenten Anna och till kursen oos. Registreringen 2 associeras till studenten Nils och till kursen oos. Slutligen associeras registreringen 6 till studenten Nils och kursen oop. nils:Student 2:Registrering oos:Kurs 6:Registrering tove:Student jök:Kurs

Attribut har också multiplicitet
Student Registrering Kurs 1..1 0..* 0..* 1..1 personnr namn epostadress [1..1] registreringsID datum [1..1] kursID kursnamn [1..1] [1..1] [1..1] [0..1] [1..*] Multipliciteten för attribut (och association) indikerar hur många olika objekt (eller värden) som kan uppfylla egenskapen Riktlinje: Man bör försöka få attribut som har multipliciteten 1..1. Om attribut har annan multiplicitet än 1..1 bör attributet transformeras till en klass (se modelleringspraktik för klassdiagram) I denna kurs behöver ni bara ange multiplicitet hos attribut om de har en annan multiplicitet än 1..1. Alla egenskaper, både attribut och associationer, har en multiplicitet. Multipliciteten för en egenskap, det vill säga ett attribut eller en association, indikerar hur många olika objekt (eller värden) som kan uppfylla egenskapen. Här har vi angett multiplicitet för alla attribut och associationer. Det är förstås bara ett exempel. Det finns säkert flera andra möjligheter till val av multiplicitet för bildens klassdiagram. Notera att multiplicitet för associationer anges vid var och en av de associerade klasserna för sig. Det fullständiga sättet att skriva multiplicitet på, är att: - det minsta möjliga (eller tillåtna) antalet anges först, - det största möjliga (eller tillåtna) antalet anges sist, - två punkter skrivs ut mellan antalen.

Notes Student Notes är kommentarer i UML-diagram.
Kan stå för sig själv – ej kopplat till något speciellt modelleringselement. Om notes gäller ett speciellt modelleringselement kopplas det till elementet med en streckad linje. Notera att linjen har en liten ofylld cirkel längst ut. Notes kan även användas för att ange begränsningar (eng. constraints) för modelleringselement. Begränsningar måste då skrivas inom klammerparenteser (måsvingeparanteser). Begränsningar kan skrivas i vanlig text eller mer formellt. Ibland vill vi kunna lägga in kommentarer för att underlätta tolkningen av våra diagram. För detta ändamål har UML ett modelleringsbegrepp som kallas notes. Notes ritas som en rektangel med ett litet invikt hörn uppe till höger i rektangeln. I rektangeln skriver vi i fritext den information vi vill förmedla. Notes kan stå för sig själv om det inte gäller något speciellt modelleringselement. Om notes gäller ett speciellt modelleringselement kopplar vi en streckad linje till det modelleringselementet. Linjen avslutas med en liten ofylld cirkel. I UML kan vi ange restriktioner (eng. constraints) för varje modelleringselement. Ett sätt att göra det på är genom att utnyttja notes. Det viktiga då är att restriktionerna skrivs inom krullparenteser. I övrigt kan de vara fritext eller skrivna i något formellt språk. Inkluderar högskolestudenter, men inte gymnasister. { Endast studenter som finns på SU } Student

En övning

Domänbeskring och uppgift
Zoo International är ett företag med åtta djurparker i olika europeiska storstäder. Varje zoo har ett namn, en adress och ett telefonnummer samt en ansvarig. För varje djur måste företaget dokumentera namn, ras, kön och födelsedatum (om det är känt). Varje djur har en anställd som är ansvarig för djuret. En anställd kan vara ansvarig för flera djur. Företaget måste också dokumentera vilket datum som ett djur anländer till en viss djurpark, och om djuret lämnar djurparken eller dör, ska även detta datum dokumenteras. Uppgift: Gör en domänmodell I UML-klassdiagram baserad på domänbeskrivningen.

Modelleringspraktik för klassdiagram

Hur ska man börja modellera?
Domänbeskrivning: En patient som kommer till sjukhuset måste först skriva in sig vid en klinik, vilket innebär att patientens namn, adress och personnummer registreras. Ett sjukhus har en eller flera kliniker och varje klinik har en eller flera avdelningar. Nu gör vi en domänmodell av domänbeskrivningen! En svårighet när vi ska modellera är att veta hur man ska börja. Det behövs tumregler som hjälper oss när vi modellerar. Vi ska åskådliggöra detta genom att titta på hur ett exempel på en väldigt enkel domänbeskrivning. Det här är domänbeskrivningen: En patient som kommer till sjukhuset måste först skriva in sig vid en klinik, vilket innebär att patientens namn, adress och personnummer registreras. Ett sjukhus har en eller flera kliniker och varje klinik har en eller flera avdelningar. Låt oss nu göra en domänmodell av denna domänbeskrivning! Två tumregler vi använder inledningsvis när vi modellerar vår domän är, att alla substantiv i domänbeskrivningens text blir till klasser, och att alla verb blir till associationer. Problem: Svårt att veta hur ska man börja skapa en domänmodell från en domämbeskrivning Tumregler: Låt substantiv i domänbeskrivningen representeras av klasser i domänmodellen Låt verb i domänbeskrivningen representeras av associationer i domänmodellen

Ett första försök Adress Avdelning Personnummer Namn Patient Klinik
har har har har skriver in sig vid Patient Klinik I vår text hittar vi substantiven patient, namn, adress, personnummer, avdelning, klinik och sjukhus. Vi skapar klasser för dessa. Vi ser sedan att patienten dels skriver in sig vid en klinik, dels kommer till sjukhuset. Det leder till att vi skapar två associationer för dessa verbfraser. Av domänbeskrivningen framgår också att patienten har namn, adress och personnummer. Relationerna mellan dessa termer/begrepp blir också associationer. Vi ser också att sjukhuset har kliniker och att kliniker har avdelningar. Även dessa relationer representeras av associationer. Vi har nu skapat ett förslag på en modell av domänbeskrivningen från föregående bild och visualiserat modellen i ett klassdiagram. Notera också att klasserna alltid anges i singularis. Det står ”avdelning” och inte ”avdelningar” har kommer till Sjukhus

Allt kan inte modelleras
Adress Avdelning Personnummer Namn har har har har skriver in sig vid Patient Klinik har kommer till Sjukhus I detta fallet hade vi en relativt enkel domänbeskrivning. Vanligtvis innehåller domänbeskrivningarna betydligt mer termer och begrepp och allt kan inte modelleras. Då bör man fokusera på de centrala termerna/begreppen. Vi följer då tumregeln: allt i domänbeskrivningen behöver inte representeras i domänmodellen – bara det centrala. Vilka är då de centrala termerna/begreppen? Det finns inget generellt svar på detta eftersom det beror på syftet med modelleringen. Problem: Om allt i domänbeskrivningen ska representeras i domänmodellen kommer denna snabbt växa Tumregel: Allt i domänbeskrivningen behöver inte representeras i domänmodellen – bara det centrala. Vad är då det centrala? Det beror på syftet med domänmodellen.

Allt kan inte modelleras
Adress Avdelning Personnummer Namn har skriver in sig vid Patient Klinik Ett exempel kan förtydliga. Det kanske inte viktigt att modellera att en patient kommer till ett sjukhuset. Det räcker med att beskriva att patienten skriver in sig vid en klinik. har kommer till Sjukhus

Associationer kan bli klasser
Adress Avdelning Personnummer Namn har har har har skriver in sig vid Patient Klinik har Men domänbeskrivningen skulle också kunna modelleras på ett annat sätt. Anta att vi vill beskriva att en patient skriver in sig vid en klinik vid ett specifikt datum, men termen/begreppet datum bör varken associeras med patient eller med klinik. Snarare bör datum associeras med associationen ”skriver in sig vid”. Ett sätt att hantera detta är att skapa en klass av associationen ”skriver in sig vid” för att på så sätt associera datum till denna nyskapade klass. Vi följer här en ny tumregel: en del associationer görs till klasser och verben substantiveras därmed Sjukhus Problem: - Om kliniken vill dokumentera vilket datum patienten skriver in sig. Till vilken klass ska datum associeras? Datum hör snarast till associationen ”skriver in sig vid”! Tumregel: - En del associationer görs till klasser och verben substantiveras därmed

Associationer kan bli klasser
Adress Avdelning Personnummer Namn har har har har Patient Klinik vid genomför har Vi substantiverar helt enkelt verbfrasen ”skriver in sig vid” och skapar substantivet ”inskrivning”. Till denna nyskapade klass kan nu klassen datum associeras. Fortfarande gäller de två tumreglerna från föregående bild. Nu kan vi dock utöka med en tredje tumregel: en del centrala verb, som till exempel skriver in sig vid, görs om till klasser genom att verbet substantiveras, i vårt exempel till inskrivning. Datum vid Inskrivning Sjukhus

Klasser kan bli attribut
Adress Avdelning Personnummer Namn har har har har Patient Klinik vid genomför har Vi har ännu inte introducerat några attribut. Några av klasserna borde snarare fungera som attribut. Även här kan vi följa en tumregel: företeelser som i verkligheten fungerar som egenskaper hos ting kan göras till attribut hos klasser. Datum vid Inskrivning Sjukhus Problem: - Några klasser borde kunna göras om till attribut. Vilka? Tumregel: - Företeelser som i verkligheten fungerar som egenskaper hos ting kan göras till attribut hos klasser

Klasser kan bli attribut
Patient Avdelning personnummer namn adress namn har Klinik namn genomför vid har En patient har egenskaperna namn, adress och personnummer. De tre senare termerna/begreppen kan med fördel göras om till attribut i klassen patient. Notera också hur introduktionen av attribut förbättrade överblicken av modellen. Sjukhus Inskrivning namn datum

Klasser kan bli attribut (fortsättning)
Avdelning namn har Klinik namn vid har Sjukhus Inskrivning namn I denna bild har även patient blivit ett attribut. Det är dock inte särskilt lyckat om en patient har egenskaper eller bör associeras med andra termer/begrepp. I så fall bör patient vara en egen klass. Notera med andra ord att attribut som själva bör ha attribut, associationer eller operationer bör göras om till klasser. Endast klasser kan ju ha attribut, associationer och operationer datum patient Notera Attribut som själva bör ha attribut, associationer eller operationer bör dock göras om till klasser. Attributet patient har ju egenskaper som namn, adress och personnummer. Därför bör det vara en klass! Endast klasser kan ju ha attribut, associationer och operationer

Datum som egen klass? Patient Avdelning Klinik Sjukhus Inskrivning
personnummer namn adress namn har Klinik namn genomför vid har Sjukhus Inskrivning Även attributet datum skulle kunna göras om till en klass. Till exempel så kan attributet datum kan göras om till klass om det finns behov av följande operationer: konvertera mellan kalendrar, verifiera att en viss dag finns eller om det är helgdag. Dessa operationer hör snarare till datum än till inskrivning. Vi kan här följa tumregeln: ett attribut kan göras om till klass om det finns operationer som vi vill utföra på objektet. namn datum Problem: När skulle det vara motiverat att ha till exempel datum som egen klass? Tumregel: - Ett attribut kan göras om till klass om det finns operationer som vi vill utföra på objektet. Till exempel så kan attributet datum kan göras om till klass om det finns behov av följande operationer: konvertera mellan kalendrar, verifiera att en viss dag finns eller om det är helgdag

Datum som egen klass? Patient Avdelning Klinik Datum Sjukhus
namn personnummer namn adress har Klinik har Datum namn datum kollaOmHelgdag() kollaOmDagFinns() konverteraKalendrar() har genomför vid Sjukhus Datum har i denna modell blivit en egen klass med operationerna kollaOmHelgdag(), kollaOmDagFinns() och konverteraKalendrar(). Notera dock att vi rekommenderar att på denna grundnivå i objektorienterad analys och design inte göra datum till egen klass utan låta datum vara attibut. namn vid Inskrivning Notera Det rekommenderas dock inte att skapa en datumklass i denna kurs!

Multiplicitet för att precisera begrepp
Patient Avdelning personnummer namn adress namn har Klinik har namn genomför vid har Sjukhus Inskrivning Det är dock fortfarande oklart vad vi menar med de olika termerna/begreppen i domänmodellen. För att precisera dem (minska tolkningsutrymmet) måste vi ange multiplicitet. namn datum Problem: Fortfarande oklart vad vi menar med termer/begrepp i domänmodellen Tumregel: Ange multiplicitet för att mer precist definiera termer/begrepp

Multiplicitet för att definiera begrepp
Patient Avdelning personnummer namn adress namn 1..* har 1..1 Klinik 1..1 1..1 namn genomför 1..* vid har 1..1 I denna bild är multipliciteten angiven och vi har precist definierat vad vi menar med olika termer/begrepp. Patient är någon som genomför en eller flera inskrivningar. En person är alltså patient först när han eller hon är inskriven vid en klinik. Denna definition skulle kunna ifrågasättas. Om en person kommer akut till ett sjukhus och inte hinner skrivas in före operation, är denna person då inte en patient? 0..* Sjukhus Inskrivning namn datum 1..*

Associationer kan ersättas med attribut
Patient Avdelning personnummer namn adress namn 1..* har 1..1 Klinik 1..1 1..1 namn genomför 1..* vid har 1..1 0..* Sjukhus Inskrivning namn När en modell som denna ska ligga till grund för ett databasschema eller ett Javaprogram måste associationerna ersättas. Av vad och hur? datum 1..* Problem: Vid implementation (i form av databasschema och/eller (Java)program) måste associationerna ersättas. Av vad? Hur?

Associationer kan ersättas med attribut
Patient Inskrivning personnummer namn adress genomför datum 1..1 1..* Patient I konceptuell modellering ska dock associationer användas då sådana är betydligt mer visuella än attribut. Utan associationer ser vi inte lika omeddelbart hur klasserna är associerade Inskrivning datum patient [1..1] personnummer namn adress inskrivning [1..*] Associationerna ersätts med attribut. Antingen får en av klasserna ett attribut som representerar en riktning i associationen eller så får båda de associerade klasserna får varsitt nytt attribut (som i ett exemplet ovan) som då representerar båda riktningarna i associationen. Attributen får den multipliciteten som fanns i associationsänden när vi läste från respektive klass. Tumregel: Associationerna ersätts med attribut. Antingen får en av klasserna ett attribut som representerar en riktning i associationen eller så får båda de associerade klasserna får varsitt nytt attribut (som i ett exemplet ovan) som då representerar båda riktningarna i associationen. Attributen får den multipliciteten som fanns i associationsänden när vi läste från respektive klass.

UML Aktivitetsdiagram

UML Aktivitetsdiagram
Välkommen till denna presentation av UML:s aktivitetsdiagram (eng. activity diagram). Ett förenklat exempel på ett aktivitetsdiagram visas i bilden. Aktivitetsdiagrammen använder vi för att modellera olika slags aktiviteter (eng. activities). Ett aktivitetsdiagram modellerar en aktivitet, det vill säga ett diagram visar en aktivitet. Aktivitetsdiagrammet illustrerar ordningen, flödet, bland en mängd aktioner (eng. actions) associerade med ett särskilt objekt eller en mängd av objekt. Det beskriver sekvensreglerna för dessa aktioner, det vill säga i vilken ordning de kommer. Tillsammans utgör aktionerna alltså aktiviteten. Aktivitetsdiagram har likheter med flödesscheman. Den största och viktigaste skillnaden är att aktivitetsdiagram stödjer modellering av parallella sekvenser av aktioner. I tidigare UML-versioner var aktivitetsdiagram ett specialfall av tillståndsmaskinsdiagram, men från UML 2.0 är den kopplingen bruten. Aktivitetsdiagrammen kan numera ses som flöden av en eller flera markörer (eng. tokens) som visar vilka aktioner som är aktiverade. Vi återkommer till detta senare i presentationen.

Verkligheten och UML-modeller
Verksamhetsprocesser (i aktivitetsdiagram) Kommunikation mellan personer (i sekvensdiagram) Verksamhetsbegrepp (i klassdiagram) Användningsfall Vi placerar först in UMLs aktivitetsdiagram i ett större perspektiv. För detta använder vi bilden vi beskrev i sin helhet i föreläsningen UML översikt , bilden om verkligheten och UML-modeller. Aktivitetsdiagram kan användas på den övre nivån, där människor utför manuella aktiviteter. Aktiviteterna kan vara flöden av komplicerade användningsfall eller delar av verksamhetsprocesser. Aktivitetsdiagram kan även användas på den undre nivån, där datoriserad utrustning utför automatiska aktiviteter. Då kan vi modellera delar av procedurell logik i mjuk- respektive hårdvaruprocesser. Till exempel hur ett program kan exekvera. Aktivitetsdiagram Sekvensdiagram Informationsmodell (i klassdiagram) Verkligheten UML-modeller

Grundläggande notation
startnod (nod) initial node aktion (nod) action (node) aktion (nod) action(node) aktivitetsslut (nod) activity final flöde (kant) flow (edge) flöde (kant) flow (edge) flöde (kant) flow (edge) Den här bilden syftar till att förklara de mest grundläggande symbolerna som används i notationen för aktivitetsdiagram. Aktivitetsdiagram innehåller noder (eng. nodes) av ett antal olika slag. Bilden visar tre grundläggande slag av noder. Längst till vänster ser vi startnoden (eng. initial node). Denna nod anger var aktiviteten börjar. Vi ritar den som en stor svart punkt. Det får bara finnas en startnod i ett aktivitetsdiagram. Rektanglar med rundade hörn visar aktivitetens diskreta aktioner. Det kan finnas ett godtyckligt, men inte obegränsat, antal aktioner inom en aktivitet. I rektangeln skriver vi också in en lämplig, kortfattad text som beskriver aktionen i fråga. Notera alltså skillnaden mellan aktivitet och aktion. Ibland ser vi inkonsekventhet även i facklitteraturen runt användningen av dessa två termer och begrepp. Längst till höger ser vi en nod som visar aktivitetens slut (eng. activity final). Den ritar vi med en ring runt en likadan svart punkt som startnoden har. Det kan finnas fler än ett aktivitetsslut i ett aktivitetsdiagram; när något av dem nåtts avslutas aktiviteten. Aktivitetsdiagram innehåller också flöden (eng. flows). Flöden kan också helt synonymt kallas kanter (eng. edges). Ett flöde är alltid riktat från en nod till en annan och visas med en pil mellan noderna. Vi får ge en textbeskrivning av ett flöde om vi vill, men det sker sällan i praktiken.

Parallella beteenden förgrening (nod) AND split el. fork
förening (nod) AND join el. syncronization el. join Aktivitetsdiagram stödjer modellering av parallella sekvenser av aktioner. Med parallellt menas att aktioner kan utföras samtidigt, eller att vi inte vet vilken av aktionerna som ska utföras först. Många processmodelleringsspråk stödjer inte parallellt beteende. Parallellt beteende är vanligt i verksamhetsprocesser och i programmering med användning av oberoende trådar. När vi använder parallellism måste vi tänka på att aktionerna måste synkroniseras en eller flera gånger under exekveringen. Den notation vi använder för att visa parallellt beteende bygger på paret förgrening (eng. fork) och förening (eng. join). Notera dock att det från och med UML 2.0 inte är nödvändigt att balansera, det vill säga synkronisera, varje förgrening med exakt en förening. En förgrening ritar vi som ett tjockt svart streck. Varje förgrening har ett inflöde, och två eller fler grenar av utflöden, som alla måste utföras. När aktionen som föregår inflödet har slutförts påbörjas exekveringen av de utgående flödena. Men notera att varje gren av utflöden kan exekveras helt separat och godtyckligt, det vill säga i vilken ordning som helst, till och med sekvensiellt. Förgrening kallas ofta AND split. Förr eller senare måste dock alla grenar av flöden som gått ut från förgreningar förenas, eller synkroniseras. Notationen för detta är densamma som för en förgrening, med den skillnaden att nu finns det två eller fler grenar av inflöden. Viktigt här är att alla ingående flöden måste vara aktiverade för att det utgående flödet (de utgående flödena) ska börja exekveras. Förening kallas ofta AND join, eller synkronisering. Om man behöver göra en ny förgrening direkt efter en förening är det tillåtet att göra en kombination så att samma nod representerar både en förening och en förgrening.

Villkorsstyrda beteenden
beslut (nod) OR split el. decision villkor condition [ … ] [ … ] samgående (nod) OR join el. merge En mycket viktig egenskap för ett aktivitetsdiagram är att kunna modellera delar av aktiviteter, där nästa aktion i exekveringen beror av något villkor som ska uppfyllas. För detta använder vi notationsparet beslut (eng. decision) och samgående (eng. merge). Beslut visar vi med en diamant (en vriden fyrkant). En beslutsnod har alltid ett, och endast ett, inflöde, men flera utgående flöden. De utgående flödena är alla kopplade till varsitt booleskt villkor (eng. guard, el. condition). Villkoren anges inom hakparenteser i anslutning till respektive flöde. Endast ett av de utgående flödena kan vara sant samtidigt, och alla möjligheter måste vara täckta. Ett vägval görs alltså omedelbart när aktionen innan beslutsnodens ingående flöde har slutförts. Beslut kallas ofta ”OR split”. Ett samgående visar vi på samma sätt som ett beslut med den skillnaden att det nu finns fler än ett ingående flöde, men bara ett utgående flöde. Så fort någon av aktionerna som föregår ett ingående flöde har slutförts kommer det utgående flödet att aktiveras. Samgående kallas ofta ”OR join”.

Aktivitetsdiagram – kompletterat exempel
startnod aktion förgrening Ta emot order flöde Hämta böcker från lager Uppdatera kundpreferenser beslut Beräkna summa [Summa > 100] villkor Här har vi nu kompletterat aktivitetsdiagrammet från den första bilden med det vi har lärt oss hittills notationsmässigt, samt ett konkret textgivet exempel. Vi börjar i startnoden och följer flödena genom aktionsnoderna. Vi kommer till en förgreningsnod som ger parallella sekvenser av flöden. Vi kommer till en beslutsnod, med dess villkorade utgående flöden, som så småningom återförs i en samgåendenod. De parallella sekvenserna av flöden från förgreningen går också de så småningom samman, i föreningsnoden. Slutligen når vi noden för aktivitetsslut. [Summa <= 100] samgående Beräkna fraktavgift förening Beräkna ny summa Leverera order aktivitetsslut

Aktivitetsdiagram – partitioner
Ordermottagningen Leveransavdelningen Marknadsavdelningen Ta emot order Utförare/ansvarig Hämta böcker från lager Uppdatera kundpreferenser Beräkna summa [Summa > 100] Hittills har vi bara pratat om vad som sker i en aktivitet. Ofta vill vi också kunna beskriva vem som utför det som sker i aktiviteten. För programmeraren motsvarar det att kunna utläsa vilken klass som utför vad, och för affärsmodelleraren innebär det att kunna se vilken del av organisationen som utför vad. För detta ändamål kan vi använda oss av partitioner. Vi delar in aktivitetsdiagrammet på lämpligt sätt med hjälp av streck och ger varje partition ett beskrivande namn på utföraren eller den ansvarige. Partitioner kallades i tidigare versioner av UML för simbanor (eng. swim lanes). Namnbytet beror på att aktivitetsdiagrammen från och med UML 2.0 inte bara kan delas in endimensionellt, som på bilden, utan också med hjälp av ett tvådimensionellt rutnät, och även hierarkiskt. [Summa <= 100] Beräkna fraktavgift Beräkna ny summa Leverera order

Explicit förening och samgående
Explicit förening (nod) AND join el. Synkronisering el. join Explicit samgående (nod) OR join el. merge I tidigare UML-version: implicit samgående Numera, i UML 2.0 implicit förening Låt oss nu återkomma en stund till föreningar och samgåenden. Först en kort repetition: - förening är när vi explicit låter parallella flöden gå samman, det vill säga synkroniseras, också kallat AND join - samgående sker när vi explicit låter olika villkorsstyrda flödesgrenar åter börja följa samma flöde, också kallat OR join Det är dock tillåtet att låta multipla flöden gå direkt till en aktionsnod, utan att först passera en föreningsnod eller en samgåendenod Men notera här att i föregående version av UML betydde detta ett implicit samgående. I UML 2.0, däremot, har notationen ändrats till att istället betyda en implicit förening. På grund av att det finns uppenbar risk för missförstånd om vi använder den implicita notationsformen rekommenderas att vi alltid istället använder de explicita notationsvarianterna för både förening och samgående. Vi upprepar: använd explicit förening och explicit samgående! Använd explicit förening och explicit samgående!

Aktivitetsdiagram – signaler
Två timmar före avgång Packa väskorna Åka till flygplatsen Taxin kommer Ringa taxi Sändsignal Tidssignal Acceptsignal Tidssignal – inträffar när någon tidpunkt passeras diagrammet definierar hur aktiviteten reagerar på signalen Acceptsignal – tar emot en signal från en extern aktivitet diagrammet definierar hur aktiviteten reagerar på signalen Sändsignal – signal som skickas till en extern aktivitet triggar aktioner Aktivitetsdiagram kan också innehålla signalnoder. Vi ser på bilden ett enkelt aktivitetsdiagram. Diagrammet innehåller de tre signalnodstyperna som finns. Vi går nu igenom dessa. En tidssignal inträffar när någon viss tidpunkt passeras. Vad som sker när tidssignalen inträffar beror på hur diagrammet i övrigt ser ut. Acceptsignaler tar emot signaler från externa aktiviteter. Liksom för tidssignaler definierar diagrammet i övrigt vad som sker när signalerna tas emot. Slutligen finns sändsignaler, som är signaler som skickas till externa aktiviteter. Signaler kan alltså användas för att visa vad som sätter igång (triggar, eng. triggers) aktioner. Signaler kan användas för att visa vad som sätter igång (triggar, eng. trigger) aktioner

Aktivitetsdiagram – markörer
Markörer (eng. tokens) visualiserar flödet och flödets tillstånd. De rör sig, konsumeras och produceras, av noderna i diagrammet, längs med flödet. Markörerna kan sakna mening, eller de kan representera något objekt, till exempel en order. Små svartfyllda cirklar representerar markörerna. Två timmar före avgång Packa väskorna Åka till flygplatsen Taxin kommer Markörer (eng. tokens) visualiserar aktivitetens flöde och flödets tillstånd. Markörerna rör sig, konsumeras och produceras, längs med flödet i takt med att aktioner och andra noder exekverar. Markörerna kan sakna mening, eller de kan representera något objekt, till exempel en order. Små svartfyllda cirklar representerar markörerna. Vi åskådliggör med ett exempel. Vi låter noderna ”Packa väskorna” och ”Taxin kommer” innehålla varsin markör. Det innebär att föreningsnoden är klar att exekvera. Föreningsnoden exekverar och konsumerar därvid bägge inflödenas markörer, och producerar sedan en ny markör på sitt utflöde. Hade det nu varit en nod med flera utflöden så hade noden producerat en markör till alla utflöden. Undantaget är förstås beslutsnoder, som endast producerar en markör till ett av sina utflöden, styrt av gällande villkor.

Aktivitetsdiagram – markörer igen
Ta emot order Hämta böcker från lager Uppdatera kundpreferenser Beräkna summa [Summa > 100] Som en ytterligare exemplifiering av markörers konsumtion och produktion i ett aktivitetsdiagram går vi igenom det kompletterade aktivitetsdiagrammet från en tidigare bild, men nu med markörer som rör sig genom bilden. Vi börjar i startnoden och följer flödena genom aktionsnoderna. Vi kommer till en förgreningsnod som ger parallella sekvenser av flöden. Vi kommer till en beslutsnod, med dess villkorade utgående flöden, väljer en väg, och så småningom återförs vi i en samgåendenod. De parallella sekvenserna av flöden från förgreningen går också de så småningom samman, i föreningsnoden. Slutligen når vi noden för aktivitetsslut. [Summa <= 100] Beräkna fraktavgift Beräkna ny summa Leverera order

Fyra sätt att visa ett flöde på
Ta emot faktura Betala Konnektorer Ta emot faktura A A Betala Objektnod Ta emot faktura Order Betala Pins Vi kan visa flöden på fyra olika sätt. Varje sätt kan ha sina fördelar och nackdelar. Vi beskriver nu de fyra sätten i turordning. Det första sättet är det vi redan sett i tidigare bilder, det vill säga en enkel pil som visar flödet. Det är det enklaste och mest rättframma sättet. Om det börjar bli svårt att dra tydliga pilar som inte korsar varandra kan vi istället arbeta med konnektorer (eng. connectors). Då är det viktigt att konnektorerna ritas som par av ett utflöde och ett inflöde som bägge har samma beteckning. Nackdelen med att använda konnektorer är att vi lätt tappar den intuitiva överblicken över aktivitetens flöde. Det tredje sättet innebär att vi låter markörerna i flödet ersättas av meningsfulla objekt. Dessa objekt visas då i speciella objektnoder i form av klassrektanglar. Objektnoderna placeras mellan utflödesnoden och inflödesnoden. Det fjärde sättet är bara en variant av det tredje och innebär att vi ritar den vanliga flödespilen med tillägget att vi också ritar så kallade pins vid vardera utflödesnoden och inflödesnoden. Dessutom anger vi vid respektive pin namnet på objektet som ligger i flödet. Aktionsnoder kan ha parametrar, på samma sätt som metoder kan. Parametrarna representeras i UML med hjälp av de pins vi beskrivit tidigare. Dessa pins visar då data som behövs (input) och data som produceras (output). Vi kan alltså lägga ytterligare semantik på dessa pins; nu är objekten vi skickar inte bara med som information, utan de har en strikt betydelse vid exekveringen av aktivitetsdiagrammet. Därmed är presentationen av UML:s aktivitetsdiagram slut. Order Ta emot faktura Betala Order Pins kan också representera parametrar till och från noder och inte bara fungera som output- och input-data

Aktiviteter kan bestå av subaktiviteter
Ordermottagningen Leveransavdelningen Marknadsavdelningen Gaffelsymbol visar att detta är en subaktivitet Ta emot order Hämta böcker från lager Uppdatera kundpreferenser Beräkna summa [Summa > 100] Aktiviteter behöver inte bara bestå av aktioner utan även av aktiviteter, som vi kallas subaktiviteter (även om inte UML använder denna term). En gaffelsymbol visar att det handlar om en subaktivitet. [Summa <= 100] Beräkna fraktavgift Beräkna ny summa Leverera order

Subaktiviteter Uppdatera
kundpreferenser En subaktivitet kan bestå av aktioner och/ eller subaktiviteter Uppdatera kundpreferenser Subaktiviteten ”Uppdatera kundpreferenser” består av två aktioner Identifiera ny info om kund i ordern En subaktivitet består i sin tur av aktioner och/eller subaktiviteter. Det är alltså möjligt att modellera en aktivitet i form av en hierarki av subaktiviteter. Uppdatera kundstödssystem med ny info om kund

Input- och outputparametrar
Subaktiviteter kan också innehålla aktivitetsparametrar i form av input- och outputparametrar. Dessa input- och outputparametrar representeras som objektnoder på subaktivitetsgränsen. (I figuren nedan finns endast en inputparameter). Identifiera ny info om kund igenom analys av order Order Aktivitets-parameter i form av inputparameter (objektnod) Subaktiviteter kan också innehålla aktivitetsparametrar i form av input- och outputparametrar. Dessa input- och outputparametrar representeras som objektnoder på subaktivitetsgränsen. I bilden finns endast en inputparameter: Order. Uppdatera kundstödssystem med ny info om kund

Ytterligare exempel på subaktivitet
Notera att en subaktivitet inte behöver (men kan) innehålla en startnod och aktivitetsslut! Aktion Godkända datorer Produktions-material Konstruera datorer Testa datorer Ej godkända datorer Konstruerade datorer I denna bild finns aktivitetsparametrar, dels inputparametrar och dels outputparametrar till subaktiviteten. Dessa input- och outputparametrar till aktiviteten är objektnoder. Det finns ytterligare en objektnod i bilden, nämligen ”Konstruerade datorer”. Detta objektnod är output från aktionen ”Konstruera datorer” och input till aktionen ”Testa datorer”. Aktivitetsparameter i form av inputparameter (objektnod) Objektnod Aktivitetsparameter i form av output- parameter (objektnod)

Aktivitetsnoder - notation
Det finns tre typer av aktivitetsnoder: Aktionsnoder: Objektsnoder: Kontrollnoder: Testa datorer Produktions-material I ett aktivitetsdiagram finns det tre kategorier av aktivitetsnoder, nämligen aktionsnoder, objektsnoder och kontrollnoder.

Expansionsregion Välja ut tävlingsbidrag Offentliggör resultat
En aktion kan trigga en mängd instanser av en annan aktion. Eller uttryckt på annat sätt: en aktion kan producera flera tokens som ska exekvera en rad aktioner. Detta kan modelleras med hjälp av en så kallad expansionsregion. Producerade tokens hamnar då i en inpulista (lista med bidrag) och för varje token ska en eller flera aktioner exekvera. Varje token hamnar sedan i en outputlista (lista med bedömda bidrag). Välja ut tävlingsbidrag lista av bidrag Offentliggör resultat Implementera lösning Utforma tävlingsbidrag Bedöma tävlingsbidrag lista av bedömda bidrag

En övning

Domänbeskrivning Zoo International har specificerat en introduktionsrutin för att hantera djur som kommer till en av företagets djurparker. Först ska högsta ansvarig vid djurparken kontrollera den dokumentationen som djurleveranören hade med sig om djuret. Om någon dokumentation saknas begär den ansvariga komplettering från leverantören. När högsta ansvarig godkänt dokumentationen, kommer den ansvariga att fylla i ett formulär för att på så sätt dokumentera djuret enligt Zoo International egen standard. När formuläret är ifyllt ska djuret antingen gemomföra en medicinsk undersökning, eller träffa sina burkollegor. Denna senare aktivitetet måste övervakas av särksild personal. När den medicinska undersökningen och det nyanlända djuret har presenterats för sina burkollegor, så är introduktionsrutinen genomförd. Beskriv verksamhetsprocessen med hjälp av UML aktivitetsdiagram.

GES :OOS Objektorienterad analys och design Föreläsning1och 2

Liknande presentationer

En presentation över ämnet: "GES :OOS Objektorienterad analys och design Föreläsning1och 2"— Presentationens avskrift:

Liknande presentationer

Om projektet

Kontakta oss

Logga in

Logga in via sociala nätverk:

GES :OOS Objektorienterad analys och design Föreläsning1och 2

Liknande presentationer

En presentation över ämnet: "GES :OOS Objektorienterad analys och design Föreläsning1och 2"— Presentationens avskrift:

Liknande presentationer

Om projektet

Kontakta oss