...
Expand | |||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||
Denne første versjonen av systemet består av tre klasser. Patient er en tom klasse. Doctor-klassen har en assosiasjon til en Patient. TreatmentUnit holder rede på hvilke pasienter og doktorer som finnes, og styrer avvikling av behandlingskøen. Pasienter som har blitt behandlet av en lege fjernes fra systemet. Pasientene har altså ingen (helse)tilstander her.
Oppgave a)Skriv ferdig Doctor-klassen i henhold til skjelettet, altså nødvendige innkapslingsmetoder og isAvailable. Patient er så langt en tom klasse, du trenger ikke implementere denne.
Oppgave b)Skriv følgende deler av klassen TreatmentUnit, basert på beskrivelsen i skjelettet:
Vær obs på at enkelte av disse metodene bør kalle startTreatment fra 1c.
Oppgave c) - TreatmentUnit: Koble pasient og doktorHver gang en ny pasient eller lege er lagt til, eller en lege har avsluttet en behandling, bør TreatmentUnit forsøke å koble en ledig lege og en pasient som skal behandles. Implementer de to startTreatment-metodene og treatmentFinished (sistnevnte brukes ikke i denne underoppgaven, men senere).
Oppgave c) - TreatmentUnit: Koble pasient og doktorHver gang en ny pasient eller lege er lagt til, eller en lege har avsluttet en behandling, bør TreatmentUnit forsøke å koble en ledig lege og en pasient som skal behandles. Implementer de to startTreatment-metodene og treatmentFinished (sistnevnte brukes ikke i denne underoppgaven, men senere).
|
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Alle pasienter har på forhånd blitt diagnostisert med en eller flere (helse)tilstander (conditions) som må behandles. Tilsvarende har alle doktorer et sett med tilstander som de er kompetente til å behandle. En doktor kan ikke behandle pasienter den ikke har kompetanse til å behandle, og en pasient må være i systemet helt til alle tilstander er behandlet.
Oppgave 2a) - PatientImplementer følgende deler av Patient-klassen i henhold til skjelettet:
Oppgave 2b) - DoctorImplementer følgende deler av Doctor-klassen i henhold til skjelettet:
Oppgave 2b) - DoctorImplementer følgende deler av Doctor-klassen i henhold til skjelettet:
Oppgave 2c - TreatmentUnit
Oppgave 2c - TreatmentUnitNå som pasienter har ulike tilstander, og doktorer kan behandle slike tilstander, må Nå som pasienter har ulike tilstander, og doktorer kan behandle slike tilstander, må dette taes hensyn til i klassen TreatmentUnit. En doktor kan ikke behandle pasienter den ikke har kompetanse til å behandle, og en pasient må være i systemet helt til alle tilstander er behandlet.
Du har fått utdelt et skjelett med halvferdige testmetoder (TreatmentUnitTest). Gjør testmetodene fullstendige i henhold til kommentarene. Du vil finne dokumentasjon av testing i vedlegget nederst på siden.
Oppgave 2d - TestingDu har fått utdelt et skjelett med halvferdige testmetoder (TreatmentUnitTest). Gjør testmetodene fullstendige i henhold til kommentarene. Du vil finne dokumentasjon av testing i vedlegget nederst på siden.
Oppgave 2e) - SekvensdiagramTegn sekvensdiagram av det som skjer mellom start sequence diagram- og end sequence diagram-kommentarene i testklassen i skjelettkoden. Diagrammet skal inkludere testen selv, akuttmottaket, pasienten og doktoren som (i den delen av testen) deltar i behandlingen. Du skal ikke ha med kode du legger til selv (f.eks. kall til assert-metoder), som svar på 2 d). Det skulle være omtrent 8-10 kall til metoder i denne delen.
Vanlige feil/alternative løsninger:
|
Expand | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Expand | ||||||||||||||||||||
| ||||||||||||||||||||
Fokus i del 3 er organisering av objektorientert kode med arv. Oppgaven kan derfor løses ved hjelp av pseudokode. Systemet skal støtte tre ulike logikker for å knytte doktor til pasient:
I denne deloppgaven skal du beskrive eller implementere støtte for disse egenskapene ved å bruke arv. Du finner ikke noe nytt skjelett til denne oppgaven, men du vil finne skjelettet fra del 2 for oppslag. Vi ønsker å ende opp med tre klasser, TreatmentUnit, PriorityTreatmentUnit og EmergencyPriorityTreatmentUnit, som implementerer hver sin logikk i lista over. Forskjellen dem i mellom skal være hvordan de implementerer startTreatment-metodene. De skal være knyttet sammen med arv for å gjøre det enkelt for andre klasser å bytte mellom dem og for å gi god gjenbruk, men detaljene i hvordan arvingsmekanismen brukes skal være opp til deg. Det er lov å innføre ekstra klasser og metoder i arvingshierarkiet, hvis det gjør løsningen bedre. Forklar med tekst og kode hvordan du vil 1) strukturere arvingshierarkiet og 2) hvilke metoder som deklareres/implementeres hvor. Skriv også kode for metodene. Siden fokuset her er mer på objektorientert organisering av kode, vil det også gis poeng for pseudokode.
|
Expand | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||
Mens du i del 3 brukte arv, skal du i denne delen bruke delegering for å oppnå det samme. I henhold til delegeringsteknikken definerer vi et grensesnitt, DoctorAllocator. I tillegg lager du (minst) tre hjelpeklasser tilsvarende de tre logikkene beskrevet i del 3, som implementerer grensesnittet. Forklar hvordan koden i vedlagte TreatmentUnit-skjelett skal gjøres fullstendig slik at startTreatment-metoden bruker delegering riktig. Forklar også med tekst og/eller kode hvordan du vil utforme hjelpeklassene som implementerer DoctorAllocator. Da målet er å vise kunnskap om delegering kan dere bruke pseudokode i denne oppgaven. Det er greit å referere (pseudo)koden i del 3, hvis det er til hjelp.
| ||||||||||||||||||||||||||||||||
Expand | ||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||
Mens du i del 3 brukte arv, skal du i denne delen bruke delegering for å oppnå det samme. I henhold til delegeringsteknikken definerer vi et grensesnitt, DoctorAllocator. I tillegg lager du (minst) tre hjelpeklasser tilsvarende de tre logikkene beskrevet i del 3, som implementerer grensesnittet. Forklar hvordan koden i vedlagte TreatmentUnit-skjelett skal gjøres fullstendig slik at startTreatment-metoden bruker delegering riktig. Forklar også med tekst og/eller kode hvordan du vil utforme hjelpeklassene som implementerer DoctorAllocator. Da målet er å vise kunnskap om delegering kan dere bruke pseudokode i denne oppgaven. Det er greit å referere (pseudo)koden i del 3, hvis det er til hjelp.
Vi gjentar fra del 3 hvordan vi ønsker å knytte doktor til pasient, men dette skal nå gjøres ved å implementere DoctorAllocator i stedet for å bruke arv:
Vi gjentar fra del 3 hvordan vi ønsker å knytte doktor til pasient, men dette skal nå gjøres ved å implementere DoctorAllocator i stedet for å bruke arv:
|
Expand | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||
På venterommet skal det være et informasjonspanel, som forteller ventende pasienter om hvilken doktor de skal gå til, når det er deres tur. Panelet implementeres med JavaFX, og tanken er at kontroller-objektet (av typen TreatmentUnitController ) skal lytte på et TreatmentUnit-objekt og få beskjed når koblingen mellom doktor og pasient etableres, slik at panelet kan vise en tekst av typen «Pasient X skal gå til Doctor Y» (du kan forvente at Patient og Doktor har en toString() som gir navn, dette trenger du ikke implementere i tidligere oppgaver). I denne delen kan du bygge videre på koden fra del 2. Du trenger altså ikke ha løst del 3 eller 4.
Oppgave 5a) – Lyttergrensesnitt
| |||||||||||||||||
Expand | |||||||||||||||||
| |||||||||||||||||
På venterommet skal det være et informasjonspanel, som forteller ventende pasienter om hvilken doktor de skal gå til, når det er deres tur. Panelet implementeres med JavaFX, og tanken er at kontroller-objektet (av typen TreatmentUnitController ) skal lytte på et TreatmentUnit-objekt og få beskjed når koblingen mellom doktor og pasient etableres, slik at panelet kan vise en tekst av typen «Pasient X skal gå til Doctor Y» (du kan forvente at Patient og Doktor har en toString() som gir navn, dette trenger du ikke implementere i tidligere oppgaver). I denne delen kan du bygge videre på koden fra del 2. Du trenger altså ikke ha løst del 3 eller 4. Expand | | ||||||||||||||||
|
Code Block |
---|
// TreatmentUnit.fxml:<?xml version="1.0" encoding="UTF-8"?>
<?import javafx.scene.layout.VBox?>
<?import javafx.scene.control.Label?>
<?import javafx.scene.layout.HBox?>
<?import javafx.scene.text.Font?>
<HBox xmlns:fx="http://javafx.com/fxml/1" fx:controller="ord2019.part5.TreatmentUnitController">
<Label fx:id="patientMessage" text="<Her kommer meldinger til pasienter>">
</Label>
</HBox>
// TreatmentUnitController.java:
public class TreatmentUnitController {
TreatmentUnit treatmentUnit;
public TreatmentUnitController() {
treatmentUnit = // assume treatmentUnit is set automatically.
// ... 5 b) other initialization ...
}
// ... 5 b) declarations and methods here...
} |
Definer et egnet lyttergrensesnitt og forklar med tekst og kode hvordan TreatmentUnit må endres for å kunne fungere som observert i et observatør-observert-forhold.
Expand | ||
---|---|---|
| ||
Standardteknikken krever et passende lyttergrensesnitt og en liste av lyttere som kalles på passende sted. En bruker gjerne en Collection for å lagre lytterne og add/remove-metoder for å administrere lytterne. LF definerer lyttergrensesnittet TreatmentListener. Dette grensesnittet har én metode, som kalles idet doktor-pasient-koblingen etableres, altså på tidspunktet det passer å gi beskjed til pasienten om hvilken doktor hen skal gå til. Metoden bør ta inn faktisk pasient, doktor og akuttmottak (TreatmentUnit). Endringer som må gjøres i den observerte, TreatmentUnit, er at alle lytterne lagres i en private Collection av type TreatmentListener, og at den legger inn relevante public add/remove til denne. I tillegg defineres hjelpemetoden fireTreatmentStarted, som kalles rett etter at setPatient har etablert en ny doktor-pasient-kobling (i både startTreatment(Doctor) og startTreatment(Patient)). public interface TreatmentListener {
public void treatmentStarted(Doctor doctor, Patient patient, TreatmentUnit treatmentUnit);
}
public class TreatmentUnit {
// Lots of code unchanged here, find it in part 2 of TU.
private Collection<TreatmentListener> treatmentListeners = new ArrayList<>();
public void addTreatmentListener(TreatmentListener listener) { treatmentListeners.add(listener); }
public void removeTreatmentListener(TreatmentListener listener) { treatmentListeners.remove(listener); }
private void fireTreatmentStarted(Doctor doctor, Patient patient) { for (TreatmentListener treatmentListener : treatmentListeners) { treatmentListener.treatmentStarted(doctor, patient, this); } }
private boolean startTreatment(Doctor doctor) { for (Patient patient : getWaitingPatients()) { if (doctor.canTreat(patient) > 0.0) { doctor.setPatient(patient); fireTreatmentStarted(doctor, patient); return true; } } return false; }
private boolean startTreatment(Patient patient) { for (Doctor doctor : getAvailableDoctors()) { if (doctor.canTreat(patient) > 0.0) { doctor.setPatient(patient); fireTreatmentStarted(doctor, patient); return true; } } return false; } } |
Oppgave 5b) – Controller
Fyll ut kodeskjelettet for kontrollerklassen TreatmentUnitController, slik at det fungerer med den vedlagte FXML-koden og fyller rollen som observatør av TreatmentUnit. Som indikert i kodeskjelettet, så kan du anta at treatmentUnit-variablen i kontrollerklassen settes «automagisk» i konstruktøren.
Expand | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
I FXML-koden ser en at det finnes en Label med fx:id="patientMessage". Her må man skjønne/gjette at det er dette objektet som skal oppdateres når en pasient skal gå til en doktor. En kan også lese at controlleren er en (instans av) TreatmentUnitController. TreatmentUnitController: - Label patientMessage i FXML må knyttes til en variabel i TreatmentUnitController, gjennom å bruke @FXML-annotasjonen og Label-type. - Konstruktøren oppretter en ny TreatmentUnit. Så er det litt valgfritt hva som skjer, men den viktige biten er at man i konstruktøren også må opprette forbindelsen mellom TreatmentUnitController som lytter/observatør og TreatmentUnit som observert vha. et kall til addTreatmentListener-metoden fra 5a. - TreatmentUnitController må implementere lyttergrensesnittet og (den ene) lyttermetoden må oppdaterer status på Label-objektet.
private TreatmentUnit treatmentUnit;
public TreatmentUnitController() { treatmentUnit = new TreatmentUnit();
// …
}
@FXML private Label patientMessage;
@Override public void treatmentStarted(Doctor doctor, Patient patient, TreatmentUnit treatmentUnit) {
} }
Vanlige feil/alternative løsninger:
|