View Improvement. Software Architecture [A6]

Transcription

1 View Improvement Peter Florijn ( ) mcs-iwt Peter Gels ( ) mcs-mm Timen Olthof ( ) mcs-mm Peter Peerdeman ( ) mcs-mm Joep Ruiter ( ) mis Team VGA Software Architecture [A6]

2 Contents Contents 2 Introduction 3 1 Assesment Report 3 1 Check out issues Advertisement FUEGO! Data loss Special Card Travel abroad Hackers Narrow casting Information View Improvement 5 1 Semantical Improvement Structure and modularity Results 7 1 Shapes Size and width Layout Color Evaluation 9 2

3 Introduction This document is seperated in two parts, one of which is the report of the assesment meeting we had with our stakeholders while the other one is the improvement of one of our views according to the assesment meeting and the view improvement method described in section 2. We chose to improve the information view because this view was argued about the most by our stakeholders and we were confident that we could use the improvement methods to improve this view to gain better understandability as well as processing the new information we have gathered during the assesment. 1 Assesment Report At Monday 8 December from 15:15 until 17:15 1 we had our first assessment meeting with the two stakeholder teams. All architects and all stakeholders except the Government were present. We talked about a wide variety of scenarios, ranging from future expansions of the system to emergency scenarios. We got a lot of useful feedback from these discussions and try to summarize the main conclusions below. The most important change is that a sniffer system will be added. The sniffer system is a RFID scanner with an extended range. The sniffer will check every traveller carrying a chip card that passes by. At the end of the day, the entire system can determine which traveller forgot to check out when he or she was using the public transportation system. These instances can occur in train stations where it is not feasible to install access gates or in for example trams. When its noticed that a traveller forgot to check out during the day, the last known location of this traveller can be determined by the sniffer. This way the traveller can still be charged for using the public transportation system. 1 Check out issues A customer that uses either a personal or anonymous access card or ticket notices that he/she has lost this in the train at the moment he/she wants to check out. The questions are: how does he or she leave the platform, as the gates will only open when you have a card? How does he or she pay for the travel (payment usually happens at checkout time)? There are a few cases to be distinguished here: at small stations, the check out gates will not physically obstruct the traveller from leaving the station, but a sniffer system will be used to detect people who forget to check in or out. At middle-large and large stations, personnel will be available to help travellers who lost their traveller card check out, either from a distance (middle-large stations) or on-site (large stations.. In all cases, losing your card will result in a fine for the traveller to pay. 2 Advertisement Some travel companies want to offer their customers personalized advertisements (relevant to his/her travel patterns). Some customers might value their privacy above offers via advertisement, but still want to make use of the public transport system. This scenario was quickly settled by pointing out that advertisement will be optional. Customers have the choice of enabling or 1 We didn t use the complete timeslot because we finished all scenarios around 16:30. 3

4 disabling (personal) advertisements in their personal profile pages. Receiving special offers is thus by no means necessary to make use of the public transport system. 3 FUEGO! Due to a fire in a train station, emergency services need to enter the station with their equipment. This operation needs to be performed in chaotic conditions where a stream of travellers needs to be evacuated, and every second counts. The access system cannot form a barrier. Everyone immediately agreed that the safety of people is of great importance. The gates of our system will be connected to the emergency trigger functions that every station has. At the same point where emergency services are (automatically) called to the station, all gates will automatically open, or (in case power is unavailable) easy to open by hand (and will remain opened once opened by hand). When an emergency occurs, it is a natural reaction that the traveller will forget to check out. Using the sniffer system, the traveller will be checked out. Considering witnessining an emergency is a possible traumatic experience, the traveller won t be charged for using the public transportation system. 4 Data loss The database of the travel companies containing customer information is lost in a fire. The customer information was linked to certain travel tickets. Data loss may always occur at a given site. By using s distributed storage system with advanced redundancy and data protection features, we ensure that when data is lost at one site, they will be available at all times from another site. The destroyed site may then be restored, and can be brought up-to-date again as soon as it is up and running again. 5 Special Card In two years from now the government decides that guides of (a group of) handicapped (both mental and physical) people need their own special card, and with this card these guides van travel for free when he is guiding handicapped people. How would the system facilitate this function? After we came to the conclusion that our system does not currently facilitate this function, we indicated that special versions of customers would be a relative easy adaption to make to the system, even in the future, as nothing at the card itself does have to change to implement this function. Functions like these may be implemented in the future in the back-end software. 6 Travel abroad A traveller wants to go to Belgium and back with public transport. As it is his first time that he is going with the public transport abroad, he is wondering how the system works when he goes abroad. He is travelling first with the bus to a station and then with the train to Belgium. For international travelling not much will change. National Railways of different countries will have to come to an agreement on mutual traveller handling, as is currently the case. In so far as payments systems in other countries differ from the new system, travellers will have to obtain two tickets, one for each country. The best option would be to sell the new system also to neighbouring countries, but if that won t happen, traveller cards for the new system will also have to be distributed by other National Railway companies. This will have some consequences for crossing the border: when leaving the Netherlands, travellers need to check out from the new system (which may be 4

5 done with assistance from the conductor or at a check out machine in the international train), and people entering the Netherlands will have to check in at the border using the same procedure. They will basically receive a prepaid traveller card with just enough money on it to pay for the part of the trip that is on Dutch soil. 7 Hackers A group of hackers found a way to interfere with billing transactions of travelers so that payments are transferred to their Icesave bank account instead of to that of the NS/RET/GVB bank account. While a system will never be entirely invulnerable (due to for example social engineering, corrupt employees or just plain bugs), the new system will be as safe as possible since thin clients will be used: no data stored or actions will be performed by any of the systems (gates/scanners/sniffers/support systems) at the stations, but everything will be handled in the distributed main server, which will have to be well secured of course. Securing the distributed back-end system is however easier than securing numerous fat clients. For securing the actual payment transactions, cooperation with a bank will be necessary, and the security of the process will also partly be their responsibility. Would a succesfull attack occur in spite of all the protection measures, this will be reported to the police. 8 Narrow casting In 2015 a new trend of narrow casting occurs. the NS wants to advertise by narrow casting SMS messages, but at this moment the system doesn t have any narrow casting capabilities. It will be possible to add these features in the future. Of course, for privacy reasons, narrow casting will only be possible if the customer agrees on receiving advertisements. 2 Information View Improvement For this assignment we chose to improve the information view. We chose the information view because it is a technical view, therefore easier the analyze than the other views. It is also the view that raised the most questions among the stakeholders and the course staff. Thus we assume it is also the most incomprehensible view of the ones we have so far. Especially this reason made us choose to improve the Information View, as it will eliminate uncertainty within the architecture. The usability view was accepted very well by both at the stakeholder as well as the rest af the architect teams during the presentation. The view did not raise any questions among the stakeholders and was found to be very clear and direct. The stakeholders did not give us sufficient reason to improve this view above the Information View. The money flow view also didnt raise questions from the stakeholders. We thus assumed that this view was sufficiently understandable from the stakeholders point of view and didn t feel the need to improve this view because we could invest our time better in improving the information view. 5

6 User Store Regular Customer Card Customer ID Regular Customer Card Salespoint Prepaid Card Prepaid Card ID Prepaid Card Salespoint Customer ID Prepaid Card ID Thin Client RFID-Reader in Vehicle/Station Customer ID Bank Account Prepaid Card ID Prepaid Card Balance Database Billing Server Customer identifier Central Server Prepaid Card ID Loction/Timestamp Confirmation/ Customer ID/ Prepaid Card ID Customer Bank Account/Denial Customer Bank Account Confirmation Denial Appication Server Figure 1: Old Information View 1 Semantical Improvement The purpose of the information view is to demonstrate how the information flows within the VGA card system. The Architectural Structure present in the visual representation of the view is a Component & Connector Structure. The diagram gives an answer to the question of which information is exchanged between various components of the system. In Bass et al. 2 the question How does data progress through the system? is correlated with a Component & Connector 2 Bass, Clements, Kazman. (2003). Software Architecture in Practice. SEI Series in Software Engineering. Addison-Wesley. 6

7 Structure. The question of which information is exchanged within the system is a perfect analogy with the question posed in Bass (2003). From the visual representation of the Information View, the major components and their interaction can also be derived, supporting the Component & Connector Structure. The Information View also has elements from the Module Structure. From the diagram, it is possible to extract the functional responsibility of various functions within the system. In short: the main structure present in the information view is the Component & Connector Structure, but it also has some elements from the Module Structure. 2 Structure and modularity From the Module Architectural Structure, we can identify the Decomposition Structure / Style as a Software Structure. The Decomposition Structure / Style shows how larger modules are split into smaller sub-modules. Splitting of modules in smaller sub-modules is what happens in the information view. The Central Server is split up into an Application Server, a Database and a Billing Server. The Thin Client is refined further to an RFID reader. From the Component & Connector Structure the following Software Structures/Styles can be determined in relation to Bass et al. and Clements et al. 3 : The Communicating Processes Structure and the Shared Data Structure. The Communicating Processes Structure shows how components in a system are connected to each other, via communication, synchronization and/or exclusion operations. The Communicating Processes Structure is present in the diagram by showing the types of information that are communicated among components of the system. Considering that the system thats being developed is a distributed system, this structure is essential in modeling the system. The Shared Data Structure shows components and connectors that create, share and store persistent data. The Shared Data Structure is shown in the information view through the data thats interlinked between components. The diagram particularly shows which data is shared and stored at what location. In the Client-Server Structure various components are shown and the messages they exchange. In the Information View, these components are the Thin Client and the Central Server. The connectors are the messages they exchange, such as Customer ID, bank account details and the confirmation/denial that is sent between the Thin Clients and the Server. 3 Results In this section we describe what improvements we made according to the method that was provided to us. This method seperates the improvement of diagrams in several components which we will describe per point. In this way we can give a clear view on what is the difference between the old version and the new version, plus the reason why we made these changes. 3 Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord and Stafford. (2002). Documenting Software Architectures: Views and Beyond, Addison-Wesley 7

8 User Store Personalized or Pre-paid VGA card Card Identifier Store Computer Traveller Card Identifier On-site Hardware RFID Sniffer RFID Reader Request New Card Identifier Response Send Data. Distributed VPN Network Database Data Request Response Access Request Response Application Server Legend Request Data Billing Server Payment Request Distributed Server Confirmation Client-side Hardware Figure 2: Improved Information View 1 Shapes We have rearranged the sizes of the components to show what the biggest and smallest components are, reflecting the physical sizes of the real components. We have brought a little more structure in the system by separating distributed servers in the central server from small independant machines at the local stations and vehicles. We have also changed the notation of some arrows to indicate that there is a difference between a dataflow and a requestflow. This greatly increases the meaning of the picture as well as the readability because we don t have to explain the connections with a lot of words. 2 Size and width The user part is slightly bigger so we are able to show a picture of a user, better illustrating that this is not a real component as in hardware or software but that it is rather the userside that interacts with the rest of the system. 8

9 As a general improvement we have altered the spacing and notation next to the lines. By creating a legend and reducing the text next to the lines to a minimum we greatly increase the readability of the diagram. 3 Layout Another general improvement to the diagram is that we have included a legend which shows what the different interactions between components mean. This gives a better understanding what is actually happening between components and the general information flow in the whole system. We have sorted the components in a grid forming one big square to show the borders of the system. We have aligned the components on the left side of the diagram for better readability and style. The other boxes are aligned to horizontal lines to avoid summoning an unintended meaning. The direction of the flows is mainly up and down except for the bottom two components in which we have made a turn. Instead of drawing a diagonal line we have chosen for a turn because all of the other lines are either horizontal and vertical. 4 Color We have chosen to exclude color for our diagram. We have thought about seperating the client, thin client and server backend with different colors but this just made the diagram more complex. Next to this we found that adding colors was actually not pleasing for the eye but rather confusing and annoying. 4 Evaluation Overall, we managed to get the Information View improved considerably. In terms of presentation and semantics, we carefully followed the steps as described in the document Annex A6: A step-to-step guide to view improvement, and improved our view to be more simplified, and yet we made sure that it didn t lose the amount of information it already had. Through the assesment meetings, we discovered that the Steakholders also were interested in implementing a sniffer in order to complement the system, and we were able to successfully insert this into the new diagram of the information view. In our personal opinion, the new diagram is much easier on the eyes because of the removal of a lot of unneccesary text that made the old version of the model too convoluted. Details like the difference between a prepaid card and a regular customer card can now simply be explained within the explanation of the view. We feel that the stakeholders will now be able to get a better view of the information flow within the system, which will hopefully eliminate any potential misunderstandings. 9