Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Object-Oriented Software Development

VIEWS: 3 PAGES: 19

									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                 c02fpk+oosd@cs.umu.se




           Object-Oriented Software
                 Development
     UI redesign for MSA Thermotest – D3.4 OOA&D




         Supervisor: Johansson, Mats (matsj@cs.umu.se)
         Author(s): Fredriksson, Patrik (c02fpk@cs.umu.se)
                         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 final
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 notified. 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 specifies 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 confirm 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 field for every requirement-to-class
dependency (figure 1 and figure 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 final
list of classes can be seen in the class diagram in figure 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 (figure 4)
The user tries to log into the system using login name and password. The sys-
tem verifies the information, and if it is correct the user has logged in.

 U2 (figure 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 (figure 6)
The user wishes to create a new patient. The user enters information regarding
the new patient, and the system verifies 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 (figure 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 finished he/she can submit the
changes to the system which then saves them.

 U5 (figure 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 specifies the date and the system verifies the
date. If everything is okay, a new examination is created for the specified 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 (figure 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 (figure 10)
The user performs a series of tests in a row. Every single test is performed as
explained in U9.

 U11 (figure 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 (figure 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 fills in this new form and submits it. The system verifies 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 first one is the Exam class that can be seen in figure 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 figure 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 figure 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 figure 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 (figure 17). This shows the system infrastructure and the connec-
tion between the different 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 different modules of the
system. It shows the five 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 affecting 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 different 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 scientific 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 different
kinds of reports.
Functions: Has functions to generate regular reports in .doc, and .pdf and also
to generate a text file 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 different 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

								
To top