Domænemodeller og Systemsekvensdiagrammer

PlanPlan

• TilstedeværelseTilstedeværelse

• Domænemodeller

Ø l d llé d l i f• Øvelse: modellér model over reservation af biografbillet

• Systemsekvensdiagrammer

2

DomænemodelDomænemodel

• Model over konceptuelle klasser/fænomener i et udsnit af problemdomænet (vi modellerer kun det der har relevans for den nuværende iteration og dens use‐cases)

• Hjælper os til at få et overblik over den verden vi skal modellere 

• Giver os et fælles vokabular omkring problemdomænet (tag udgangspunkt i kundens definitioner)

• Kan udvikles sammen med kunden• Ikke et Designklassediagram men kan bruges som 

inspiration til at udvikle detteinspiration til at udvikle dette– mindske den repræsentative kløft imellem domæne og kode

3

Består af:Består af:

• Klasser med navne og attributter samtKlasser med navne og attributter samt associationer imellem klasserne

association

KatPersonnavnfarvekøn

navn

Attributter

Klasse

4

Notationsform/konventionerNotationsform/konventioner

• Klasse‐ og attributnavne skrives medKlasse og attributnavne skrives med ”camelCase” hvis der indgår flere ord i navnet

• Klassenavne er altid med stort• Klassenavne er altid med stort begyndelsesbogstav

A ib l id d lill• Attributnavne er altid med lille begyndelsesbogstav 

ActivityRevision

revisionId

5

quota

Abstraktioner over problemdomænetAbstraktioner over problemdomænet

• Hvilke konceptuelle klasser og attributter er p grelevante at få med?– Bestemmes ud fra den kontekst vi arbejder medInden for det samme problemdomæne kan der– Inden for det samme problemdomæne kan der forekomme forskellige former for relevans alt efter hvilke bruger vi har med at gøreS f f j d l å I ikk d ll– Sørg for at afgrænse jeres model, så I ikke modellerer hele domænet, men kun den del I vil fokusere på (f.eks. med udgangspunkt i en use‐case)

• Mulige klasser/attributter til fænomenet Person– Navn, adresse, alder, køn, vægt, indkomst, uddannelse sygdomme kørekort kontonummeruddannelse, sygdomme, kørekort, kontonummer

6

Forskellig relevans JobcenterForskellig relevansLægeklinik

Jobcenter

Sekretær

Læge Person

Sekretær

navn

adresse sygdomme

indkomst

Tlf/email

indkomst

vægt

l k talder

uddannelse

kørekort Analyseinstitut

Bank lønkontoBank

Långiver

Analytiker

Forsikringsagent

7

Kandidater til konceptuelle kl / bklasser/attributter

• Tag udgangspunkt i jeres use‐casesll d k d d l kl– Alle navneord er kandidater til klasser

– 1. Assistenten anmoder om at oprette ny vare2. Systemet skifter til opret ny vare tilstand3. Assistenten registrerer den nye vare4 Systemet verificerer data for den nye vare4. Systemet verificerer data for den nye vare5. Systemet gemmer den nye vare (i varekataloget)6. Systemet informerer om at varen er gemt

• Brug kategorilisten fra bogen (s. 140 ‐ 141)T k i l i b li f d l b illi– Transaktioner: salg, reservation, betaling, forsendelse, bestilling 

– Hvad omhandler transaktionen: vare, service, måltid– Hvordan/hvor bliver transaktionen registreret: Kasseapparat, regnskabsbog, 

protokol, bestillingsliste, varekatalog– Hvem indgår i transaktionen: kunde, sælger, passager, grossist– Hvor foregår transaktionen: butik, biograf, web‐butik– …. 

8

Attribut eller klasse?Attribut eller klasse?

• Attributter er egenskaber ved en klasse som ikke selv kan have tt ib tt lt å i l t å t k t t l d/f l k diattributter altså simple typer såsom tekst, tal, sand/falsk‐værdier (boolean)– Hvis vi ikke anser fænomenet som værende af disse typer i den 

virkelige verden, er de det typisk heller ikke i domænemodellenvirkelige verden, er de det typisk heller ikke i domænemodellen• Undersøg bl.a. ved at spørge ”har fænomenet egenskaber og er de relevante?” 

hvis ja er det en klasse– Simple typer i den virkelige verden kan dog også anses som værende 

en klasse i domæne‐modellenen klasse i domæne modellen• Navn ‐> kan bestå af fornavn, mellemnavn, efternavn• Adresse‐> kan bestå af gade, nr, etage, by, postnummer• Cpr‐nr ‐> kan bestå af fødselsdato, århundrede, løbenummer, køn

Mål > ll t• Mål ‐> cm eller tommer• Penge ‐> hvilken valuta• Pris ‐> start og slutdato

– Handler igen om kontekst

9

Attribut eller klasse 2? JobcenterAttribut eller klasse 2?Lægeklinik

Jobcenter

Sekretær

Læge Person

Sekretær

navn

adresse sygdomme

indkomst

Tlf/email

indkomst

vægt

l k talder

uddannelse

kørekort Analyseinstitut

Bank lønkontoBank

Långiver

Analytiker

Forsikringsagent

10

AssociationerAssociationer

• Associationer imellem klasser fortæller noget om deres indbyrdes tilhørsforhold– A ejes af B ‐> Person ejer Kat– A er en del af B ‐> Bildør del af BilA er en del af B  > Bildør del af Bil– A indeholder B ‐> Klasselokale indeholder Studerende– A beskriver B ‐> Stamtavle beskriver Hund(se hele listen s 155 156)– (se hele listen s. 155 ‐ 156)

• Vær moderat med associationer, medtag kun de vigtigste, dem der fremmer forståelsen og fortæller 

d h knoget der er vigtigt at huske

Bildør Bil

Association 11

AssociationsmærkaterAssociationsmærkater

• For at gøre diagrammerne lettere at læse kanFor at gøre diagrammerne lettere at læse kan der tilføjes mærkater til associationerne – Mærkaterne skal fremme forståelsen ellers er de– Mærkaterne skal fremme forståelsen ellers er de ligegyldige. Er associeret til, har, bruger er alle dårlige eksempler, da de ikke siger mere end selve g p , gassociationsstregen

– Ud over den forklarende tekst kan en læseretningspil også tilføjes

Bildør BilIndgår i ‐>

Indeholder ‐> Bildør BilKlasselokale Studerende

12

Associationsmærkater IIAssociationsmærkater II• Vær opmærksom på at vi har med et statisk diagram at gøre og associationer i den 

sidste ende også bare er attributter for en klasse Associationer skal altså ikkesidste ende også bare er attributter for en klasse. Associationer skal altså ikkeudtrykke handlinger.

• Følgende er altså kun gyldige hvis vi kan omsætte associationen til en attribut –altså information vi ønsker at have viden om. Ellers er det handlinger og skal ikke med i modellenmed i modellen

• Dette vil også fremstå tydeligere hvis man prøver at vende læseretningen

Person PosteringSletter ‐> Postering

‐navn ‐ beløb

Person Posteringforetager ‐>

‐ beløb‐ slettetAf : Person

Postering

‐navn ‐ beløb

P P t iændrer ‐>

‐ beløb‐ foretagetAf : Person

Postering

ok

Person

‐navn

Postering

‐ beløb

ændrer  > Postering

‐ beløb‐ændretAf : Person

MultiplicitetMultiplicitet

• Multiplicitet udtrykker restriktioner forMultiplicitet udtrykker restriktioner for associationerne imellem de forskellige klasser– Restriktionerne skal fortolkes som værende udtryk yfor hvad der er tilladt i en bestemt situation eller tidspunkt

E P h k ét l i• En Person har kun ét navn selvom personen igennem sit liv kan skifte navn flere gange.

– Mulitiplicitet kan læses i begge retningen ved altid p gg gat tage den første klasse i associationen som værende ental

Klasselokale StuderendeIndeholder ‐>1 *

14

Multiplicitet 2Multiplicitet 2

• * ‐> 0 til mange• 1..*, 3..* ‐> udgangspunkt til mange• 3..10 ‐> bestemt interval• 10 ‐> bestemt• 3, 5, 10 ‐> flere bestemte• Igen er det konteksten der bestemmer hvilken multiplicitet vi 

modellerer– Selvom en Person typisk kun vil have en adresse vil det i folkeregister 

kontekst være relevant at have informationer om alle adresser en person har boet på og så adskille dem ved at kunne definere nuværende adresse og tidligere adresser

Person Adresse

Nuværende ‐>* 1

Tidligere ‐>* *

15

Tidligere  >

ProduktbeskrivelseProduktbeskrivelse

• Knytter sig til et ”produkt”Knytter sig til et  produkt

• Mere end bare en attribut, udgør metainformation omkring produktet en formmetainformation omkring produktet, en form for prototype

U d å d d d• Undgå redundant data– Ret kun data et sted

• Gør det muligt at få information om ”produkter” selvom der ikke er nogen på lager

16

Produktbeskrivelse VIP‐O‐MATICProduktbeskrivelse VIP O MATIC

• En postering beskriver en bestemt aktivitet udført af en VIP og hvor mange timer denne er blevet udført

• Første udkast kunne altså være følgende:Entry VIPEntry

namequotadescription

VIP

name1*

• Der sker tit at den samme aktivitet udføres mange gange med den samme timetakst, så vi kan løbe ind i problemer:

p

– Vi skal huske at skrive navnet og beskrivelsen ens– Vi skal huske hvad den typiske timetakst er– Hvis der sker ændringer, skal vi foretage dem i alle posteringer

17

Produktbeskrivelse VIP‐O‐MATIC 2Produktbeskrivelse VIP O MATIC 2

• Vi gør aktiviteten uafhængig af om der er oprettet posteringer eller j D t til kti it t f h ld t åej. Det er nu op til aktiviteten af holde styr på:– Navn– Beskrivelse

Takst– Takst• Der opstår dog nu det problem at vi ikke kan variere taksten hvis en 

postering f.eks. skal gøre det ud for 2 * aktivitet. Dette løses med en faktor

Entry

factor

VIP

name

Activity

name1**1

quotadescription

18

Produktbeskrivelse VIP‐O‐MATIC 3Produktbeskrivelse VIP O MATIC 3

• Der forekommer nu det problem at kvoten for en aktivitet kan ændre sig grundet forhandlinger og ændringer i aktivitetens omfang. Hvis vi ændrer taksten på aktiviteten vil tallet for allerede udførte posteringer p p gogså ændre sig. Vi skal altså have en form for revision/historik indbygget

E t VIPA ti it Entry

factoractivityRevisionId

VIP

name

Activity

namedescription

1**1

ActivityRevision

1

1..*

ActivityRevision

revisionIdquota 19

Afledte attributterAfledte attributter

• Det kan nogen gange ønskes at udtrykke enDet kan nogen gange ønskes at udtrykke en attribut som allerede er beskrevet via associationerne eller andre attributter Enassociationerne eller andre attributter. En sådan attribut kaldes en afledt attribut. Og beskrives ved hjælp af ”/” foran attributnavnetbeskrives ved hjælp af  /  foran attributnavnet

Person

Kat

navn

Har killinger*Person

fornavnmellemnavnefternavn

farvekøn/antalKillinger

1/navn

20

Attribut kravAttribut krav

• Sæt ekstra specifikationer på attributter hvis detSæt ekstra specifikationer på attributter hvis det fremmer forståelsen, er de f.eks. optionelle, kan ikke ændres, har en standard værdi, type, , yp

KristenVerden

type

Standard værdigudsSøn : PersontidAtSkabe : int = 7 {readOnly}pave : Person [0..1]

Kan ikke ændresKan ikke ændres

Optionel værdiOptionel værdi

21

ØvelseØvelse

• Brug 20 min. på at lave en domænemodelBrug 20 min. på at lave en domænemodel over en reservation til en biograffilm– Konceptuelle klasser/fænomenerp /– Attributter– Associationer

• Tag udgangspunkt i navneord fra jeres use‐case fra sidst og listen i bogen s. 140 ‐ 141

• Vi diskuterer bagefter jeres modeller og prøver at lave en samlet på tavlen 

22

Eks. på domænemodel for biografEks. på domænemodel for biograf

SystemsekvensdiagrammerSystemsekvensdiagrammer

• Supplement til use‐casesSupplement til use cases

• Visualisering af kommunikationen med systemet og dets feedback (input/output)systemet og dets feedback (input/output)

• Giver et godt overblik når vi skal til at designe kl k divores klasse‐ og sekvensdiagrammer

– Hvilken input skal behandles

– Hvilke resultater skal returneres til brugeren

24

Eksempel på SSDEksempel på SSD

• Tag udgangspunkt i succes‐scenariet fra denTag udgangspunkt i succes scenariet fra den use‐case der skal modelleres – Den primære aktør stilles over for systemet– Den primære aktør stilles over for systemet

Opret studieordning

:SystemTAP

25

• Identificer operationer brugeren anmoder systemet om df f db k fat udføre samt feedback fra systemet.

– Operationsnavne skrives med ”camelCase”, hvilket i denne omgang bare betyder at det er operation der udføres på g g y p ø psystemet

:System

Opret studieordning

TAPopretNyStudieordningp y g

inputNavn

l d fvalidering af navn

tilFøjKursus

kursus tilføjet studieordningkursus tilføjet studieordning

gemStudieordning26

• Find dernæst den information der skal overføres til systemet og tilføj den til operationerne

:System

Opret studieordning

TAPopretNyStudieordningp y g

inputNavn(navn)

l d fvalidering af navn

tilføjKursus(navn, takst)

kursus tilføjet studieordningkursus tilføjet studieordning

gemStudieordning27

• Hvis den samme operation kan udføres mere end en gang kan den omgrænses af en interaktionsen gang kan den omgrænses af en interaktions‐ramme med tilhørende betingelse

Opret studieordning

:System

p g

TAPopretNyStudieordning

inputNavn(navn)

validering af navn

type

tilføjKursus(navn, takst)

kursus tilføjet studieordning

gemStudieordning

loop [Flere kurser]

gemStudieordningbetingelse

28

Modulopgave 2Modulopgave 2• 3‐5 sider pr. person

Sk l i d h ld• Skal indeholde:– Domæne‐model(ler)– Klasse‐diagram(mer)– Use‐cases

Sekvens diagrammer for hver use case (i hvert fald 2)– Sekvens‐diagrammer for hver use‐case (i hvert fald 2)– Glossary med beskrivelser af termer brugt i problemdomænet, samt evt. restriktioner 

(valideringsregler)– Supplementerende specifikation med udgangspunkt i FURPS+

• Alle diagrammer ledsages af forklarende tekstg g• Kan indeholde

– Mockups brugt til test af jeres use‐cases– Systemsekvens‐diagram for use‐cases– Vision– ...

• Mindst 5 klasser i domænemodellen for at opnå en tilstrækkelig kompleksitet• Afleveringsdato: 20. nov. kl. 12.00 i aula

29

Eksamen kandidatEksamen kandidat

• Der er en fejl i studieordningDer er en fejl i studieordning– Følgende er forkert: 5‐8 sider eksklusiv programkode ekstern censurprogramkode, ekstern censur

• Jeg lægger en ny studieordning op på aula i dag som der er givet dispensation tildag, som der er givet dispensation til

30