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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Concurrent states Slut tilstand Ó Bennedsen 2001 Dynamik

Sending messages Ó Bennedsen 2001 Dynamik

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

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

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

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

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

Klassemodel (problemområdet) Ó Bennedsen 2001 Dynamik

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Binding - eksempel Ó Bennedsen 2001 Dynamik

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

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

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

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

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

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

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

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

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

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

Eksempel Stair: Fork Ó Bennedsen 2001 Dynamik

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

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

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