[ieee 2009 wri world congress on software engineering - xiamen, china (2009.05.19-2009.05.21)] 2009...
Post on 23-Dec-2016
218 Views
Preview:
TRANSCRIPT
FMEA for UML-based Software
Wang Wentao Zhang Hong
Dept. of System Engineering of Engineering Technology
Beihang University, Beijing, P. R. China
wwtjun@gmail.com zh@buaa.edu.cn
Abstract- As one of the most important methods used to
improve the software reliability and safety, Software
Failure Modes and Effects Analysis (SFMEA) has
increasingly been applied to many areas. Meanwhile, the
Unified Modeling Language (UML) has become the main
language for Object-Oriented software design. Therefore,
the method of UML-based SFMEA is of importance to
Object-Oriented software. In this paper, this research
takes advantage of the characteristics of the UML
diagrams used in different software development phases
such as requirement analysis phase and architectural
design phase, builds the relationships respectively
between SFMEA and use case diagram, activity diagram,
and lastly establishes the corresponding analysis methods
illustrated with an example.
Keywords- SFMEA, UML, OO
1. Introduction
With wide application of computer software in
many areas, the reliability and safety are also
increasingly becoming prominent. As a general method
of software reliability and safety analysis, Software
Failure Modes and Effects Analysis (SFMEA) has
been playing an important role in enhancing the
software reliability and safety. Currently, Object-
Oriented (OO) method has become the mainstream of
software development, while UML has also been the
unified modeling language in software industry [1].
Since the modeling language draws the blueprint of
software construction, apparently it is the source for
reliability analysis. Therefore, the research on SFMEA
based on UML makes actual sense to the reliability
analysis of Object-Oriented software.
So far, the researches on this topic are somewhat
few in software reliability area. The article [2] presented
by Professor Nathaniel Ozarin in 2004 stated the
relationships among software development stages,
UML diagrams and FMEA levels (method, class,
module and package), but not focused on the concrete
process when performing FMEA with UML diagrams.
In the same year, Professor Herbert Hecht in his
article [3] described respectively the application of UML
to SFMEA during the concept phase (the requirement
analysis stage in OO process) and the implementation
phase (the coding stage in OO process), while he only
took advantage of the use case diagram and class
diagram, lacking dynamic diagrams such as activity
diagram and sequence diagram, etc.
Therefore, in this paper some fresh researches on
FMEA for UML-based software will be described in
two development phases of OO software.
2. The Features of UML
The advent of OO technique and particularly of
the UML has motivated us to take a fresh look at
overcoming the previous difficulties in generating
SFMEA. The key to this fresh look is that objects are
uniquely characterized by their methods (sometimes
called behaviors) [3]. If all methods of an object are
executing in accordance with their specification the
object has not failed. Conversely, the object will fail.
The failure effect will depend on the mode in which
the method failed.
Now we will demonstrate orderly how these
characteristics can be used to generate a FMEA from
the UML diagrams available during the requirement
analysis phase and architectural design phase.
3. SFMEA in Requirement Analysis Phase
Requirement analysis is the first and also
important phase in OO software development process,
identifying the user’s functional requirements which
could be described with use case diagram. And it could
also use activity diagram to establish the order of
requirements as auxiliary artifacts. In this early phase
performing SFMEA could help the analyst find
potential weaknesses in system level, and
communicate to all project participants that special
attention to reliability or safety critical aspects is
required. Also, applying SFMEA in the early phase
needs comparatively little effort but great benefit [4].
World Congress on Software Engineering
978-0-7695-3570-8/09 $25.00 © 2009 IEEE
DOI 10.1109/WCSE.2009.342
457
World Congress on Software Engineering
978-0-7695-3570-8/09 $25.00 © 2009 IEEE
DOI 10.1109/WCSE.2009.342
457
World Congress on Software Engineering
978-0-7695-3570-8/09 $25.00 © 2009 IEEE
DOI 10.1109/WCSE.2009.342
456
World Congress on Software Engineering
978-0-7695-3570-8/09 $25.00 © 2009 IEEE
DOI 10.1109/WCSE.2009.342
456
World Congress on Software Engineering
978-0-7695-3570-8/09 $25.00 © 2009 IEEE
DOI 10.1109/WCSE.2009.342
456
Take the common ATM system for instance. We
apply our approach in the software part of this system,
whose use case diagram is shown in Figure 1 as below,
including “deposit”, “withdraw”, “query balance” ,
“login” and “print receipt” five use cases. Then we
discuss the steps of performing SFMEA [5].
Figure 1 ATM Use Case Diagram
(1) System defining and partitioning. As a
bottom-up analysis method, SFMEA requires firstly
the system under analysis to be hierarchically divided
into components in such a way that the failure modes
of the components at the bottom level can be
identified [6].
As is shown in Figure 1, the three main use cases,
also the three main components should be the first
level for analysis. “Login” belongs to the included use
case, which means it must be a necessary part of other
use cases (symbolized with <<uses>>), and it should
be allocated to the second level. The “print receipt”
belongs to the extended use case, which means it is a
supplementary but not necessary part of other use
cases (symbolized with<<extends>>). And also these
two special use cases are independent of each other.
The correlations among use cases could help us
acquaint with the system and components.
(2) Identify analysis level and analysis item. It is important to make sure which level we start
analyzing from. Generally, the lower level chosen, the
more components concerned, and the higher cost. The
basic factors influencing the selection of the proper
lowest level of system decomposition are the purpose
of the analysis and the availability of system design
information [7]. Once analysis level is identified, each
component at this level could be considered as the
analysis item. According to Figure 1, we choose the case level
as the analysis level and each use case is regarded as
an item. For each item, we start to bottom-up analyze.
(3) Identify failure modes. A failure mode is
defined to be “the physical or functional manifestation
of a failure” [8]. As one of the components which
perform an independent function from others, its
failure modes could be regarded as function failure
modes and performance failure modes. The former
often includes “unable to initialize”, “could not
perform correctly”, “correct operation but bad result”
and so on; the latter often pays attention to time and
memory such as “perform delays”, “memory leaks”
and so on.
In this example our discussion concentrates on the
“login” item. In accordance with its functional
requirement, the most common failure modes are
“unable to login” and “illegal login”. Besides,
considering the time factor, “login delays” is another
failure mode. In order to identify more failure modes,
except for experiences, the analyst also need to refer to
other development documents and communicate with
experts in related domain.
(4) Trace the failure effect. Failure effect,
which is the consequence that a software failure causes,
could propagate from the lower level to the higher one.
The failure effects of the lower level components
constitute the failure modes of the upper level
components. Failure effect is generally composed of
the local effect, the next higher level (NHL) effect and
system effect. In this example, solely on the basis of
Figure 1, we could not trace the local failure effect of
“login” item, thus we need the activity diagram to
show the relationship between items.
Figure 2 The System Activity Diagram
As is shown in Figure 2, the system activity
diagram contains a sequence of activities displaying
how a customer uses the ATM system. Thus, we can
judge that the local effect caused by the failure mode
“illegal login” will influence the next activity
(“withdraw”/ “deposit”/ “query balance”) and will
458458457457457
cause specifically withdraw, deposit, and query
balance illegally. The NHL effect and system effect are
the same one in this example, which indicates that the
system operates abnormally and personal account will
be stolen, which is a high severity failure.
If another failure mode “login delays” happens,
despite local effect or system effect, it may only cause
the system’s performance degradation but not
influence its normal operation and personal safety, and
we define this kind of failure effect as “moderate”. So
a FMEA worksheet for the “login” use case based on
Figure 1 and Figure 2 is shown in Table 1. Finally,
performing FMEA for the rest items could follow the
rules as above.
To sum up, the method based on UML to generate
software FMEA during the requirement analysis phase
is that:
� Analysis basis: use case diagram, activity
diagram;
� Analysis item: use case;
� Analysis step: make use of use case diagram
to identify analysis level and items, activity diagram to
trace the local effect, and use case diagram to trace the
system effect.
Table 1 Worksheet in Requirement Analysis Phase
ID Item/
Function
Failure
Modes
Cause Local
Effect
NHL
Effect
System
Effect
Severity Compensation
1.1.1 Login Illegal
login
Login part
lacks fault
tolerance
design in
hardware and
software;
Withdraw,
deposit,
and query
balance
illegally.
N/A The system
operates
abnormally,
or personal
account is
stolen
High Implement fault
tolerance design in
hardware and
software part.
1.1.2 Login Unable
to login
Hardware
fails; defect
in software
design
Unable to
withdraw,
deposit,
and query
balance.
N/A The system
operates
abnormally
High Make sure hardware
is all right before
operation or could
reject card if does not
work; Add another
validation process
1.1.3 Login Login
delays
Lack of
explanation on
login time in
requirement
Accessing
operation
interface
delays.
N/A The system
operation
delays
Moderate Add clear explanation
on login time in
requirement
… … … … … … … … …
4. SFMEA in Architectural Design Phase
The architectural design phase, which is based on
requirement, describes the system architecture and
functions how to operate. In this phase, activity
diagram or sequence diagram need to be used for
depicting the main use cases, so that the definement of
system structure is clearer and concreter than the
former phase. And performing SFMEA will detect
more potential failure modes so that it could reduce
more risk. Now our approach will be illustrated by
means of the activity diagram for “login” use case.
As is shown in Figure 3, the “login” use case has
been divided into a sequence of activities, such as
“insert card”, ”validate card”, ”input password”,
“validate password”, etc, and all of them are in the
same level. So the activity level could be the analysis
level, and each activity can be regarded as an analysis
item since it represents an individual function.
Figure 3 “Login” Activity Diagram
459459458458458
The parts of logical decision and concurrent in
software, which are represented by the symbols
“branch” and “fork” in activity diagrams, are usually
easy to fail. Hence more attentions should be paid to
these two parts in generating SFMEA. In addition, the
failure modes at this level concern about not only each
item’s behavior, but also the relationships between
behavior and its inputs and outputs, and relationships
with other items, mainly generated from the analyst’s
experiences and acquaintance with the object under
analysis.
Take the item “validate card” related to a branch
symbol for example. Considering the behavior process
itself, it has three common failure modes like “unable
to validate card”, ” validate card illegally”, and
“validation delays”, similar to the ones in requirement
analysis phase; With regard to input, there are such
failure modes as “receive a wrong card”, “the valid
card is swallowed abnormally”, etc; Similarly, in terms
of output, there are such failure modes as “validate
successfully but cannot access the password interface”,
“the invalid card cannot exit after validation”, etc. It is
really difficult to cover all failure modes, but the more
we detect, the less risk the system will confront with.
The local failure effect could be identified by the
direction to the arrowhead points. The NHL effect and
system effect could be established from the use case
diagram, which is very similar to the method used in
former phase. Finally, a FMEA worksheet for the
“validate card” activity based on Figure 3 and Figure 1
is shown in Table 2.
Table 2 Worksheet in Architectural Design Phase
ID Item/
Function
Failure
Modes
Cause Local
Effect
NHL
Effect
System
Effect
Severity Compensation
2.1.1 validate
card
Unable to
validate card
Lack of fault
tolerance
design in
hardware and
software;
network fault
Access the
password
validation
interface
illegally.
Login
illegally
Refer to
ID1.1.1
High
Implement fault
tolerance design in
hardware and
software part of
card validation;
check network
transmission
normal
2.1.2 validate
card
Validate
card
illegally
Hardware
fails; defect
in software
design
Unable to
access the
password
validation
interface
Unable
to login
Refer to
ID1.1.2
High
Refer to ID 1.1.2
2.1.3 validate
card
Validation
delays
Network fault;
the amount of
visiting goes
beyond the
limits
Delay to
access the
password
validation
interface
Login
delays
Refer to
ID1.1.3
Moderate Check network
transmission
normal; Add clear
explanation on the
amount of visiting
in design
2.1.4 validate
card
Receive a
wrong card
Lack of
another
verifying
process before
validate; the
hardware part
fails
Might access
the password
validation
interface
illegally;
Refer to
ID2.1.1
Refer to
ID1.1.1
Moderate Add another
verifying process
for initial check;
Implement fault
tolerance design in
hardware.
2.1.5 validate
card
The valid
card is
swallowed
abnormally
Defect in
validation part
design such as
lacking the
times of input,
or logic
confusion
Unable to
access the
password
validation
interface
Refer to
ID2.1.2
Refer to
ID1.1.2
High
Modify the
weakness, enhance
validation part
design
460460459459459
2.1.6 validate
card
Validate
successfully
but cannot
access the
password
interface
Defect in GUI
part design;
the display
screen fault
Unable to
access the
password
validation
interface
Unable
to login
or login
delays
Refer to
ID1.1.2/
ID1.1.3
Moderate Enhance GUI part
design; check
display screen to
work normally
2.1.7 validate
card
The invalid
card cannot
exit after
validation
Logic
confusion in
validation part
design; the
“reject card”
hardware fault
Might access
the password
validation
interface
illegally
Refer to
ID2.1.1
Refer to
ID1.1.1
Moderate Enhance validation
part design; check
“reject card”
hardware to work
normally
… … … … … … … … …
Therefore, the method based on UML to generate
software FMEA during the architectural design phase
is that:
� Analysis basis: activity diagram, use case
diagram;
� Analysis item: activity;
� Analysis step: make use of activity diagram to
identify analysis level, items and to trace the local
effect; make use of use case diagram to trace the NHL
effect and system effect.
It must be admitted that completing an accurate,
complete and effective SFMEA worksheet does not
only depend on how sufficient experiences an analyst
has, but also needs the analyst to communicate
necessarily with the developers and experts, repeatly
modify and confirm the result.
5. Conclusion and Prospect
Via the application of our method to OO software
requirement analysis phase and architectural design
phase, we could make more affirmations about the
benefits brought by UML-based SFMEA:
� Convenient — the analyst don’t need to
partition the program into functions, since the analysis
items are defined by the use case diagram in
requirement analysis phase and the activity diagram in
architectural design phase;
� Unique — the dynamic diagrams such as
activity diagrams and sequence diagrams (although not
be introduced yet) could reveal the sequence or other
relationships among items, which aid the analysts to
trace the failure effects;
� Complete — the requirements are covered
with use case diagrams and the use case diagrams are
divided into activity diagrams, which assure the
analysis results complete.
There is still much work to do in the future,
although our researches seem to be encouraging. We
are continuing with this research by applying SFMEA
to the sequence diagrams and class diagrams in the
detail design phase and the implementation phase. Of
course our ultimate goal is to establish a set of
comprehensive and in-depth SFMEA approaches
applicable to the whole OO software development
process.
References [1] Song Bo, Liu Jie, UML based OO Technology and
Practice [M], Science Press, 2005,10
[2] Nathaniel Ozarin. Failure Modes and Effects Analysis
during Design of Computer Software [J]. IEEE, 2004:
201-206
[3] Herbert Hecht, Xuegao An, Myron Hecht. Computer
Aided Software FMEA for Unified Modeling Language
Based Software [J]. IEEE, 2004: 243-248
[4] Bowles, J.B., The new SAE FMECA standard.
Proceedings Annual Reliability and Maintainability
Symposium [C], 1998: 48–53.
[5] Li Fang, Huang Xizi, Software Failure Modes and
Effect Analysis Method [J], UESTC, 1998
[6] Haapanen Pentti, Helminen Atte, Failure modes and
effects analysis of software based automation systems
[C], STUK-YTO-TR 190, 2002.8
[7] Peter L.Goddard. Software FMEA Techniques [J].
Reliability and Maintainability Symposium. Jan.2000:
118-123
[8] Lutz, R.R., Woodhouse, R.M. Contributions of SFMEA
to Requirements Analysis [J]. Proceedings of the
Second International Conference. April 1996: 44 – 51
461461460460460
top related