Programmering og systemudvikling

Præsentationer af emnet: "Programmering og systemudvikling"— Præsentationens transcript:

1 Programmering og systemudvikling
Lektion 5 Dynamik og interaktion Ó Bennedsen 2001 Dynamik

2 Formål Dynamik Teknikker til beskrivelse af begreber med et interessant dynamisk forløb. Sammenhæng mellem den dynamiske model og klassemodellen. Anvendelse af den dynamiske model gennem systemudviklingsforløbet. Hvorledes realiseres systemets funktionalitet (udtrykt i termer af brugsmønstre) ved hjælp af samarbejdende objekter. Sekvens diagrammer — hvad anvendes de til og hvornår? Ó Bennedsen 2001 Dynamik

3 Virkeligheden vs. systemet
Gift hændelse, der skal ændre tilstanden af de to involverede objekter Peter bliver associeret til Lise Ja - selvfølgelig gift Er ugift Er gift Ó Bennedsen 2001 Dynamik

4 Dynamiske syn Livsforløbet af et objekt
De (overordnede) tilstande der er for et objekt Overgange mellem tilstandene Hændelser Betingelser Attributter Adfærdsmønster der fastlægger de lovlige hændelsesforløb for ALLE objekter af en klasse Ó Bennedsen 2001 Dynamik

5 Hændelse En øjeblikkelig begivenhed der involverer et eller flere objekter begivenhed i problemområdet der skal afspejles i systemet. Øjeblikkelig skal defineres ex: Aftaleindgåelse Hændelse og use case: En use case beskriver en sammenhængende klump funktionalitet, der godt må have tidslig udbredelse En hændelse kan have parametre Ó Bennedsen 2001 Dynamik

6 Find hændelser Fokuser på udsagnsord i beskrivelser af systemet
Se på tilsvarende edb-systemer Se på faglitteratur Se på generelle typer Ó Bennedsen 2001 Dynamik

7 Vurder hændelser Hændelser skal være forretningsmæssige Check:
Beskriver hvad der kan ske i systemet bør være relevant for en eller flere use cases bør ikke beskrive hvad der sker ret teknisk Check: Er hændelsen atomar? Er hændelsen øjeblikkelig Kan hændelsen identificeres når den sker Ó Bennedsen 2001 Dynamik

8 Navngiv hændelser Brug simple og læsbare betegnelser
Brug betegnelser fra domæne modellen Vare solgt <> salg Brug enkle udsagnsord eller korte sætninger Brug betegnelsen om en enkelt hændelse Ó Bennedsen 2001 Dynamik

9 Hændelsestabel Lav en tabel over (alle) hændelsser i systemet og deres tilknytning til klasserne Fælles hændelse Sammenhæng mellem klasserne Ó Bennedsen 2001 Dynamik

10 Adfærd De lovlige hændelser samt deres sammenhæng beskriver hvordan objekter af en given klasse udvikler sig gennem tid jf. sekvensdiagram for use case Hændelsernes sammenhæng beskrives i et tilstandsdiagram vha: sekvens selektion iteration ... Ó Bennedsen 2001 Dynamik

11 Eksempel: Patient venteliste aflys indkald indkaldt udskriv udskriv
tilknytSeng tilknytSeng rekreer indlagt rekrevativ operer Ó Bennedsen 2001 Dynamik

12 Keep it simple Beskrivelsen af adfærden skal indfange alle hændelsesforløb, men ikke være unødigt kompliceret Lad være med at inkludere specielle og detaljerede forhold i diagrammet, men beskriv det almindelige forløb og lav en kommentar om de andre Brug hierarkiske beskrivelser ... ... Ó Bennedsen 2001 Dynamik

13 Adfærd og arv Adfærd nedarves fra superklassen til subklassen
Subklassen har alle superklassens hændelser Subklassen skal overholde superklassens adfærdsmønster Overtræksretskonto: Konto: Ó Bennedsen 2001 Dynamik

14 Patient klasse Enten tilstands- attribut eller andet Hændelser
fra til- stands- diagram Ó Bennedsen 2001 Dynamik

15 Repræsentation af hændelser
En hændelse er et udtryk for en betydningsfuld forandring i domænet som skal afspejles i edb-systemets modelkomponent Overvej om der skal holdes styr på de hændelser der er indtruffet Påvirker kun saldoen, men vi vil gerne holde styr på rækken af indsættelser og hævninger Ó Bennedsen 2001 Dynamik

16 Repræsentation af hændelser (2)
Selektion og sekvens kan repræsenteres af en attribut, iteration kræver som oftest en ny klasse Ó Bennedsen 2001 Dynamik

17 Repræsentation af hændelser (3)
Ó Bennedsen 2001 Dynamik

18 UML Tid Aktivitet i tilstanden Start tilstand Betingelse Handling på
overgangen Ó Bennedsen 2001 Dynamik

19 Concurrent states Slut tilstand Ó Bennedsen 2001 Dynamik

20 Sending messages Ó Bennedsen 2001 Dynamik

21 Kontekst CALL BEFOREPGM Ó Bennedsen 2001 Dynamik USING RESPFROMCALL,
SELF-I, THISOPERATION IN CONCRETEPGM ATTRNAME-I. IF SEVERITY IN RESPFROMCALL > 3 MOVE RESPFROMCALL TO RESPONSE-O GO TO L-CHECK-ERROR END-IF. PERFORM P-GETATTRIBUTE THRU P-GETATTRIBUTE-X. IF SEVERITY IN RESPONSE-O > 3 Ó Bennedsen 2001 Dynamik

22 Sekvens diagram Control focus Objekt Attribut Aktuelle parametre Tid
aCustomer anOrder aPayment aDiscountAgrement debt(date) price Aktuelle parametre Tid amount discount(totalPrice, discountedPrice) besked operation Ó Bennedsen 2001 Dynamik

23 Besked En besked svarer til et konkret kald af en operation (eller en aflæsning af en attribut) Parametre i besked er aktuelle parametre attribut, rolle.attribut, rolle.rolle.attribut,.. fast værdi medsendt parameter Ó Bennedsen 2001 Dynamik

24 Formål med sekv. diag Arbejdsredskab Produkt til brug for test
til design af funktionalitet operationer afledte attributter til overblik/fokus på ansvarsdelegering mellem klasser Produkt til brug for test Ó Bennedsen 2001 Dynamik

25 Eksempel Ó Bennedsen 2001 Dynamik Ordremodtager Ordremodtagelse «Uses»
Kunde_gæld «Uses» Debitorstatistik Kvartalsstatistik Ó Bennedsen 2001 Dynamik

26 Klassemodel (problemområdet)
Ó Bennedsen 2001 Dynamik

27 Kunde_gæld Bruger: Ordre-modtager, Kvartalsstatistik
Formål: At beregne kundens gæld Hvad sætter casen igang: Ordremodtagelse, eller Kvartalsstatistik Startbetingelse: Kunden skal have tilknyttet allerede ekspederede ordrer indenfor den specificerede periode Hyppighed/frekvens: Ca. 50 gange om dagen (Odremodtagelse), ca. 1 gang pr. kunde pr. kvartal (Kvartalsstatistik) Ó Bennedsen 2001 Dynamik

28 Kunde_gæld(2) Beskrivelse: Ordre-modtager:
1) Kundeoplysninger initieres (jf. hoved-Use Case) 2) Beregningsdato initieres 3) Beregning af kundegæld pr. dato anfordres SYSTEM: 4) Den angivne Kundes gæld beregnes pr. den angivne dato : Gælden beregnes som prisen for alle kundens ikke afsluttede ordrer fratrukket evt. indbetalinger og rabat. Ó Bennedsen 2001 Dynamik

29 Kunde_gæld(3) a) Følgende ordrer indgår i beregningsgrundlaget :
* Der skal eksistere en reference til kunden (fra input) * Må ikke være afsluttet (afslutningsdato ikke udfyldt) * Ordre-optagelsesdatoen skal være mindre end beregningsdatoen b) Summen af ikke-afsluttede ordrers pris beregnes : * Ordrelinierne til ovenstående ordrer udsøges * Prisen på den enkelte ordrelinie beregnes på baggrund af det registrerede kvantum og prisen (fratrukket rabat) på den tilknyttede vare. * Prisen for den samlede ordre summeres på baggrund af ordrelinierne. Ó Bennedsen 2001 Dynamik

30 Kunde_gæld(4) c) Indbetalinger knyttet til kunden summeres :
* Indbetalingsdatoen skal være mindre end beregningsdatoen d) Kundens rabat beregnes med udgangspunkt i den samlede pris for kundens totale ordremængde. [Undtagelse 1] : Prisen for kundens ordrer fratrukket indbetalinger og rabat giver et negativt beløb] Sluttilstand:Kundens gæld er beregnet, evt. er markeret at kundens gæld er negativ. Undtagelser: 1) : Kundens gæld returneres som et negativt beløb, dog medsendes også en markering af, at dette er tilfældet, således at resultatet ikke forveksles med en regnefejl. Ó Bennedsen 2001 Dynamik

31 Sekvens diagram aCustomer anOrder aPayment aDiscountAgreement
debt(date) For all Orders associated with this Customer where Orders.admissionDate<date price For all Payments associated with this Customer amount sum(Payments.amount) if Payments.admissionDate<date then discount(totalPrice,discountedPrice) DiscountAggreement.discount Ó Bennedsen 2001 Dynamik

32 Niveau aCustomer anOrder aPayment anDiscountAgreement debt(date) price
amount discount(totalPrice,discountedPrice) Ó Bennedsen 2001 Dynamik

33 Niveau (2) Egenskaben price på Item er begrenet  aflæsning i anden klasse Order OrderLine Item Price price price price Ó Bennedsen 2001 Dynamik

34 Niveau (3) (En del af) niveauet fastlægges allerede i use case struktureringen: gentagne dele af use case  udfaktorisering vha. <<uses>>  kunde.1 hele «uses» udfaktoriseret del Ó Bennedsen 2001 Dynamik

35 Udvidelser <<uses>>  <<extends>>  exceptions
flaghejsning, eksplicit kodning (besk. i description feltet) cvblæckvbkæcvhbcv Hjkgfhjkhjkblcvbc vcbcvbcvbcvbcv bcvb cvbcv bcvbcvbcvbcvbcvbcvb Extends <diagramnavn, entydig placering> Ó Bennedsen 2001 Dynamik

36 Alt dette lyder meget godt men ...
Husk det skal være naturligt for en klasse at ”eje” egenskaben forestil dig at objektet er levende - giver det mening at spørge det om egenskaben? Ó Bennedsen 2001 Dynamik

37 Agent Hvad sker der, når jeg forsøger at sende en buket blomster til Alice i Svendborg? Ó Bennedsen 2001 Dynamik

38 Interaktion Vi opfatter klasserne som agenter, der kan foretage en række handlinger Beskrevet i klassens grænseflade Vi skal beskrive samarbejdet mellem klasserne: Ó Bennedsen 2001 Dynamik

39 Hjælpemidler til egenskabsplacering
Fornuft Erfaring shopping list approach Retningslinier GRASP patterns Best practices Tommelfingerregler Ó Bennedsen 2001 Dynamik

40 CRC-kort Class responsibility card navnet på klassen klassens ansvar
de klasser der samarbejdes med for at opnå ansvaret Ó Bennedsen 2001 Dynamik

41 Kobling Afhængighed mellem klassers egenskaber
Minimer en klasses afhængighed af andre klassers egenskaber (viden og kunnen) sådan at ændringer et sted påvirker andre mindst muligt! Minimer Kobling! Ó Bennedsen 2001 Dynamik

42 Kobling - eksempel totalPriceOrders :
forAll(Orders where Orders.admissionDate < debtDate) do sum(Order.price) totalPriceOrders:= 0; Per Order forAll(Order.OrderLines) do Per OrderLine x:= sum(OrderLine.Item.Price.price)) totalPriceOrders:= totalPriceOrders + x Ó Bennedsen 2001 Dynamik

43 Specielt om kobling! Hierarkier Aggregering (UML’s ”Composition”)
En superklasse bør være LØST koblet med sine subklasser En subklasse ER STÆRKT koblet med sin superklasse Aggregering (UML’s ”Composition”) Den ”indeholdende klasse” ER STÆRKT koblet med sit indhold Indholdet ER STÆRKT koblet med den ”indeholdende klasse” Ó Bennedsen 2001 Dynamik

44 Binding Entydighed indenfor en klasses egenskaber
Maximer entydigheden i en klasses ansvar så ansvaret for det samlede system er fordelt på en entydig og overskuelig måde Maximer samhørigheden mellem klassens egenskaber så klassens ansvar er veldefineret også udenfor det aktuelle system Tilstræb høj grad af Binding! Ó Bennedsen 2001 Dynamik

45 Binding - eksempel Ó Bennedsen 2001 Dynamik

46 Hvor skal operationen placeres?
Har koen en ”afMælk” operation eller har mælken en ”udKo” operation? Det er ikke altid oplagt at operationalitet kan placeres på et domæne begreb Ó Bennedsen 2001 Dynamik

47 Kontrolklasse Når ”styringen” af en use case ikke kan placeres
operation på speciel klasse - kontrolklasse kontrolklasse  procedure En kompleks use case  en eller flere kontrolklasser Ó Bennedsen 2001 Dynamik

48 Et eksempel Vi ønsker at ændre leveringen af en bestemt vare -
”Flytte” varen til en anden ordre Ó Bennedsen 2001 Dynamik

49 Flyt ordrelinie BRUGER: 1) Følgende indtastes : Kundenummer, FraOrdre,
TilOrdre, Vare SYSTEM: 1) Ordrerne fremfindes udfra ordrenumrene. 2) Hvis FraOrdren ikke er leveret flyttes netop den Ordrelinie, som er knyttet til den indtastede Vare. [Undtagelse 1) FraOrdren er leveret] 3) Den relevante ordrelinie knyttes til den indtastede TilOrdre. [Undtagelse 2) TilOrdren har allerede en Ordrelinie med denne Vare] Ó Bennedsen 2001 Dynamik

50 flytOrdrelinie (2) Sluttilstand:
Ordrelinien er flyttet til den ønskede ordre Undtagelser: 1) FraOrdren er ekspederet: Der gives en fejlmeddelelse 2) TilOrdren har allerede en OrdreLinie for den aktuelle Vare: Antallet på den eksisterende OrdreLinie opdateres med antallet fra den flyttede OrdreLinie. Ó Bennedsen 2001 Dynamik

51 Flyt ordrelinie (2) Hvor skal operationen der styrer flow’et i use case’n placeres? Order OrderLine Customer Item moveOrderLine kontrolklasse Ó Bennedsen 2001 Dynamik

52 FlytOrdreLinie (3) Ó Bennedsen 2001 Dynamik moveOrderLine OrderLine
moveOrderLine(fromOrder, toOrder, customer, item) state if fromOrder.state<>delivered then fromOrderLine:= select from fromOrder.OrderLines select where OrderLine.Item=item Delete fromOrderLine.delete CREATE(toOrder,...) OrderLine.CREATE(toOrder, info from fromOrderLine) Ó Bennedsen 2001 Dynamik

53 Typer af kontrol ”Fork” struktur: En operation styrer
kalder alle andre operationer ”Stair” struktur: Ansvaret er delegeret Der er ingen "central" klasse. Alle klasser kender kun få andre klasser - ved hvilken klasse der kan hjælpe med en specifik egenskab. Ó Bennedsen 2001 Dynamik

54 Stair versus fork En ”stair” struktur bruges når:
operationerne er tæt koblede Klasserne er aggregeringsstruktur Associeringerne repræsenterer en fast tidsmæssig sammenhæng advertisement-order-invoice-delivery- payment operationerne altid skal udføres i den samme rækkefølge Ó Bennedsen 2001 Dynamik

55 Stair vs. Fork (2) En ”fork” struktur anvendes når:
operationerne kan/vil ændre rækkefølge nye operationer skal kunne indføjes der er tale om en kontrolklasse Ó Bennedsen 2001 Dynamik

56 Eksempel Stair: Fork Ó Bennedsen 2001 Dynamik

57 3 lags arkitektur Grænseflade- komponent <<interface>>
Funktions- komponent <<control>> Model- komponent <<entity>> Ó Bennedsen 2001 Dynamik

58 Processen og klassemodellen
Mønstre class Customer { ….. } Interaktion Claus Mønstre Dynamik Ó Bennedsen 2001 Dynamik

59 Endemål Mål: Udvikling af et system, der består af en række samarbejdende objekter Struktur af systemet: Class8 Class3 Class4 Class7 Class1 Class8 Class3 Class4 Class2 Class7 Class6 Class1 Class9 Class5 Class3 Class4 Class7 Class1 Class1 Class4 1 2 3 4 5 6 7 8 9 Grænse flade Grænse flade kompo- nent Funktions- komponent Model- komponent Persistens- kompoent Rela- tionel DB Ó Bennedsen 2001 Dynamik