assignment (PDF)

9

Phase III – Architecture Extension

Your assignment for Phase III of the project is to extend an existing architecture. You have to perform five tasks (labeled A, B, C, D and E, but not necessarily in that order), where each task consists of implementing a security requirement in the architecture. You get access to a catalog of security patterns which you can use for creating your solution. Each tasks is given in the form of one or more (negative) misuse cases that should be mitigated, together with a (positive) quality scenario that describes the requirement.

9.1

Setup

For Phase III, you will work with SATool. This is a modified version of the TOPCASED UML editor1 , an Eclipse-based open-source toolkit designed for modeling critical systems and developed by a consortium led by Airbus. The tool has been extended with features to assist you in following the pattern-based process described in a previous lecture. The link to obtain the tool can be found on Toledo. There, you can also find a zip file containing the architectural model from which you start in this phase. Complete the following steps to setup your environment: 1. Download and extract the tool. Note: if you don’t have enough space in your home folder (the extracted tool weighs about 70Mb), use the /tmp folder of the machine you are working on. In this case, make sure that your workspace (see next) is located in your home folder, so it won’t get deleted! 2. Run the tool and indicate (create) your workspace location (somewhere in your home folder). 3. Download the project zip file and extract it into the workspace folder. 4. In the tool, import the extracted project (File > Import > General > Existing Projects into Workspace). 5. The first time you open the UML model (Models/PMSArchitecture.umldi), the tool will ask for the group code that has been provided to you. If you do not know your group code, ask one of the assistants!

10

Working with the tool

Make sure you are always working with the TopcasedSP perspective, and use the Topcased Navigator. In the Models folder, you can find the UML diagrams (PMSArchitecture.umldi). Expanding this file in the Topcased Navigator shows a list of all diagrams. Remember to only open the .umldi file, and not the .uml file, to avoid inconsistencies. Additional files exist or are generated in the background (config.dat, processstate.pdat and results.mdat). You should ignore these files. Important whenever you take a break (i.e., are not working on the project), use the pause button to keep track of this. Note The tool collects additional measurements about your actions during the project. Remember that data obtained from the tool in no way influences your final grade.

Figure 1: Pause button 1 http://www.topcased.org

18

10.1

Following the process

To follow the pattern-based process, a process view is located at the right side of your workbench. In this view, you can find the current task you need to work on. To view the details about the task, click the link. Follow the process like it was explained during the lecture. Within a task, you can backtrack to an earlier step if you have made an error; you should avoid doing this unless you have a good reason to do so. Note that it is also possible to perform multiple iterations per task, in case you need to do additional work. You can open the security pattern catalog by clicking the link in steps 2, 3 and 4. Notice that you can (and should) only edit your UML model in the instantiation step (i.e., step 4). During the other steps, you can still browse the UML model. When you indicate that a certain task is finished, your results will be packaged in a zip-file and placed in a Results folder of your project. In the background, this zip file is uploaded to a web server. Also, a report of your decisions is generated in the results folder, which you can use for creating your final report. Important: only submit a task when you are satisfied with your solution, as you will not be able to revisit that task afterwards. If you feel you need to do additional work before submitting, start a new iteration.

10.2

Creating UML diagrams with TOPCASED

TOPCASED to a large extent resembles other UML tools, although (as with any tool) there are some intricacies you should be aware of. This section aims at pointing out the most important things you need to know in order to work with it. • TOPCASED imposes some restrictions on what you can draw, in order to achieve a model that is compliant with the UML specification. Not all UML features and diagrams are (fully) supported. For this assignment, you should limit yourself to Component, Composite Structure, Deployment and Class diagrams. • Each diagram must be contained by a UML element. To create a new diagram, right-click on the element in the Outline view, and use the ‘Add diagram’ submenu. Note that not all diagram kinds can be created within every type of UML element. • The size of a diagram is expressed as a paper size in TOPCASED; use this as an indication of how much you can/should put on one diagram. Creating additional views per use case or concern is recommended. • To create a new UML element on a diagram, select the kind of element you want to create in the palette and click on the diagram. Contrary to most UML tools, you should also use this approach to add ports to a component, attributes or operations to a class, etc. • To add an already existing element on a diagram, drag-and-drop the element from the outline onto the diagram. • To generate an image file of a diagram, right-click on the diagram and choose ’Export to file’. You can export all diagrams at once by right-clicking the .umldi-file and choosing the corresponding option. You can also generate an interactive HTML version of the UML model. Note It can be hard (and frustrating) to create pixel-perfect layouts for your diagrams in TOPCASED. Therefore, do not spend too much time creating beautiful diagrams; just try to keep the diagram readable.

11

Starting point: PMS architecture

The SATool contains the initial architecture for you to start with. This architecture is based on the requirements for phase II, but it is not a reference architecture or ideal solution for phase II. The architecture itself can be viewed in the tool; here we list the main architectural decisions. Context We define five external users of the system: the gateway, the cardiologist, the technical nurse, the personal health community (PHC, which includes the GP, the Patient, the Buddies, Trustees, and Home Caretakers) and the hospital information system (HIS). Each of them communicates with the system through a frontend component using a thin client.

19

Gateway • The Gateway communicates with the PMS through the Gateway Frontend. • The Gateway submits sensor data on regular intervals using the submit data interface. Newly-arrived data is sent to the Patient Data Processor (cf. below). • The Gateway can be dynamically reconfigured. Pushing the data from the PMS to the Gateway would require a very costly bidirectional connection, lowering scalability and performance. Instead, the Gateway regularly (e.g. once per minute) checks for an updated configuration itself, using the check configuration interface. It therefore sends the timestamp of his current configuration. The PMS responds with the new configuration if needed. The messages from the Gateway can also be used as heartbeats by the PMS. • The Gateway Frontend is also responsible for authenticating the gateway device (by means of the unique identifier that associates the gateway device to the identity of the patient). Patient data processing • The Gateway Frontend sends newly-arrived sensor data to the Patient Data Processor. This component drives the main patient data processing flow: 1. The newly-arrived sensor data is stored in the Detailed DB. 2. The Patient Data Processor fetches the following data from the Patient DB: – the current risk level of the patient, – the specific cardiologist involved in the treatment of the patient, – the list of clinical models to be applied, – the configuration of each clinical model. 3. A processing job is scheduled for this sensor data (based on the record id of the raw sensor data in the Detailed DB) on the corresponding Priority Queue of each clinical model. The queues are introduced for reasons of performance. 4. After queueing, the processing job is executed by the corresponding Clinical Model component. 5. After processing, the Combine and Notify component combines the results of the different clinical models into one risk estimation for the patient, stores these results (individual results per clinical model and the combined result) in the Processed Results DB component and notifies the cardiologist of the patient (the Cardiologist Client component). • As the Patient Data Processor is a key component in the PMS, its availability is monitored by the Processor Availability Monitor which listens to its heartbeat. The party this component should notify in case of failure is not shown in the architecture. Authentication • For authentication, the users have to provide their credentials (e.g. username and password). The Session Manager component validates these and returns a token that is valid during the session. To access any of the different services (e.g. check a patient’s status or update a patient’s configuration), the users provide this token as proof of their identity. Personal Health Community The term Personal Health Community (PHC ) is used to group the GP, the Buddies, the Trustees, the Home Caretakers and the Patient himself. These actors all know the patient in person and use the system to stay up-to-date on his status or give some input about it (e.g. questionnaires). They have similar requirements and can be grouped together. • The PHC communicates with the PMS through the PHC Frontend using the Personal Health Community client. • The PHC can check the patient’s status using the Consult interface. For performance reasons, the information to be presented to the PHC is created asynchronously by the PHC View Preprocessor. It combines the raw sensor data from the Detailed DB with the processed results from the Combined Results DB and stores the results in the Consolidated Status DB. This database is queried by the PHC Frontend. 20

• Questionnaires are entered through the Questionnaire interface. The PHC Frontend forwards the questionnaires to the PHC Handler, which stores them in the PHC Data database, selects the relevant information from the questionnaire answers and sends these to the Patient Data Processor. Here, they are processed similarly to newly-entered sensor data (cf. above). • The PHC Frontend is also responsible for validating the session token given by the user, using the Check Token interface of the Session Manager. Cardiologist • The Cardiologist communicates with the PMS through the Cardiologist Frontend using the Cardiologist Client. • The Cardiologist can check a patient’s status using the Consult interface. The Cardiologist Frontend therefore employs the Cardiologist Frontend component which combines data from all relevant databases: the patient risk level from the Patient DB, the detailed sensor data from the Detailed DB, the processed results from the Processed Results DB and the questionnaire data from the PHC Data database. • Similar to the gateway configuration, the on-demand consultation by the cardiologist would also require a bidirectional connection between the PMS and the Gateway. Instead, when asking for an on-demand consultation, the PMS sets the data transmission interval of the Gateway to be very short (e.g. four times per minute). At the next heartbeat, this change will propagate to the Gateway, which will start sending sensor data continually to the PMS, emulation a real-time data stream. Afterwards, the PMS sets the configuration of the gateway back to its original state. • The Cardiologist can change the configuration settings of the patient (e.g. risk level, clincal model configurations etc.) using the Configure interface. This configuration information propagates to the Patient DB through the Configuration Management component. • The Cardiologist Frontend is also responsible for validating the session token given by the user, using the Check Token interface of the Session Manager. Technical nurse • The Technical Nurse communicates with the PMS through the Nurse Frontend using the Technician Client. • The Technical Nurse can register and unregister patients using the Patient Registration interface. This configuration information propagates to the Patient DB through the Configuration Management component. • The Nurse Frontend is also responsible for validating the session token given by the user, using the Check Token interface of the Session Manager. HIS Integration • The Hospital Bridge deals with the integration of the PMS to the Hospital Information System (HIS). • The PMS can access the patient record in the HIS using the GetInfo interface. • The PMS can update the patient record in the HIS using the UpdateInfo interface. EHR Integration • It is presumed the HIS integrates with the Electronic Health Record (EHR) directly and deals with synchronizing patient data. Therefore, the PMS itself does not access the EHR directly. Emergencies • The Gateway can issue an emergency through the emergency alert interface of the Emergency Frontend component. This emergency alert is processed by the Emergency Handler which uses the Emergency Model to quickly verify it. Once confirmed, the hospital emergency services are contacted through the Hospital Bridge using the Notify Emergency interface. 21

12

Format of the report

Integrate the documents and models that come out of this phase of the project in a consistent and coherent report. Deliver a physical copy of this report in project post boxes (in the student print room A00.03) on the main floor of the Department of Computer Science. We also expect you to hand in a digital copy of the report on Toledo. Use SATool for your diagrams and make sure to include your project in the digital copy (File > Export... > General > Archive File, include your whole project). The deadline is Monday 23th of May (at 23:59). Structure your report as follows: 1. Per task: (a) A summary of the decision process you followed (patterns you considered etc.) together with the rationale of your solution (the trade-offs you made). (b) A component & connector view and a deployment view showing only the parts of the architecture impacted by your solution. Note: Build your architecture incrementally, i.e. the second task extends the architecture built during the first etc. For each task, you should only document the parts of the architecture that differ from the previous one. 2. The whole of your final architecture (i.e. not only the parts of it that changed during the tasks in this assignment). Include at least a component & connector view and a deployment view. 3. The updated use cases impacted by your final solution. Good luck! The Software Architecture team.

22