Get documents about "Object-Oriented Software Development
Document Sample
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
