Introduktion til SundhedsIT – koncepter og systemer

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

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

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

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

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… 50673 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

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

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

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

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

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

Tilstandsdiagrammer IV Fødsel Betingelser Død Attributter

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

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

Aktivitetsdiagrammet Formål og notation Bennet kap.5

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)

Add a New Client Assign StaffContact [no campaign to add] [campaign to add] Add New Campaign Notation • Start tilstand • Aktiviteter • Rektangler med runde hjørner • Meningsfuldt navn • Transitioner • Pile med åbne pilehoveder • Beslutningspunkt • Betingelser • Slut tilstand

CampaignManager Accountant Client Record Completion of a campaign Issue invoice Pay invoice Record client payment Notation Svømmebaner • Lodrette kolloner • Angiver hvilken person, organisationeller afdeling, der er ansvarlig for aktiviteterne i kollonen

Author Reviewer Typesetter Printer Write Chapter Review Chapter Revise Chapter [book not complete] [book complete] Typeset Book Correct Proofs Reset Book Print Book 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

Write Chapter Plan Chapter Produce First Draft Author Reviewer Typesetter Printer Revise Draft Write Chapter [not satisfied] [satisfied] Review Chapter Add Exercises Revise Chapter [book not complete] Add References to Bibliography [book complete] Typeset Book Correct Proofs Reset Book Print Book 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

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

Operationsspecifikationer Bennett kap. 10

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.

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.

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.

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

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

Specifikation af den indre logik To hovedkategorier: • Algoritmiske metoder - fokuserer på hvordanoperation fungerer • Ikke-algoritmiske metoder fokuserer på hvadoperationen skal opnå White box Black box

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

Specifikation af den indre logikIkke-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øren operation kan udføres? • Hvilken ny tilstand befinder systemet sig i efterat operationen har kørt.

Specifikation af den indre logikAlgoritmiske 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

Specifikation af den indre logikAlgoritmiske 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

Specifikation af den indre logikAlgoritmiske 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; } }

Specifikation af den indre logikAlgoritmiske 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( )

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

Introduktion til SundhedsIT – koncepter og systemer