Introduktion til SundhedsIT – koncepter og systemer

Præsentationer af emnet: "Introduktion til SundhedsIT – koncepter og systemer"— Præsentationens transcript:

1 Introduktion til SundhedsIT – koncepter og systemer
Uddybning af enkelte emner fra 1. semester

2 Dagens gang Præsentation af det kommende semester
Objekters adfærd samt opgave Generalisering og mapning samt opgave Aktivitetsdiagram og opgave Beskrivelsesteknikker til operationer og funktioner samt opgave

3 Præsentation af semesteret
..\index.html

4 Klasse struktur Flyvende ting Fly Helikopter Landingsbane Start
Flyveleder Landing 1 0..*

5 Adfærd Et objekt kommer ud for lidt af hvert i sit liv:
Et SK45:fly bliver lavet, letter, lander, letter, lander, letter og falder ned – Dette er hændelsesforløbet for SK45 Et SK46:fly bliver lavet, letter, lander, letter, lander… gange … letter og lander og bliver skrottet – Dette er hændelsesforløbet for SK46 Begge objekter tilhører klassen Fly. Reglerne for ”korrekt” / ”mulig” fly opførsel beskrives i et ADFÆRDSMØNSTER for klassen Fly

6 Adfærdsmønster Adfærdsmønsteret for fly definerer lovlig adfærd for objekter af klassen Fly (alt det som ikke er lovligt er ulovligt ) Adfærdsmønstre beskrives med lovlige tilstande for objekter og med de hændelser som ændrer tilstanden for objekterne til en anden lovlig tilstand lette Fly I luften På jorden lande

7 Tilstandsdiagrammer I
Adfærdsmønstre kan beskrives i tilstandsdiagrammer: Tilstande: Transformationer (her hændelser) I luften lande

8 Tilstandsdiagrammer II
Typiske strukturer i tilstandsdiagrammer: Selektion: I luften På jorden lande Falde ned Skrottet En af flere mulige hændelser

9 Tilstandsdiagrammer II
Typiske strukturer i tilstandsdiagrammer: sekvens: I luften På jorden lande + skrotte Skrottet Hændelser i fastlagt rækkefølge

10 Tilstandsdiagrammer III
Typiske strukturer i tilstandsdiagrammer: iteration: På jorden reparere Hændelser gentages uden Tilstandsskift Eller lette I luften På jorden lande

11 Tilstandsdiagrammer IV
Fødsel Betingelser Død Attributter

12 Opgave Tegn tilstandsdiagrammer for samtlige klasser Hændelserne er
lande melde klar få starttilladelse flyve ind reparere skrotte falde ned Opstil en hændelsestabel

13 Opgave mapning af generaliseringer
Brug mapningsreglerne til at mappe ovenstående strukturer og vurder hvilken der er bedst egnet.

14 Aktivitetsdiagrammet
Formål og notation Bennet kap.5

15 Aktivitetsdiagrammet (Activity diagram)
Formål: Beskrivelse af arbejdsopgaver og forretningsgange Beskrivelse af en funktion eller operation i systemet Aktivitetsdiagrammer er velegnede til at beskrive arbejdsopgaver i de tidlige faser i systemudviklingsforløbet. Forretningsaktivitetsdiagrammer kan være et godt udgangspunkt for definition af use cases. Til beskrivelse af operationer findes der bedre diagrammer! (fx sekvensdiagrammer) Activity diagrams can be used to illustrate different aspects of a system……. Activity diagram are particularly suitable for describing tasks in the early phases of systems development. Business activity diagrams can serve as a starting point for defining use cases. You can use activity diagrams to describe operations, but as you will find out later there are other diagrams which are much more suited for that. For instance sequence diagrams.

16 Notation Start tilstand Aktiviteter Transitioner Beslutningspunkt
Rektangler med runde hjørner Meningsfuldt navn Transitioner Pile med åbne pilehoveder Beslutningspunkt Betingelser Slut tilstand [campaign to add] [no campaign to add] Add a New Client Assign Staff Contact Add New Campaign The diagram uses the Agate case as an example. Agate is an advertising agency.

17 Notation Svømmebaner Lodrette kolloner
Angiver hvilken person, organisation eller afdeling, der er ansvarlig for aktiviteterne i kollonen Record Completion of a campaign Issue invoice Campaign Manager Client Accountant Pay invoice Record client payment

18 Notation Svømmebaner Lodrette kolloner
Angiver hvilken person, organisation eller afdeling, der er ansvarlig for aktiviteterne i kollonen Record Completion of a campaign Issue invoice Campaign Manager Client Accountant Pay invoice Record client payment

19 Write Chapter Review Chapter Author Printer Typesetter Reviewer Typeset Book Correct Proofs Reset Book Print Book [book complete] [book not complete] Revise Chapter AKTIVITETSDIAGRAMMET Et godt diagram indeholder en enkel notation, der er intuitivt let at forstå. Kompleksiteten i systemudvikling kræver brug af mange forskellige diagrammer, med hvert deres formål

20 Write Chapter Review Chapter Author Printer Typesetter Reviewer Typeset Book Correct Proofs Reset Book Print Book [book complete] [book not complete] Revise Chapter Plan Chapter Produce First Draft Revise Draft [satisfied] [not satisfied] Add Exercises Add References to Bibliography Write Chapter Detaljeskjul En udbredt metode til at skule mængden af detaljer er nedbrydning af diagrammer, hvor hver nedbrydning har fokus på et delelement, der så beskrives i yderligere detaljer

21 Øvelse Tegn et aktivitetsdiagram over en patient-indlæggelse og behandling på et sygehus.

22 Operationsspecifikationer
Bennett kap. 10

23 Operationsspecifikationer
Specifikation af operationer er en detaljeret beskrivelse af de enkelte operationer, enten i form af struktureret sprog, formaliserede tabeller eller aktivitetsdiagrammer. Formålet med specifikation af operationer: Fra et analyseperspektiv: Sikring at brugernes behov er forstået. Fra et designperspektiv: Et grundlag for korrekt programmering. Fra et testperspektiv: Test at metoderne gør, hvad de skal.

24 Operationsspecifikationer
Hvornår skal specifikationerne laves ? ”det er vigtigt, at lave alle operationer inden designfasen.” ”ikke før end der foreligger et stabilt klassediagram.” Skal alle specifikationer specificeres? Rumbaugh: ”trivielle” operationer skal ikke specificeres, da de er selvforklarende. Bennett: Alle operationer skal specificeres, af hensyn til fremtidig vedligeholdelse.

25 Trivielle og ikke-trivielle operationer
Ikke trivielle operationer er med mange sideeffekter: Opretter eller sletter objektinstanser Opdaterer attributværdier Opretter eller sletter relationer mellem objekter Foretager beregninger Kalder metoder I andre objektet Trivielle operationer er uden sideeffekter: Forespørger på data uden at ændre noget.

26 Operationsspecifikationer beskrevet som Kontrakter
En service mellem to objekter kan defineres som en kontrakt mellem de aktive objekter. Kontrakter har fokus på input og output. Hvad der sker I metoderne betragtes som en blackbox. Kontrakter har derfor fokus på udførelsen af services, men ignorerer implementering. Black box Output Input

27 Operationsspecifikationer beskrevet som kontrakter
I en kontrakt beskrives, hvordan klient objektet skal opnå en service. En kontrakt kan indeholde følgende punkter: Formålet med operationen. Operationens signatur, herunder returtype Beskrivelse af indre logik. Andre operationer der kaldes. Hændelser der videreføres til andre objekter Attributer, der sættes ved eksekvering af operationen Retursvar ved exceptions (f.eks. forkerte parameter) Ikke-funktionelle krav (fx svartid) Kontrakter er ikke UML-notation eller specifikt objektorienteret

28 Specifikation af den indre logik
To hovedkategorier: Algoritmiske metoder - fokuserer på hvordan operation fungerer Ikke-algoritmiske metoder fokuserer på hvad operationen skal opnå White box Black box

29 Specifikation af den indre logik Ikke-algoritmiske metoder
Beslutningstabeller: En beslutningstabel viser de betingelser, der medfører en bestemt handling Conditions and actions Rule 1 Rule 2 Rule 3 Conditions Is budget likely to be overspent? N Y Is overspend likely to exceed 2%? - Actions No action X Send letter Set up meeting Beslutningstabeller er velegnede, hvor der er mange forskellige betingelser, der resulterer i forskellige handlinger

30 Specifikation af den indre logik Ikke-algoritmiske metoder
Før- og efterbetingelser: pre-conditions: creativeStaffObject is valid gradeObject is valid gradeChangeDate is a valid date post-conditions: a new staffGradeObject exists new staffGradeObject linked to creativeStaffObject new staffGradeObject linked to previous value of previous staffGradeObject.gradeFinishDate set equal to gradeChangeDate Operationen CreativeStaff.changeGrade() Use case: Change the grade for a member of staff Idéen med før- og efter-betingelser er at specificere: Hvilke betingelser skal være til stede før en operation kan udføres? Hvilken ny tilstand befinder systemet sig i efter at operationen har kørt.

31 Specifikation af den indre logik Algoritmiske metoder
En algoritme beskriver den interne logik i en operation Algoritmiske specifikationer gør brug af kontrolstrukturerne: Sekvens Selektion Iteration Forretningsmæssige regelsæt kan med fordel specificeres ved: Struktureret sprog Pseudokode Aktivitetsdiagrammer

32 Specifikation af den indre logik Algoritmiske metoder
Struktureret sprog Målet er at beskrive den algoritmiske struktur og logik i et program uden, at blive programmeringssprogs specifik. Derfor er det let at skrive og læse. Struktureret sprog anvendes ofte til at præciserer forretningslogik. Eksempel: If client contact is ”Luis” Set discount rate to 5% Else Set discount rate to 2 % End if Do while there are more adverts for campaign Get next advert Get cost for this advert Add to cumulative cost for campaign End do selektion iteration

33 Specifikation af den indre logik Algoritmiske metoder
Pseudo-kode Pseudo-kode er i sprogform tættere på det konkrete Programmeringssprogs syntaks og notation. Målet er at danne et direkte grundlag for implementeringen. Pseudo-kode er derfor typisk en designaktivitet. Eksempel: { while more adverts get advertcost; cumcost = cumcost + advertcost; next advert; }

34 Specifikation af den indre logik Algoritmiske metoder
Aktivitetsdiagrammer Er velegnede til at specificere kompleks algoritmisk logik på grund af den letforståelige grafiske notation. Er en del af UML notationen. Eksempel: Aktivitetsdiagram for CreativeStaff.calculateBonus( )

35 Opgave Regler for opsigelsesvarsel fra arbejdsgiver:
Inden udløb af : Varsel fra arbejdsgiver 5 måneder 1 måned 2 år og 9 måneder 3 måneder 5 år og 8 måneder 4 måneder 8 år og 7 måneder 5 måneder Herefter 6 måneder Vi har en medarbejder-klasse med bl.a. en attribut ansættelsesdato og en operation beregnOpsigelsesvarsel der returnerer et antal måneder for varsel for opsigelse fra arbejdsgiver. 1.Beskriv reglerne i et beslutningstræ 2.Beskriv reglerne i en beslutningstabel 3.Beskriv operationen i struktureret naturligt sprog 4.Beskriv operationen med et aktivitetsdiagram