Mandatory Project: Software Architecture of the TM12 System Morten Mackenhauer og Kim Kokholm Department of Computer Science, University of Aarhus Aabogade 34, 8200 Å rhus N, Denmark 20108038, 20024448 mackenhauer@gmail.com, kokholm@gmail.com 10/9/2012 Abstract The TM12 system implements an information system for supporting tele medicine, i.e. patients making measurements in their homes for review by general practitioners as well as hospital clinicians. This report gives a software architecture description of an architectural prototype of the TM12 system. The techniques used for architectural description are taken from [Christensen et al., 2012]. 1 Introduction Figure 1 shows a schematic overview of TM12. Knud had a heart attack Inger must monitor high blood pressure General Practitioner Hospital Clinician Figure 1: Rich picture of the TM12 architecture 1
TM12 is based on a device/tablet in the home that can make measurements of blood pressure and upload these to a TM12 web server. Such a measurement is denoted a tele observation or just observation. The software architect has made a decision to make the size of the message sent from home client to TM12 server small. The TM12 converts the observation into a standard format for clinical information, HL7 v.3 1, and stores it in an XDS 2 storage system. A general practitioner can review observations for a patient using a web browser interface implemented on the TM12 server. 2 Architectural Requirements For our purposes there is two main use case for the TM12 system: Tele observation upload: The patient makes a measurement in his/her home and uploads it to the TM12 server. Tele observation review: The general practitioner reviews all tele observations for at given patient in a given time interval using a web browser. The major driving qualities attributes of the TM12 system are 3 : Performance. TM12 should be performant so that a large number of patients may be part of the system. Modifiability. It must be possible to modify TM12 to include new types of clinical measurements. Sikkerhed. Da systemet arbejder med potentielt personfølsomme data bør sikkerhed være et centralt kvalitetskriterie. Sikkerhed. Da systemet arbejder med potentielt personfølsomme data bør sikkerhed være et centralt kvalitetskriterie. Tilgængelig. Tilgængelig er vigtig for bred tilgængelig i form af anvendelse af åbne standarder. 2
3 Architectural Description 3.1 Module Viewpoint Pakkediagram Cs.saip Main XDS Delegate DataFormat Delegate Domain IPC HTTP Delegate Ovenstående figur viser hvordan de forskellige pakker interagerer med hinanden. Dette synliggører afhængigheder og fortæller ved ændringer, hvor ændringer skal formidles ud henne og hvilke impacts ændringer kan have. 3
Klasse-diagram Main JettyServer HomeClient JettyServerMain Domain ddd TeleObservation ClinicalQuantity IPC dataformat IPC ddd Forwarder Serializer Builder Director Receiver InterProcessConnector Result Receive() Bool issuccess(); ddd xds XDSBackend Metadata Se tilhørende tekst, på næste side.
Ovenfor ses klasse-diagrammet på overordnet niveau. Vi har valgt ikke at illustrere interface implementationer. Vi har valgt dette for at skabe overblik. Systemet indeholder veldefinerede interfaces - der agerer som kontrakter. Hvordan implementeringen er/kan være, er ikke så relevant på det overordnede plan. 3.2 Component & Connector Viewpoint Den kommende arkitektur vil indeholde en enhed/tablet til at aggere som en klient. Denne klient er i koden symboliceret via en simpel klasse (HomeClient). Denne klasse kan derfor beskrives som klient-komponenten i en klient/server arkitektur. Webserveren hoster en servlet og til sammen repræsentere de server-komponenten. Den fjerde og sidste komponent er XDS storage systemet som kan betragtes som en backend eller persisteringslag for systemet. Integrationen mellem servlet og XDS er lavet som en strategy så en mere simpel backend kan anvendes. Client HTTP Webserver (Jetty) Servlet Strategy XDS Klient-programmet sender teleobservationer til en webserver over HTTP, observationerne serializeres via JSON. Webserveren hoster en servlet som deserializerer beskederne og sender dem videre til XDS-servicen. Den centrale use-case dokumenteres i nedenstående sequencediagram. En telesobservation bliver via klassen Forwarder serializeret af en Serializer og afsendt vhf. InterProcessConnector til en webserver. Webserveren hoster en servlet som vidersender beskeden til en Receiver vis ansvar er at sende teleobservatioen til en XDSBackend. Forwarder Serializer InterProcessConnector StandardHTTPServelet Receiver XDSBackend Send Serialize SerializedString sendtoserver HTTP-Post receive provideandregisterdocument Result HTTP-Get 5
3.3 Allocation Viewpoint Clients Medicine-item HTTP-Protocol Tele Medicine Server WWW-node HTTP-Protocol HL7 format National XDS XDS-System HL7 format HTTP-Protocol Hospital/Doctors Browser Protokol mellem Tele Medicine Server og Nationale XDS er out of scope for denne løsning. Det er primært mellem patient/server og hospital/server der er aktuel her. Krav til hardwaren og platforme er ikke illustreret på ovenstående figur. 1 www.hl7.org 2 Cross-Enterprise Document System, wiki.ihe.net/index.php?title=cross- Enterprise Document Sharing 3 These qualities will be operationalized in a later exercise 6
4 Discussion Selv om kodebasen til TM12-systemet er relativ lille, så oplever vi de 3 perspektiver giver et godt overblik over systemets arkitektur. Vi er derfor overbeviste om at en sådan dokumentation vil være en stor hjælp for de personer som skal udvikle eller drive det kommende system. Generelt oplever vi at: Module viewpoint: Giver et godt indblik over de centrale klasser og disses samspil C&C viewpoint: Giver indsigt i flowet de enkelte komponenter imellem Allocation view: Bidrager med indsigt i hvordan systemet er fordelt ud over hardware Selvom vi syntes at denne model/fremgangsmåde er god, så følger vi at den mangler nogle argumenter for hvorfor man har valgt netop denne arkitektur. Dette kunne f.eks være en bedre binding/relation til de opstillede kvalitetskriterier. Vi har haft svært ved at bedømme denne fremgangsmåde ud fra følgende betragtninger: Facit? Hvornår er man færdig, hvornår er arkitektur beskrivelsen komplet? Iterativt? Fungerer denne fremgangsmåde under en iterativ process. Hvor sent/tidligt i processen kan man udføre denne arkitektur beskrivelse? Kan denne arkitektur-beskrivelse fungere, hvis designet/kravspecifikationen ikke er helt på plads? Hvor store/små løsninger - vil denne arkitektur beskrivelse være at foretrække? 5. Question: Consider the definition of software architecture by [Perry and Wolf, 1992]. Discuss what the 'elements', 'form', and 'rationale' according to this definition would be for the TM12 system -------- Perry and Wolf beskriver software arkitektur på følgende måde: Software arkitektur = { Elements, Form, Rationale } Elements bliver kan yderligere opdeles i 3 grupper: processing elements data elements connection elements I TM12 systemet vil processing dataelements være klasserne fra domain-pakken, processing elements klasserne fra dataformat-pakken og connection elements klasserne fra IPC-pakken. Form: Formen illustrerer strukturen mellem komponenter og connectors. Systemet indeholder interfaces/kontrakter for elementerne imellem. Dette kan sammenlignes med de 3 views fra 3+1 modellen, som beskriver hvordan arkitekturens elementer er forbundet 7
Rationale: Hvor Elements+Form kan beskrives som: The What of the architecture Kan Rationale beskrives som: The Why of the architecture. Der kan være mange interessenter forbundet med de arkitekturvalg man tager, men hensigten er at forankre disse i kvalitetskriterierne til systemet. Man kan sige kvalitetskriterierne skal matche hinanden - de hører sammen. For lidt rationale, kan føre til at kvalitetskriterier ikke er opfyldte. For meget rationale kan samtidig overskride kvalitetskriterierne. F.eks. økonomi, skalerbarhed, support og sikkerhed. Rationale for TM12-systemet ligger an på HL7 og XDS - grundet udbredelsen og en standard indenfor industrien. Motivationen (rationalet) for denne beslutning har været at det er industri-standard og mulighed for at ramme bredt - så løsningen er fremtidssikret. Kommunikation mellem patienter/sygehuse sker via WEB/HTTP-teknologier - motivationen (rationalet) for at vælge dette er at det er en velkendt og yderst udbredt teknologi. Vi ønsker stor og bred udbredelse, derfor dette valg. Som et eksempel. Ved ikke at have vægtet rationalet, kan vi ikke sikre at vi har opnået vores forudsatte quality attributes Sikkerhed kan opfyldes i form af WEB løsningerne (f.eks.: NemID + digitale signaturer). Modificerbarhed i forbindelse med interfaces/kontrakter mellem de forskellige grænser. References [Christensen et al., 2012] Christensen, H. B., Corry, A., and Hansen, K. M. (2012). An Approach to Software Architecture Description Using UML 2.3. Technical report, Computer Science Department, University of Aarhus. 8