Software Architecture Project 2

Software Architecture: Phase 2
Dommicent Leendert - s0205006 Van Loock Jorn - s0205008
Prof.: W. Joosen Assistent: Riccardo Scandariato
Contents
1 Introduction 2 Attribute Driven Design 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Iteration 1: Decomposing the AlarmComponent . . . . . . . . . . . . . . . . . . . . . . . . Iteration 2: Decomposing the AlarmComponents IncomingScheduler . . . . . . . . . . . . Iteration 3: Decomposing the AlarmComponents AlarmHandler . . . . . . . . . . . . . . Iteration 4: Redesign of I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 5 5 7 8 9
Iteration 5: Decomposing the I/Os IncomingModule . . . . . . . . . . . . . . . . . . . . . 12 Iteration 6: Decomposing the I/Os OutgoingModule . . . . . . . . . . . . . . . . . . . . . 13 Recapitulation: Use case overview 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Iteration 7: Decomposing the Measurement component . . . . . . . . . . . . . . . . . . . . 16
2.10 Iteration 8: Decomposing the Measurements TrameHandler . . . . . . . . . . . . . . . . . 17 2.11 Iteration 9: Decomposing the Measurements HeartBeatDetector . . . . . . . . . . . . . . 18 2.12 Iteration 10: Decomposing the Measurements AnomalyDetection . . . . . . . . . . . . . . 20 2.13 Recapitulation: Use case overview 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.14 Iteration 11: Decomposing the Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.15 Iteration 12: Decomposing the Storages MeasurementStorage . . . . . . . . . . . . . . . . 24 2.16 Iteration 13: Decomposing the Storages ConsumerStorage . . . . . . . . . . . . . . . . . . 25 2.17 Iteration 14: Decomposing the Storages AlarmStorage . . . . . . . . . . . . . . . . . . . . 26 2.18 Recapitulation: Use case overview 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.19 Iteration 15: Decomposing the ControlPanel . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.20 Iteration 16: Decomposing the ControlPanels AuthService . . . . . . . . . . . . . . . . . 30 2.21 Iteration 17: Decomposing the ControlPanels AuthServices TokenGenerator . . . . . . . 31 2.22 Iteration 18: Decomposing the ControlPanels FrontController . . . . . . . . . . . . . . . . 33 2.23 Iteration 19: Decomposing the ControlPanels Backend . . . . . . . . . . . . . . . . . . . . 34 2.24 Recapitulation: Use case overview 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.25 Iteration 20: Decomposing the ControlComponent . . . . . . . . . . . . . . . . . . . . . . 37 2.26 Iteration 21: Decomposing the BillingComponent . . . . . . . . . . . . . . . . . . . . . . . 38 2.27 Iteration 22: Decomposing the BillingComponents InvoiceSender . . . . . . . . . . . . . . 40 3 Final Architecture 42
3.1 3.2 3.3 3.4
The context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 The Overall system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Decomposition diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 55
4 Scenarios 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9
User prole creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 User prole associations with a remote monitoring module . . . . . . . . . . . . . . . . . . 55 Remote monitoring: Installation and initialization . . . . . . . . . . . . . . . . . . . . . . 55 Remote monitoring: transmission frequency reconguration . . . . . . . . . . . . . . . . . 56 Remote monitoring: troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Remote monitoring: Alarm notication recipient conguration . . . . . . . . . . . . . . . 57 Remote control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Normal measurement data transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Individual data analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.10 Utility production planning analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.11 Information exchange towards the UIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.12 Alarm data transmission: remote monitoring module . . . . . . . . . . . . . . . . . . . . . 59 4.13 Alarm data transmission: ReMeS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.14 Remote control module de-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.15 New bill creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.16 Bill payment is received . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5 Appendix 5.1 64
Element Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 5.1.7 Alarm Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 BillingComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 ControlComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 ControlPanel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 MeasurementComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.2.1 AlarmComponent - iteration 1,2,3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3
5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.2.7
BillingComponent - iteration 21,22 . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 ControlComponent - iteration 20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 ControlPanel - iteration 15,16,17,18,19 . . . . . . . . . . . . . . . . . . . . . . . . . 72 I/O - iteration 4,5,6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 MeasurementComponent - iteration 7,8,9,10 . . . . . . . . . . . . . . . . . . . . . . 76 Storage - iteration 11,12,13,14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Introduction
This report handles the second phase of the ReMeS-system. The AttributeDrivenDesign will be handled in the nextion section. In the section thereafter the nal total architecture is worked out. Finally the predened scenarios can be found. In the appendix you nd the element catalog, explaining the responsibilities for each component, and the interfaces of all the components.
2
2.1
Attribute Driven Design

Introduction
In this section the full ADD will be explained. Hereinafter every section will be an iteration to decompose a previously created component. The report is mainly structured as a depth-rst order to decompose the system unless otherwise stated.
2.2
Iteration 1: Decomposing the AlarmComponent
Components to decompose To start the ADD we chose the most important drivers. We chose the drivers that are architectural on the ouside of the system. This way we can use the approach to analyse the system by ADD from the outside to the inside. Because this is the rst iteration we decompose the ReMeS system as a whole.
Architectural Drivers We chose the next drivers to create the rst decomposition: Use Case 7: Send trame to remote device Use Case 13: Send alarm Performance 1: Timely closure of valves
Tactics to address the requirements To achieve the drivers we chose the following tactics: Resource Arbitration: Scheduling We did choose the previous tactic because we want to guarantee that high priority alarms like gas leaks will be handled rst. This will also guarantee the timely closure of the valves. Alternative tacticts would be reduce computation overhead. We did not choose this because we do not have much control over the overhead.
Architectural Patterns The use cases deal with the alarm section of the ReMeS-system. Incoming alarms schould be scheduled on priority, handled and there has to be a possibility to send out alarms. To design this problem we used Active Object as a pattern. The gure can be found in gure 2.
Decomposition This paragraph will always explain the working of the decomposition and the job of new created components. In the chosen use cases we need to have the possibility to send a trame to a remote device. The remote device can send an alarm to the system and the system can notify the consumer and CallCenter of this alarm. Alarms have dierent priorities and have to be handled in dierent orders. This gives us 5
3 components: a SchedulerIn for scheduling incoming alarms on priority, an AlarmHandler for handling (reading, storing, ...) the alarm and nally a SchedulerOut to schedule the outgoing alarms. You can see this rst decomposition in gure 1.
Diagrams Here you nd the diagrams for this iteration. In gure 1 you can nd the gure of the decomposition tree. In gure 2 you can nd the component diagram of the AlarmComponent.
Figure 1: Tree iteration 1
Figure 2: Active Object
Functionality Reallocation The IncomingScheduler has to be able to read the trames and schedule the incoming trames by their priority. For this we create new use cases. The OutgoingScheduler does the same for sending trames. The AlarmHandler will handle the trames. Now we can reallocate the use cases over the tree in gure 1. The designed use cases 7 and 13 are rened, the leftover use cases and non-functional requirements are numbered with the number from the appendix in the assignment. This convention will hold throughout the report. IncomingScheduler: (iteration 2) UC: read trame UC: schedule on priority AlarmHandler: (iteration 3) UC: save alarm UC: load consumer conguration UC 9: notify the consumer OutgoingScheduler: UC: schedule outgoing trames UC: send trame Other functionality: UC 1,2,3,4,5,6,8,10,11,12,14,15,16,17
Availability 1,2,3 Performance 2,3 Modiability 1,2,3 Done use cases and non-functional requirements: UC 7, 13 Performance 1
2.3
Iteration 2: Decomposing the AlarmComponents IncomingScheduler
Components to decompose From the tree in the rst iteration in gure 1, we will now make a new decomposition. The rst component to decompose is the IncomingScheduler.
Architectural Drivers the IncomingScheduler.
The architectural drivers are the drivers we dened in the rst iteration for
UC: read trame UC: schedule on priority
Tactics to address the requirements Tactics are not applicable here because the drivers are all use cases. From now this paragraph wont be listed if this is the case.
Architectural Patterns For this component we did not use any specic pattern. From now if this is the case this paragraph wont be listed.
Decomposition The main component will be a Scheduler that schedules a set of incoming data. The scheduling is based on the priority or type of the alarm. Therefore a component Type is introduced. The Scheduler has a list of alarms ordered on priority. It keeps taking an element from the incoming Buer and orders it in his list. To deal with starvation an aging algorithm can be used. The Scheduler provides a function for the HandlerComponent of gure 1 to get the highest priority alarm in his list. The working is displayed in gure 4.
Diagrams Here you nd the diagrams for this iteration. In gure 3 you can nd the gure of the decomposition tree of the IncomingScheduler. In gure 4 you can nd component diagram of the IncomingScheduler.
Figure 4: Incoming scheduler Functionality Reallocation We will not decompose the components in the IncomingScheduler anymore. From now the previous created use cases for the IncomingScheduler are satised. The other use cases are not changed and remain assigned to their components like stated in iteration 1. Done use cases and non-functional requirements: UC 7, 13 Performance 1
2.4
Iteration 3: Decomposing the AlarmComponents AlarmHandler
Components to decompose From the tree in the rst iteration in gure 1, we will now make a new decomposition. The IncomingScheduler was decomposed in iteration 2. The next one is the AlarmHandler.
Architectural Drivers the AlarmHandler.
The architectural drivers are the drivers we dened in the rst iteration for
UC: save alarm UC: load consumer conguration UC 9: notify the consumer
Decomposition A TrameTreader is needed for reading the incoming trames from the IncomingScheduler of iteration 2. The TrameTreader uses ConsumerInfo, which has a database connection, to get the consumer of the valve. With that knowledge there is access to the noticationpreferences. We need this to inform the consumer of the alarm and we can create a message for that in the ConsumerMsgBuilder. This can be send to the OutgoingScheduler of gure 1. Finaly the TrameReader will save the alarm with a connection to the database. This way low battery alarms can be saved so they can be viewed in the control panel. Likewise storing the alarms gives the opportunity to the consumer to set an alarm as a false positive from the control panel. The TrameTreader will also save the status of the valve (open or closed). This is necessary because the gas leaks require the valve to be shutdown. In that case the TrameReader will want to call a function in the OutgoingScheduler to send a command to shutdown the valve. The TrameReader can determine through which technology the trame was sent for sending
back the shutdown command (see interfaces of I/O OutgoingModule) through the same technology. This working is displayed in gure 6. Diagrams Here you nd the diagrams for this iteration. In gure 5 you can nd the decomposition tree of the AlarmHandler. The component diagram of the AlarmHandler is in gure 6.
Figure 6: Alarm Handler
Functionality Reallocation We will not decompose the components of the AlarmHandler anymore. From now the previous created use cases for the AlarmHandler are satised. The other use cases are not changed and remain assigned to their components like stated in iteration 1. Done use cases and non-functional requirements: UC 7, 9, 13 Performance 1
2.5
Iteration 4: Redesign of I/O
Until now two of three components of gure 1 are decomposed and should do what they have to do. This 3 components are all related with the alarms. Lets call this set the AlarmComponent. On the same 9
level, next to the AlarmComponent we could dene a MeasurementComponent for use case 8 (and later a ControlComponent). They would handle the measurement data (and for the ControlComponent the test of the connection when a new valve is installed at a consumers home).
Architectural Drivers From now, the MeasurementComponent will be included at high level. Availability 2 (missing measurements) will be split over in two seperate ones. The rst Availablity 2a will represent the acknowledgement of every received trame, will be handled in the Incoming Module. The second Availablity 2b will represent the detection of dead valves, valves that arent sending any data anymore, will be handled in the MeasurementComponent. Modiability 1 is seperated anologue. UC 8: Send measurement Availablity 2a: Acknowledge every received trame Availablity 2b: Detection of dead valves Modiability 1a: Sending commands to remote smart devices (HAS). Modiability 1b: Consumer can have a dynamic billing prole Modiability 3: Decentralized electricity generation
Tactics to address the requirements Generalize the module Anticipate expected changes To achieve Modiability 1 new commands has to be sent out to smart remote devices. Adding such commands and keeping seperation of concerns brought us to Generalize the module. We chose this tactic because this new functionality isnt tightly coupled with other components but we can reuse yet existing components. Modiability 3 asks us to easily add new components like the AlarmComponent & MeasurementComponent. This extra component would handle trames sent by the remote module with data of produced power. By placing an I/O IncomingModule these trames can easily be ltered out and passed to that extra component. Anticipate expected changes is applied here. With this design new functions could easy be plugged in in the ReMeS-system. We didnt chose Restrict communication path because there are many unexpected connections that have to be made in the system, so this tactic doesnt seem feasible.
Decomposition We could set the MeasurementComponent, AlarmComponent and (later) the ControlComponent on one hypothetical level with connections to a Storage component. For good design requirement like speration of concerns 1 module for the incoming messages could be build and placed in front of those 3 components. This corresponds to the tactics we want to use. Analogue a component to send messages is placed behind those 3 components. This I/O Module will be decomposed in iteration 5 (for I/O:Incoming Module) and iteration 6 (for I/O:Outgoing Module). In this situation we assume the Outgoing Module can send and work instantly. We can drop the Outgoing Scheduler in the AlarmComponent. We will get a new design tree like in gure 7. A high level overview is in gure 8. For readability only 1 methodconnection is drawed between the components. There could be more and these will be specied and get clear throughout the next iterations. Modiability 1a can now be easy included for its part of sending commands to Home Automation Systems. The OutgoingModule can easy be extended for doing this. Modiability 1b will be explained in iteration 21. From now we will use this tree as the new tree to work with. The decomposition of the AlarmComponent in gure 7 stays the same as created in iteration 2 and 3.
10
Diagrams
Here you nd the diagrams for this iteration:
Figure 7: New decomposition tree A short overview of the components iterations: AlarmComponent: Iteration 1 AlarmComponent - IncomingScheduler: Iteration 2 AlarmComponent - AlarmHandler: Iteration 3 I/O - IncomingModule: Iteration 5 I/O - OutgoingModule: Iteration 6 MeasurementComponent: Iteration 7
Figure 8: The new high-level overview
Functionality Reallocation Here you nd the new reallocation of the uses cases over the new components. If the Incoming and Outgoing Module are decomposed (after itaration 6) a total recapitulation of the done use cases will be provided. IncomingModule: (iteration 5) Availablity 2a: Acknowledge every received trame UC: route messages Modiability 3: Decentralized electricity OutgoingModule: (iteration 6) UC: create messages UC: send messages Modiability 1a: Sending commands to remote smart devices (HAS).
11
MeasurementComponent: (iteration 7) Availablity 2b: Detection of dead valves UC: Store measurement UC: notify consumer/call center Performance 2: Anomaly detection
2.6
Iteration 5: Decomposing the I/Os IncomingModule
Components to decompose This iteration and the next one will be the decomposition of the I/O component. This component represents the handling of incoming data and the possibility to send out data. This iteration will do the decomposition of the Incoming Module of gure 7.
Architectural Drivers Like stated in iteration 4, we can now handle the created use case: Availablity 2a: acknowledge received data. Due to the design change in iteration 4, the Incoming Module needs the ability to route messages to the right component (MeasurementComponent or AlarmComponent of gure 8). Alarms must go to the AlarmComponent and measurements must go to the MeasurementComponent. Availablity 2a: acknowledge received data UC: route messages Modiability 3: Decentralized electricity
Tactics to address the requirements Ping/Echo Anticipate expected changes We chose Ping/Echo tactic because the messages themself represent the ping and our acknowledgment can be the echo. This doesnt give us so much overhead as the heartbeattactic, then we would have to monitor every module continiously. The tactic Anticipate expected changes gives us the opportunity to add new components to the ReMeS system in the future.
Architectural Patterns router.
To route the messages the each component we could just use a message
Decomposition To keep the design of gure 8, the Incoming Module must have a component MessageRouter that routes the incoming data to the right component (AlarmComponent, MeasurementComponent and later in iteration 20 the ControlComponent). The routing can be done on the type of the incoming data. A component Type is introduced that can determine the type of the incoming data. Finally there is a connection to the OutgoingModule of the I/O. This connection is to tell the Outgoing Module to send an acknowledge of the received data. The technology through which the trame was received is send as paramter with the command. This way an acknowledge can be sent back through the same technology. The working of this is displayed in gure 10. Modiability 3 states that individual trames of utility usages and produced power at the consumers home could be sent to the system and handled. A new trame type for these data can easy be included. A component to handle the trames of the own produced power can be added thanks to the MessageRouter. This component will handle this trame similar like the MeasurementComponent. The MessageRouter can then send the received trames to the right component. This way consumers who are not producing power wont be aected if this would be introduced. 12
Diagrams Here you nd the diagrams for this iteration. In gure 9 you can nd the gure of the decomposition tree of the Incoming Module. In 10 you can nd the component diagram of the Incoming Module.
Figure 9: Decomposition of the incoming module of the I/O component
Figure 10: Component diagram of the incoming module
Functionality Reallocation The use cases of the Incoming Module are fullled. The components in the Incoming Module will not be decomposed any further.
2.7
Iteration 6: Decomposing the I/Os OutgoingModule
Components to decompose This iteration will be the decomposition of the outgoing module of the I/O component, see gure 7. This component represents the handling of the data to be send.
Architectural Drivers The Outgoing Module must accept requests to create and send a specic trame to a location. UC: create messages UC: send messages Modiability 1a: Sending commands to remote smart devices (HAS).
Tactics to address the requirements
13
Generalize the module This tactic was chosen because it gives us the opportunity to reuse the OutgoingModule. This way Modiability 1a can be implemented very fast.
Decomposition A component MessageCreator can create messages for every connectiontechnology and has an interface for all data that must can be sent. E.g: sendAcknowledge(valve) from the Incoming Module, sendConsumerAlarmNotication(message) from the AlarmComponent, ... (see the interface in the appendix) It sends this message to the actual Sender who sends the message to its destination. Each Sender represents a sender for a dierent technology. Because we added more general methods (E.g: notifyConsumer(..) see interfaces in the appendix) to the MessageCreators interface, these methods can be reused over and over again by dierent components. This decomposition is displayed in gure 12.
Diagrams Here you nd the diagrams for this iteration. In gure 11 you can nd the gure of the decomposition tree of the Outgoing Module. In 12 you can nd the component diagram of the Outgoing Module.
Figure 11: Decomposition of the outgoing module of the I/O component
14
Figure 12: Component diagram of the outgoing module Functionality Reallocation The use cases of the Outgoing Module are fullled. The components in the Outgoing Module will not be decomposed any further.
2.8
Recapitulation: Use case overview 1
In this section we give a short review of the completed and incompleted use cases and non-functional requirements. Completed use cases: UC UC UC UC 7: send trame to remote device - Outgoing Module 8: send measurement - Incoming Module(routing to Measurement) 9: notify consumer - AlarmComponent & Outgoing Module 13: send alarm - AlarmComponent
Completed non-functional requirements: Performance 1: Timely closure of valves - AlarmComponent Availability 2a: Acknowledge received data - Incoming/Outgoing Module Modiability 1a: Sending commands to remote smart devices (HAS) - OutgoingModule Modiability 3: Decentralized electricity generation - IncomingModule
Use cases to do: UC 1,2,3,4,5,6,10,11,12,14,15,16,17 Non functional requirements to do: Availability 1,3 Availability 2b: Detection of dead valves Performance 2,3 15
Modiability 1b,2
2.9
Iteration 7: Decomposing the Measurement component
Components to decompose This iteration will be the decomposition of the Measurement component. This is the last component of gure 7 to be decomposed. This component does the analysis of the receiving measurements. The subcomponents will be decomposed in iteration 8, 9 and 10.
Architectural Drivers The Measurement component receives from the Incoming Module only trames with measurement data. It must be possible to store the data in the database, the component has to detect if there are dead valves and nally it must do an anomaly detection on the measurement data to create an alarm if necessary. This gives analogue on the reallocation in iteration 4 the following drivers: UC: Detect missing heartbeat (to do in HeartBeatDetector) UC: Store measurement (next iteration - TrameHandler ) UC: notify consumer/call center (to do in Anomaly Detection) Performance 2: Anomaly detection (to do in Anomaly Detection) UC 10: Detect anomaly (to do in Anomaly Detection)
Decomposition Because the component can be busy when new measurements are coming in, well start with placing a Buer at the incoming port of the Measurement component. The TrameHandler reads the trame and sees from which valve the measurement is coming. The TrameHandler has access to the database to get the consumer of the valve. Second, the measurements are stored with the consumer id. The AnomalyDetection analyses the data by comparing it to previous measurements and false positives from the database with respect to the consumersettings. If an anomaly is detected, the AnomalyDetection creates an alarm and sends it to the AlarmComponent like the incoming module would do. Finally the TrameHandler informs the HeartBeatDetector from which valve a measurement is received. The Detector checks if valves are not sending any data anymore and has the possibility to send a command to the Outgoing Module. The Outgoing Module will send a command to the valve with a request to send data. In gure 14 you can see the working more easily. The measurement trames come from the IncomingModule in the buer.
Diagrams Here you nd the diagrams for this iteration. In gure 13 you can nd the gure of the decomposition tree of the MeasurementComponent. In 14 you can nd the component diagram of the MeasurementComponent.
Figure 13: Decomposition the measurement component A short overview of the components iterations: MeasurementComponent: this - Iteration 7
16
TrameHandler: Iteration 8 HeartBeatDetector: Iteration 9 AnomalyDetection: Iteration 10
Figure 14: Component diagram of the measurement component
Functionality Reallocation Reallocation of functions over MeasurementComponents components: TrameHandler: (iteration 8): UC: Read trame UC: Store measurement HeartBeatDetector: (iteration 9): UC: Detect missing heartbeats Availability 2b: Detect dead valves AnomalyDetection: (iteration 10): UC: notify consumer Performance 2: Anomaly Detection UC 10: Detect anomaly
2.10
Iteration 8: Decomposing the Measurements TrameHandler
Components to decompose This iteration will be the decomposition of the TrameHandler of the Measurement component in gure 13.
Architectural Drivers Like said in iteration 7, this component has to read trames and create a MeasurementObject to store the received measurement in the database. UC: Read trame UC: Store measurement
17
Decomposition The TrameReader gets an incoming measurementtrame from the Buer. It reads the trame and gets from which valve the trame is coming. With a connection to the database the consumer of that valve is received. With the help of MeasurementData its possible to create a MeasurementObject from the data with the consumer id. This MeasurementObject can be stored in the database. There is a connection to the AnomalyDetection to analyse the measurementdata. There is also a connection to the HeartBeatDetector for updating his table to say that a new measurement from a specic valve is received. The working gets clear in gure 16.
Diagrams Here you nd the diagrams for this iteration. In gure 15 you can nd the gure of the decomposition tree of the TrameHandler. You nd the component diagram of the TrameHandler in gure 16.
Figure 15: Decomposition the TrameHandler in the Measurement component
Figure 16: Component diagram of the TrameHandler
Functionality Reallocation The use cases of the TrameHandler are fullled. The components in the TrameHandler will not be decomposed any further.
2.11
Iteration 9: Decomposing the Measurements HeartBeatDetector
Components to decompose This iteration will be the decomposition of the HeartBeatDetector of the MeasurementComponent of gure 13 in the MeasurementComponent.
Architectural Drivers This component checks if remote valves keep sending measurements. The drivers are analogue as those stated in iteration 7. UC: Detect missing heartbeats Availability 2: Detect missing measurements 18
Tactics to addresss the requirements To achieve the drivers we chose the following tactic: HeartBeatDetection Because the modules have to send with a regular their messages are in fact already a heartbeat. So it is easier to implement this than any other tactic. For example with Ping/Echo we would also need a connection to OutgoingModule to continiously ping the remote module. This would create unnecessary overhead.
Decomposition To achieve the requirements we need a table having entries of the valves from who we need measurements. This table also needs timing data per valve, this represents in which time we want to have at least 1 incoming measurement of that valve. We will call this component the TimeTable. The TimeTable provides a function to reset an entry of a specic valve with a given time. The caller of this function will be the TableManager. The consumer is also passed to it so a specied timing can be set per valve according to the consumers module conguration. If a new measurement is received this TableManager will be notied with the consumer object, the valveId, the valveAddress and the technology for that valve. All coming from the TrameReader. The Manager updates the table for that valve and sets the timing to the normal timing for the valve. The TimeTable will do a countdown on the timings per tick. If the timing of a valve becomes zero, a request to remote valve must be send. Therefore we have a component TableAnalyser. This component checks in the TimeTable for negative values. If found, a command to the OutgoingModule can be created to send to the remote valve a request for sending some data. This way the TableAnalyser can check how many misses happened and can create an alarmTrame if this is over a specied amount (3 times). The AlarmComponent will notify the consumer and store it in the database so it can be viewed in the ControlPanel. At last the TimeTable has a delDevice method. When a consumer decides in the control panel to stop using the system, no new measurements of that module have to be received. This working is like in gure 18.
Diagrams Here you nd the diagrams for this iteration. In gure 17 you can nd the gure of the decomposition tree. The working like explained above can be found in the component diagram in gure 18.
Figure 17: Decomposition the HeartBeatDetector in the Measurement component
19
Figure 18: Component diagram of the HeartBeatDetector Functionality Reallocation The use cases of the HeartBeatDetector are fullled. The components in the HeartBeatDetector will not be decomposed any further.
2.12
Iteration 10: Decomposing the Measurements AnomalyDetection
Components to decompose This iteration will be the decomposition of the AnomalyDetection. This is last component to be done of the MeasurementComponent like displayed in gure 13.
Architectural Drivers This component does the detection of anomalies in the measured data coming from the TrameHandler in the MeasurementComponent (gure 14). The drivers are those of the reallocation in iteration 7. UC: notify consumer Performance 2: Anomaly Detection UC 10: Detect anomaly
Tactics to addresss the requirements Performance 2 says we need a scheduler, scheduling on the environment mode, normal or overloaded, of the system. Additionally the load is balanced over multiple instances. To achieve the drivers we chose the following tactics: Resource Arbitration: scheduling Resource Management: concurrency We do not know yet the anomalyAlgorithms, so we cant reduce the computational overhead or increase the computation eciency.
Architectural Patterns The scheduling can be done like in the rst iteration for the AlarmComponent with the ActiveObject pattern with an extra ModeComponent. For concurrency and the balancing over multiple instances we chose the LeaderFollower pattern.
Decomposition Because the system can operate in 2 modes, the normal environment and the overloaded mode, we start with a component that represents the Mode of the AnomalyDetectionComponent. 20
The SchedulingComponent, scheduling depending on the mode, is connected to that. It can set the mode depending on the amount of requests. The Scheduler receives also the consumer of the measurementdata, to schedule on his SLA in overload mode. The AnomalyAlgorithm gets the next measurementdata from the Scheduler that needs to be processed as rst. The AnomalyDetection gets the other measurements and alarms of that consumer out of the database. It has now all the data available to run an algorithm to detect anomalies. The alarms and previous measurements are needed to learn from previous false positives. The alarms will hold data representing the alarm was true or false. The consumer can set this in the ControlPanel (see later). The AnomalyAlgorithmcomponents work like the LeaderFollower pattern. This way the load is balanced over multiple instances. The AnomalyAlgorithm can do a getConsumer(consumerId) (consumerId is in the measurementData) to get the valve properties of those measurements. This way an alarmTrame can be send to the AlarmComponent like it was an alarmTrame from a remote valve. The alarm will then be handled correctly. This working is like in gure 20.
Figure 19: Decomposition of the AnomalyDetection in the Measurement component
Figure 20: Component diagram of the AnomalyDetection
Functionality Reallocation The use cases of the AnomalyDetection are fullled. The components in the AnomalyDetection will not be decomposed any further.
21
2.13
Uptill now all the components of gure 7 and gure 13 are decomposed. We have: AlarmComponent: Iteration 1 AlarmComponent - IncomingScheduler: Iteration 2 AlarmComponent - AlarmHandler: Iteration 3 I/O - IncomingModule: Iteration 5 I/O - OutgoingModule: Iteration 6 MeasurementComponent: Iteration 7 MeasurementComponent - TrameHandler: Iteration 8 MeasurementComponent - HeartBeatDetector: Iteration 9 MeasurementComponent - AnomalyDetection: Iteration 10
A review of the completed and incompleted use cases and non-functional requirements: Completed use cases: UC UC UC UC UC 7: send trame to remote device - Outgoing Module 8: send measurement - Incoming Module(routing to Measurement) 9: notify consumer - AlarmComponent & Outgoing Module 10: detect anomaly - AnomalyDetection 13: send alarm - AlarmComponent
Completed non-functional requirements: Performance 1: Timely closure of valves - AlarmComponent Performance 2: Anomaly Detection - AnomalyDetection Availability 2a: Acknowledge received data - Incoming/Outgoing Module Availability 2b: Detection of dead valves - MeasurementComponent Modiability 1a: Sending commands to remote smart devices (HAS) - OutgoingModule Modiability 3: Decentralized electricity generation - IncomingModule
Use cases to do: UC 1,2,3,4,5,6,11,12,14,15,16,17 Non functional requirements to do: Availability 1,3 Performance 3 Modiability 1b,2
2.14
Iteration 11: Decomposing the Storage
Components to decompose From section 2.13 we see a lot of components are decomposed. The missing high priority keypart for letting all of these components work is storage. In this section we will begin the decomposition of the StorageComponent. Adding the storage to the current system (gure 7) gives us gure 21.
Architectural Drivers Related to the StorageComponent are the following drivers: Availability 1: Measurement database failure Performance 3: Requests to the measurement database
22
Figure 21: Adding the Storage to the system Decomposition Because the drivers state the database of the measurements has to be somewhat apart from the other databases we chose to make 3 dierent components. We get the MeasurementStorage, ConsumersStorage and the AlarmStorage. In front of those components we place a QueryHandler having an interaface of available queries for the other external components. The QueryHandler completes all of these queries by routing them to the right storage.
Figure 22: The decomposition tree of the Storage A short overview of the components iterations: Storage: this - Iteration 11 MeasurementStorage: Iteration 12 ConsumerStorage: Iteration 13 AlarmStorage: Iteration 14
Figure 23: Component diagram of the Storage
Functionality Reallocation MeasurementStorage: (iteration 12) 23
Availability 1: Measurement database failure Performance 3: Requests to the measurement database UC: Store & retrieve ConsumerStorage: (iteration 13) UC: Store & retrieve AlarmStorage: (iteration 14) UC: Store & retrieve
2.15
Iteration 12: Decomposing the Storages MeasurementStorage
Components to decompose In decomposing the storage we will start with the MeasurementStorage of gure 22. This is an important component with some serious drivers.
Architectural Drivers tion of iteration 11:
The key drivers for the MeasurementStorage are those stated in the realloca-
Availability 1: Measurement database failure Performance 3: Requests to the measurement database UC: Store & retrieve
Tactics to addresss the requirements Performance 3 says we need a scheduler, scheduling on the environment mode, normal or overloaded, of the system. Additionally the load is balanced over multiple instances. To achieve the drivers we chose the following tactics: Resource Arbitration: Scheduling Resource Management: Concurrency We cant increase the computational eciency because the DBMS will handle the queries. We assume this will do the queries as ecient as it can be.
Architectural Patterns We chose to use a DataMapper to access the database. The LeaderFollower pattern added for DataMappers to deal with concurrency. And nally an ActiveObject is used for the scheduling.
Decomposition We have a Scheduler, scheduling depending on the mode of the ModeComponent. The scheduler can set this mode if he receives a specied amount of requests in a specied interval of time. If in overload mode the Scheduler does a query to the ConsumerStorage to get the consumer for his SLA to schedule getqueries. The Scheduler could hold a cache himself that is used if in overloaded mode. Finally the Scheduler uses a DataMapper to access the Database. The Database is built out of a master and slaves. The Mapper can read from cheaper slaves but only write to (and read from) the fast master. The master will write to the slaves. The slaves will be a replica of the master. The DataMappers own a priority map. First the fast master, second the cheaper slave1, third slave2. Each write will try to write in this order untill a write succeeds. If the master is down a slave will perform the write and write to the other lower priority databases. If the master does a recovery, he recovers from the available highest priority slave. If he is running again the DataMappers can write again to the master. The working is displayed in gure 25.
24
Figure 24: The decomposition tree of the Storages MeasurementStorage
Figure 25: Component diagram of the Storages MeasurementStorage
Functionality Reallocation The use cases of the MeasurementStorage are fullled. The components in the MeasurementStorage will not be decomposed any further.
2.16
Iteration 13: Decomposing the Storages ConsumerStorage
Components to decompose The MeasurementStorage of gure 22 was decomposed in the previous iteration. The component for this iteration will be the ConsumerStorage. Architectural Drivers The key drivers for the ConsumerStorage are those stated in the reallocation of iteration 11: UC: Store & retrieve Architectural Patterns We chose to use a DataMapper to access the database. Decomposition Only 2 components are used inside the ConsumerStorage. We use a DataMapper to access the nal Database. 25
Figure 26: The decomposition tree of the Storages ConsumerStorage
Figure 27: Component diagram of the Storages ConsumerStorage
Functionality Reallocation The use cases of the ConsumerStorage are fullled. The components in the ConsumerStorage will not be decomposed any further.
2.17
Iteration 14: Decomposing the Storages AlarmStorage
Components to decompose The last component of gure 22 that will be decomposed is the AlarmStorage and will be done in this section. The working of this component is completely like the ConsumerStorage from the previous itertion. We will only give the diagrams here.
Diagrams Here you nd the diagrams for this iteration. In gure 28 you can nd the gure of the decomposition tree. The component diagram can be found in gure 29.
26
Figure 28: The decomposition tree of the Storages AlarmStorage
Figure 29: Component diagram of the Storages AlarmStorage Functionality Reallocation The use cases of the AlarmStorage are fullled. The components in the AlarmStorage will not be decomposed any further.
2.18
Uptill now all the components of gure 21 are decomposed. We have: AlarmComponent: Iteration 1 AlarmComponent - IncomingScheduler: Iteration 2 AlarmComponent - AlarmHandler: Iteration 3 I/O - IncomingModule: Iteration 5 I/O - OutgoingModule: Iteration 6 MeasurementComponent: Iteration 7 MeasurementComponent - TrameHandler: Iteration 8 MeasurementComponent - HeartBeatDetector: Iteration 9 MeasurementComponent - AnomalyDetection: Iteration 10 Storage: Iteration 11 Storage - MeasurementStorage: Iteration 12 Storage - ConsumerStorage: Iteration 13 Storage - AlarmStorage: Iteration 14
A review of the completed and incompleted use cases and non-functional requirements: Completed use cases: UC 7: send trame to remote device - Outgoing Module UC 8: send measurement - Incoming Module(routing to Measurement) 27
UC 9: notify consumer - AlarmComponent & Outgoing Module UC 10: detect anomaly - AnomalyDetection UC 13: send alarm - AlarmComponent Completed non-functional requirements: Performance 1: Timely closure of valves - AlarmComponent Performance 2: Anomaly Detection - AnomalyDetection Performance 3: Requests to the measurement database - MeasurementStorage Availability 1: Measurement database failure - MeasurementStorage Availability 2a: Acknowledge received data - Incoming/Outgoing Module Availability 2b: Detection of dead valves - MeasurementComponent Modiability 1a: Sending commands to remote smart devices (HAS) - OutgoingModule Modiability 3: Decentralized electricity generation - IncomingModule
Use cases to do: UC 1,2,3,4,5,6,11,12,14,15,16,17 Non functional requirements to do: Availability 3 Modiability 1b,2
2.19
Iteration 15: Decomposing the ControlPanel
Components to decompose The current system is the complete decomposition of gure 21. The next priority is the ControlPanel. Imagine we add a component ControlPanel next to Storage from gure 21. This results in gure 30.
Figure 30: Adding the ControlPanel to the current system
Architectural Drivers At high-level the ControlPanel has to do a lot of the remainig use cases: UC UC UC UC UC UC UC UC UC UC 1: Log in 2: Log o 3: Register consumer 4: Unregister consumer 5: Associate device to consumer 6: Customize consumer prole 11: Operate actuator remotely 12: Set alarm recipients 14: Request consumption predictions 17: Request consumption predictions
Architectural Patterns We will use a FrontController for the ControlPanel to receive all its requests. It will pass them to other components and respond to the client.
28
Decomposition We use a FrontController for the ControlPanel. We assume our ControlPanel will be a website. But a program with a connection through HTTP is possible. The FrontController will receive all the incoming HTTP requests and handle them. We need an AuthenticationService for handling the authentication of people that log in on the system. We have a GUI component representing the view. This component includes just the webpages to be displayed. We could have a page for consumers to register, pages for the CallCenter operators, pages for the consumers, pages for the researchers (UC 17), pages for the UtilityProviders for seeing the predictions (UC 14) and pages for EmergencyServices where they could see high priority alarms like gas leaks so they have direct access to urgent data. The last component will be the Backend for the business logic of the ControlPanel. This Backend will include components for handling the operations available in the ControlPanel. Therefore these components will have a direct connection to the StorageComponent for getting data. The pages for the CallCenter operators could have a section alarms. In that section all alarms and details in the database could be listed. Alarms set in the database coming from the AlarmComponent like low batteries or leaks can now be viewed by the CallCenter operators on their ControlPanel. The incoming HTTP requests will directly be on the FrontController and not to the IncomingModule of iteration 5. The addition of this components does not have any impact on the previous created components.
Figure 31: The decomposition tree of the ControlPanel A short overview of the components iterations: ControlPanel: this - Iteration 15 AuthService: Iteration 16 FrontController: Iteration 18 Backend: Iteration 19
Figure 32: Component diagram of the ControlPanel
29
Functionality Reallocation We will reallocate use cases over the subcomponents of the ControlPanel AuthService: (iteration 16) UC: UC: UC: UC: UC: UC: UC: UC: UC: UC: Lookup user Check password Check session Create token Reading incoming requests Pass requests to backend Pass backend response to the GUI Send GUI to client Check permissions for an operation Check if login or session is valid
FrontController: (iteration 18)
Backend: (iteration 19) UC: handle all the operations performed via the website.
2.20
Iteration 16: Decomposing the ControlPanels AuthService
Components to decompose This is the rst iteration in decomposing the ControlPanels components of gure 31. This iteration handles the AuthService.
Architectural Drivers The key drivers for the AuthService are those stated in the reallocation of iteration 15: UC: UC: UC: UC: Lookup user Check password Check session Create token
Decomposition We start with a component LoginCheck that handles the authentication of the user. We will work with a password system to authenticate the user. The FrontController will pass the loginrequest (and logoutrequest) to this AuthService. The LoginCheck gets the consumer out of the database and checks the password. We could use an MD5-hash storage of the password in the database. This way no cleartext passwords are saved in the database. If the authentication is succesfull a token is generated for that user in the TokenGenerator. We would use librarys to generate the token so its quasi impossible to guess a token. This token will represent a sessionId to generate a session with the user. It will be send back to the user and the user sends it back with each HTTP request he does. In the sessionTable the active sessions are stored. The LoginCheck can also do a doLogOut. It will do a removeSession on the SessionTable to remove the session out of the SessionTableComponent (this isnt displayed in the gures). With every incoming request the FrontController calls the SessionCheckComponent to check if the session of the received token is still active.
30
Figure 33: The decomposition tree of the ControlPanels AuthService
Figure 34: Component diagram of the ControlPanels AuthService Functionality Reallocation The use cases of the AuthService are fullled. We will do a decomposition of the TokenGenerator in the next iteration. The use cases for the TokenGenerator are: UC: Generate consumertoken UC: Generate representativetoken UC: Generate techniciantoken
2.21
Iteration 17: Decomposing the ControlPanels AuthServices TokenGenerator

In this section we will decompose the TokenGenerator of the AuthSer-
Components to decompose vice in the ControlPanel.
31
Architectural Drivers The key drivers for the TokenGenerator are those stated at the end of the previous section: UC: Generate consumertoken UC: Generate representativetoken UC: Generate techniciantoken We generate 3 dierent tokens so there is a possibility to check on the incoming token from the client what kind of user it is. A consumer, a representative (CallCenter operator) or a technician.
Decomposition If a request comes in to generate a token it comes in on the RequestHandler. This one calls the ConsumerToken or the RepresentativeToken, depending the request, to generate a token. Each token will be unique and hard to guess. But it is possible when a token is generated to determine from which generator it is coming. To deal with low priority UC 14 and 17 we could add a tokengenerator for researchers and UtilityProviders. Finally a generator could be added for EmergencyServices so they can access urgent alarms like gasleaks. This should allow them to login too and see everything where they have access to. This is not displayed in the gures.
Figure 35: The decomposition tree of the ControlPanels AuthServices TokenGenerator
Figure 36: Component diagram of the ControlPanels AuthServices TokenGenerator
Functionality Reallocation The use cases of the TokenGenerator are fullled. The components in the TokenGenerator will not be decomposed any further. 32
2.22
Iteration 18: Decomposing the ControlPanels FrontController
Components to decompose In this section the FrontController of the ControlPanels in gure 31 will be decomposed.
Architectural Drivers The key drivers for the AuthService are those stated in the reallocation of iteration 15: UC: UC: UC: UC: UC: UC: Reading incoming requests Pass requests to backend Pass backend response to the GUI Send GUI to client Check permissions for an operation Check if login or session is valid
Decomposition We start with a component RequestReader that handles all the incoming HTTP requests. The session is checked or a login is performed with the AuthService described above. Not everybody can make the same requests to the Backend. We generated dierent types of tokens depending on the users that logged in (described in iteration 17). The RequestReader could extract the token from the request and with the help of the ServiceLookupTable see if the operation is permitted for that type of token (user). Evenso the checklogin returns the userId. With that userId rules for example setRecipient can be checked. He can only do this query if the target userId is the same as the user doing the operation. The ServiceLookupTable has thus database access to check these high-level rules. He needs only access to the consumerdatabase. If the request is granted it is passed to the MessageRouter. The MessageRouter routes the operation to the right component of the Backend (next iteration). Otherwise a error is send back to the client. The response of the Backend is send to the GUI component of gure 31. The GUI component generates with the received dataset (e.g: MeasurementData) a ready html page. The generated page is send back to the FrontController who sends it back to the client.
Figure 37: The decomposition tree of the ControlPanels FrontController
33
Figure 38: Component diagram of the ControlPanels FrontController Functionality Reallocation The use cases of the FrontController are fullled. The components in the FrontController will not be decomposed any further.
2.23
Iteration 19: Decomposing the ControlPanels Backend
Components to decompose In this section the Backend of ControlPanel in gure 31 will be decomposed.
Architectural Drivers The drivers for this iteration are handling the functions that must be done from the ControlPanel and are also listed in the interfaces section. We will give them here too: UC: registerUserByCallCenter - Registering a user from the CallCenter. UC: registerUserByUser - Registering a user himself from the website. Afterwards the registration has to be approved by the CallCenter. UC: getNonApprovedUsers - Returns the non-approved users. UC: approveUser - Approve a user. UC: conrmViaMail - The users conrms his registration by the http-link in the conrmation mail. UC: removeUserByUser - Sets the users devices as non active. Sets a user property he wants to be deleted. The delDevice from the HeartBeatDetector is invoced. UC: removeUserByCallCenter - The CallCenter removes a user. UC: getRemovedUsers - Returns a list of users who want to stop using the system (set by removeUser(..)). A technician has to come by to pick up the modules UC: deleteUser - After the technician has picked the modules he can invoke this method. The user is now completely deleted from the system. UC: addModule - A remote module is coupled to a user. UC: addActuator - The actuator is coupled the module, that is coupled to a user. UC: changeAlarmRecipient - Changes the recipient of the alarms for a user owning a module. UC: changeMeasurementsTresholds - Change the treshold of a device. UC: changeDeviceCong - Change the conguration of a device. Like sending timings and tresholds. The new conguration can be sent with the OutgoingModule. 34
UC: changeMailAddress - Sets the new mailaddress. UC: changeSmsNumber - Sets the new smsnumber. UC: changeLocation - Sets the new location. UC: setDeviceStatus - Can set a device status. E.g: open, closed,.. A shutdowncommand can be sent with the OutgoingModule. UC: setAlarmReceiveTechn - Set for the alarms coming from a device the noticationtechnology for the consumer. UC: getAlarms - Gets all the alarms. The CallCenter sees all the alarms. The consumer only his alarms. UC: markAlarmAsRead - The consumer can set an alarm as viewed. UC: setAlarmAsFalsePositive - Sets the property of an alarm as a false positive. UC: getPredictions - Gets the predictions of water, gas,... UC: getMeasurementsQuery - Can do a GETQuery for researchers.
Decomposition Our decomposition will consist out of 3 components. A ConsumerService, a DeviceService and a MeasurementService. Respectively they will handle the incoming requests on the ControlPanel for the consumers (e.g: registration), the management of devices like controlling (e.g: shutdown a valve) the users devices from the ControlPanel and the measurement operations. The components have access to the Storage component for doing queries. This way, the database keeps safe because operations only gets to these components if they can pass the safety due to the ServiceLookupTable in the FrontController as explaind in iteration 18. The rst two components have an output to the I/O OutgoingModule. The ConsumerService for sending a mail in case of a user registration. The DeviceService for sending a command to shutdown a valve or the new conguration if this was changed. The ConsumerService has a connection to the UIS so he can notify the UtilityProviderss system when a consumer stops using ReMeS.
Diagrams Here you nd the diagrams for this iteration. In gure 39 you can nd the gure of the decomposition tree. The rst two components of the Backend are found in gure 40 and gure 41. The measurementService is similar.
Figure 39: The decomposition tree of the ControlPanels Backend
Figure 40: Component diagram of the ControlPanels Backends ConsumerService
35
Figure 41: Component diagram of the ControlPanels Backends DeviceService Functionality Reallocation If we assume the 2 components have the interfaces to handle all the operations that have to be done from the ControlPanel. This is too low level to further decompose here.
2.24
Uptill now all the components of gure 30 are decomposed. We have: AlarmComponent: Iteration 1 AlarmComponent - IncomingScheduler: Iteration 2 AlarmComponent - AlarmHandler: Iteration 3 I/O - IncomingModule: Iteration 5 I/O - OutgoingModule: Iteration 6 MeasurementComponent: Iteration 7 MeasurementComponent - TrameHandler: Iteration 8 MeasurementComponent - HeartBeatDetector: Iteration 9 MeasurementComponent - AnomalyDetection: Iteration 10 Storage: Iteration 11 Storage - MeasurementStorage: Iteration 12 Storage - ConsumerStorage: Iteration 13 Storage - AlarmStorage: Iteration 14 ControlPanel: Iteration 15 ControlPanel - AuthService: Iteration 16 ControlPanel - AuthService - TokenGenerator: Iteration 17 ControlPanel - FrontController: Iteration 18 ControlPanel - Backend: Iteration 19
A review of the completed and incompleted use cases and non-functional requirements: Completed use cases: UC UC UC UC UC UC 1: Log in - ControlPanel 2: Log o - ControlPanel 3: Register consumer - ControlPanel 4: Unregister consumer - ControlPanel 5a: Associate device to consumer - ControlPanel 6: Customize consumer prole - ControlPanel 36
UC UC UC UC UC UC UC UC UC
7: Send trame to remote device - Outgoing Module 8: Send measurement - Incoming Module(routing to Measurement) 9: Notify consumer - AlarmComponent & Outgoing Module 10: Detect anomaly - AnomalyDetection 11: Operate actuator remotely - ControlPanel 12: Set alarm recipients - ControlPanel 13: Send alarm - AlarmComponent 14: Request consumption predictions - ControlPanel 17: Perform research - ControlPanel
Completed non-functional requirements: Performance 1: Timely closure of valves - AlarmComponent Performance 2: Anomaly Detection - AnomalyDetection Performance 3: Requests to the measurement database - MeasurementStorage Availability 1: Measurement database failure - MeasurementStorage Availability 2a: Acknowledge received data - Incoming/Outgoing Module Availability 2b: Detection of dead valves - MeasurementComponent Modiability 1a: Sending commands to remote smart devices (HAS) - OutgoingModule Modiability 3: Decentralized electricity generation - IncomingModule
Use cases to do: UC 5b: Additional connection tests UC 15,16 Non functional requirements to do: Availability 3 Modiability 1b,2
2.25
Iteration 20: Decomposing the ControlComponent
Components to decompose In the recapitulation of the previous section we see that use case 5b still needs to be done. When a new device is installed, inital connection tests need to be performed. In this section we will add a ControlComponent to the system resulting in gure 42.
Figure 42: Adding the ControlComponent to the system
Architectural Drivers The things needs to be done are: UC: receiving testTrame UC: sending testTrame UC: mark device as active 37
Decomposition We need a TrameReader to check from which valve the testTrame is coming. We need a TestTable to hold the current test status per valve and nally a DbUpdater for updating the database if the valve can be set active after passing the tests. The TestTable could hold the amount of received testTrames per module. After a specied number it could call the DbUpdater to set the module as ready. The TestTable has a connection to the I/O OutgoingModule to send additional testTrames. The incoming testTrames rst come in on the I/O IncomingModule of iteration 5. Imagine its like adding a component ControlComponent beneath the AlarmComponent in gure 8.
Figure 43: The decomposition tree of the ControlComponent
Figure 44: Component diagram of the ControlComponent
Functionality Reallocation Use case UC: 5 Associate device to consumer is now complete. Further decomposition of the ControlComponent isnt necessary.
2.26
Iteration 21: Decomposing the BillingComponent
Components to decompose To deal with the remaining use cases we add a BillingComponent to the system and decompose it in this iteration. Our new tree becomes like gure 45.
38
Figure 45: Adding the BillingComponent to the system Architectural Drivers The drivers are the leftover use cases: UC 15: Generate invoice UC 16: Mark invoice paid Availability 3: Third party billing service failure Modiability 1b: Consumer can have a dynamic billing prole.
Tactics to address the requirements Ping/echo Anticipate expected changes We will use the ping/echo tactic to detect a failure of the 3th party billing company. In fact the message that is send can be the ping. If we ask to the 3th party billing company to acknowledge every sended message than this can play the role of echo. This way we can easily set up a reliable system. The method with the heartbeat would give us to much overhead. It is also not relevant that the billing system of the 3th party is down when you dont want to send messages to it. A tactic for Modiability 1b is Anticipate expected changes. We chose this because we think it is easy to accomplish.
Decomposition The TimeTicker will ask to generate invoices every day to the InvoiceHandler. This component will get the consumers which billing date is the current date. For every consumer he will then ask to create an invoice to the InvoiceCreator, who gets the current rates. He will get the measurements from the database for that user and create an invoice. He will add that invoice to the consumer prole and save this. He will also tell the InvoiceSender to send this invoice. When the consumer has paid the invoice the 3th party billing company will let the listener know that the invoice is paid and the listener will store that in the database. To achieve Modiability 1b only some small modications to gure 47 should be made because we already get the rates. We could create a component that continiously gets the new rates, checks which consumers have dynamic pricing in their prole (includes a small modication to the controlpanel and backend so consumers can set this property), check the pricerate with the consumers treshold. Finally a connection to the I/Os OutgoingModule for sending a command to activate a remote smart device could be made (or a notication to the consumer for manual intervention). (like said in iteration 4) We can also take back Modiability 3: Decentralized electricity generation (introduced in iteration 4 and 5) This aects also the billing. If this would be implemented the measurements(usages) can be get from the database. But also the consumers generated power can be get from the database(requires only
39
1 extra request next to getMeasurements in gure 47). Based on those 2 datasets the new billing can be done.
Figure 46: The decomposition tree of the BillingComponent
Figure 47: Component diagram of the BillingComponent
Functionality Reallocation We will make a further decomposition of the InvoiceSender in the next iteration. The use cases for that component are: UC: Send an invoice UC: wait for an acknowledgement UC: Resend an message if the acknowledgement isnt received
2.27
Iteration 22: Decomposing the BillingComponents InvoiceSender
Components to decompose In this section we will decompose the InvoiceSender of gure 46 of the BillingComponent. 40
Architectural Drivers iteration:
The drivers are those stated in the reallocation at the and of the previous
UC: Send an invoice UC: wait for an acknowledgement UC: Resend an message if the acknowledgement isnt received
Decomposition The RequestHandler will receive the sending request. He will send the message through the sender. He will also add an entry to the AckTable. This table will decrease the time on the entries every xed interval. When it reaches zero he will try to resend the message. When an acknowledgement is received the AckUnit will delete the entry from the AckTable.
Figure 48: The decomposition tree of the InvoiceSender
Figure 49: Component diagram of the InvoiceSender
Functionality Reallocation The use cases for this component are fullled. The subcomponents will not be decomposed any further. All the use cases are fullled. From the non-functional requirement only the low-priority M2: Fine grained metering for enterprises isnt worked out.
41
3
3.1
Final Architecture
The context diagram
Figure 50: The context diagram of the overall system In gure 50 you can nd the context diagram of the overall system. While designing the system we tried to limit the amount of components that interact directly with the environment. The I/O component is in charge of handling all the communication. This includes sending the trames to the measurement and control modules and sending an e-mails or sms to notify a consumer. All these dierent communication channels are represented by MessageChannel in the context diagram. The UIS is be used by two components the BillingComponent and the ConsumerService. The Billingng Component uses the UIS to get the rates of the consumers so he can make an invoice. He then sends this invoice to the 3th party billing which explains that connection. Also the ConsumerService needs the UIS to signal that a consumer isnt longer using the ReMeS system. The last connection is that of the client to the GUI. The GUI is used by the consumers, call center operatives and the technicians. This is a webpage that gives commands to the back-end. All the human interaction to the system is given through this control panel.
3.2
The Overall system
In gure 51 you can nd a component diagram of the overall system. Not all connections are displayed to keep the diagram clear. For detailed connections you can consult the diagrams of the decomposition. All the trames enter the system through the I/O component. This component analysis the type of trame and redirects it to the right component that will handle it. The AlarmComponent handle all the alarms. It will store this is permanent storage en will act upon it following the conguration settings of the consumer. The ControlComponent handles all control messages of new modules. When the modules are fully tested he will mark this is the database. This way a technician can see if the module is correctly installed. The MeasurementComponent handles all the measurement trames. It will store these in the database. He will also run anomaly detection algoritmes on the results and send a alarm to
42
Figure 51: A component diagram of the overall system the AlarmComponent if necessary. The three previous components also have a connection back to the I/O to send messages but this isnt displayed on the diagram to keep it clear. 43
The Storage component handles all the databases. It gives an interface to modify consumer, alarm and measurement objects. For certain functions it also has replicas to guarantee a good uptime. The ControlPanel handles all the communication with the users, call center representatives and technicians. All the commands the control panel can do are handled by the back-end components who have access to the storage. The connection between the Control Panel and the MeasurementComponent is necessary when a module has to be deleted. In that case the module has to be deleted from the heartbeat table, otherwise the system would generate an alarm. It also has a connection with the UIS so it can inform the utility providers when a consumer starts or stops using ReMeS. The connection to the I/O component is for notifying clients The nal component is the BillingComponent. This component handles the generation of the invoices for the consumers. It has a connection to the UIS for this so he can get the rates for the consumers. After creating this invoice he will store it and send it to a 3th party billing company who will handle the logistic element. When the invoices are paid they will let this know to our system. In the next system we will decompose these components to clarify their functionality.
3.3
Decomposition diagrams
I/O component This component consists of an incoming and outgoing module. The Incoming module handles the incoming trames and sends these to the right component it also sends acknowledgement trames to the outgoing module who will send it to the measurement modules. The Outgoing module handles all the messages that have to be send. This can be done over dierent media so for every media there is a sender who will prepare and send the message.
44
Figure 52: The decomposition of the I/O component Alarm component De AlarmComponent handles all the alarms. All alarms enter through the Incoming Scheduler. This scheduler will read the type of the alarm and schedule it. The AlarmHandler will repeatedly ask an alarm from the scheduler and handle it. It will handle it by storing the alarm in the permanent storage and sending an close valve command to the control module if necessary. To know which actions he has to do he asks the conguration from the consumer for that module. The consumer can also be notied if it is listed in the conguration.
45
Figure 53: The decomposition of the alarm component Control Component The ControlComponent only works when a new module is added to the system. When a module is installed it is programmed to send control trames. These are sended to this component. The content are stored in the TestTabel. If the ControlComponent needs more info the TestTabel will detect it and request for more info. If the info is complete the TestTabel will mark the module as ready in the database. This way a technician can see in the database if the module is ready.
46
Figure 54: The decomposition of the control component Measurement Component The MeasurementComponent handles all the incoming measurements. The decomposition isnt complete in this diagram to keep it clear. You can nd the decomposition of TrameHandler, HeartBeatDetector and AnomalyDetection below.
Figure 55: The decomposition of the measurement component
Trame Handler The TrameHandler gets the incoming trames from the buer. He will create an MeasurementDate object and store it in the database. He will also update the HeartbeatDetector and ask the AnomalyDetection component to check for anomalies.
47
Figure 56: The decomposition of the trame handler HeartBeatDetector The HeartBeatDetector checks whether a module stops sending trames. The TrameHandler will update when a message is received and he will also say when the next trame should be received. This info is stored in the TimeTable. This TimeTable will decrease the time values in his table every minute. The TableAnalyser will than check the table every minute for modules which are missing a message. He will send this module a trame to make him send a message. If this fails three times he will raise an alarm for the AlarmComponent.
Figure 57: The decomposition of the heartbeat detector
Anomaly Detection The AnomalyDetection component will run an algorithm on the new measurement data together with older ones which it gets from the database. He will also take into account previous alarms. There are multiple instances than run these algorithms at the same time. There is also a scheduler because certain consumers get priority over others.
48
Figure 58: The decomposition of the anomaly detection Storage The Storage component handles all the databases. All the requests enter the QueryHandler who will route it to the correct database. The databases all return an object which than can be read and updated. To make the transition between objects and the relational databases themselves, a DataMapper is used. The MeasurementStorage is dierent from the other ones because it has a scheduler to schedule the requests, multiple Datamappers and a replicated Database.
49
Figure 59: The decomposition of storage component 50
Control Panel The ControlPanel component is the only way the system communicates with actual users. There is a GUI which is a site which is build with basic web technology like HTML and JavaScript. This website contains commands which will be handled by the FrontController. He will redirect this command to the right service in the Backend. Before he will redirect the command he will however rst check with the AuthService, if the user is allowed to use this command.
Figure 60: The decomposition of the control panel
Back end The Backend component handles all the command that are transmitted by the control panel. To complete this commands he needs information from some other systems. He has a connection to the Storage to get and update consumers, a connection to the I/O to send messages, a connection to the UIS to signal the utility provider that a user starts or stops using ReMeS and a connection to the MeasurementComponent to delete a device from the heartbeat table.
Figure 61: The decomposition of the back end
51
Authentication Service The AuthService component handles the login of users en checking of session. When a users logs in, the AuthService will generate a token depending on the access clearance of the user. With every command that is given by the GUI the AuthService will be asked if the user is logged in.
Figure 62: The decomposition of the authentication service
Billing Component The BillingComponent creates the invoices. The TimeTicker will call generateInvoices every day. The InvoiceHandler will than get the consumers from the storage which have as invoice date the current date. He will than pass the job to InvoiceCreator who creates the invoice and stores it in the storage. He will also send the invoice to the 3th party billing company through the InvoiceSender. If the consumer has paid his invoice, the 3th party billing company will call the markAsPaid method. The Listener will than get the invoice (which is located in the consumer object) and mark it as paid. The InvoiceSender also has an acknowledgement system so the sending of the invoices to the 3th party billing company cant fail.
Figure 63: The decomposition of the billing component
52
3.4
Deployment Diagram
In gure 64 you can end the deployment diagram of the system. The clients (consumers, call center operatives and technicians) use a computer to access the systems control panel. The Control panel is hosted on a webserver. This webserver will than contact the back-end through RMI messages. Because the systems in this Back-End are state-less he can be replicated to allow more requests. The Back-End also accesses the storage through the Storage Access server. This server handles all the database requests en route then to the correct database server. On the diagram there is only one database server displayed but in reality there will be multiple servers that are also replicated. The I/O server is the server where all messages leave and come in. This server will connect to three dierent servers that all contain their own component. Again the communication will run through RMI. This three servers, the Measurement server, Control server and Alarm server can also be replicated because they are also stateless. All the states are stored in the storage component. By consequence the only synchronization that has to be done is in the component. The nal server is the Billing server he will get data from the databases and from the UIS with which he will build the invoices. The invoices are then sended to the 3th Party Billing company. All the extern connections arent represented on this diagram because this falls out of the scope for this system. There has to be a consensus with the UIS and the 3th Party Billing companies for which protocols that will be used.
53
Figure 64: The deployment diagram of the system
54
4
4.1
Scenarios
User prole creation
Figure 65: The sequence diagram for user prole creation In gure 65 you can nd the sequence diagram for this scenario. The call center operative will ll in a form on the GUI. He will then send a command to the ConsumerService through the FrontController. The ConsumerService stores the new user and sends an e-mail through the I/O component.
4.2
User prole associations with a remote monitoring module
Figure 66: The sequence diagram for the device association The consumer can add a device through the control panel. The GUI will then send an add device command to the ConsumerService through the FrontController. The ConsumerService will than create a device prole. He will get the consumer object from the storage and add the device object to the consumer. He will than store the consumer. This way the device is linked.
4.3
Remote monitoring: Installation and initialization
The device association with the consumer is the same as in the previous section. The only dierence is that we have to handle the rst testing frames and ag the device as active. The sequence diagram for this part of the scenario is displayed in gure 67. Because the devices are precongure to send trames the I/O will receive these and redirect them to the ControlComponent. This component will send a trame asking for more details are mark the device as ready. He does this by getting the consumer object in which the device object is located. He nished by storing the consumer again in the storage. 55
Figure 67: The sequence diagram for the control sequence We do not have functionality to give the module a start value, because this requirement didnt show up during design. You can however easily integrate this in the DeviceService.
4.4
Remote monitoring: transmission frequency reconguration
In gure 68 you can nd the sequence diagram for this action. The GUI will again pass the message to the DeviceService through the FrontController. The DeviceService will then get the consumer object from storage and edit the conguration of the module. Then the consumer object will be stored again. He will also send a command to the I/O, so this component would send a trame to the module that the update frequency is changed.
Figure 68: The sequence diagram for the transmission frequency reconguration
4.5
Remote monitoring: troubleshooting
We only have a acknowledgement system for the incoming messages to the modules and a heartbeat system for missing measurement readings. So the technician cant see that the module is down directly after sending a reconguration. This can be xed by adding an acknowledgement system to the OutgoingModule. But the system can detect when a module is down when he dont receives measurements, so like this a failed module can be discovered in the current design. In gure 69 the mechanism for this system is displayed. The TableAnalyzer will get the modules that responded too late form the TimeTable. If they missed their deadline a few times he will raise an alarm to the AlarmComponent.
56
Figure 69: The sequence diagram for the heartbeat system
4.6
Remote monitoring: Alarm notication recipient conguration
This scenario has the same actions in the system than the scenario in section 4.4. The only dierence is that the DeviceService doesnt send a message to the I/O component because the module doesnt have to be notied of the change.
4.7
Remote control
The rst section of the scenario can be completed the same way as the installation of the measurement module in section 4.3. The only dierence is that the GUI doesnt call addModule but addActuator so the actuator is coupled with the measurement module. The sequence diagram for this part of the scenario is displayed in gure 70.
Figure 70: The sequence diagram for linking of the actuator The second part of the scenario is the same as section 4.6. Because when the GUI calls changeDeviceCong the DeviceService will detect whether the id is of a measurement module or a actuator and update the conguration in the consumer object accordingly.
4.8
Normal measurement data transmission
The sequence diagram for this scenario is displayed in gure 71. The I/O adds the trame to a buer. The TrameReader will get the trame when hes ready. He will then create a MeasurementData object and store it in the database.
57
Figure 71: The sequence diagram for receiving measurement
4.9
Individual data analysis
The sequence diagram for this section builds further on that of section 4.3 beginning from the TrameHandler. Figure 72 contains this sequence diagram. The TrameHandler stores an anomaly detection job in the Scheduler. This Scheduler schedules the request according to the current mode and the SLA with the consumer. AnomalyAlgorithm will than request for a job when hes ready. He asks the needed info from storage and raises an alarm to the AlarmComponent if needed.
Figure 72: The sequence diagram for anomaly detection on measurements
4.10
Utility production planning analysis
The sequence diagram for this scenario is displayed in gure 73. The utility provider can login to the panel and ask for predictions. The GUI will pass this request to the MeasurementService through the FrontController. The MeasurementService can then get the measurements from all users and make a prediction. This part of the functionality isnt worked out very deep because it was a low priority.
4.11
Information exchange towards the UIS
This scenario is related with the previous one. The MeasurementService can connect to the UIS and update the information like used forecasting models. But also this functionality isnt worked out very 58
Figure 73: The sequence diagram for the planning production deep.
4.12
Alarm data transmission: remote monitoring module
Figure 74 contains the sequence diagrams for handling alarms. The I/O will store the requests in the IncomingScheduler. This Scheduler will schedule the alarms according to type. The Tramereader will handle the next alarm when he is ready. He will get the module conguration from the ConsumerInfo who will also notify the consumer and emergency services. The TrameReader will than close the valve if necessary according to the conguration. If he closes the valve he will change the status of this valve in the storage. He will also store the alarm in the storage.
4.13
Alarm data transmission: ReMeS
In section 4.9 we already described how we detect anomalies inside the ReMeS system and how we raise an alarm in this case. Our system will assume that all alarms are correct except when a user marks it as a false positive. You can nd the sequence diagram for this action in gure 75. The user will mark the alarm as a false positive in the control panel. The GUI will then pass this command to the ConsumerService through the FrontController. This component will get the alarm from storage, mark it as false and store it again. The anomaly detection algorithm takes all the alarms into account including these false positives. In this design we dont save individual consumption patterns.
4.14
Remote control module de-activation
In gure 76 you can nd the sequence diagram for deactivating modules. The user will use the control panel to do the deactivation. The GUI will pass the command to the DeviceService through the FrontController. The DeviceService will then get the consumer object from the storage and delete the device. The consumer object is then stored again. He will also send a message to the MeasurementComponent to delete the device from the hearbeat table otherwise false alarms would be generated.
4.15
New bill creation
In 77 you can nd the sequence diagram for creating new invoices. The Timeticker will ask the InvoiceHandler to generate the invoices for the people which billing month ends the current day. The InvoiceHandler will get these consumers from the storage. For every consumer he will then run the create invoice command on the InvoiceCreator. This component will then get the measurements for that user and his rate from the UIS. He will then create the invoice. The invoice will be sent with the
59
InvoiceSender to the UIS and the 3th party billing company. It will also be stored in the consumer object in the database.
4.16
Bill payment is received
The mechanism to mark an invoice as paid is displayed in 78. First the 3th party billing company will call the mark as paid method of the BillingComponent, this step isnt shown on the diagram. The listener will then get the consumer object which contains the invoices. He will then mark the correct invoice as paid and store the object again.
60
Figure 74: The sequence diagram for the handling of alarms
61
Figure 75: The sequence diagram for the agging of alarms
Figure 76: The sequence diagram for the de-activation of modules
Figure 77: The sequence diagram for creating invoices
62
Figure 78: The sequence diagram for marking invoices paid
63
5
5.1
5.1.1
Appendix
Element Catalog
Alarm Component
The AlarmComponent will handle all the incoming alarms from the remote device. In case of which alarm and the consumers conguration the remote valve will be shut down and the consumer will be notied.
AlarmComponents AlarmHandler This component will handle the incoming alarm trame
AlarmComponents AlarmHandlers ConsumerInfo Tis component holds the consumers preferences and decides a notication for the consumer should be created or not.
AlarmComponents AlarmHandlers ConsumerMsgBuilder tication message with the needed data for the consumer.
This component can create a no-
AlarmComponents AlarmHandlers TrameReader The TrameReader will read the incoming trame and extract the neccesary data from that for further processing in the AlarmHandler.
AlarmComponents IncomingScheduler The IncomingScheduler receive the incoming trames, buer them untill one is asked for processing. It will give the highest priority alarm available.
AlarmComponents IncomingSchedulers Buer The Buer will buer incoming trames. If the Scheduler asks a next trame, the Buer gives that FIFO-based.
AlarmComponents IncomingSchedulers Scheduler The Scheduler asks a next element from the buer and schedules it on priority to the alarms in his own buer. If the alarm is scheduled he asks the next from the BuerComponent. From this Scheduler the AlarmHandler asks the next highest priority alarm to handle.
AlarmComponents IncomingSchedulers Type This component is used to ask the type of a trame to determine its priority.
5.1.2
BillingComponent
The BillingComponent handles the whole billing aspect of the system. From the creation of the invoice to the sending. It will also have the functionality to mark invoices as paid.
BillingComponents InvoiceCreator Create the actual invoice for a certain costumer. To achieve this he gets the measurements from the storage and the rates from the UIS. He will also store this invoice in the consumer object.
64
BillingComponents InvoiceHandler He will search all consumers for which an invoice has to be created. For each of this consumers he orders the creation of an invoice. BillingComponents InvoiceSender This component does the sending of the invoice to the 3th party billing company and the utility service providers. It assures that all sent messages are also received by means of an acknowledgement service.
BillingComponents InvoiceSenders AckTable This component holds all the messages and the allowed time to rest unacknowledged. Every time interval he will decrease this time and when it reaches zero he will attempt to resend.
BillingComponents InvoiceSenders AckUnit The AckUnit handles the external ackInvoice commands by deleting the corresponding invoice from the AckTable.
BillingComponents InvoiceSenders RequestHandler sending and the insertion of the invoice in the AckTable.
This component handles the requests for
BillingComponents InvoiceSenders Sender providers and the 3th party billing companies.
Does the actual sending of the invoice to the utility
BillingComponents Listener Listens for the markAsPaid paid command that is called externally. He will then update the invoice accordingly.
BillingComponents TimeTicker This component assures that the invoices are created every day.
5.1.3
ControlComponent
The ControlComponent will handle and coordinate the testTrames when initialising a new remote module.
ControlComponents DbUpdater This component updates the database when the new remote module passed the connection tests.
ControlComponents TestTable This component will hold records of remote modules who are currently in the testphase and their progress.
ControlComponents TrameReader The TrameReader reads the incoming testTrames, extracts the necessary data to update the TestTable.
5.1.4
ControlPanel
The ControlPanel does the coordination of the website with the control panel. Authentication is done on the requests. There are pages for the technicians, consumers, utilityproviders, researchers, callcenter operatives and new consumers who want to register.
65
ControlPanels AuthService This component handles the loggin in and out. Checks if a session is valid.
ControlPanels AuthServices LoginCheck This component checks if the provided username and password is valid and the authentication is succesfull.
ControlPanels AuthServices SessionCheck received with a sessionId.
This component checks the session if a request is
ControlPanels AuthServices SessionTable
This component hold the currently alive sessions.
ControlPanels AuthServices TokenGenerator This component can create unique tokens representing the sessionIds in dierent categories. Categories are: technician, representatives, consumers, researchers, emergency services and utility providers.
ControlPanels AuthServices TokenGenerators ConsumerToken Creates tokens in the consumercategory.
ControlPanels AuthServices TokenGenerators RepresentativeToken Creates tokens in the representativecategory.
ControlPanels AuthServices TokenGenerators RequestHandler quest to generate a token and forwards it to the right tokengenerator.
Handles the incoming re-
ControlPanels AuthServices TokenGenerators TechnicianToken niciancategory.
Creates tokens in the tech-
ControlPanels Backend databasedata.
This component handles all the requests for displaying pages that need
ControlPanels Backends ConsumerService This component handles all the requests for the control panel related to the consumers and can get consumers out of the database and do operations on those objects. It can also call the I/Os OutgoingModule to send for example a conrmationmail to a consumer in case of a new registration.
ControlPanels Backends DeviceService This component handles all the requests for the control panel related to the devices stored in the database. It has operations to get and modify the consumers devices. It has also a connection to the I/Os OutgoingModule to send for example a close command to a valve when the user set this option in the controlpanel.
ControlPanels Backends MeasurementService This component will handle all the operations related to measurementdata. It has operations to get and modify the measurement objects stored in the database.
66
ControlPanels GUI This component has dynamic pages that can be built out of the responses from operations that were sent to the backend by the FrontController that was handling an incoming request.
ControlPanels FrontController The FrontController handles all the incoming http-requests. Passes the request to check the login or session to the AuthService. Checks if an operation from the logged in user is allowed. If it is, it passes the requested operation to the Backend.
ControlPanels FrontControllers MessageRouter This component routes the allowed requested operation to the right Backends ConsumerService, MeasurementService or DeviceService.
ControlPanels FrontControllers RequestReader The RequestReader reads the incoming request and decides what to do next. Pass a login check or pass a sessioncheck and check if a requested operation is allowed by calling the ServiceLookUpTable.
ControlPanels FrontControllers ServiceLookUpTable This component holds high-level rules to decide if an operation is allowed. These rules can be based on the tokencategory (see higher: tokengenerator) like some operations are allowed by CallCenter operatives. The rules can also be based on userIds like changing the prole of a userId. In that case the target userId has to match the userId that requests the operation.
5.1.5
I/O
The I/O does the handling of all the trac exept that from the controlpanel that goes directly to the FrontController, the connection with the 3th party billing service and the connection to the UIS. Mainly it is for the connection to the remote modules through the dierent technologies like sms, mail, ... and for notifying the consumer through these technologies.
I/Os IncomingModule those stated above.
The component handles all the incoming trames to the ReMeS-system of
I/Os IncomingModules MessageRouter The MessageRouter routes the incoming trame to the right component. AlarmTrames will be passed to the AlarmComponent, MeasurementTrames will be passed to the MeasurementComponent, TestTrames will be passed to the ControlComponent.
I/Os IncomingModules Type The above MessageRouter uses this Type to determine the type of the incoming trame to do the routing.
I/Os OutgoingModule The OutgoingModule does the outgoing trac to the remote valves and consumers. It has a wide interface for which messages to send through which technology.
I/Os OutgoingModules MessageCreator Out of the provided data, this component creates the nal message to send.
I/Os OutgoingModules Sender This is the actual send of a message.
67
5.1.6
MeasurementComponent
The MeasurementComponent handles all the incoming measurementtrames. Anomalydetection will be done on those data. The AlarmComponent can be invoced.
Measurements AnomalyDetection This component will do the detection of anomalies on given measurementdata.
Measurements AnomalyDetections AnomalyAlgorithm This hold algorithms to do the effective detection with previous generated alarms, false positives, consumer settings, previous measurements,...
Measurements AnomalyDetections Mode This will hold the working mode. Overloaded or normal environment.
Measurements AnomalyDetections Scheduler This component will schedule the incoming data depending on the current mode and the consumers SLA.
Measurements Buer The Buer will buer incoming measurements untill asked by the TrameHandler.
Measurements HeartBeatDetector This component checks that all the active remote modules keep sending data in the intervals set by the consumer.
Measurements HeartBeatDetectors TableAnalyser This component analyses the TimeTable to get the valves from who no measurements are received in time. It could call the I/Os OutgoingModule to request the remote module to send some data and can create and alarmTrame for the AlarmComponent. This way the CallCenter can see the alarm this alarm in their controlpanel.
Measurements HeartBeatDetectors TableManager The TableManager receives the notication when a measurement from a remote module is received. He will update the TimeTable, with the consumers timingpreferences for that module, to indicate a measurement for that module is received.
Measurements HeartBeatDetectors TimeTable The TimeTable holds records of remote modules for in which time at least 1 measurement has to be received. It does continiously a countdown in the timings for all the valves.
Measurements TrameHandler The TrameHandler handles incoming measurementTrame. It can read the trame and build a measurementDataObject from the data and store it in the database. It will call to update the HeartBeatTable and call the AnomalyDetection to analyse the data.
Measurements TrameHandlers MeasurementData An object created in the MeasurementData represents an object holding measurements for a consumer.
68
Measurements TrameHandlers TrameReader The TrameReader reads the incoming trame, extracts data from it and passes the necessary data to the MeasurementData to create a measurementDataObject from it. Stores the object in the database, notify the HeartBeatDetector a measurement is received and call the AnomalyDetection to analyse the data.
5.1.7
Storage
The Storage holds all the databases. There are 3 databases: the alarmStorage for alarmObjects. Related to a consumer. A consumerStorage for the consumers information, devices and the devices preferences. And nally a measurementStorage to store measurements. Also related to a consumer.
Storages AlarmStorage The storage component for the alarmsObjects.
Storages AlarmStorages Database
The eective database of the alarms.
Storages AlarmStorages DataMapper
Maps the alarmObjects to the relational database.
Storages ConsumerStorage The storage component for the consumers. This storage holds all the users. Technician accounts, CallCenter accounts, researchers accounts, ... are also stored in this storage so they can login on the controlpanel.
Storages ConsumerStorages Database The eective database for the consumerobjects. Also technicians accounts, CallCenter accounts, researchers accounts, ...
Storages ConsumerStorages DataMapper
Maps the consumerObjects to the relational database.
Storages MeasurementStorage
The storage component for measurementObjects.
Storages MeasurementStorages Database The eective database of the measurements.
Storages MeasurementStorages DataMapper Maps the measurementObjects to the relational database.
Storages MeasurementStorages Mode Holds the environmentmode of the MeasurementStorage. It operates in dierent ways if in normal mode or overloaded mode.
Storages MeasurementStorages Scheduler Depending on the set mode this scheduler will schedule the incoming queries. Queries of users who want to get their measurement data will be scheduled based on the users SLA if in overloaded mode.
Storages QueryHandler The handler of all the incoming queries. It can accept advanced queries and split them up in smaller ones and divide them over the individual storages.
69
5.2
Interfaces
In this section the interface of each component will be listed in a table. The components are ordered alphabetically, rst per parent then child.
5.2.1
AlarmComponent - iteration 1,2,3
Method Arguments Explanation AlarmComponent (iteration 1) receiveAlarm Trame trame Give an alarm trame to the AlarmComponent. AlarmComponent - AlarmHandler (iteration 1,3) AlarmComponent - AlarmHandler - ConsumerInfo (iteration 3) getModuleConf String moduleId returns the module conguration of a module AlarmComponent - AlarmHandler - ConsumerMsgBuilder (iteration 3) buildMsg String recipient, MsgType msg- With the given recipient, type of message (e.g: gas Type, String technology leak) and the given technology (sms, mail, ...) a standard message is build. AlarmComponent - AlarmHandler - TrameReader (iteration 3) AlarmComponent - IncomingScheduler (iteration 1,2) receiveAlarm Trame trame Give an alarm trame to the IncomingScheduler. AlarmComponent - IncomingScheduler - Buer (iteration 2) getNextElement / Returns the next trame from the buer. receiveAlarm Trame trame Give an alarm trame to the Buer. AlarmComponent - IncomingScheduler - Scheduler (iteration 2) getNextAlarm / Returns the next highest priority trame. AlarmComponent - IncomingScheduler - Type (iteration 2) getType Trame trame Returns type of the given trame.
70
5.2.2
BillingComponent - iteration 21,22
Method Arguments Explanation BillingComponent (iteration 21) markAsPaid Int invoiceId Marks an invoice as paid. BillingComponent - InvoiceCreator (iteration 21) createInvoice Int consumerId Creates the invoice for that user for the current month. BillingComponent - InvoiceHandler (iteration 21) generateInvoices Generates the invoices for all the users for which their billing month ends the current day BillingComponent - InvoiceSender (iteration 21,22) sendInvoice Invoice object Sends the invoice object which contains the invoiceId, info about the consumer and the actual invoice to the 3th party billing company and the service utility providers. BillingComponent - InvoiceSender - AckTable (iteration 22) delete invoiceId Deletes the invoice from the acknowledgement table. This is done when the acknowledgement is received for that invoice. BillingComponent - InvoiceSender - AckUnit (iteration 22) ackInvoice invoiceId Acknowledges the invoice with that id. BillingComponent - InvoiceSender - RequestHandler (iteration 22) sendInvoice Invoice object Sends the invoice to the 3th party billing company and utility service providers. It will also guarantee that the invoice is received by means of an acknowledgement system. BillingComponent - InvoiceSender - Sender (iteration 22) send Invoice Object Does the actual sending of the invoice. BillingComponent - Listener (iteration 21) markAsPaid Int invoiceId Marks the invoice with that id as paid. BillingComponent - TimeTicker (iteration 21)
5.2.3
ControlComponent - iteration 20
Method Arguments Explanation ControlComponent (iteration 20) receiveControl Trame trame Give a control trame to the ControlComponent. ControlComponent - DbUpdater (iteration 20) markComplete String moduleId Updates the database to set the testing of a module as complete and set the status to a ready-state. ControlComponent - TestTable (iteration 20) updateTable String moduleId, String mod- Update the table with the given parameters . uleAddress, Type technology ControlComponent - TrameReader (iteration 20) receiveControl Trame trame Give a control trame to the TrameReader.
71
5.2.4
ControlPanel - iteration 15,16,17,18,19 Explanation Handle an HTTP get-request. Handle an HTTP post-request.
Method Arguments ControlPanel (iteration 15) doGet HTTPRequest doPost HTTPRequest ControlPanel - AuthService (iteration 15,16) checkLogin String username, String password checkSession String sessionId doLogOut String sessionId
Checks if the users given username and password is correct. If successfull returning the userId. Checks if the provided sessionId is correct. Removes the sessionId and the user is marked as logged out. ControlPanel - AuthService - LoginCheck (iteration 16) checkLogin String username, String Checks if the users given username and password is password correct. If successfull returning the userId. doLogOut String sessionId Removes the sessionId and the user is marked as logged out. ControlPanel - AuthService - SessionCheck (iteration 16) checkSession String sessionId Checks if the provided sessionId is correct. ControlPanel - AuthService - SessionTable (iteration 16) addSession String sessionId Adds a new sessionId to the SessionTable. checkSession String sessionId Checks if the provided sessionId is correct. removeSession String sessionId Removes a session from the SessionTable to log out a user. ControlPanel - AuthService - TokenGenerator (iteration 16,17) getToken Type type Returns a new token representing a sessionId for that type (consumer, representative, technician). ControlPanel - AuthService - TokenGenerator - ConsumerToken (iteration 17) getConsumerToken / Returns a new token representing a sessionId for consumers. ControlPanel - AuthService - TokenGenerator - RepresentativeToken (iteration 17) getRepresentativeToken / Returns a new token representing a sessionId for representatives (e.g:call-center operators, ...). ControlPanel - AuthService - TokenGenerator - RequestHandler (iteration 17) getToken Type type Returns a new token representing a sessionId for that type (consumer, representative, technician). ControlPanel - AuthService - TokenGenerator - TechnicianToken (iteration 17) getTeechnicianToken / Returns a new token representing a sessionId for technicians.
72
ControlPanel - Backend (iteration 15,19) addActuator String actuatorSerial, String moduleSerial addModule String moduleSerial, String userId approveUser String userId changeAlarmRecipient String recipientName, String recipientAddress, String moduleId, ... changeDeviceCong String deviceId, Conguration newConguration changeLocation String newLocation changeMailAddress String newMailAddress changeMeasurementsTresholds String deviceId, int newTreshold changeSmsNumber String newSmsNumber conrmViaMail String userId deleteDevice deleteUser Int deviceId String userId
the actuator is coupled the module, that is coupled to a user. A remote module is coupled to a user. Approve a user. Changes the recipient of the alarms for a user owning a module. Change the conguration of a device. Like sending timings and tresholds. Sets the new location. Sets the new mailaddress Change the treshold of a device. Sets the new smsnumber. The users conrms his registration by the http-link in the conrmation mail. Deletes a device of the consumer. After the technician has picked the modules he can invoke this method. The user is now completely deleted from the system. Gets all the alarms. The CallCenter sees all the alarms. The consumer only his alarms. Can do a GETQuery for researchers. Returns the non-approved users. Gets the for a given provider. Returns a list of users who want to stop using the system (set by removeUser(..)). A technician has to come by to pick up the modules. Conrm an alarm as viewed Does input validation on the provided data. If ok create approved user in the database and send conrmation mail. Does input validation on the provided data. If ok create non-approved user in the database (to be approved by the CallCenter) and send conrmation mail. The CallCenter removes a user. Sets the users devices as non active. Sets a user property he wants to be deleted. The delDevice from the HeartBeatDetector is invoced. Sets the property of an alarm as a false positive. Set for the alarms coming from a device the noticationtechnology for the consumer. Can set a device status. E.g: open, closed,.. Via the OutgoingModule a shutdown command could be sent.
getAlarms getMeasurementsQuery getNonApprovedUsers getPredictions getRemovedUsers String queryString / String utilityProvider
markAlarmAsRead registerUserByCallCenter
registerUserByUser
removeUserByCallCenter removeUserByUser
String alarmId String name, String address, String currentCompany, String mailaddress, ... String name, String address, String currentCompany, String mailaddress, ... String userId String userId
setAlarmAsFalsePositive setAlarmReceiveTechn setDeviceStatus
String alarmId Type technology, String deviceId Type status
73
ControlPanel - Backend - ConsumerService (iteration 19) [The previous consumer related operations come here] ControlPanel - Backend - DeviceService (iteration 19) [The previous device related operations come here] ControlPanel - Backend - MeasurementService (iteration 19) [The previous measurement related operations come here] ControlPanel - GUI (iteration 15) getRequestDispatcher String page Returns the requestDispatcher of a page. This object has several methods like setAttribute(String attribute, Object o) for giving objects to the page. This could be a list so a the dynamic page could be created. Doing a get on the requestDispatcher could be the nal html5 page to be send to the client. ControlPanel - FrontController (iteration 15,18) doGet HTTPRequest Handle an HTTP get-request. doPost HTTPRequest Handle an HTTP post-request. ControlPanel - FrontController - MessageRouter (iteration 18) routeMessage String operationString routes the message to the Backend and returns the answer object. ControlPanel - FrontController - RequestReader (iteration 18) doGet HTTPRequest Handle an HTTP get-request. Extract parameters for Backend, pass for checking the sessionId, ... doPost HTTPRequest Handle an HTTP post-request. Extract parameters for Backend, pass for checking the sessionId, ... ControlPanel - FrontController - ServiceLookupTable (iteration 18) getServiceInfo String operation, String ses- Returns a boolean to check if an operation is permitsionId ted to a sessionId. This sessionId is one of the types generated in the TokenGenerator.
74
5.2.5
I/O - iteration 4,5,6
Method Arguments Explanation I/O (iteration 4) receiveTrame Trame trame send a trame to I/O of the ReMeS-system. I/O - IncomingModule (iteration 5) receiveTrame Trame trame send a trame to IncomingModule. I/O - IncomingModule - MessageRouter (iteration 5) receiveTrame Trame trame send a trame to the MessageRouter. I/O - IncomingModule - Type (iteration 5) getType Trame trame Returns the type of an incoming trame (alarm, measurement, control) I/O - OutgoingModule (iteration 6) notifyConsumer String address, String message, sends a notication message to the consumer with Type technology the provided technology. Can be used in case of an alarm. shutDown String valveAddres, Type tech- Send a command to shutdown a valve to a given nology valveaddress. sendAckTrame String moduleAddress, Type sends an acknowledge trame to a module. technology sendAliveTrame String valveAddress, Type tech- Send a trame to a valve to see if is still alive by nology request for measurements. sendExtaTestTrames String moduleAddress, Type Send test/controlTrames to the specied module technology through the specied technology. sendNewCong String valveAddress, Congu- Sends a new conguration to the provided valveAdration newConguration, Type dress through the given technology. technology I/O - OutgoingModule - MessageCreator (iteration 6) notifyConsumer String address, String message, sends a notication message to the consumer with Type technology the provided technology. Can be used in case of an alarm. shutDown String valveAddres, Type tech- Send a command to shutdown a valve to a given nology valveaddress. sendAckTrame String moduleAddress, Type sends an acknowledge trame to a module. technology sendAliveTrame String valveAddress, Type tech- Send a trame to a valve to see if is still alive by nology request for measurements. sendExtaTestTrames String moduleAddress, Type Send test/controlTrames to the specied module technology through the specied technology. sendNewCong String valveAddress, Congu- Sends a new conguration to the provided valveAdration newConguration, Type dress through the given technology. technology I/O - OutgoingModule - Sender (iteration 6) send Serialized message Send the message.
75
5.2.6
MeasurementComponent - iteration 7,8,9,10 Explanation
Method Arguments MeasurementComponent (iteration 7) receiveMeasurement Trame trame
Give a measurement trame to the MeasurementComponent. MeasurementComponent - AnomalyDetection (iteration 7,10) detectAnomaly Measurement measurement, Detects an anomaly on the given measurement. DeConsumer consumer pending on the consumers SLA the scheduling can be done if in overloaded mode. In case of an anomaly the AlarmComponent will receive an alarm. MeasurementComponent - AnomalyDetection - AnomalyAlgorithm (iteration 10) MeasurementComponent - AnomalyDetection - Mode (iteration 10) getMode / Returns the current set mode. setMode Type type Set the mode to normal or overloaded. MeasurementComponent - AnomalyDetection - Scheduler (iteration 10) detectAnomaly Measurement measurement, Detects an anomaly on the given measurement. DeConsumer consumer pending on the consumers SLA the scheduling can be done if in overloaded mode. In case of an anomaly the AlarmComponent will receive an alarm. getNextElement / Returns the measurement from the scheduler. MeasurementComponent - Buer (iteration 7) getMeasurement / Get the next trame from the MeasurementComponents Buer. receiveMeasurement Trame trame Give a measrurement trame to the MeasurementComponents Buer. MeasurementComponent - HeartBeatDetector (iteration 7,9) updateTable String deviceId, String de- Updates the HeartBeatDetector that a new measureviceAddress, Consumer con- ment from a device is received with a timing stored sumer, Type technology in the consumers moduleconguration. MeasurementComponent - HeartBeatDetector - TableAnalyser (iteration 9) MeasurementComponent - HeartBeatDetector - TableManager (iteration 9) updateTable String deviceId, String de- Updates the HeartBeatDetector that a new measureviceAddress, Consumer con- ment from a device is received with a timing stored sumer, Type technology in the consumers moduleconguration. MeasurementComponent - HeartBeatDetector - TimeTable (iteration 9) delDevice String deviceId Remove the record of the provided deviceId from the TimeTable. The device isnt checked anymore for sending measurements. resetTable String deviceId, String de- Set the timing of a the device back to the consumers viceAddress, Consumer con- conguration. sumer, Type technology MeasurementComponent - TrameHandler (iteration 7,8) MeasurementComponent - TrameHandler - MeasurementData (iteration 8) createMeasurement List measurements, String con- Returns a MeasurementObject from the given measumerId surements. MeasurementComponent - TrameHandler - TrameReader (iteration 8)
76
5.2.7
Storage - iteration 11,12,13,14 Explanation returns the alarms of the given Id. returns the alarm of the given alarmId. returns the consumer of the given Id. returns the consumer of the given valveId. returns the measurements of the given consumerId. returns the measurements of the given utilityProvider. Save a give alarm to the database. Save a consumer to the database. Set the the status of a module. (active, shutdown, ...) Store a measurement.
Method Arguments Storage (iteration 11) getAlarms String consumerId getAlarm String alarmId getConsumer String consumerId getConsumer String valveId getMeasurements String consumerId getMeasurements String utilityProvider saveAlarm saveConsumer saveModuleStatus Alarm alarm Consumer consumer Status status, Module module
storeMeasurement Measurement measurement Storage - AlarmStorage (iteration 11,14) getAlarms String consumerId returns the alarms of the given Id. getAlarm String alarmId returns the alarm of the given alarmId. saveAlarm Alarm alarm Save a give alarm to the database. Storage - AlarmStorage - DataMapper (iteration 14) Storage - ConsumerStorage (iteration 11,13) getConsumer String consumerId returns the consumer of the given Id. getConsumer String valveId returns the consumer of the given valveId. Storage - ConsumerStorage - DataMapper (iteration 13) Storage - MeasurementStorage (iteration 11,12) getMeasurements String consumerId returns the measurements of the given consumerId. getMeasurements String utilityProvider returns the measurements of the given utilityProvider. storeMeasurement Measurement measurement Store a measurement. Storage - MeasurementStorage - DataMapper (iteration 12) Storage - MeasurementStorage - Mode (iteration 12) getMode / Returns the current set mode. setMode Type type Set the mode to normal or overloaded. Storage - MeasurementStorage - Scheduler (iteration 12) getMeasurements String consumerId returns the measurements of the given consumerId. storeMeasurement Measurement measurement Store a measurement. Storage - QueryHandler (iteration 11) getAlarms String consumerId returns the alarms of the given Id. getAlarm String alarmId returns the alarm of the given alarmId. getConsumer String consumerId returns the consumer of the given Id. getConsumer String valveId returns the consumer of the given valveId. getMeasurements String consumerId returns the measurements of the given consumerId. getMeasurements String utilityProvider returns the measurements of the given utilityProvider. saveAlarm Alarm alarm Save a give alarm to the database. saveModuleStatus Status status, Module module Set the the status of a module. (active, shutdown, ...) storeMeasurement Measurement measurement Store a measurement.
77

Software Architecture Project 2

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Architecture Project 2

Transféré par

Droits d'auteur :

Formats disponibles

Software Architecture: Phase 2

Dommicent Leendert - s0205006 Van Loock Jorn - s0205008

Prof.: W. Joosen Assistent: Riccardo Scandariato

3.1 3.2 3.3 3.4

Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.2.1 AlarmComponent - iteration 1,2,3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3

5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.2.7

Attribute Driven Design

Iteration 1: Decomposing the AlarmComponent

Figure 1: Tree iteration 1

Figure 2: Active Object

Iteration 2: Decomposing the AlarmComponents IncomingScheduler

Architectural Drivers the IncomingScheduler.

UC: read trame UC: schedule on priority

Figure 3: Tree iteration 2

Iteration 3: Decomposing the AlarmComponents AlarmHandler

Architectural Drivers the AlarmHandler.

Figure 5: Tree iteration 3

Figure 6: Alarm Handler

Iteration 4: Redesign of I/O

Here you nd the diagrams for this iteration:

Figure 8: The new high-level overview

Iteration 5: Decomposing the I/Os IncomingModule

Architectural Patterns router.

Figure 9: Decomposition of the incoming module of the I/O component

Figure 10: Component diagram of the incoming module

Iteration 6: Decomposing the I/Os OutgoingModule

Tactics to address the requirements

Figure 11: Decomposition of the outgoing module of the I/O component

Recapitulation: Use case overview 1

Iteration 7: Decomposing the Measurement component

TrameHandler: Iteration 8 HeartBeatDetector: Iteration 9 AnomalyDetection: Iteration 10

Figure 14: Component diagram of the measurement component

Iteration 8: Decomposing the Measurements TrameHandler

Figure 15: Decomposition the TrameHandler in the Measurement component

Figure 16: Component diagram of the TrameHandler

Iteration 9: Decomposing the Measurements HeartBeatDetector

Figure 17: Decomposition the HeartBeatDetector in the Measurement component

Iteration 10: Decomposing the Measurements AnomalyDetection

Figure 19: Decomposition of the AnomalyDetection in the Measurement component

Figure 20: Component diagram of the AnomalyDetection

Recapitulation: Use case overview 2

Iteration 11: Decomposing the Storage

Figure 23: Component diagram of the Storage

Functionality Reallocation MeasurementStorage: (iteration 12) 23

Iteration 12: Decomposing the Storages MeasurementStorage

Architectural Drivers tion of iteration 11:

Figure 24: The decomposition tree of the Storages MeasurementStorage

Figure 25: Component diagram of the Storages MeasurementStorage

Iteration 13: Decomposing the Storages ConsumerStorage

Figure 26: The decomposition tree of the Storages ConsumerStorage

Figure 27: Component diagram of the Storages ConsumerStorage

Iteration 14: Decomposing the Storages AlarmStorage

Figure 28: The decomposition tree of the Storages AlarmStorage

Recapitulation: Use case overview 3

Iteration 15: Decomposing the ControlPanel

Figure 30: Adding the ControlPanel to the current system

Figure 32: Component diagram of the ControlPanel

FrontController: (iteration 18)

Iteration 16: Decomposing the ControlPanels AuthService

Figure 33: The decomposition tree of the ControlPanels AuthService

Iteration 17: Decomposing the ControlPanels AuthServices TokenGenerator

Components to decompose vice in the ControlPanel.

Figure 35: The decomposition tree of the ControlPanels AuthServices TokenGenerator