VIEWS: 3 PAGES: 19 POSTED ON: 8/13/2011
UNIVERSITY OF UMEA ˚ Object-Oriented Software Development Department of Computing Science TDBC31, HT05 D3.4 OOA&D UI redesign for MSA Thermotest TSS - Trustworthy Software Solution firstname.lastname@example.org Object-Oriented Software Development UI redesign for MSA Thermotest – D3.4 OOA&D Supervisor: Johansson, Mats (email@example.com) Author(s): Fredriksson, Patrik (firstname.lastname@example.org) Version: 1.0 December 19, 2005 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution Signature block Responsible team members Abrahamsson, Tomas Contributing team members a N¨slund, Alexander Nilsson, Benny Approving team members Fredriksson, Patrik Olofsson, Peter 1 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution history Document- Document created 2005-11-17 Version 1.0 Contents 1 Introduction 3 2 Target environment 3 3 Software architecture 4 4 Traceability matrix 4 5 Object model 4 6 Dynamic model 7 7 State model 11 8 System overview 14 9 Class descriptions 16 10 Glossary 18 2 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution 1 Introduction This document begins with a description of the target environment, and then continues with the software architecture. It also contains an analysis of the sys- tem to be created, starting from the functional and non-functional requirements and the use cases developed for the requirements document1 . This document will also eventually contain the design phase, and this will be added as the project proceeds. In other words, this document is not the ﬁnal one, but will evolve into it through several iterations. 2 Target environment The target environment describes the boundaries the system should work within. It includes hardware and software requirements, and it is created from the non- functional requirements: NFR 1 - Modularity By building the system in a modular way it can easily be changed and extended. This is most notable with the ability to include more test methods. NFR 2 - Platform independent The system should be written so it would be easy to move to another platform. The core of the system should be platform independent. The GUI will not be independent since it is written for Windows. Java could not be used because it only supports serial communication on Solaris and Linux (without resorting to 3rd party solutions). NFR 3 - Performance There should not be long delays when doing an update or searching the database. A certain latency must be expected when creating reports or when doing large database searches. NFR 4 - Reliability The system should run without program failures resulting in crashes and/or internal data corruption. In case of failure the loss of data should be minimized and the user should be notiﬁed. There will not be any backup feature in the system, so the customer must backup the database by himself. NFR 5 - Free licence for components Any component used in the system should be available for free. This includes the DBMS, tools for generating reports and libraries used in the code. This does not include the operating system for the workstations, database server and tools for viewing reports since the FR speciﬁes that Word should be used. NFR 6 - Familiar UI Since the program should look like an ordinary Windows program the user 1 http://www.cs.umu.se/˜c02pon/oosd/Docs/ 3 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution should be familiar with the look of the system and how to use it. NFR 7 - Unlimited number of patients The systems ability to handle an unlimited number of patients will be limited by the database server, but with the performance of today’s computers this will not be a problem. A quick count showed that each patient will take approxi- mately 50 kilobytes on the database server. This gives about 2 million patients on a 100 gigabyte hard disk. The memory required for the client is less then what Windows require so it will not be a problem. 3 Software architecture Some of the non functional requirements impacts on the software architecture. The following requirements will constrain the architecture of the system. • Free licence for components • Unlimited number of patients • Reliability 4 Traceability matrix Using a traceability matrix is a way to conﬁrm if the chosen classes have their foundation in the requirements. This is made by listing every class on a separate row and then every requirement in a separate column. In-between them a matrix is formed. This matrix will have a ﬁeld for every requirement-to-class dependency (ﬁgure 1 and ﬁgure 2). Then it is only a relativly small task to indicate what classes have what dependency to make sure that all classes are necessary and also to make sure that all requirements are covered in the set of classes. A class is regarded as necessary if one or more of the requirements have a dependency towards them. 5 Object model Based on the requirements the team came up with a collection of classes through brainstorming. These classes are listed below. • Communication • Core • DatabaseCommunication • Diagram • Exam • ExtraPatientInfo • GUI 4 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution Class\FR 1 2 3 4 5 6 7 8 9 10 11 Communication X Core X X X X X X X GUI X X X X X DatabaseCommunication X X X X Exam X X X ExtraPatientInfo X X Patient X X Report X X X X X Setting Template X Test X X X TestMethod X X TestPoint TestSeries X X X Figure 1: Traceability Matrix, functional requirements 1-11 Class\FR 12 13 14 15 16 17 Communication X X X Core X X X X GUI X X X X DatabaseCommunication X Exam ExtraPatientInfo Patient Report X X Setting Template Test TestMethod TestPoint TestSeries Figure 2: Traceability Matrix, functional requirements 12-17 5 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution • Language • Patient • Report • Search • Settings • Template • Test • TestSeries • TestMethod Through discussions about the each class, the classes Language, Search and Diagram were dropped. The classes were all thought of as having too small functionality to be classes and were moved into Core, DatabaseCommunication and Core respectively. The list then consisted of the classes below. • Communication • Core • DatabaseCommunication • Exam • ExtraPatientInfo • GUI • Patient • Report • Settings • Template • Test • TestSeries • TestMethod After some work with the diagram the TestPoint class was added and the ﬁnal list of classes can be seen in the class diagram in ﬁgure 3. 6 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution Figure 3: UML diagram of the system 6 Dynamic model Here several sequence diagrams of use cases are shown. We have opted to dis- regard some of the use cases as they are nearly identical to others (which we do show). Also, please note that references to objects used are assumed to exist in each object which uses them. U1 (ﬁgure 4) The user tries to log into the system using login name and password. The sys- tem veriﬁes the information, and if it is correct the user has logged in. U2 (ﬁgure 5) The user submits information, which the system commits a search on. The user is then presented with a list of possible matches, and he/she can then either select one of them or do a new search. U3 (ﬁgure 6) The user wishes to create a new patient. The user enters information regarding the new patient, and the system veriﬁes that information. If the entered SSN is unique in the system, create the new user. If it isn’t, select the patient to who the SSN belongs. U4 (ﬁgure 7) The user wants to change information regarding a patient (which is already se- lected). The system displays information about the patient, and the user can then edit that information. When the user is ﬁnished he/she can submit the changes to the system which then saves them. U5 (ﬁgure 8) 7 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution Database GUI dbCon User insertInfo(login,pw) doLogin(login,pw) createSqlLine insert SqlLine result result success [result == true] Figure 4: Sequence diagram for use case 1 Database GUI dbCom User Insert infomation submit search search(information) create SqlLine insert SqlLine results display results Figure 5: Sequence diagram for use case 2 The user wishes to create a new examination for a patient. The patient has already been chosen. The user speciﬁes the date and the system veriﬁes the date. If everything is okay, a new examination is created for the speciﬁed date and patient. 8 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution GUI dbCon Database User createPatient(info) findPatient(info) createSqlLine insert SqlLine result resultList insertPatient(info) [resultList == createSqlLine empty] insert SqlLine Figure 6: Sequence diagram for use case 3 U9 (ﬁgure 9) The user intends to add a test to an already selected examination. When the user starts the test, the system makes a series of repeating tests on a point. The results are displayed to the user and then saved. U10 (ﬁgure 10) The user performs a series of tests in a row. Every single test is performed as explained in U9. U11 (ﬁgure 11) The user wishes to generate a report on an already selected examination. When the report module receives the request, the user is presented with a set of dif- ferent layout settings to choose from. U14 (ﬁgure 12) The user wants to create a new user account. The user tells the system he/she wishes to create a new user account. To do this a new form is presented to the user. The user ﬁlls in this new form and submits it. The system veriﬁes the information and adds the new user to the system. 9 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution Database GUI dbCon User reviseInfo(patient) getInfo(patient) createSqlLine insert SqlLine result result displayInfo() submitChanges(info) changeInfo( patient,info) createSqlLine insert SqlLine Figure 7: Sequence diagram for use case 4 db GUI Patient dbCom User submit examination createExamination() <<create>> Examination save() saveExam() create SqlLine insert SqlLine success Figure 8: Sequence diagram for use case 5 10 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution GUI Test Database Com dbCom User Thermotest doTest performTest() performTest(settings) settings results results save() creat SqlLine inser SqlLine display results Figure 9: Sequence diagram for use case 9 GUI Testserie Test Actor [ for every test in serie ] do Testserie loop doTestserie() doTest() perform Test [UC9] result display results Figure 10: Sequence diagram for use case 10 7 State model This section contains state chart diagrams for classes that contain states that are non-trivial. The ﬁrst one is the Exam class that can be seen in ﬁgure 13. The Exam class starts when a patient is brought into the system and the class will then be in an active state. From the active state tests, or test series can be created without changing state. When the exam gets archived the exam changes state to archive and no more tests or test series can be created. The only way a examination is brought back to an active state is if a administrator of the system de-archives the exam. The 11 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution GUI Examination Raport User make raport generateReport() generateReport(Exam) display layouts chooseLayout(choice) generateReport() Figure 11: Sequence diagram for use case 11 Figure 12: Sequence diagram for use case 14 exam can also change to the state deleted if the admin deletes the exam when 12 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution the exam is in the active state. After that we have the Communication class as seen in ﬁgure 14 which has Figure 13: State chart diagram for Exam class three states: inactive, send and receive. From the inactive state the send state can be reached when the class wants to send or poll the hardware. The receive state is then reached when the class waits for a response from the hardware. After a response has arrived the class then returns to the inactive state. The report class in ﬁgure 15 has two states, inactive and active between Figure 14: State chart for Communication class which it changes between. When the class is initiated it starts in the inactive state and when a matrix document or a report is generated the class goes into the active state until it’s done and then it becomes inactive again. 13 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution Lastly we have the TestMethod class in ﬁgure 16 which consists of three Figure 15: State chart for Report class states, inactive, active and wait. The class starts out as inactive and then goes into active when a test is initiated. In the active state test cases can be executed without changing state but after a test case has been executed the class goes into the wait state where it waits a random amount of time before returning to the active state. After the test is done the class returns to the inactive state. Figure 16: State chart diagram for the TestMethod class 8 System overview This section will present a high-level overview of the system. First is the hard- ware overview (ﬁgure 17). This shows the system infrastructure and the connec- tion between the diﬀerent parts of the system. Everything is available except the software for the web server and DBMS. The use of a web server is depend- ing on how the work on creating reports turns out. The database server can be located on one of the workstations connected to the local LAN. The connection between the clients and server can be made secure with SSL or SSH. Figure 18 gives a view of the layout of the client showing the connection to the database and Thermotest. Figure 19 shows the diﬀerent modules of the system. It shows the ﬁve modules of the system. The GUI module is a platform dependent implementation of the GUI. The Core module gives the GUI an API to the rest of the system. This makes it easier to change things in the core without aﬀecting the GUI. Then there are the three modules Database Communication, Communication and TestMethod. This will be an abstract class that makes it possible to im- plement diﬀerent test methods. The Communication module handles the com- munication between the client and the Thermotest. This might not be platform 14 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution Figure 17: System infrastructure overview independent. By moving the communication into a module the system can eas- ily be updated to support other ways of communication, like USB or IEEE1394. The last module is the Database Communication module which provides access to the database server. This can also be updated to support another DBMS. Software IP (SSL/SSH?) Database Serial communication Thermotest Figure 18: High-level client overview 15 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution GUI Core Thermotest Database Test methods communication communication Figure 19: Medium-level overview showing main module of system 9 Class descriptions Class: Communication Description: The Communication class hides the internal structure of the communication with the hardware. Functions: Send and receive data. Interacts with: Core, TestMethod. Class: Core Description: Used by the GUI to control all the parts of the system. Functions: Has access to more or less all the functions in the system. Interacts with: All except Setting, ExtraPatientInfo, Test and TestSeries. Class: GUI Description: The graphical user interface for the system. Functions: Collect data from user and pass on to other parts of the system. Receive data from other parts of the system and display to user. Interacts with: Core. Class: DatabaseCommunication Description: The part of the system that handles the communication with the database. Functions: Collect data for patient, exam, and test. Authorize users. Interacts with: Core. Class: Exam 16 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution Description: The Exam class represents an examination and holds test data. It also holds referring physician, examiner, date and place. Functions: Retrieve tests. edit comments. Interacts with: Patient, Test, TestSeries. Class: ExtraPatientInfo Description: Container for scientiﬁc information connected to a patient. Functions: Insert and collect information. Interacts with: Patient Class: Patient Description: The Patient class holds the information about a patient along with all the examinations the patient has undergone. Functions: Show the patients exams and extra patient info. Interacts with: Core, ExtraPatientInfo, Exam. Class: Report Description: The report class provides the possibility to generate diﬀerent kinds of reports. Functions: Has functions to generate regular reports in .doc, and .pdf and also to generate a text ﬁle with data from several patients in form of a matrix. Interacts with: Core. Class: Setting Description: The Setting class is a container used for communicating with the TestMethod class. Functions: Insert and edit settings. Interacts with: Test, TestMethod. Class: Template Description: The template class holds the description for a template. Functions: Edit, add and remove testpoints. Edit comments for template. Interacts with: Core, TestPoint, Exam. Class: Test Description: The Test class represents a single test containing a number of test cases. The Test class have information about the settings for a test such as minimum and maximum temperature, default temperature and more. Functions: Execute test, edit settings. Interacts with: Exam, TestMethod, Setting. Class: TestMethod Description: Since diﬀerent kinds of test methods should be able be imple- mented in the future the TestMethod class will follow an interface. It will be using the Communication class to perform the test. Functions: Do test. Interacts with: Test, Setting, Communication, Core. Class: TestPoint Description: A test point represents a certain point of the body. The test 17 Object-Oriented Software Development D3.4 OOA&D TDBC31, HT05 TSS - Trustworthy Software Solution point contains settings for testing on that point of the body. Functions: Set and get test settings. Interacts with: Template Class: TestSeries Description: The TestSeries class contains the actual tests that a template describes. Functions: Get tests, edit comments. Interacts with: Exam, Test. 10 Glossary API - Application Programming Interface FR - Functional Requirements GUI - Graphical User Interface IEEE1394 - Standard for what is commonly known as FireWire LAN - Local Area Network NFR - Non-Functional Requirements SSH - Secure SHell, a network protocol SSL - Secure Sockets Layer UI - User Interface USB - Universal Serial Bus 18
"Object-Oriented Software Development"