GES OOS Objektorienterad analys och design Frelsning 1

GES : OOS Objektorienterad analys och design Föreläsning 1 och 2 Erik Perjons perjons@fc. dsv. su. se 1

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

Introduktion till modeller och modelleringsspråk 3

Verkligheten – tre nivåer Människor utför manuella aktiviteter Människor interagerar med datorer Datorer utför automatiserade aktiviteter 4

Verkligheten och modeller – tre nivåer Verksamhetsprocesser (i aktivitetsdiagram) Domänmodell (i klassdiagram) Interaktion med datorer (i användningsfall) Interaktion mellan objekt (i sekvensdiagram) Verkligheten Systemmodell (i klassdiagram) Grafiska modeller/diagram 5

Vad är en grafisk modell? - En grafisk modell är en förenklad och visualiserad beskrivning av en företeelse (oftast ett system) 6

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 7

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 8

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 -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? 9

Struktur- och beteendemodeller • Strukturella modeller/ strukturdiagram Verksamhetsprocesser (i aktivitetsdiagram) Domänmodell (i klassdiagram) • Beteendemodeller/ beteendediagram Interaktion med datorer (i användningsfall) Interaktion mellan objekt (i sekvensdiagram) Systemmodell (i klassdiagram) Modeller/diagram 10

Modeller skrivs i ett språk Begrepp i ett UML aktivitetsdiagram: aktion flöde förgrening samgående Språk är skrivet i ett Beteendediagram Begrepp i ett UML klassdiagram: klass attribut operation association Språk är skrivet i ett Begrepp i ett beteendediagram: ta emot order kontrollera order leverera order beskrivs av Strukturdiagram Begrepp i ett strukturdiagram: kund ordernummer beskrivs av System [Kleppe et al, 2003] 11

UML-diagram baseras på ett enda språk UML: s strukturdiagram och beteendediagram skrivs i samma språk Språk är skrivet i ett Beteendediagram beskrivs av Begrepp i ett beteendediagram: ta emot order, kontrollera order leverera order System Strukturdiagram Begrepp i ett strukturdiagram: kund, ordernummer beskrivs av [Kleppe et al, 2003] 12

Språkets notation vs semantik Grafiska modelleringsspråk består av: Språk är skrivet i ett Diagram 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 13

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 Begrepp i diagram: kund, ordernummer är skrivet i ett attribut definieras av Diagram har specificerat Språk beskrivs av System klass Notation En metamodell är en modell som beskriver (definierar) ett språks modelleringsbegrepp [Kleppe et al, 2003] 14

Modelleringsbegrepp – en jämförelse Klassdiagram E(A)R-diagram Databasdiagram Klass Entitetstyp (entitet) Tabell Association Relationstyp (relation) Främmande nyckel Attribut Kolumn Multiplicitet Avbildningsregler Objekt Instans (”entity occurence”) Rad eller post 15

Relationen begrepp och term Begrepp Term ”Dator” 16

Begrepp n Ett begrepp är en tankeenhet, en mental föreställning Begrepp av en eller flera företeelser i verkligheten Term ”Dator” [Hedin et al, 2000] 17

Term Begrepp n En term är en mer eller mindre godtycklig symbol för ett begrepp n En term kan bestå av artikulerade ljud, ett ord i form av bokstäver, en ordgrupp, eller en grafisk symbol Term ”Dator” n Term och ord kan ses som synonymer [Hedin et al, 2000] 18

Relationen begrepp och term Begrepp n För att använda ett begrepp måste man ha en term för det n Sambandet mellan begrepp och term bör vara så entydigt som möjligt, annars uppstår tolkningsproblem, som: n - Synonymi n - Polysemi Term ”Dator” [Hedin et al, 2000] 19

Relationen begrepp och term Begrepp Synonym A Termer x y z Polysem A B x Olika termer hänvisar till samma begrepp (”UML” och ”Unified Modeling Language” hänvisar till samma sak) Samma term hänvisar till olika begrepp. Det beror ofta på att det stipuleras nya betydelser för gamla termer. (”demokrati”, ”tjänstebaserad utveckling”) [Hedin et al, 2000] 20

Ogdens triangel (”Meaning triangle”) Charles Ogden (1889 -1957) 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 Referent Ogdens triangel Term ”Dator” [Sowa, 2000] 21

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 Referent Ogdens triangel Term ”Dator” 22

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 Referent Ogdens triangel ”Server” ”Skärm” Term 23

Ogdens triangel – ett användbart verktyg Begrepp Problem begrepp referent: • Verkligheten tolkas olika på grund av olika förförståelse Referent Problem begrepp - term • Synonym • Polysem Term ”Dator” ”Server” ”Skärm” 24

Ogdens triangel – ett användbar verktyg Begrepp - Begreppsdefinition - Begreppsmodell - Terminologi Referent Term ”Dator” ”Server” ”Skärm” 25

Vad gör vi när vi begreppsmodellerar? n 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 n Begreppsmodellering är ett instrument för att : - specificera begrepp oavsett vilka termer vi använder - specificera vilka termer som ska användas Kund Anställd Customer 1. . * Bankkonto Lönekonto Samma begrepp, olika termer Bank account [Hedin et al, 2000] 26

Vad gör vi när vi begreppsmodellerar? Begrepp x gift med ”gift med” y Term ”Nisse” x Referent ”gift med” Anna Nisse y ”Anna” 27

Vad gör vi när vi begreppsmodellerar? Begrepp Anna gift med ”gift med” Nisse Term ”Nisse” x Referent ”gift med” Anna Nisse y ”Anna” 28

n UML en översikt 29

UML – en översikt Vad är UML? 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, www. omg. org, [2] OMG, 2003, UML 2. 0 Superstructure Specification, www. omg. org ”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. 30

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 31

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 32

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) Diagram (13 st) Beteendediagram (7 st) 33

UML – strukturdiagram Klassdiagram Objektdiagram Strukturdiagram Paketdiagram Komponentdiagram Kompositstrukturdiagram Utplaceringsdiagram 34

UML – beteendediagram Aktivitetsdiagram Användningsfallsdiagram Tillståndsmaskinsdiagram Beteendediagram Interaktionsdiagram Sekvensdiagram Kommunikationsdiagram Interaktionsöversiktsdiagr. Synkroniseringsdiagram 35

I fokus för denna kurs Strukturdiagram: Beteendediagram: - Klassdiagram - Paketdiagram - Aktivitetsdiagram - Användningsfallsdiagram - Tillståndsmaskinsdiagram - Sekvensdiagram Strukturdiagram Diagram Klassdiagram Paketdiagram Aktivitetsdiagram Användningsfall Beteendediagram Tillståndsmaskinsdiagram Sekvensdiagram 36

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 38

UML klassdiagram och lite om objektdiagram Klass Association 39

Verkligheten och modeller – tre nivåer Verksamhetsprocesser (i aktivitetsdiagram) Domänmodell (i klassdiagram) Interaktion med datorer (i användningsfall) Interaktion mellan objekt (i sekvensdiagram) Verkligheten Systemmodell (i klassdiagram) Grafiska modeller/diagram 40

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 registrera. För. Kurs() Kurs är registrerad vid kurs. ID kursnamn

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 Student Registrera. Vid. Kurs() Operation (eller ”metodhuvud”) Attribut Notera att stor bokstav kan finnas mitt i texten om attribut och operation består av flera ord

Klasser representerar ofta grupperingar av ting i verkligheten Student personnr namn epostadress registrera. För. Kurs() Kurs kurs. ID kursnamn

Associationer representerar roller mellan dessa grupperingar av ting Student studentnummer namn epostadress Stad namn är registrerad vid Kurs kurs. D kursnamn har avslutat är huvudstad i tillhör Land 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 44

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) Student är registrerad vid kurs har registrerade Kurs 2) använda verb med fylld pil Student är registrerad vid Kurs 3) Använda substantiv nära klassen (notera hur detta ska läsas) Student kurs student Kurs

Associationer har riktningar Association med två riktningar Student Kurs Association med enriktning Student Kurs Kan tolkas som: a) association med två riktningar, eller b) att man inte visar riktningen/riktningarna Student Kurs

Attribut & associationer är egenskaper Student studentnummer namn epostadress kurs Kurs kurs. ID kursnamn Kurs kurs. ID 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. 47

Attribut & associationer är egenskaper Student studentnummer namn epostadress Kurs kurs. ID kursnamn Kurs kurs. ID Kursnamn Fråga: Vad händer om associationen bara har en riktning? 48

Attribut & associationer är egenskaper pilen på associationen reprensenterar navigerbarhet Student studentnummer namn epostadress Kurs kurs. ID 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 ”Nisse Hall” ”Anna Svan” Referent Symbol/Term ”Nisse Hall” ”Anna Svan” ”Nisse Hall” ”Student” 50

Klass och objekt Klasser (Enititetstyper) Kvinna Student Man Cecilia Björk Anna Svan Objekt (Instanser/ Entity occurences) Nisse Hall Zlatan 51

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

Klass- och objektdiagram Klass Objekt (instanser) studentnummer namn epostadress studentnummer= ” 850305 -1” namn = ”Nils Erik Hall” epostadress = ”hal@dsv. su. se” Kurs kurs. ID kursnamn : Student studentnummer= ” 770102 -1” namn = ”Anna Cecilia Svan” epostadress = ”sva@dsv. su. se” : Kurs kurs. ID=”” 2 I 400” kursnamn=”Data Base Design” Värden Objektdiagram: Klassens attribut har värden Länkar (”relationship occurrences”) Klassens associationer har länkar 53

Multiplicitet för associationer Kund kundnr namn epostadress 0. . * är lagd av 1. . 1 har lagt Order order. ID datum totalsumma 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 54

Multiplicitet – klass- och objektdiagram Kund kundnamn epostadress är lagd av 1. . 1 : Customer kundnummer=” 23122” namn=”Anna-Maria Lenngren” epostadress=”aml@hotmail” : Customer kundnummer=” 11145” name=”Zlatan” epostadress=”z@hotmail. com” 0. . * har lagt Order order. ID datum totalsumma : Order order. ID=” 9945361 datum=” 20070917” totalsumma=” 5124” : Order order. ID=” 9945362 datum=” 20070917” totalsumma=” 456” 55

Multiplicitet – en övning Hitta felen i objektdiagrammet – och/eller korrigera multipliciteten i klassdiagrammet så det blir korrekt Ägare personnummer 1. . * 1. . 1 Bil regnr : Ägare : Bil personnummer=“ 771134” regnr=“UML 123” : Ägare : Bil personnummer=“ 871211” regnr=“OMG 766” : Ägare : Bil Personnummer=“ 691223” regnr=“MDA 446" 56

Multiplicitet – en till övning Hitta felen i objektdiagrammet – och/eller korrigera multipliciteten i klassdiagrammet så det blir korrekt Student anna: Student nils: Student 1. . 1 0. . * Registrering 9: Registrering 2: Registrering 0. . * 1. . 1 Kurs oop: Kurs oos: Kurs 6: Registrering tove: Student jök: Kurs 57

Attribut har också multiplicitet Student personnr [1. . 1] namn [1. . 1] epostadress [1. . *] Registrering 1. . 1 0. . * registrerings. ID [1. . 1] 0. . * datum [1. . 1] Kurs 1. . 1 kurs. ID [1. . 1] kursnamn [0. . 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. 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. 58

Notes n Notes är kommentarer i UML-diagram. n Kan stå för sig själv – ej kopplat till något speciellt modelleringselement. n 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. n 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. Inkluderar högskolestudenter, men inte gymnasister. Student { Endast studenter som finns på SU } 59

En övning 60

Domänbeskring och uppgift n 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. n 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. n Uppgift: Gör en domänmodell I UML-klassdiagram baserad på domänbeskrivningen. 61

Modelleringspraktik för klassdiagram 62

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! 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 Personnummer Namn har Patient Avdelning har skriver in sig vid Klinik har kommer till Sjukhus

Allt kan inte modelleras Adress Personnummer Namn har Patient Avdelning har skriver in sig vid kommer till Klinik har Sjukhus 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. 65

Allt kan inte modelleras Adress Personnummer Namn Avdelning har Patient skriver in sig vid Klinik har kommer till Sjukhus

Associationer kan bli klasser Adress Personnummer Namn har Patient Avdelning har skriver in sig vid Klinik har 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 67

Associationer kan bli klasser Adress Personnummer Namn har har Patient Klinik genomför Datum vid Avdelning Inskrivning vid har Sjukhus 68

Klasser kan bli attribut Adress Personnummer Namn har har Patient Klinik genomför Datum vid Avdelning Inskrivning vid har 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 69

Klasser kan bli attribut Patient Avdelning personnummer namn har adress Klinik namn genomför vid Inskrivning har Sjukhus namn datum 70

Klasser kan bli attribut (fortsättning) Avdelning namn har Klinik namn vid Inskrivning har Sjukhus namn 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 71

Datum som egen klass? Patient Avdelning personnummer namn har adress Klinik namn genomför vid Inskrivning har Sjukhus 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 72

Datum som egen klass? Patient Avdelning namn personnummer har namn har Klinik adress Datum namn datum kolla. Om. Helgdag() kolla. Om. Dag. Finns() konvertera. Kalendrar() genomför har vid Sjukhus namn vid Inskrivning Notera - Det rekommenderas dock inte att skapa en datumklass i denna kurs! 73

Multiplicitet för att precisera begrepp Patient Avdelning personnummer namn har adress har Klinik namn genomför vid Inskrivning har Sjukhus 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 74

Multiplicitet för att definiera begrepp Patient Avdelning personnummer namn 1. . * adress 1. . 1 genomför vid 1. . * datum 1. . 1 Klinik namn 1. . * 0. . * Inskrivning har Sjukhus namn 1. . 1

Associationer kan ersättas med attribut Patient Avdelning personnummer namn 1. . * adress 1. . 1 genomför vid 1. . * 1. . 1 Klinik namn 1. . * 0. . * Inskrivning har Sjukhus namn datum Problem: - Vid implementation (i form av databasschema och/eller (Java)program) måste associationerna ersättas. Av vad? Hur? 1. . 1

Associationer kan ersättas med attribut Patient personnummer namn Inskrivning genomför 1. . * 1. . 1 datum adress Patient personnummer namn adress inskrivning [1. . *] 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] 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. 77

UML Aktivitetsdiagram 78

UML Aktivitetsdiagram 79

Verkligheten och UML-modeller Verksamhetsprocesser (i aktivitetsdiagram) Kommunikation mellan personer (i sekvensdiagram) Verksamhetsbegrepp (i klassdiagram) Användningsfall Aktivitetsdiagram Sekvensdiagram Informationsmodell (i klassdiagram) Verkligheten UML-modeller 80

Grundläggande notation startnod (nod) initial node flöde (kant) flow (edge) aktion (nod) action (node) aktion (nod) action(node) flöde (kant) flow (edge) aktivitetsslut (nod) activity final flöde (kant) flow (edge) 81

Parallella beteenden förgrening (nod) AND split el. fork förening (nod) AND join el. syncronization el. join 82

Villkorsstyrda beteenden beslut (nod) OR split el. decision villkor condition […] samgående (nod) OR join el. merge 83

Aktivitetsdiagram – kompletterat exempel startnod Ta emot order aktion förgrening flöde Hämta böcker från lager Beräkna summa Beräkna fraktavgift Uppdatera kundpreferenser beslut [Summa > 100] [Summa <= 100] villkor samgående förening Beräkna ny summa Leverera order aktivitetsslut 84

Aktivitetsdiagram – partitioner Ordermottagningen Leveransavdelningen Marknadsavdelningen Ta emot order Utförare/ansvarig Uppdatera kundpreferenser Hämta böcker från lager Beräkna summa Beräkna fraktavgift [Summa > 100] [Summa <= 100] Beräkna ny summa Leverera order 85

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 Använd explicit förening och explicit samgående! 86

Aktivitetsdiagram – signaler Två timmar före avgång Packa väskorna Taxin kommer Ringa taxi Sändsignal Tidssignal Åka till flygplatsen Acceptsignal – inträffar när någon tidpunkt passeras diagrammet definierar hur aktiviteten reagerar på signalen triggar aktioner 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 Signaler kan användas för att visa vad som sätter igång (triggar, eng. trigger) aktioner 87

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 Taxin kommer Åka till flygplatsen 88

Aktivitetsdiagram – markörer igen Ta emot order Uppdatera kundpreferenser Hämta böcker från lager Beräkna summa Beräkna fraktavgift [Summa > 100] [Summa <= 100] Beräkna ny summa Leverera order 89

Fyra sätt att visa ett flöde på Ta emot faktura Betala Konnektorer Ta emot faktura A A Betala Objektnod Order Ta emot faktura Pins Ta emot faktura Betala Order Pins kan också representera parametrar till och från noder och inte bara fungera som output- och input-data 90

Aktiviteter kan bestå av subaktiviteter Ordermottagningen Ta emot order Leveransavdelningen Gaffelsymbol visar att detta är en subaktivitet Uppdatera kundpreferenser Hämta böcker från lager Beräkna summa Beräkna fraktavgift Marknadsavdelningen [Summa > 100] [Summa <= 100] Beräkna ny summa Leverera order 91

Subaktiviteter Uppdatera kundpreferenser Identifiera ny info om kund i ordern Uppdatera kundstödssystem med ny info om kund En subaktivitet kan bestå av aktioner och/ eller subaktiviteter Subaktiviteten ”Uppdatera kundpreferenser” består av två aktioner

Input- och outputparametrar Subaktiviteter kan också innehålla aktivitetsparametrar i form av inputoch outputparametrar. Dessa input- och outputparametrar representeras som objektnoder på subaktivitetsgränsen. (I figuren nedan finns endast en inputparameter). Order Aktivitetsparameter i form av inputparameter (objektnod) Identifiera ny info om kund igenom analys av 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 Produktionsmaterial Konstruera datorer Testa datorer Konstruerade datorer Aktivitetsparameter i form av inputparameter (objektnod) Objektnod Godkända datorer Ej godkända datorer Aktivitetsparameter i form av outputparameter (objektnod)

Aktivitetsnoder - notation Det finns tre typer av aktivitetsnoder: Aktionsnoder: Testa datorer Objektsnoder: Produktionsmaterial Kontrollnoder:

Expansionsregion 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 Utforma tävlingsbidrag Bedöma tävlingsbidrag Offentliggör resultat lista av bedömda bidrag Implementera lösning

En övning 97

Domänbeskrivning n Zoo International har specificerat en introduktionsrutin för att hantera djur som kommer till en av företagets djurparker. n 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. n Beskriv verksamhetsprocessen med hjälp av UML aktivitetsdiagram. 98