close

Вход

Забыли?

вход по аккаунту

?

Dependability-Oriented Model-Driven Requirements Engineering for Reactive Systems

код для вставкиСкачать
Dependability-Oriented
Model-Driven Requirements Engineering
for Reactive Systems
Sadaf Mustafiz
Doctor of Philosophy
School of Computer Science
McGill University
Montreal, Quebec
October 2009
A Thesis Submitted to McGill University
in Partial Fulfillment of the Requirements of the Degree of Doctor of Philosophy
c Sadaf Mustafiz, 2009
Library and Archives
Canada
Bibliothèque et
Archives Canada
Published Heritage
Branch
Direction du
Patrimoine de l’édition
395 Wellington Street
Ottawa ON K1A 0N4
Canada
395, rue Wellington
Ottawa ON K1A 0N4
Canada
Your file Votre référence
ISBN: 978-0-494-66470-4
Our file Notre référence
ISBN: 978-0-494-66470-4
NOTICE:
AVIS:
The author has granted a nonexclusive license allowing Library and
Archives Canada to reproduce,
publish, archive, preserve, conserve,
communicate to the public by
telecommunication or on the Internet,
loan, distribute and sell theses
worldwide, for commercial or noncommercial purposes, in microform,
paper, electronic and/or any other
formats.
.
The author retains copyright
ownership and moral rights in this
thesis. Neither the thesis nor
substantial extracts from it may be
printed or otherwise reproduced
without the author’s permission.
L’auteur a accordé une licence non exclusive
permettant à la Bibliothèque et Archives
Canada de reproduire, publier, archiver,
sauvegarder, conserver, transmettre au public
par télécommunication ou par l’Internet, prêter,
distribuer et vendre des thèses partout dans le
monde, à des fins commerciales ou autres, sur
support microforme, papier, électronique et/ou
autres formats.
L’auteur conserve la propriété du droit d’auteur
et des droits moraux qui protège cette thèse. Ni
la thèse ni des extraits substantiels de celle-ci
ne doivent être imprimés ou autrement
reproduits sans son autorisation.
In compliance with the Canadian
Privacy Act some supporting forms
may have been removed from this
thesis.
Conformément à la loi canadienne sur la
protection de la vie privée, quelques
formulaires secondaires ont été enlevés de
cette thèse.
While these forms may be included
in the document page count, their
removal does not represent any loss
of content from the thesis.
Bien que ces formulaires aient inclus dans
la pagination, il n’y aura aucun contenu
manquant.
ABSTRACT
Errors made during requirements development of dependable systems are very expensive to fix later in the lifecycle, and can result in minor to catastrophic failures. Discovering
and documenting potential abnormal situations and irregular user behavior that can interrupt normal system interaction is of tremendous importance in the context of dependable
systems development. Exceptions that are not identified during requirements elicitation
might eventually lead to an incomplete system specification during analysis, and ultimately
to an implementation that lacks certain functionality, or even behaves in an unreliable way.
This thesis introduces a model-driven requirement development process that systematically guides the developer to consider reliability and safety concerns of dependable reactive
systems. Our Dependability-Oriented Requirements Engineering Process (DREP) is comprised of five phases: requirements elicitation, requirements specification, dependability
assessment, dependability-based refinement, and requirements summary.
Our approach extends use case-based elicitation with ideas from the exception handling
world. It leads the developer to explore exceptional situations arising in the environment
that change user goals and service-related exceptional situations that threaten to fail user
goals. The process requires the developer to specify means that detect such situations, to
define the recovery measures that attempt to continue to provide service in a dependable
manner, to offer degraded services where applicable or to ensure system and user safety.
The need for exceptional modes of operation is also taken into account. The notions of
dependability are integrated in activity diagrams and communication diagrams, which are
used as specification models.
We also propose a probabilistic extension of statecharts to formally model the interaction requirements defined in the use cases. The formalism, DA-Charts, allows a modeller to
use success and failure probabilities to model the unreliable behaviour of the environment.
Subsequently, the model can be probabilistically analyzed to determine achievable reliability and safety of the system interactions. A visual modelling environment for DA-Charts
supporting automatic probability analysis has been implemented.
We show that the proposed methodology leads to notable improvement in system
dependability by applying our work to three case studies: the Elevator Control System,
the 407 Express Toll Route System, and the Crisis Management System.
ii
ABRÉGÉ
Lorsque l’on développe des systèmes fiables, les erreurs ou oublis qui pourraient
éventuellement se glisser dans la spécification du système peuvent avoir des conséquences
néfastes, et pas seulement du point de vue monétaire.
Il est par conséquent impératif de découvrir et d’analyser toute situation anormale
ou comportement irrégulier d’un utilisateur du système qui pourrait interrompre le fonctionnement et les interactions habituelles du système. Une telle exception, qui n’aurait
pas été découverte pendant la phase d’analyse des besoins, produirait une spécification de
l’application à développer contenant des lacunes, ce qui, à la fin, causerait une implémentation
de l’application à laquelle il manquerait des fonctionnalitées, ou qui se comporterait d’une
manière peu fiable.
Cette thèse présente un processus de développement orienté modèle qui mène le
développeur à prêter une attention particulière à la sûreté et à la fiabilité du système
en développement. Notre approche, nommée DREP, est constituée de cinq phases: la
découverte des besoins, la spécification des besoins, l’évaluation de la fiabilité, le raffinement, et le résumé des besoins.
Notre phase de découverte des besoins se base sur les cas d’utilisation. Elle mène le
développeur à considérer des situations exceptionnelles qui pourraient surgir dans l’environnement
et changer les buts des utilisateurs du système. Le développeur est également poussé à
réfléchir aux situations qui pourrait empêcher le système de fournir un service avec succès.
Dans ces cas, DREP demande au développeur de spécifier les démarches à suivre pour
traiter cette situation, si possible en continuant à fournir le service demandé, ou à défaut,
en fournissant un service diminué, ou simplement en s’assurent que le système s’arrête sans
causer de dommage. DREP intègre également la notion de modes exceptionnels d’opération
du système.
DREP propose des extensions au diagrammes d’activités et de communication d’UML
pour permettre au développeur d’exprimer la fiabilité dans les modèles de spécification
du système. Une extension des diagrammes d’états intégrant les probabilités permet de
modéliser les pannes qui pourraient surgir dans l’environnement. Un outil d’analyse permet
ensuite de déterminer la sûreté et la fiabilité atteignable du système.
iii
On démontre que notre approche génère des spécifications de systèmes plus fiables avec
trois cas d’études: un contrôleur d’ascenseur, un système de collecte de payage d’autoroute,
et un système de gestion de crises.
iv
ACKNOWLEDGEMENTS
My deepest thanks go to my supervisor, Prof. Jörg Kienzle. This thesis would not
have been possible without him. I am indebted to him for the advice, guidance, and
encouragement he has given me during my graduate studies. I thank him for introducing
me to this area of research, and for teaching me excellent research and teaching practices.
I thank him for always having confidence in me, for making me believe in myself, and for
helping me reach the finishing line. I truly appreciate the time and effort he has given in
reviewing this thesis. His valuable and constructive feedback has significantly improved this
thesis. I am grateful for the financial support I received from his research grant throughout
my Ph.D. studies.
I wish to thank my Ph.D. progess committee members, Prof. Hans Vangheluwe and
Prof. Martin Robillard, for their time, effort, and constructive feedback on my work.
I would especially like to extend my gratitude to Prof. Vangheluwe for introducing me
to the world of models and MDE. I greatly appreciate the time and guidance he has given
me during my PhD. I thank him for his valuable feedback on the work on dependability
assessment and model transformation. The work on dependability assessment using DACharts in this thesis has been motivated by him. I believe my work and my conversations
with him have truly made a difference in this thesis.
I would like express my appreciation towards Prof. Nicholas Guelfi of LASSY, University of Luxembourg for inviting me to work on the Crisis Management System case study.
The case study has helped me further validate my work. My sincere thanks to Prof. Guelfi
for giving me the opportunity, and for funding the research visit.
I wish to thank Aaron Shui and Ximeng Sun for their contributions to this project, and
Jamal Sheikh for his contributions to the 407 ETR case study. I would like to acknowledge
the students of COMP 533 (Fall 2006 and Fall 2007): their work with use cases and DREP
in the course facilitated the evaluation of my work.
I extend my thanks to the many SEL members who have come and gone over the
last few years for maintaining a friendly lab environment. My special thanks to Alexandre
Denault and Samuel Gélineau. I thank Alex for his encouragement and suggestions during
the writing of this thesis, and for making this lab a fun place to be in. I appreciate his
taking the time to review one of the introductory chapters of this thesis. I would like to
v
thank Samuel for being my latex helpline, for proofreading the french abstract, and for
giving constructive feedback on the work on degraded modes of operation.
I sincerely thank the system staff, Ron Simpson and Andrew Bogecho, for their help
and support during the last few years. I was never short on technical resources thanks to
them. I would also like to extend my appreciation to past and present administrative staff,
especially Vicki Keirl, Diti Anastasopoulos, and Danielle Bissonnette.
I wish to express my heartfelt appreciation to my family. I deeply thank my father
for encouraging me to embark on this journey, and for always keeping me in his prayers.
My life as a graduate student in Canada would have never been without his support. I
am grateful to my mother for her advice and encouragement. She has always been my
inspiration and my role model, and it is because of her that I was always interested in
Software Engineering and continued to work in this field during my Masters and my PhD.
My warm thanks to my sisters and brother for keeping up my spirits, and for their moral
support.
I also wish to thank my friends for their encouragement, and for helping make graduate
student life a lot of fun.
I would like to thank my husband, Rafi, who has gone through this with me more than
anyone else. My deepest gratitude goes to him for his constant support, encouragement,
understanding, and patience. The last few months would have been much more difficult
without him by my side.
Above all, I am grateful to God for giving me the strength and the ability to reach
my goals.
vi
TABLE OF CONTENTS
ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
ABRÉGÉ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
v
LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
1
2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1
1.2
1.3
1.4
1.5
1.6
.
.
.
.
.
.
1
4
5
6
7
8
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.1
2.2
2.3
10
11
12
13
15
15
17
18
18
19
19
20
2.4
2.5
2.6
Motivation . . . . . .
Research Problem . .
Scope . . . . . . . .
Thesis Contributions
Published Articles .
Thesis Roadmap . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Software Engineering . . . . . . .
Model Driven Engineering . . . .
UML . . . . . . . . . . . . . . . .
2.3.1 UML Diagrams . . . . . .
2.3.2 UML Profiles . . . . . . .
Requirements Engineering . . . .
2.4.1 Requirements Elicitation .
2.4.2 Requirements Analysis . .
2.4.3 Requirements Specification
2.4.4 Requirements Validation .
Non-functional Requirements . .
Dependability . . . . . . . . . . .
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
23
23
26
28
Dependability in Model-Driven Software Engineering . . . . . . . . . . . . . . .
29
3.1
.
.
.
.
.
.
.
.
29
30
31
31
32
33
33
34
Addressing Dependability in Requirements Engineering . . . . . . . . . . . . .
36
4.1
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
37
37
37
40
40
41
41
43
44
45
47
Integrating Dependability in Requirements Models . . . . . . . . . . . . . . . .
49
5.1
50
51
52
52
54
55
56
56
2.7
3
3.2
3.3
4
4.2
4.3
4.4
4.5
5
5.2
2.6.1 Dependability Attributes
2.6.2 Dependability Threats .
2.6.3 Dependability Means . .
2.6.4 Exception Handling . . .
Summary . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Model-Driven Software Development . .
3.1.1 UML . . . . . . . . . . . . . . . .
3.1.2 The Unified Process . . . . . . . .
3.1.3 Fondue . . . . . . . . . . . . . . .
Dependability and Software Engineering
3.2.1 DREP and UP . . . . . . . . . .
3.2.2 DREP and Fondue . . . . . . . .
Summary . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
The Basic Concepts . . . . . . . . . . . . . . . . . . .
4.1.1 System and its Structure . . . . . . . . . . . . .
4.1.2 Services and Outcomes . . . . . . . . . . . . . .
Attaining Dependability in Requirements Engineering
4.2.1 Exceptions . . . . . . . . . . . . . . . . . . . . .
4.2.2 Recovery Measures . . . . . . . . . . . . . . . .
4.2.3 Associating Exceptions and Handlers . . . . . .
4.2.4 Fault Assumptions . . . . . . . . . . . . . . . .
Exceptional Service Outcomes . . . . . . . . . . . . . .
Exceptional Modes of Operation . . . . . . . . . . . .
4.4.1 Kinds of Services . . . . . . . . . . . . . . . . .
4.4.2 Kinds of Operation Modes . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Dependability in Use Cases . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Integrating Exception Handling in Use Cases . . . . . . . . .
5.1.2 Representing Exceptions and Handlers in Textual Use Cases .
5.1.3 Representing Exceptions and Handlers in Use Case Diagrams
5.1.4 Representing Degraded Outcomes in Use Cases . . . . . . . .
Dependability in Activity Diagrams . . . . . . . . . . . . . . . . . . .
5.2.1 Integrating Exceptions and Handlers in Activity Diagrams . .
5.2.2 Representing Exceptions and Handlers in Activity Diagrams .
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.3
5.4
5.5
5.6
6
DREP: A Dependability-Oriented Requirements Engineering Process . . . . . .
6.1
6.2
6.3
6.4
7
5.2.3 Representing Degraded Outcomes in Activity Diagrams . . . . .
Dependability in Interaction Models . . . . . . . . . . . . . . . . . . . .
5.3.1 Integrating Exceptions and Handlers in Interaction Models . . . .
5.3.2 Representing Exceptions and Handlers in Interaction Models . . .
Requirements Metamodels . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Textual Use Case Metamodel . . . . . . . . . . . . . . . . . . . .
5.4.2 Exceptional Use Case Diagram Metamodel . . . . . . . . . . . . .
5.4.3 Activity Diagram Metamodel . . . . . . . . . . . . . . . . . . . .
5.4.4 Communication Diagram Metamodel . . . . . . . . . . . . . . . .
Case Study: Elevator Control System . . . . . . . . . . . . . . . . . . . .
5.5.1 Elevator Arrival Subsystem: Standard Use Cases . . . . . . . . .
5.5.2 Elevator Arrival Subsystem: Exceptional Use Cases . . . . . . . .
5.5.3 Elevator Arrival Subsystem: Exceptional Use Case Diagram . . .
5.5.4 Elevator Arrival Subsystem: Degraded Outcomes . . . . . . . . .
5.5.5 Elevator Arrival Subsystem: Activity Diagrams . . . . . . . . . .
5.5.6 Elevator Arrival Subsystem: Exceptional Communication Diagram
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Dependability-Oriented Requirements Engineering Process
6.1.1 Requirements Elicitation and Discovery . . . . . . . . .
6.1.2 Requirements Definition and Specification . . . . . . .
6.1.3 Dependability Assessment . . . . . . . . . . . . . . . .
6.1.4 Dependability-based Refinement . . . . . . . . . . . . .
6.1.5 Requirements Summary and Documentation . . . . . .
DREP and Model-Driven Engineering . . . . . . . . . . . . .
6.2.1 Tool Support . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 Discussion and Limitations . . . . . . . . . . . . . . . .
Case Study: Elevator Control System . . . . . . . . . . . . . .
6.3.1 Requirements Elicitation and Discovery . . . . . . . . .
6.3.2 Requirements Definition and Specification . . . . . . .
6.3.3 Requirements Analysis . . . . . . . . . . . . . . . . . .
6.3.4 Dependability-based Refinement and Iteration . . . . .
6.3.5 Requirements Summary . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
58
58
60
61
61
63
63
65
66
67
67
69
69
71
73
75
79
80
80
86
89
90
92
94
96
97
97
98
99
104
105
108
111
Dependability Requirements Assessment Method . . . . . . . . . . . . . . . . . 114
7.1
Model-Driven Dependability Assessment of Requirements . . . . . . . . 115
7.1.1 Dependability Assessment Methods . . . . . . . . . . . . . . . . . 115
7.1.2 Assessment using DA-Charts . . . . . . . . . . . . . . . . . . . . . 116
ix
7.2
7.3
7.4
7.5
7.6
7.7
8
Probabilities in Requirements Models . . . . . . . . . . . . . . . . . . . .
DA-Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 Statecharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.2 Extending Statecharts with Probabilities . . . . . . . . . . . . . .
7.3.3 Mapping Exceptional Use Cases to DA-Charts . . . . . . . . . . .
7.3.4 Other Features of DA-Charts . . . . . . . . . . . . . . . . . . . .
Tool Support for DA-Charts . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1 AToM3 : A Tool for Multiformalism and MetaModelling . . . . . .
7.4.2 DA-Charts Implementation in AToM3 . . . . . . . . . . . . . . .
7.4.3 Probability Analysis of DA-Charts in AToM3 . . . . . . . . . . .
7.4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dependability Analysis with DA-Charts . . . . . . . . . . . . . . . . . .
7.5.1 Degraded Outcomes in DA-Charts . . . . . . . . . . . . . . . . .
7.5.2 Safety Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.3 Reliability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.4 Markov Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Case study: Elevator Control System . . . . . . . . . . . . . . . . . . . .
7.6.1 Analyzing Exceptions in the Elevator Arrival Use Case . . . . . .
7.6.2 The DA-Charts Model of the Basic Elevator Arrival System with
Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.3 The Markov Chain of the Basic Elevator Arrival System with
Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.4 Evaluating Dependability of the System . . . . . . . . . . . . . .
7.6.5 Refining the Elevator Arrival Use Case . . . . . . . . . . . . . . .
7.6.6 The DA-Charts Model of the Safety-Enhanced Elevator Arrival
Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.7 Refining the Elevator Arrival Use Case to Improve Reliability . .
7.6.8 The DA-Charts Model of the Reliability-Enhanced Elevator
Arrival Use Case . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.9 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
117
119
119
119
121
122
123
123
124
124
126
128
129
129
129
129
130
130
131
132
133
134
134
136
136
137
139
Model Transformations in DREP . . . . . . . . . . . . . . . . . . . . . . . . . . 141
8.1
8.2
8.3
Model Transformation: Characteristics . . . . . . . . . . . . . . . . . . . 142
Model Transformation: From Exceptional Use Cases to Activity Diagrams143
8.2.1 The Source Model: Exceptional Use Cases . . . . . . . . . . . . . 143
8.2.2 The Target Model: DREP Activity Diagrams . . . . . . . . . . . 144
8.2.3 Transformation Definition . . . . . . . . . . . . . . . . . . . . . . 144
Model Transformation: From Exceptional Use Cases to DA-Charts . . . 150
8.3.1 The Source Model: Exceptional Use Cases . . . . . . . . . . . . . 150
x
8.4
8.5
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
150
150
154
155
155
155
155
Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
9.1
9.2
9.3
9.4
10
8.3.2 The Target Model: DA-Charts .
8.3.3 Transformation Definition . . .
Case Study: Elevator Control System .
8.4.1 ECS: Use Case Models . . . . .
8.4.2 ECS: Activity Diagrams . . . .
8.4.3 ECS: DA-Chart Models . . . .
Summary . . . . . . . . . . . . . . . .
Elevator Control System . . . . . . . . . . . . . . . .
9.1.1 Problem Statement . . . . . . . . . . . . . . .
9.1.2 Requirements Development . . . . . . . . . .
407 ETR System . . . . . . . . . . . . . . . . . . . .
9.2.1 Problem Statement . . . . . . . . . . . . . . .
9.2.2 Requirements Elicitation and Discovery . . . .
9.2.3 Requirements Definition and Specification . .
9.2.4 Requirements Analysis . . . . . . . . . . . . .
9.2.5 Dependability-based Refinement and Iteration
9.2.6 Requirements Summary . . . . . . . . . . . .
Car Crash Crisis Management System . . . . . . . .
9.3.1 Problem Statement . . . . . . . . . . . . . . .
9.3.2 Requirements Development . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
158
159
159
159
160
161
163
166
166
169
169
169
172
175
Evaluation of Proposed Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
10.1
10.2
10.3
10.4
Methodology . . . . . . . . . . . . . . . . . . . . .
Elevator Control System(ECS) Case Study . . . .
10.2.1 Theory . . . . . . . . . . . . . . . . . . . . .
10.2.2 Study Design . . . . . . . . . . . . . . . . .
10.2.3 Results . . . . . . . . . . . . . . . . . . . . .
10.2.4 Validity . . . . . . . . . . . . . . . . . . . .
407 Express Toll Route (ETR) System Case Study
10.3.1 Theory . . . . . . . . . . . . . . . . . . . . .
10.3.2 Study Design . . . . . . . . . . . . . . . . .
10.3.3 Results . . . . . . . . . . . . . . . . . . . . .
10.3.4 Validity . . . . . . . . . . . . . . . . . . . .
Crisis Management System (CMS) Case Study . .
10.4.1 Theory . . . . . . . . . . . . . . . . . . . . .
10.4.2 Study Design . . . . . . . . . . . . . . . . .
10.4.3 Results . . . . . . . . . . . . . . . . . . . . .
xi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
177
178
178
179
180
183
183
184
184
185
188
189
190
190
191
10.5
10.6
11
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
11.1
11.2
11.3
11.4
11.5
12
10.4.4 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
e-Health Insulin Pump Web Information System Case Study . . . . . . 192
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Dependability in Requirements Models . . . . . . . . .
11.1.1 Non-Functional Requirements . . . . . . . . . .
11.1.2 Fault Tolerance and Exception Handling . . . .
11.1.3 Exceptional Outcomes and Modes of Operation
11.1.4 Review . . . . . . . . . . . . . . . . . . . . . . .
Dependability-Oriented Requirements Engineering . .
11.2.1 Use-Case Based Approaches . . . . . . . . . . .
11.2.2 Goal-Oriented Approaches . . . . . . . . . . . .
11.2.3 Failure and Hazard-Driven Approaches . . . . .
11.2.4 Other Approaches . . . . . . . . . . . . . . . . .
11.2.5 Review . . . . . . . . . . . . . . . . . . . . . . .
Model-based Dependability Assessment . . . . . . . .
11.3.1 Probabilistic Statecharts . . . . . . . . . . . . .
11.3.2 Dependability Analysis . . . . . . . . . . . . . .
11.3.3 Model Checking . . . . . . . . . . . . . . . . . .
11.3.4 Review . . . . . . . . . . . . . . . . . . . . . . .
Model Transformation . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
195
196
198
200
202
202
202
205
205
207
209
209
210
210
211
212
212
214
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
12.1
12.2
12.3
Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Critical Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
12.2.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
12.2.2 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
12.2.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
12.3.1 Design Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
12.3.2 Idealized Fault-Tolerant Components in Requirements Engineering 221
12.3.3 Priorities in Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 223
12.3.4 Formalizing Reliability and Safety . . . . . . . . . . . . . . . . . . 225
12.3.5 Integrating Timeliness Concerns . . . . . . . . . . . . . . . . . . . 226
12.3.6 Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
xii
A
Case Study Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
A.1
A.2
A.3
ECS Case Study . . . . . . . . . . . . .
A.1.1 DREP Use Case Model . . . . . .
A.1.2 DREP Activity Diagrams . . . .
A.1.3 DREP Exception Table . . . . . .
A.1.4 DREP Mode Table . . . . . . . .
A.1.5 DREP Communication Diagram .
407 ETR Case Study . . . . . . . . . . .
A.2.1 DREP Use Case Model . . . . . .
A.2.2 DREP Activity Diagrams . . . .
A.2.3 DREP Exception Table . . . . . .
A.2.4 DREP Mode Table . . . . . . . .
A.2.5 DREP Communication Diagram .
Crisis Management System Case Study .
A.3.1 DREP Use Case Model . . . . . .
A.3.2 DREP Activity Diagrams . . . .
A.3.3 DREP Exception Table . . . . . .
A.3.4 DREP Mode Table . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
228
228
228
229
229
230
238
238
243
243
243
243
250
250
263
264
264
B
DREP Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
C
ANZAC ECS Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
D
Non-functional Requirement (NFR) List . . . . . . . . . . . . . . . . . . . . . . 271
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
xiii
LIST OF TABLES
Table
page
1–1 Relative Cost to Repair a Defect at Different Lifecycle Phases (Adapted
from Fig. 1-2 [127]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2–1 Formal Specification Methods . . . . . . . . . . . . . . . . . . . . . . . . . .
18
5–1 Use Case Diagrams: Summary of Notations
. . . . . . . . . . . . . . . . . .
76
5–2 Activity Diagrams: Summary of Notations . . . . . . . . . . . . . . . . . . .
77
5–3 Communication Diagrams: Summary of Notations . . . . . . . . . . . . . . .
78
6–1 ECS: Exception Summary Table . . . . . . . . . . . . . . . . . . . . . . . . . 110
9–1 Summary of Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
10–1 Claims Addressed by Case Studies . . . . . . . . . . . . . . . . . . . . . . . . 176
10–2 Characteristics of Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . 176
10–3 CMS: Validation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
12–1 ECS: Priority Table 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
12–2 ECS: Priority Table 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
12–3 ECS: Priority Table 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
A–1 ECS: DREP Mode Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
A–2 407 ETR System: Exception Table . . . . . . . . . . . . . . . . . . . . . . . 248
A–3 407 ETR: DREP Mode Table . . . . . . . . . . . . . . . . . . . . . . . . . . 248
A–4 Car Crash CMS: Context-Affecting Exceptions Summary Table . . . . . . . 264
A–5 Car Crash CMS: Service-Related Exceptions Summary Table . . . . . . . . . 265
xiv
A–6 Car Crash CMS: Service-Related Exceptions in Handlers Summary Table . . 266
A–7 CMS: DREP Mode Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
xv
LIST OF FIGURES
Figure
page
2–1 Waterfall Process Model (Software Development Life Cycle) . . . . . . . . .
11
2–2 The Modelling Spectrum (Reproduced with kind permission from Springer
Science+Business Media: [33] Fig. 1) . . . . . . . . . . . . . . . . . . . .
12
2–3 Requirements Engineering Process Model . . . . . . . . . . . . . . . . . . .
17
2–4 The Dependability Tree (Reproduced from Fig. 2.1 [12] with permission
c 2004 IEEE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
c 2004
2–5 The Fault Tolerance Tree (Reproduced from [124] with permission IEEE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3–1 UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3–2 UP Requirements MetaModel (Adapted from Fig 3.3 [8]) . . . . . . . . . . .
32
3–3 Fondue Models (Reprinted from Fig. 1 [206]) with permission from Elsevier) 32
3–4 DREP and UP Requirements MetaModel . . . . . . . . . . . . . . . . . . .
34
3–5 DREP and Fondue Models
. . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5–1 Exceptional Use Case Template . . . . . . . . . . . . . . . . . . . . . . . . .
53
5–2 Handler Use Case Template . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5–3 Standard Use Case Diagram Template . . . . . . . . . . . . . . . . . . . . .
55
5–4 Extended Use Case Diagram Template . . . . . . . . . . . . . . . . . . . . .
55
5–5 Elements of Activity Diagrams . . . . . . . . . . . . . . . . . . . . . . . . .
57
5–6 Textual Use Case Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5–7 Exceptional Use Case Metamodel . . . . . . . . . . . . . . . . . . . . . . . .
64
xvi
5–8 Extended Use Case UML 2.0 Metamodel . . . . . . . . . . . . . . . . . . . .
65
5–9 Communication Diagram Meta Model: Adapted Model Elements . . . . . .
66
5–10 ECS: Standard Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . .
68
5–11 ECS: Elevator Arrival Use Case . . . . . . . . . . . . . . . . . . . . . . . . .
68
5–12 ECS: ElevatorArrival Exceptional Use Case . . . . . . . . . . . . . . . . . .
69
5–13 ECS: Partial Exceptional Use Case Diagram . . . . . . . . . . . . . . . . . .
70
5–14 ECS: Stop Motor Activity Diagram . . . . . . . . . . . . . . . . . . . . . . .
71
5–15 ECS: Elevator Arrival Activity Diagram . . . . . . . . . . . . . . . . . . . .
72
5–16 ECS: Partial Exceptional Interaction Diagram . . . . . . . . . . . . . . . . .
74
6–1 Task Structure of DREP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
6–2 DREP and Modelling Formalisms: Summary . . . . . . . . . . . . . . . . .
94
6–3 DREP and Modelling Formalisms: Alternate Task Structure . . . . . . . . .
96
6–4 ECS: TakeElevator Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6–5 ECS: CallElevator Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6–6 ECS: RideElevator Use Case
. . . . . . . . . . . . . . . . . . . . . . . . . . 101
6–7 ECS: UserEmergency and ReturnToGroundFloor Handler Use Case . . . . . 102
6–8 ECS: Annotated ElevatorArrival Use Case . . . . . . . . . . . . . . . . . . . 103
6–9 ECS: Annotated RideElevator Use Case . . . . . . . . . . . . . . . . . . . . 104
6–10 RedirectElevator Handler Use Case . . . . . . . . . . . . . . . . . . . . . . . 106
6–11 ECS: DoorAlert Handler Use Case . . . . . . . . . . . . . . . . . . . . . . . 106
6–12 ECS: OverweightAlert and EmergencyBrake Handler Use Cases . . . . . . . 107
6–13 ECS: CallElevatorOperator Handler
. . . . . . . . . . . . . . . . . . . . . . 108
6–14 ECS: Exceptional Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . 109
6–15 ECS: Exceptional Interaction Diagram . . . . . . . . . . . . . . . . . . . . . 112
7–1 Model-Driven Process for Assessment and Refinement of Use Cases . . . . . 118
xvii
7–2 Example DA-Chart Model in AToM3 . . . . . . . . . . . . . . . . . . . . . . 127
7–3 ECS: Refined ElevatorArrival Use Case . . . . . . . . . . . . . . . . . . . . 131
7–4 ECS: DA-Chart Model of the Elevator Arrival Use Case with Failures . . . 132
7–5 ECS: Markov Chain of the Elevator Arrival Use Case with Failures . . . . . 133
7–6 ECS: EmergencyBrake Handler Use Case . . . . . . . . . . . . . . . . . . . . 134
7–7 ECS: DA-Chart Model of the Elevator Arrival System with Failures and
Safety Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7–8 ECS: RetryDoor Handler Use Case . . . . . . . . . . . . . . . . . . . . . . . 136
7–9 ECS: DA-Chart Model of the Elevator Arrival System with Failures and
Reliability Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7–10 ECS: DA-Chart Model of the Elevator Arrival System with Failures and
Dependability Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7–11 ECS: Hierarchical DA-Chart Model of Ride Elevator . . . . . . . . . . . . . 139
8–1 Mapping a use case model to an activity model . . . . . . . . . . . . . . . . 145
9–1 407 ETR Gantry and Transponder (Reproduced from [67][179])
. . . . . . 161
9–2 407 ETR: Standard Use Case Diagram . . . . . . . . . . . . . . . . . . . . . 162
9–3 407 ETR: TakeHighway Use Case . . . . . . . . . . . . . . . . . . . . . . . . 164
9–4 407 ETR: ProcessRegisteredVehicle Use Case . . . . . . . . . . . . . . . . . 165
9–5 407 ETR: ActivateBarrier Handler Use Case
. . . . . . . . . . . . . . . . . 166
9–6 Updated TakeHighway Use Case . . . . . . . . . . . . . . . . . . . . . . . . 167
10–1 ECS: Validation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
10–2 Validation Results: Standard Use Cases versus DREP . . . . . . . . . . . . 187
10–3 Validation Results: Exceptional Use Cases versus DREP . . . . . . . . . . . 188
12–1 Idealized Fault-Tolerant Component . . . . . . . . . . . . . . . . . . . . . . 221
12–2 Idealized Fault-Tolerant Component in Requirements Engineering . . . . . . 223
A–1 ECS: Take Elevator Activity Diagram . . . . . . . . . . . . . . . . . . . . . 229
xviii
A–2 ECS: Call Elevator Activity Diagram . . . . . . . . . . . . . . . . . . . . . . 230
A–3 ECS: Ride Elevator Activity Diagram . . . . . . . . . . . . . . . . . . . . . 231
A–4 ECS: Close Door Subactivity . . . . . . . . . . . . . . . . . . . . . . . . . . 231
A–5 ECS: Elevator Arrival Activity Diagram . . . . . . . . . . . . . . . . . . . . 232
A–6 ECS: Call Request Subactivity . . . . . . . . . . . . . . . . . . . . . . . . . 233
A–7 ECS: Ride Request Subactivity . . . . . . . . . . . . . . . . . . . . . . . . . 233
A–8 ECS: Start Motor Subactivity . . . . . . . . . . . . . . . . . . . . . . . . . . 233
A–9 ECS: Stop Motor Subactivity . . . . . . . . . . . . . . . . . . . . . . . . . . 233
A–10ECS: Approaching Destination Floor Subactivity . . . . . . . . . . . . . . . 234
A–11ECS: Open Door Subactivity . . . . . . . . . . . . . . . . . . . . . . . . . . 234
A–12ECS: Emergency Brake Handler Activity Diagram . . . . . . . . . . . . . . 234
A–13ECS: User Emergency Activity Diagram . . . . . . . . . . . . . . . . . . . . 234
A–14ECS: Door Alert Handler Activity Diagram . . . . . . . . . . . . . . . . . . 235
A–15ECS: Overweight Alert Handler Activity Diagram . . . . . . . . . . . . . . . 236
A–16ECS: Return To Ground Floor Handler Activity Diagram . . . . . . . . . . 237
A–17407 ETR: Exceptional Use Case Diagram . . . . . . . . . . . . . . . . . . . 243
A–18ETR: Take Highway Activity Diagram . . . . . . . . . . . . . . . . . . . . . 244
A–19ETR: Process Registered Vehicle Activity Diagram . . . . . . . . . . . . . . 245
A–20ETR: Process Unregistered Vehicle Activity Diagram . . . . . . . . . . . . . 246
A–21ETR: Send Green Signal SubActivity . . . . . . . . . . . . . . . . . . . . . . 247
A–22ETR: Activate Barriers Activity Diagram . . . . . . . . . . . . . . . . . . . 247
A–23ETR: Warn Client Activity Diagram . . . . . . . . . . . . . . . . . . . . . . 247
A–24407 ETR: DREP Communication Diagram . . . . . . . . . . . . . . . . . . . 249
A–25Car Crash CMS: Standard Use Case Diagram . . . . . . . . . . . . . . . . . 250
A–26Car Crash Case: Exceptional Use Case Diagram . . . . . . . . . . . . . . . 262
xix
A–27Car Crash Case Study: Assign Internal Resource Activity Diagram . . . . . 263
xx
CHAPTER 1
Introduction
Software and cathedrals are much the same - first we build them then we pray!
- Sam Redwine, Jr.
1.1
Motivation
Complex computer systems are increasingly built for highly critical tasks in domains
spanning from military and aerospace to industrial and commercial. Failures of such systems may have severe consequences ranging from loss of business opportunities, physical
damage, to loss of human lives. Systems with such responsibilities should be highly dependable. On the software analyst’s part, this involves acknowledging that many exceptional
situations may arise during the execution of an application: external devices that the system needs to provide a service may fail, or communication links may break down, or users
might not obey to the specified system interaction protocol. Foreseeing measures to handle
such situations is essential to maintain system reliability and safety. A dependable software
development process should lead the developer to discover these exceptional situations, and
then define precisely how the system should react.
When using a standard software development process to develop systems, there is no
guarantee that such situations are considered during the development. Whether the system
can handle these situations or not depends highly on the imagination and experience of
the developers. In addition, even if the application can actually deal with these special
situtations, the particular way that the developer chose to address that situation might
not be the one that a typical user of the system would expect if it was not explicitly agreed
upon and documented in the requirements. As a result, the final application might not
1
1.1. Motivation
function correctly in all possible situations or react in unexpected ways. This can at best
annoy or confuse the user, but can also have more severe repercussions.
Numerous accidents and incidents have taken place over the last decades that show
us that the cause behind many failed projects is primarily the failure to “build the right
thing”. Significant software failures that have been reported, some of which are listed as
follows. [169] discusses other cases of software failures.
• An Arian 5 rocket launched by the European Space Agency exploded just forty
seconds after take-off causing loss of lives.
• Software flaws in Therac-25, a cancer treatment system, caused radiation overdoses
which lead to the death of several patients.
• The Denver airport faced problems with its computerized baggage system which
delayed its opening by several months. The failures persisted which reportedly lead
to maintenance costs of several million a year. The project was later abandoned.
• A flaw in the Apollo 11 software made moons gravity repulsive rather than attractive.
• The AT&T system suffered a nine hour nation-wide blockade. The switch experienced
abnormal behaviour due to flaws in the recovery recognition software and network
design effects propagated to all switches.
• The Northeast blackout of 2003 affecting cities in US and Canada lead to fatal consequences. The power outage was reportedly caused by a software bug in General
Electric Energy’s energy management system.
• Radiation safety door of a nuclear power plant in the UK opened accidentally.
The above are all examples of software failures caused by errors in the requirements
specification or design. On the other hand, the on-board shuttle group of the Lockheed
Martin Corps space mission systems division set an excellent example by creating bug-free
software for a space shuttle that never crashes or needs to be re-booted. Fishman gives an
account of how “they write the right stuff” in [71]. “The answer is, it’s the process. The
group’s most important creation is not the perfect software they write – it’s the process
they invented that writes the perfect software.” He reports that about one third of software
development happens in this group before a line of code is written. No coding is done before
the specification and design are complete and error-free.
Errors made at the requirements stage are very expensive to fix later. According to
[51], it is 10 to 20 times more costly to repair defects at the design and coding phases
than at the requirements stage (as shown in Table 1–1). It might also be that the stated
requirements are implemented correctly, but the system developed is not what the customer
2
1.1. Motivation
wants. Hence, it is essential to determine and establish the precise expectations of the
customer about the proposed system.
Table 1–1: Relative Cost to Repair a Defect at Different Lifecycle Phases (Adapted from
Fig. 1-2 [127])
Requirements
Design
Coding
Unit Test
Acceptance Test
Maintenance
1-2
5
10
20
50
200
In 1994, a root-case analysis carried out of the software defects of the Voyager and
Galileo spacecraft show that “half of the system defects found during integration were due
to requirements” and “more than half of the requirements defects discovered were due to
tacit requirements, those that had not been written down” [15]. The report also stated
that a requirements defect is 130 times more costly to fix at the integration phase than
it is if discovered and addressed at the requirements development phase. The cost of not
discovering errors early on greatly multiplies the cost of the project.
In the context of building fault-tolerant systems, Romanovsky [181] advocates “to
place a special emphasis on fault tolerance software engineering which would provide a set
of methods, techniques, models, and tools that would exactly fit application domains, fault
assumptions and system requirements, and support disciplined and rigorous fault tolerance
throughout all phases of the life cycle”. Pelliccione et al. [166] discuss software engineering
best practices for fault-tolerant systems.
The work in this thesis relates three major disciplines: software engineering, dependability, and modelling. We believe that the correct interleaving of these disciplines is
necessary in order to develop dependable systems. Every phase in software development
needs to be enriched with phase-specific dependability means. In our work, we focus on
addressing reliability and safety attributes and means at the early stages of software development. Requirements are the foundation of software systems. At this level, it is essential
to clearly identify and precisely specify what we expect in terms of dependability. While
attaining a perfect software like the on-board shuttle team is a daunting task, we need
to define the level of dependability that is deemed satisfactory. This is similar to what is
3
1.2. Research Problem
proposed by Shaw who coined the term everyday dependability [190] [192] which she associates with software used for everyday activities. For such software, she suggests developing
cost-effective solutions and attempting to attain sufficient correctness or in other words
ensure that the software is good enough for intended use. Sufficient correctness is defined
as “the degree to which a system must be dependable in order to service the purpose its
user intends, and to do so well enough to satisfy the current needs and expectations of
those users” [191].
While several UML-based methods exist that target various application domains, there
is very limited support available for the development of dependable or fault-tolerant systems. Methods, tools, and profiles have been proposed that addresses quality-of-service,
performance, and fault-tolerance but the need for a dependability-oriented requirements
development process still remains.
1.2
Research Problem
Our job is to give the client, on time and on cost, not what he wants, but what
he never dreamed he wanted; and when he gets it, he recognizes it as something
he wanted all the time. - Dewys Lasdon [168].
Our research hypothesis is stated as follows: A requirements engineering process
catered to dependable systems can help developers create a more complete specification, and
ultimately increase the ability of a system to avoid service failures that are more frequent
and severe than is acceptable to the user.
According to the classification by Cheng and Atlee [36], the research for this thesis is
conducted by applying a combination of two research strategies: engineering and domainspecific. Engineering focuses on development of processes or strategies that allow research
solutions to be applied in a more effective manner (in terms of cost and ease of use). The
domain-specific strategy is used to develop new techniques and methods that apply to a
specific problem domain.
The goal of this Ph.D. thesis is to show how to address the concern of dependability
at the requirements engineering phase of software development methods in general, and to
demonstrate the ideas by making concrete suggestions of how to integrate fault prevention
and fault tolerance into a requirements development method.
4
1.3. Scope
At the requirements engineering stage, integration of dependability involves identifying the need for fault prevention and tolerance, finding the places where it is needed, and
specifying what degree of fault tolerance must be achieved. Important issues that must be
addressed by the proposed approach comprise: specifying the computational model for all
actors, i.e. all entities external to the system that interact with the system under development; quantizing quality of service provided in spite of faults, i.e. specifying minimum
functionality with the use of degraded modes, response times, etc.; specifying user-perceived
dependability requirements (e.g. associating them with use cases); and mapping the discovered dependability requirements to every functionality that the system must provide.
To achieve the above, we propose a model-driven dependability-oriented requirements engineering process that systematically guides the developer from requirements elicitation
with use cases towards establishing a precise, complete, and coherent specification of the
system under development in form of several behavioural UML models.
1.3
Scope
In this thesis, our target domain includes software systems that are reactive and are
required to be dependable.
Reactive systems are “systems that change its actions, outputs and conditions/status
in response to stimuli from within or outside it, and whose role is to maintain an ongoing
interaction with their environment rather than produce some final value upon termination” [89]. Typical examples of reactive systems: air traffic control system, automated
teller machine system, and elevator control system. Data-intensive systems (e.g., data
management systems) or transformational systems (e.g., batch processes, compilers, media
stream filters, numerical mathematics applications) are not classified as reactive systems.
Systems are developed to satisfy a set of requirements that meet a need. A requirement
that is important in some systems is that they be highly dependable. Dependable systems
aim to continue delivery of services despite the presence of hardware or software faults in
the system. Such systems are often also referred to as high assurance systems, trustworthy
systems, resilient systems, survivable systems, or fault-tolerant systems depending on the
research community and the concerns addressed by the system.
By dependable systems, we refer to systems which do not necessarily have to be
mission-critical systems like a flight control system, a missile defense system, or a nuclear
power plant system. Reactive systems in a less critical domain, such as a drink vending
5
1.4. Thesis Contributions
machine, pump control system, gas station system, microwave controllers, home security
systems, banking systems, or internet-based systems (such as auction systems), in which
notions of safety and/or reliability need to be considered are very much part of our target
domain.
We do not claim to cover critical systems that require safety certification. However
as a starting point, we do recommend defining safety concerns according to the DO-178B
safety standard with the use of safety integrity levels. This allows the safety standard to
be mapped on to later development phases.
As stated by Harel in [90], “reactive systems differ from transformational systems, and
require different approaches to their specification. An essential element in the specification
of reactive systems is the need for a clear and rigorous behavioral description, to serve as
the backbone of development from requirements specification all the way to user documentation.” To this aim, we propose a requirements engineering methodology specifically for
dependable reactive systems.
1.4
Thesis Contributions
The main contribution of this thesis is a requirements development method that sys-
tematically guides developers in creating more dependable systems.
The most significant contributions are summarized below:
• a requirements development process for eliciting, modelling, analyzing, and specifying
dependability requirements of reactive systems. This includes:
– a technique for eliciting and defining safety and reliability requirements using
extended use cases, together with a notation for representing exceptions and
handlers in use case diagrams
– a technique for requirements modelling using dependability-oriented modelling
formalisms such as activity diagrams and interaction diagrams
– a well-defined process that helps the developer to refine and transform the use
cases that describe the discovered functionality and dependability requirements
to a precise system specification in form of behavioral UML models
– a method for probabilistically analyzing the specification to determine if the
reliability and safety requirements are achievable
– a method for mapping use case models to dependability assessment models and
specification models
6
1.5. Published Articles
• tool support for automatic dependability assessment of reliability and safety
1.5
Published Articles
Some of the work carried out as part of this thesis have been published in the following
journal and conference articles.
1. S. Mustafiz, J. Kienzle, and H. Vangheluwe, “Model Transformation of DependabilityFocused Requirements Models”, International Workshop on Modeling in Software
Engineering (MiSE 2009), 31st International Conference on Software Engineering
(ICSE 2009), Vancouver, May 2009. IEEE Computer Society, pp. 50-55, 2009.
2. S. Mustafiz and J. Kienzle, “DREP: A Requirements Engineering Process for Dependable Reactive Systems”, In Methods, Models, and Tools for Fault Tolerance,
M. Butler, C. Jones, A. Romanovsky, and E. Troubitsyna, Eds., LNCS 5454, pp.
220-250, Springer 2009.
3. S. Mustafiz, J. Kienzle, and A. Berlizev, “Addressing Degraded Outcomes and Exceptional Modes of Operation in Behavioural Models”, International Workshop on
Software Engineering for Resilient Systems (SERENE 2008), Newcastle, November
2008, ACM Press.
4. S. Mustafiz, X. Sun, J. Kienzle, and H. Vangheluwe, “Model-Driven Assessment of
System Dependability”, Journal of Software and Systems Modeling 7(4), pp. 487-502,
2008.
5. S. Mustafiz, X. Sun, J. Kienzle, and H. Vangheluwe, “Model-Driven Assessment of
Use Cases for Dependable Systems”, 9th International Conference on Model Driven
Engineering Languages and Systems (MoDELS / UML 2006), Genova, Italy, October
2006, LNCS 4199, pp. 558-573, Springer, 2006.
6. S. Mustafiz, “Dependability in Early Software Development Stages”, Doctoral Symposium, 14th IEEE International Requirements Engineering Conference (RE’06),
Minnesota, USA, September 2006.
7. A. Shui, S. Mustafiz, and J. Kienzle, “Exception-Aware Requirements Elicitation
with Use Cases”, Advanced Techniques in Exception Handling Techniques, LNCS
Vol. 4119, pp. 558-573, C. Dony, Ed. New York: Springer Berlin / Heidelberg, 2006.
8. S. Mustafiz and J. Kienzle, “Addressing Dependability in Use Case Driven Requirements Elicitation”, Technical Report SOCS-TR-2006-3, McGill University, Canada,
2006.
7
1.6. Thesis Roadmap
9. A. Shui, S. Mustafiz, J. Kienzle, and C. Dony, “Exceptional Use Cases”, 8th International Conference on Model Driven Engineering Languages and Systems (MoDELS
/ UML 2005), Jamaica, October 2005, LNCS 3713, pp. 568-583, Springer, 2005
10. S. Mustafiz and J. Kienzle, “A Survey of Software Development Approaches Addressing Dependability”, 4th International Workshop on Scientific Engineering of
Distributed Java Applications (FIDJI 2004), Luxembourg, November 2004, LNCS
3409, pp. 78-90, Springer, 2004.
1.6
Thesis Roadmap
This thesis is structured as follows:
Chapter 2 gives a background on the research areas related to this thesis. It overviews
software development, model-driven engineering and UML, requirements engineering,
and dependability attributes and means.
Chapter 3 discusses how the proposed approach fits in the model-driven software engineering context.
Chapter 4 introduces the basic terminology and and concepts that form the foundation
of the thesis. It describes exceptions and handlers in RE, and other dependabilityrelated concepts including exceptional service outcomes and exceptional modes of
operation.
Chapter 5 focuses on the integration and representation of dependability concerns in
requirements engineering models. It proposes extensions to the notations of UML
behavioural models (use cases, activity diagrams, and communication diagrams),
and illustrates the technique using a case study.
Chapter 6 describes the proposed requirements engineering process DREP, and illustrates the process using the Elevator Control System case study..
Chapter 7 presents our dependability assessment method, DA-Charts, and demonstrates
it using a case study.
Chapter 8 defines model transformation rules for mapping our use case-based requirements models to activity diagrams and DA-Charts.
Chapter 9 presents three case studies, the Elevator Control System, the 407 ETR System,
and the Crisis Management System, which are used to demonstrate and evaluate the
work in this thesis.
8
1.6. Thesis Roadmap
Chapter 10 outlines the case studies used to validate the proposed process and techniques, and discusses evaluation results.
Chapter 11 provides a overview of the literature related to this thesis.
Chapter 12 summarizes the contributions of this thesis, and discusses possible future
extensions of this research work.
This thesis also contains three appendices: Appendix A presents the DREP artifacts
of the three case studies discussed in Chapter 9. Appendix B includes the DREP checklist
that lists in order all phases and tasks in DREP. Appendix D provides the NFR taxanomy
defined by Chung et al. [37].
9
CHAPTER 2
Background
Over the last decades, the dependence on computer-based systems has increased remarkably. Since 1968, the development of software systems has been put under the software
engineering umbrella. New fields of research related to the development of complex and
high-quality software have been introduced, and gradually new techniques, methods, and
tools have become available that address the need for cost-effective and reliable software.
This chapter presents an overview of the research areas and disciplines related to this
thesis. Section 2.1 provides a background on software engineering (SE), Section 2.2 briefly
talks about model-driven engineering (MDE), and Section 2.3 goes on to discuss UML
and how it supports software development. Section 2.4 discusses requirements engineering (RE) and its activities. Section 2.5 gives an overview of non-functional requirements
(NFR). Section 2.6 elaborates on the attributes, threats, and means of a specific NFR,
namely dependability, and gives a background on fault tolerance and exception handling.
Section 2.7 summarizes the topics discussed in the chapter.
2.1
Software Engineering
Software engineering is “an engineering discipline which is concerned with all aspects
of software production from the early stages of system specification to maintaining the
system after it has gone into use” [202].
A software development process, also known as a software development methodology or
a software engineering process is defined in the literature based on the same principles.
“The software engineering process is the total set of software engineering activities needed to transform requirements into software.” - Watts S. Humprey [98]
10
2.2. Model Driven Engineering
Requirements
Design
Implementation
Testing
Maintenance
Figure 2–1: Waterfall Process Model (Software Development Life Cycle)
“A software process a set of activities whose goal is the development or evolution
of software.” - Ian Sommerville [202]
“A software development process is a structure imposed on the development of
a software product.” - Jim Arlow and Ila Neustadt [9]
A software development life cycle (SDLC) covers the development of a system from
the initiation to implementation, and is comprised of five major phases: requirements
analysis, design, implementation, testing, and maintenance. The life cycle continues with
the maintenance activity. This model is also commonly referred to as the traditional
waterfall model (illustrated in Fig. 2–1). Other variants of the waterfall model also exist
which support iterative development.
2.2
Model Driven Engineering
Software engineering has progressed from the use of traditional waterfall models to the
practice of model-driven engineering (MDE) [184] [222]. MDE is a software development
11
2.3. UML
Code
Visualization
Roundtrip
Engineering
Model-Centric
Model Only
Model
Model
Model
Model
Code
Code
Code
Code
What's a model?
The code is
the model
Code and
model coexist
The model is
the code
Code Only
Let's do
some design
Figure 2–2: The Modelling Spectrum (Reproduced with kind permission from Springer
Science+Business Media: [33] Fig. 1)
methodology and ideology that completely relies on the use of models to drive the development process. MDE is at a higher level of abstraction than third generation programming
languages. Modelling is used in a structured manner in order to address and minimize
system complexity, and the practice of model-transformation techniques is advocated in
conjunction to allow generation of downstream models and code. Reverse engineering using MDE is also possible by transforming the code model to a model at a higher level of
abstraction.
In Fig. 2–2, Brown [33] presents a modelling spectrum which aptly shows the different
views of models and modelling in software engineering.
Following the MDE paradigm, in 2001 OMG introduced the software design approach,
model-driven architecture (MDA) [82] [118], which supports MDE in an architecture-centric
form. The MDA approach is supported by OMG’s Unified Modelling Language (UML).
2.3
UML
The Unified Modelling Language (UML) [164] [183] is a general-purpose object-oriented
visual modelling language that offers numerous formalisms to allow developers to create
models during all phases of the development life cycle. It was first conceived in 1995,
and shortly after in 1997 became the first open, industry-standard object-oriented visual
modelling language [9].
12
2.3. UML
The language supports development of software-intensive systems, and hence covers a
wide range of application domains. UML does not provide a methodology but only a set
of diagrams with well-defined syntax and semantics. Booch [28] describes UML as being
composed of three building blocks.
• Things: the modelling elements (structural things are the nouns of a model and
behavioural things are the verbs of a model)
• Relationships: semantically link things
• Diagrams: visual representation of models providing a certain view
The things and relationships that describe a particular diagram are shown as a UML
meta-model [80], which is a model at a higher level of abstraction. Meta-modelling is
concerned with the “construction of a collection of concepts (things, terms, etc.) within
a certain domain” [221]. Similar to a software program that needs to conform to its
programming language grammar, a model is required to conform to its meta-model. The
meta-models, referred to as “meta-muddles” by France et al. [74], can become extremely
complex and difficult to understand, as is the case with the UML meta-model.
2.3.1
UML Diagrams
UML offers thirteen types of diagrams which are categorized as either structural or
behavioural, as illustrated in Fig. 3–1 [164]. Behavioural diagrams are used to describe
what a system will do, and how it will do it. Structural diagrams provide a view of the
static structure of a system.
We focus primarily on behavioural diagrams in this thesis, and briefly introduce the
seven diagrams in this section.
Use Case Diagram A use case [105][43] represents a scenario or a description of system
behaviour that is required to satisfy an user goal. Use case diagrams give a summarized
view of the use cases (scenarios and system goals), relationships among the goals, and
associations with external actors (systems, components, or human agents interacting with
the system). The diagrams are created based on detailed use case analysis, and are usually
complemented with textual use cases. Textual use cases are not part of the UML standard.
Activity Diagram Activity diagrams are mostly used to model the workflow behavior
of a system with emphasize on the sequence and conditions [164]. They allow to model
13
2.3. UML
activities, e.g. actions, calculations, sending or receiving messages, and the control flow
and object flow between these activities.
The activities coordinated by an activity diagram can be initiated because other activities finish executing, because objects and data become available, or because events occur
external to the flow. Activity diagrams can show activities that are conditional or parallel. Complex activities can be decomposed into several subactivities using hierarchical
structuring.
State Machine Diagram A finite state machine or finite state automaton is a model of
the behaviour of a system, and is composed of states, transitions between those states, and
actions [29]. If there exists only one possible transition between a pair of states, the state
machine is called a deterministic finite state automaton. Otherwise, the state machine is
non-determintic. State diagrams can be used to graphically represent finite state machines.
The statecharts formalism is an extension of Deterministic Finite State Automata
with hierarchy, orthogonality and broadcast communication [91]. It is a popular formalism
for the modelling of the behaviour of reactive systems. It has an intuitive yet rigourously
defined notation and semantics. It is the basis for documentation, analysis, simulation,
and code synthesis. Many variants of statecharts exist, including the one included in the
UML standard [164].
Interaction Diagram
UML defines four kinds of interaction diagrams: sequence diagrams,
communication diagram, interaction overview diagram, and timing diagram. Interaction
diagrams allow scenarios to be described at a different level of abstraction.
A sequence diagram illustrates a particular scenario of a use case, the requests from
external actors, and responses from the system, along with their order. Sequence diagrams
are based on simple notations and explicitly shows the sequence or time ordering of messages (time flows from top to bottom). Sequence diagrams can also be used to describe
message exchanges between objects as they happen at run-time within the system.
A communication diagram depicts a different view of interactions. It provides a birdseye view of a collection of collaborating entities, and clearly shows the relationships among
the entities. Unlike sequence diagrams, sequence numbers need to be used to model ordering of messages.
If sequence diagrams and communication diagrams are used to specify the behaviour
of the system at the requirements level, then the system can be considered as a black-box
14
2.4. Requirements Engineering
or a white-box in both diagrams. The system here is just a name for the actor that is being
analyzed.
Interaction Overview Diagrams provide a summarized view of complex interactions in
a system and clearly shows the control flow within the system. The formalism is based on
activity diagrams in which each node can refer to an activity, sequence diagram, or timing
diagram representing a set of interactions [164] [9].
Timing Diagrams are similar to sequence diagrams but the focus is given on the timing
aspects of interactions.
2.3.2
UML Profiles
A UML profile allows UML models to be adapted or customized for particular domains
or platforms. Many UML profiles have been defined to date, such as the SysML Profile [83],
the QoS and Fault Tolerance Profile [85], and the MARTE Profile [84].
Profiles are defined using three extensibility mechanisms [9].
• Constraints allow the addition of new conditions or rules to model elements by specifying a text string within braces ({ }). UML comes with a constraint language, the
Object Constraint Language (OCL) [163], that can be used to define constraints.
• Stereotypes allow the addition of new model elements based on existing elements to
the UML meta-model by specifying the steretype name within guillemets (<<...>>).
The semantics of the stereotype need to be defined. It is possible to associate the
stereotype with an icon, color, or texture to graphically visualize stereotyped model
elements in a domain-specific way.
• Tagged values makes it possible to attach new properties to model elements with
a comma-delimited list of keywords and values ({tag1=value1, tag2=value2, ...}).
Tagged values can be added to stereotypes when required.
Using the above mechanisms, domain-specific profiles can be created or adapted which
cater to all the software engineering activities, or specifically software design or requirements engineering.
2.4
Requirements Engineering
A requirement for a system is a description of a particular service or an operational
constraint. Systems are developed to satisfy a set of requirements that meet a need. In
15
2.4. Requirements Engineering
software systems, requirements can be broadly categorized as user requirements and system
requirements [203].
User requirements are abstract and high-level requirements that come from the customer.
System requirements are detailed and unambiguous descriptions based on the user requirements written by the designers of the system.
• Functional requirements define the behavior of the system, that is, the functions
and services expected of the system.
• Non-functional requirements address the constraints and qualities of the system
services (described further in the following section).
• Domain requirements are application-specific requirements which take into account the characteristics and constraints of the domain, and may be functional
or non-functional in nature.
Requirements engineering (RE) is a sub-discipline of software engineering which is
focused on the development and management of requirements, according to the many
definitions in literature including [225], [203], [104], [151], [31]. A well-accepted definition
by Zave [225] is as follows:
“Requirements engineering is the branch of software engineering concerned with
the real-world goals for, functions of, and constraints on software systems. It
is also concerned with the relationship of these factors to precise specifications
of software behavior, and to their evolution over time and across software families.”
Some authors, such as [203], state that the goal of requirements engineering is to create
and maintain a requirements document, otherwise known as a requirements specification
document, a systems requirements document, or a requirements definition document. Davis
refers to requirements engineering in [50] as “all activities up to but not including the
decomposition of the software into its actual architectural components”. Kovitz [122] aptly
describes the process as “the design of requirements”. During requirements development,
we essentially begin with the problem and domain knowledge and in a step by step manner
devise, detail, and formalize the requirements.
Similar to software development processes, a requirements development process can
be split into several phases including elicitation, analysis, specification, and validation (as
shown in Fig. 2–3). The analysis and specification tasks in RE can be said to be analogous
16
2.4. Requirements Engineering
Requirements Development
Elicitation
clarify
Analysis
re-evaluate
Specification
correct and
close gaps
rewrite
Validation
Management
Figure 2–3: Requirements Engineering Process Model
to the analysis and design phases. the former concerns the problem space whereas the
latter concerns the solution space.
Requirements management is the phase that addresses issues related to evolution of
requirements.
This thesis is primarily focused on requirements development.
2.4.1
Requirements Elicitation
Requirements elicitation is the activity in which the developers work with the customer on gathering requirements by discovering the system functionality, properties, and
qualities. The main focus here is on what requirements need to be gathered, from what
sources, and by what means. The type of information required is partially dependent on
the domain, and information gathered should describe the problem domain, allow deduction of problems requiring a solution, and address behavioural or structural constraints
imposed by the stakeholders. Therefore, the stakeholders are the primary source of information, and other sources might include system users, pre-exisitng systems, competitors’
17
2.4. Requirements Engineering
products, domain experts, and technical standards [31]. Examples of elicitation techniques
include developing domain knowledge, brainstorming, document inspection, interviewing,
questionnaires, observation, and use cases and scenarios.
2.4.2
Requirements Analysis
Requirements analysis, or modelling and analysis as it is referred to at times, is closelyrelated to elicitation and often interleaved with the first activity. The intention is to
process the information elicited to understand it, classify in various categories, and relate
the customer needs to possible software requirements. The requirements are documented
as structured description and/or models, and communicated to the development team. In
RE, the analysis and the modelling is focused on the problem domain and not the solution
domain, as is the case in the later stages of software development.
2.4.3
Requirements Specification
Requirements specification is concerned with structuring the customer input and derived requirements as written documents and diagrams. The requirements specification
document describes the required behaviour of the system to be developed, and is not to be
confused with the analysis document (which might be combined with the specification document). Bray [31] refers to the activity as the external design task where the “externally
visible appearance and behaviour of the system are invented”, as opposed to the internal
design that occurs further downstream in the software development life cycle.
The behaviour can be expressed by using semi-formal methods, such as the Unified
Modelling Language [164], or formal specification methods such as the methods listed in
Table 2–1.
Table 2–1: Formal Specification Methods
Input-Output Specification
Algebraic Specification
Model-Based Approach
Process Algebra Model
Extended State Machines
Temporal Logic
Hoare Logic (First Order Predicate Calculus) [95]
ADT [133], OBJ [75], Larch [87]
Z [204], B [1], VDM-SL [24], Petri Nets [170]
CCS [152], CSP [96], ACP [20]
Finite State Machine [29], Statecharts [90]
Amir Pnueli [173], Lotos [66]
18
2.5. Non-functional Requirements
2.4.4
Requirements Validation
Requirements validation involves communicating with the stakeholders to confirm that
the written requirements specification document is accurate and complete, and if necessary
to correct errors. It is not unusual to expect that errors might crop up during requirements
development. It is however essential to identify and minimize the errors before continuing
with the next phases of software development. Errors left uncovered or unresolved at this
stage are often the most expensive. Employing good engineering practices is just part of
the game. It is vital that the requirements document is checked for errors, and that the
customer is in complete agreement with the requirements defined in the document. Any
necessary negotiations have to take place at this point. Bray [31] provides a list of things
that must be confirmed to be correct:
“Is the description of the problem domain an accurate reflection of its properties?” “Are the requirements (the effects produced in the problem domain)
accurately recorded?” “Is the external design correct; will the invented behaviour of the new system produce the required effects?” “Is the specification
an accurate reflection on the intended external design?”
Validation techniques that are commonly used to carry out checks on the requirements
include reviews, prototyping, and test-case generation [203]. Often in conjunction with validation, verification can be performed using model checking [35] or model satisfiability [103]
techniques to ensure that the specification developed meets the requirements.
2.5
Non-functional Requirements
Non-functional requirements (NFR) introduce quality concerns to a system that must
be satisfied for the system to function and provide service under all circumstances. This
is particularly important for dependable/real-time/safety-critical systems. Attributes of
common concern for such systems include but are not limited to dependability, fault tolerance, availability, reliability, maintainability, safety, security, and timeliness. However, no
consensus exists on whether these should be treated as non-functional requirements. Glinz
reflects in [78] that even though the term non-functional requirement exists for more than
two decades now, there is still no consensus on the definition on the term or on the methods
that address it. Some researchers argue that as a result of this classification, important
19
2.6. Dependability
aspects like fault tolerance, are not addressed during the early phases. Some of the existing
definitions from the literature are listed here.
“The required overall attributes of the system, including portability, reliability,
efficiency, human engineering, testability, understandability, and modifiability.”
- Davis [51]
“Requirements which are not specifically concerned with the functionality of
a system. They place restrictions on the product being developed and the
development process, and they specify external constraints that the product
must meet.” - Kotonya and Sommerville [121]
“... describe the non-behavioural aspects of a system, capturing the properties
and constraints under which a system must operate.” - Anton [7]
[78] and [38] reviews the state of the art on NFRs and presents definitions and approaches
that have had major implications in the research area.
Non-functional requirements are also referred to as desirable attributes, non-behavioural
requirements, design constraints, quality attributes, goals, extra-functional requirements,
system interface requirements, user interface requirements, hardware characteristics, software quality, or more colloquially as –ilities and –ities [37] [145]. The classic non-functional
requirement knowledge-base defined by Lawrence Chung in [37] (presented in Appendix D)
gives a view of the broad scope of NFRs.
Dependability requirements are of primary concern in this thesis, and are discussed in
details in the following subsection.
2.6
Dependability
A requirement that is important in mission-critical, safety-critical, and even business-
critical systems is that they be highly dependable. A system is deemed dependable if its
“failures are judged sufficiently rare or insignificant” [124]. Many variants of the definition
of dependability exist in current literature, and there is no consensus of the meaning of the
term. Therefore, it is important to note that the work in this thesis is based the definition
of the term by Laprie and Avizienis [124][12].
As defined in [12], dependability is the ability of a system “to deliver service that
can justifiably be trusted”. Trust, in this context, is viewed as accepted dependence.
An alternate quantitative definition stated by the authors is: “dependability of a system
is the ability to avoid service failures that are more frequent and more severe than is
20
2.6. Dependability
Availability
Reliability
Safety
Attributes
Confidentiality
Integrity
Maintainability
Faults
Dependability
Threats
Errors
Failures
Fault Prevention
Fault Tolerance
Means
Fault Removal
Fault Forecasting
Figure 2–4: The Dependability Tree (Reproduced from Fig. 2.1 [12] with permission
c 2004 IEEE)
acceptable to the user(s)”. The authors associate dependability with several attributes.
They categorize the threats to dependability as failures, errors, and faults. The means
to attain dependability are grouped into four categories: fault prevention, fault tolerance,
fault removal, and fault forecasting. The concepts are shown in the dependability tree in
Fig. 2–4, and described in this section.
Dependability, survivability, and trustworthiness are three terms with very similar
concepts only used in different domains. The goals are similar however a broader scope of
threats is addressed by the dependability concept [11].
21
2.6. Dependability
2.6.1
Dependability Attributes
Reliability
The reliability of a system measures its aptitude to provide service and remain
operating as long as required. Reliability of a service is typically measured in probability of
success of the service, once requested, or else in mean time to failure [76]. If the average
time to complete a service is known, it is possible to convert between the two values.
Safety
The safety of a system is determined by the lack of catastrophic failures it un-
dergoes. The seriousness of the consequences of the failure on the environment can range
from benign to catastrophic. It can be measured in binary terms, as in, a system can be
safe or unsafe [76]. Seriousness of consequences can also be measured with a safety index.
For instance, the DO-178B standard [102] for civil aeronautics defines safety index values
from 0 to 4 with the following meaning:
0. Without effects;
1. Minor effects lead to upsetting the stakeholders or increasing the system workload;
2. Major effects lead to minor injuries of users, or minor physical damage or monetary
loss;
3. Dangerous effects lead to serious injuries of users, or serious physical damage or
monetary loss;
4. Catastrophic effects lead to loss of human lives, or destruction of the system.
Each application has different safety requirements. It is now up to the developer in
consultation with all the stakeholders to define the number of safety levels to consider, and
their exact definitions.
Availability
The availability of a system measures its ability to provide the expected
service whenever required. It can be calculated as
MT T F
M T T F +M T T R ,
where MTTF is the
mean time to failure and MTTR is the mean time to repair [76].
Confidentiality
Confidentiality is the non-occurrence of unauthorized disclosure of infor-
mation. The resource necessary to keep the information from being leaked out of the
system is a measure of the strength of confidentiality [76]. This is a security concern.
22
2.6. Dependability
Integrity
Integrity is the non-occurrence of the improper alteration of information. It is
related to the mean time to failure of a system and may be measured by the time and resources required for accessing a system without authorization. Integrity and confidentiality
can be grouped as the security attribute.
Maintainability
The maintainability of a system is its ability to avoid, detect, localize,
and correct faults. It can be measured as the MTTR (mean time to repair) together with
consideration of the repair philosophy. To achieve maintainability, fault tolerance means
can be utilized.
The dependability requirement varies with the target application, since a constraint
can be essential in one domain and not so much in others. In this thesis, we focus on the
reliability and safety attributes of dependability.
2.6.2
Dependability Threats
Dependability impairments include aspects of a system, which cause a deviation from
the normal behavior and entail loss of quality of service to some extent.
The IEEE TC FTD/IFIP WG10.4 definitions for the three impairments are as follows:
“A service failure is an event that occurs when the delivered service deviates
from correct service”.
“A service failure means that at least one (or more) external state of the system
deviates from the correct service state. The deviation is called an error”.
“The adjudged or hypothesized cause of an error is called a fault”.
This cause-effect relationship creates a fault-error-failure (FEF) chain, which is an
iterative process.
2.6.3
Dependability Means
The dependability means are broadly categorized into four areas: fault prevention,
fault tolerance, fault removal, and fault forecasting. These techniques are all related and
should be considered together during development.
Fault prevention and fault removal means aim to increase the reliability or the availability (in case of repairable systems) of systems. Fault forecasting means are used to
23
2.6. Dependability
predict reliability of software. But together with these, fault tolerance techniques are required to ensure acceptable levels of safety, reliability, and availability to take care of the
residual faults.
Fault Prevention Fault prevention involves taking measures to minimize the creation of
faults and hence avoiding them in the first place. There are two tasks that need to be
considered to reduce occurrence of faults.
• Measures need to be taken to act on the faults created by humans during the system
development lifecycle.
• Measures need to be taken to account for faults that originate due to degradation or
damage of the technology used.
Techniques used for fault avoidance/prevention include [175]:
• refinement of the users requirements iteratively – there should be communication
between the software engineer and the system engineer to avoid faults that are created
due to a bad specification,
• engineering of the software specification process,
• use of structured design and good software programming discipline,
• unambiguous coding,
• formal methods, and
• software reuse.
Fault prevention techniques aim to produce a system without any faults. But, this
ideal scenario cannot be achieved usually, and it is important to consider the faults that
might still exist in the system. This is where fault tolerance and fault removal means
should be applied.
Fault Removal
Fault removal involves detection, diagnosis and removal of faults. This is
considered at the software verification and validation phase.
• Fault detection tests for the presence of faults.
• Fault localization involves fault diagnosis and fault isolation and it identifies the fault
present in the system.
• Fault correction eliminates faults when possible.
Fault removal means include:
24
2.6. Dependability
• Software testing, a dynamic analysis technique, is a commonly used fault removal
technique.. But, presently exhaustive testing is not possible and hence new faults are
likely to crop up during the operation phase.
• Formal inspection is carried out before testing and entails checking the source code
for faults. The errors are then corrected and verified.
• Formal design proofs are mathematical means used for removal of faults.
Fault Forecasting
Fault forecasting involves estimating the presence of faults in software
and analyzing possible consequences of the faults.
Fault forecasting techniques include:
• Reliability estimation uses inference techniques on the failure statistics generated
during tests and operation to estimate the current reliability of the software [175].
• Reliability prediction uses software metrics and measures during software development to estimate the reliability of the software in the future.
Fault removal and fault forecasting methods determine whether the software behavior
is consistent with the specifications, but they cannot detect flaws in the specifications.
Even using the best people, practices, and tools cannot guarantee that the software is free
of errors. Hence, fault tolerance means should be used to tolerate unexpected faults.
Fault Tolerance
Fault tolerance is the means by which a system can provide services in
spite of faults, errors, or failures.
There are three levels at which fault tolerance can be applied: hardware fault tolerance,
software fault tolerance, and system fault tolerance.
• Traditionally, fault tolerance has been used to compensate for faults in computing
resources (hardware). By managing extra hardware resources, the computer subsystem increases its ability to continue operation. Hardware fault tolerance measures
include redundant communications, replicated processors, additional memory, and
redundant power/energy supplies. Hardware fault tolerance was particularly important in the early days of computing, when the time between machine failures was
measured in minutes.
• A second level of fault tolerance recognizes that a fault tolerant hardware platform
does not, in itself, guarantee high availability to the system user. It is still important to structure the computer software to compensate for faults such as changes in
25
2.6. Dependability
program or data structures due to transient or design errors. This is software fault tolerance. Mechanisms such as checkpoint/restart, recovery blocks and multiple-version
programs are often used at this level.
• At a third level, the computer subsystem may provide functions that compensate for
failures in other system facilities that are not computer-based. This is system fault
tolerance. For example, software can detect and compensate for failures in sensors.
Measures at this level are usually application-specific.
In this thesis, failures are addressed at the requirements level which is very much
application-specific. Hence, in this work we consider system fault tolerance.
Fault tolerance is a means of achieving system dependability. Fault tolerance involves
error detection and system recovery as shown in Fig. 2–5 [11]. Error detection involves
identification of erroneous state in the system by means of acceptance tests or active
redundancy. Late or dead processes can be detected using timers that sound an alert
when a deadline for a specific interaction or functionality expires. The error might lead
to a permanent or transient failure. Permanent failures are failures that persist, and lead
to a loss of service until appropriate recovery measures are taken. Transient failures are
failures which disappear over time. System recovery involves correcting such problems
to ensure that the system continues to deliver its services. One technique for error handling
is forward error recovery (or rollforward) which aims to construct the system to a new,
possibly degraded, state. This approach requires knowledge of the errors and hence is
application-specific, but is efficient and suitable in cases of anticipated faults and missed
deadlines. In our work, we focus on forward error recovery and use ideas from exception
handling (discussed in the following subsection).
2.6.4
Exception Handling
An exceptional situation, or short exception, describes a situation that, if encountered,
requires something exceptional to be done in order to resolve it. Hence, an exception
occurrence during a program execution is a situation in which the standard computation
cannot pursue. For the program execution to continue, an extraordinary computation is
necessary [119].
A programming language or system with support for exception handling, subsequently
called an exception handling system (EHS) [60], provides features and protocols that allow
26
2.6. Dependability
Concurrent Error
Detection
Error Detection
Preemptive Error
Detection
Rollback
Fault Tolerance
Error Handling
Compensation
Rollforward
System Recovery
Fault Diagnosis
Fault Isolation
Fault Removal
System
Reconfiguration
System
Reinitialization
c 2004
Figure 2–5: The Fault Tolerance Tree (Reproduced from [124] with permission IEEE)
programmers to establish a communication between a piece of code which detects an exceptional situation while performing an operation (a signaler ) and the entity or context that
asked for this operation. An EHS allows users to signal exceptions and to define handlers.
To signal an exception amounts to:
1. identify the exceptional situation,
2. to interrupt the usual processing sequence,
3. to look for a relevant handler and
4. to invoke it while passing it relevant information about the exception.
Handlers are defined on (or attached to, or associated with) entities, such as data structures, or contexts for one or several exceptions. According to the language, a context may
be a program, a process, a procedure, a statement, an expression, etc. Handlers are invoked
when an exception is signaled during the execution or the use of the associated context or
nested context. To handle means to set the system back to a coherent state, and then:
• to transfer control to the statement following the signaling one (resumption model
[81]), or
27
2.7. Summary
• to discard the context between the signaling statement and the one to which the
handler is attached (termination model [81]), or
• to signal a new exception to the enclosing context.
2.7
Summary
Software engineering is concerned with the development of software systems using a
software development process. A software development process comprises of five major
phases: requirements analysis, design, implementation, testing, and maintenance. One
software development methodology that is widely used in current times is model-driven
engineering (MDE). MDE is supported by the visual modelling language, UML, which
defines several types of graphical models which can be employed during the different phases
of development.
The main interest in this thesis is on the first phase of development. Requirements
analysis, which was previously a much neglected phase, is now considered to be of major significance and has become a sub-discipline of software engineering, which is known
as requirements engineering (RE). RE encompasses several defined activities: elicitation,
analysis, specification, and validation. The activities take into account requirements of
different types: functional requirements, non-functional requirements, and domain constraints. While functional requirements is a term accepted by all in the research community, non-functional requirements (or NFRs) or concerns create a lot of debate and to this
date there exists no consensus on the meaning or applications of this term. Numerous
research communities have been created over time which focus on particular NFRs related
to a domain. In this thesis, we focus on the dependability concern, in particular on the
reliability and safety attributes of dependability. Dependability can be attained by various
means depending on the domain and type of system. Backward error recovery, compensation, forward error recovery are some possible ways of achieving dependability. Forward
error recovery using exception handling is mainly applied in this work.
28
CHAPTER 3
Dependability in Model-Driven Software Engineering
A software development approach that is significantly based on the use of models
is said to follow the Model Driven Engineering (MDE) paradigm. The models might be
very detailed forming the base for the implementation, or they might include executable
actions leading to the automatic generation of an application. Section 3.1 discusses some
approaches using MDE.
In this thesis, the main goal is to interleave the concern of dependability in an accurate
and effective manner in model-driven software engineering with a focus on the early phases
of development. This chapter sets the context of the work in this thesis and presents
the “big picture”. We begin with a brief description of some model-based development
approaches, and then discuss dependability in the software development context.
3.1
Model-Driven Software Development
Currently, models play a big role in the development of software-intensive systems.
Modelling languages can be either textual or graphical. Examples of textual languages
include Kermeta, and formal specification languages Z, Abstract Machine Notation(AMN)
of the B-Method, and VDM-SL of the Vienna Development Method. Flowcharts [161],
Petri Nets [171], SDL [34], SysML [83], and UML [164] are examples of graphical modelling
languages. In this work, we are primarily concerned with graphical modelling, and we focus
on the use of UML. UML is a semi-formal modelling language. It is different from formal
specification languages, such as Z and VDM, which are mathematically-based techniques
allowing analysis and verification to be carried out.
29
3.1. Model-Driven Software Development
3.1.1
UML
The Unified Modelling Language (UML) [164] (described earlier in Chapter 2) is an
OMG standard [82] open method for creating, visualizing, and maintaining the artifacts
during the development life cycle of an object-oriented software. UML models can be
viewed in three different ways as stated by Mellor in [149].
• Model as a sketch: provides an informal way of visualizing a system. Models created
are not used for a specific purpose and are not maintained.
• Model as a blueprint: provides a more formal and precise way of viewing and conceptualizing a system. The models are detailed, consistent, and coherent, are continuously maintained and serve as an artifact.
• Model as executable: based on MDA principles, models are constructed in a way
similar to that of writing a program. Models are required to be complete, to allow
them to be compiled and transformed to downstream models and eventually to a
working implementation of the system.
In this thesis, our focus is on UML as a blueprint. We propose a well-defined process
and supporting modelling formalisms to lead to the development of a complete and accurate
blueprint of the dependability requirements of a system.
UML diagrams can be used to provide either a structural or a behavioural view of
the system. Fig. 3–1 shows the types of diagrams that are part of UML, and highlights
the diagrams that are addressed in this thesis. We focus on the requirements development
phase which deals with defining the behavioral aspects of systems, and hence have worked
on dependability extensions for the behavioural diagrams. Structural diagrams are constructed in the analysis and design phases. Our process, DREP (presented in Chapter 6),
supports the use case diagram, the state machine diagram, and the activity diagram. To
visualize system interaction, we make use of communication diagrams. Sequence diagrams
or timing diagrams become essential when considering the timing aspects of the system.
A UML model is not necessarily just comprised of a UML diagram - the diagram
together with a semantic base make a model. For example, a use case model comprises of
textual use cases and the use case diagram. A metamodel might include a class diagram
together with OCL constraints.
It should be noted that UML is not a methodology and not does come with a process.
Over the last decade many software development processes have been adapted to work
30
3.1. Model-Driven Software Development
UML Diagram
Structure Diagram
Behaviour Diagram
Class Diagram
Component
Diagram
Composite
Structure Diagram
Object Diagram
Deployment
Diagram
Package Diagram
Activity Diagram
Use Case Diagram
State Machine
Diagram
Interaction Diagram
Sequence Diagram
Communication
Diagram
Interaction
Overview Diagram
Timing Diagram
Figure 3–1: UML Diagrams
with UML notations, and new UML-based processes have been crafted, such as the Unified
Process (UP) and its variant, the Rational Unified Process (RUP).
3.1.2
The Unified Process
The Unified Process (UP) [8] is a workflow-based software development process from
the authors of UML, and is the preferred process for UML-based development. IBM Rational Unified Process (RUP) is a commercial and more detailed version of UP. The processes
are iterative and incremental in nature, and follow a waterfall-like sequence beginning with
risk and use case-driven requirements development. The UP requirements metamodel as
defined by Arlow [8] is shown in Fig. 3–2.
3.1.3
Fondue
Fondue [206] is a UML-based software development method for reactive systems. It is
based on the Fusion [189] method which was recast to use UML notations, hence creating
Fondue. It starts with use-case driven requirements elicitation then continues on to analysis, design and implementation. Fondue offers a step-by-step process that guides developers
through the entire software development life cycle. Fondue defines several models in each
of its phases as shown in Fig. 3–3.
31
3.2. Dependability and Software Engineering
Software Requirements Specification
Functional
Requirements
Use Case Model
P1
Requirements Model
NonFunctional
Requirements
P2
P3
Figure 3–2: UP Requirements MetaModel (Adapted from Fig 3.3 [8])
Requirements Models
Domain Model
Use Case Model
Analysis Models
Environment Model
Behavior Models
Protocol Model
Concept Model
Operation Model
Design Models
A
B: A depends on B
Figure 3–3: Fondue Models (Reprinted from Fig. 1 [206]) with permission from Elsevier)
3.2
Dependability and Software Engineering
Dependability attributes and means (defined in Section 2.6) are usually not considered
throughout the software development life cycle. Many modelling languages, specification
languages, formal methods, profiles, and other design and implementation approaches have
addressed the concern of dependability and considered fault tolerance means. Ideally, every
phase in the life cycle should take into account such concerns and provide measures to
32
3.2. Dependability and Software Engineering
attain appropriate levels of dependability. Kienzle [115] addresses this need, and discusses
exception handling and the propagation of exceptions from the early phases of software
development to design and implementation.
In this thesis, we have worked on the most neglected area in the life cycle: requirements
engineering. We have proposed extensions to UML behavioural models that are applicable
in the dependable reactive system domain. We do not however just propose a dependability
profile, but we define a methodology which includes a process to define requirements and
dependability concerns, and notations to construct UML-based models.
The following sections outlines how our process, DREP, can be associated to UP and
Fondue.
3.2.1
DREP and UP
The Unified Process takes risks into account in the early stages, and supports the
definition of non-functional requirements (see Fig. 3–2). Non-functional requirements are
seen as special properties or constraints on the system. While explicitly specifying properties such as availability or security is part of addressing the dependability concerns of a
system, it does not unveil the flaws or missing elements in the requirements and neither
does it uncover the exceptional situations that might come up and the possible failures
they might lead to. UP offers a use-case driven requirements elicitation technique that
complements the traditional requirements approach. It supports textual use cases and the
use case diagram. Our use case-driven process, DREP, can be used on top of the UP usecase approach to aid in uncovering abnormal situations that arise in the system or in the
environment that might lead to system failures. It fits in well with UP since DREP uses
the same formalism to elicit requirements. Additionally, in UP the use cases are mapped to
activity diagrams in the analysis phase. Using the model transformation rules we define, it
is possible to map the DREP exceptional use cases to activity diagrams and then continue
with the UP phases. DREP activity diagrams are compatible with UP activity diagrams.
The elements used to model exceptions in use cases are part of the UML 2 activity diagram
metamodel. Fig. 3–4 shows how DREP can be integrated into the UP.
3.2.2
DREP and Fondue
Fondue does not address dependability concerns and offers no special support for
development of dependable systems. The use case elicitation in Fondue can be carried
33
3.3. Summary
Software Requirements Specification
DREP Model
DA-Chart Model
Requirements Model
Use Case Model
P1
P2
UseCase: ...
Primary Actor: ...
Secondary Actors: ...
Dep Exp.: 99.999%
Main:
1. ... Rel.: 99.83%
2. ... Rel.: 99.91%
Safety: L2
3. ... Rel.: 99.94%
Extensions:
1a. Exception {..}
*
Mini 407 System
Activity Model
>>
TakeHighway
gra
de
err
int
l>>
t&
up
fai
err
up
Exception:
{UndetectedEntry,
UndetectedExit}
t&
*
Exception:
{UnregisteredVehicle}
<<
de
EntryGantry
int
NonFunctional
Requirements
<<
Functional
Requirements
<<reliability handler>>
<<reliability handler>>
ChargeMinimalTrip
AlertPolice
1
ExitGantry
Police
Figure 3–4: DREP and UP Requirements MetaModel
out using the DREP activities. The Fondue domain model together with the DREP use
case and activity models would form the requirements artifacts. DREP offers an extended
environment model (communication diagrams), based on the Fondue environment model,
that models the normal and exceptional interactions in the systems. This model can be
used in place of the Fondue environment model. Fig. 3–5 shows a revised version of the
diagram on Fondue models. [194] proposes Fondue extensions for addressing exceptions in
the analysis phase models.
3.3
Summary
The trend in software engineering currently is following model-driven engineering,
and UML is widely used during software development. In our work we focus on UML
behavioural models, specifically the use case model, the state machine model, the activity
model, and the communication model. We aim to propose dependability extensions of
the models, and provide a well-defined requirements development process, DREP, that
supports the models. DREP and its models can be used in conjunction with software
development methods such as Fondue. The Fondue method is used in the reactive systems
domain, and DREP takes it a step further and makes it applicable for dependable reactive
systems. We discussed how DREP complements UP and Fondue to illustrate that DREP
34
3.3. Summary
Requirements Models
Elicitation Models
Domain Model
Use Case Model
Assessment Models
DA-Chart Model
Markov Chain
Specification Models
Activity Model
Analysis Models
Environment Model
Behavior Models
Concept Model
Design Models
Figure 3–5: DREP and Fondue Models
activities and models can be made part of existing software development methodologies in
the target domain. For processes which do not include a requirements elicitation phase,
DREP can be used by itself to create a specification for safety-critical or business-critical
systems in which reliability and safety are of significant concern.
35
CHAPTER 4
Addressing Dependability in Requirements
Engineering
When developing dependable systems, exceptional situations or abnormal behaviour
need to be addressed during the discovery and definition of requirements. Such situations
threaten the dependability of the system. To achieve and maintain dependability levels,
error detection and system recovery means are adopted (as mentioned in Section 2.6).
System recovery comprises of backward error recovery or forward error recovery. In our
target domain, dependable reactive systems, forward recovery techniques are applied to
tolerate faults since our main intention is to anticipate possible errors and to provide
corrective actions. We use the exception handling mechanism as the means to attain
dependability in requirements engineering.
This chapter lays down the foundation of this thesis. The basic terminology associated
with our work, including the system, services, and outcomes, are mentioned in Section 4.1.
The base concepts introduced as part of our approach are defined in Sections 4.2, 4.3, and
4.4. To conclude, Section 4.5 gives a summary of the contributions of this chapter.
4.1
The Basic Concepts
4.1.1
System and its Structure
As defined in [12]: A system is an entity that interacts with other entities, i.e., other
systems, including hardware, software, humans, and the physical world with its natural
phenomena. These other systems are the environment of the given system. The system
boundary is the common frontier between the system and its environment.
36
4.2. Attaining Dependability in Requirements Engineering
The function of a system is the set of tasks a system is expected to carry out, and the
behaviour of a system is what the system does to implement its function. The structure
of a system allows the system to execute its functionalities. At the requirements level, the
system is viewed as a black-box and considered to have no internal components.
4.1.2
Services and Outcomes
Development of requirements begins with elicitation of the goals of stakeholders. The
system to be built is required to provide services that satisfy the users’ goals. Services
are delivered by the system in response to a request of a user, and providing a service
usually involves interactions with the environment. A service is defined as the behaviour
of the system as is perceived by the user. The user can be seen as an external system that
requests and receives services from the system. The system may be able to meet the goal,
hence completing the service in a successful outcome, or fail to provide the service, and
end in a failed outcome. For instance, in an ATM system, a client can request to withdraw
money and the request can be fulfilled, if the system offers the withdraw money service at
that time. The money withdrawal service has a successful outcome if the client is able to
withdraw the desired amount of money. However, the ATM might not be able to contact
the bank backend, or there might be a bill jam in the dispenser due to which the services
end in failure.
4.2
Attaining Dependability in Requirements Engineering
In this section, we discuss how exceptions and handlers can be viewed in require-
ments engineering. We introduce two types of exceptions that need to be addressed during
requirements development, and associate exceptions to handlers.
4.2.1
Exceptions
Elicitation of requirements can be carried out effectively using use cases or scenarios
(see Chapter 5 for details). A scenario describes the sequence of interaction between the
system and the environment that leads to the fulfillment of the user’s goal. Sometimes,
however, a system is exposed to exceptional situations or conditions that interrupt the flow
of interaction leading to the fulfillment of the stakeholder’s goal. From now on, we’ll use
the word exception to refer to such exceptional situations. It is important to point out that
37
4.2. Attaining Dependability in Requirements Engineering
the meaning of exception at the requirements level is not directly related to exceptions as
defined by modern programming languages. The term exception is used at a higher level of
abstraction here. An exception occurrence endangers the completion of the stakeholder’s
goal, suspending the normal interaction temporarily or for good.
Wirfs-Brock precisely explains the difference between requirements-level exceptions
and design-level exceptions in [223]:
One thing must be made clear: Exceptions described in use cases are fundamentally different than exceptions uncovered in a design. Use case exceptions
reflect the inability of an actor or the system to continue on the same course.
Object exceptions reflect the inability of an object to perform a requested operation. During execution of a single step in a use case scenario, potentially
several use case-level exceptions could happen. However, the execution of a single use case step could result in thousands of requests between collaborators,
any number of which could cause numerous different object exceptions. There
is not a one-to-one correspondence between exception conditions described in
use cases and object exceptions.
At the requirements level, error detection involves detection of exceptional situations
by means of secondary actors such as sensors and time-outs. System recovery at the
requirements level involves describing the interactions with the environment that are needed
to continue to deliver the current service, or to offer a degraded service, or to take actions
that prevent a catastrophe. The former two recovery actions increase reliability, whereas
the latter ensures safety.
Context-Affecting Exceptions The functional requirements are defined in a scenariodriven manner such that each scenario encapsulates the system’s behaviour in response to
a request originating external to the system. The interactions that an actor has to perform
in order to achieve his/her goal is also described in the scenario.
Sometimes, however, exceptional situations arising in the environment, i.e., situations
that cannot be detected by the system itself, might cause actors to interact with a system
in an exceptional way. The situations are exceptional in the sense that they occur only
rarely, and they change the context in which the system operates either temporarily or
permanently. We call these exceptions context-affecting exceptions. Sometimes even
new actors – exceptional actors – start interacting with the system in order to signal the
38
4.2. Attaining Dependability in Requirements Engineering
exception, or to help during handling of the situation. Context-affecting exceptions are
actor-signalled, that is, they are communicated to the system by special actions of actors.
Very often, such situations are related to safety issues. In an elevator system, for
example, a fire outbreak in the building causes the elevator operator, an exceptional actor,
to activate the fire emergency mode, in which all elevator cabins go down to the lowest floor
to prevent casualties or physical damage in case the ropes break. Activating the emergency
behavior is an exceptional goal for the elevator operator, since this happens only in very
rare occasions.
Service-Related Exceptions
Even if all actors interact with the system in a normal way,
exceptional situations might prevent the system from providing the desired functionality
to the actor. We define such situations as service-related exceptions. For example,
insufficient funds can prevent a successful withdrawal, an order might not be fulfillable
because the book is currently out of stock, or a motor failure might prevent a user from
taking the elevator. In such cases, the goal of the actor cannot be fulfilled.
In general, this sort of exceptional situation also triggers some exceptional interaction
steps with the environment. One of the steps is (or should be!) to inform the actor of the
impossibility to achieve the goal. Once informed, the actor can decide how to react to the
situation. The system itself might also be capable of handling the problem (as discussed
in the next section), for instance by suggesting to withdraw a smaller amount of money, or
by suggesting to buy some other book, or by activating the emergency brakes and calling
the elevator operator.
Service-related exceptions have many natures:
• The system state makes the provision of a service impossible1 ,
• Failure of secondary actors that are necessary for the completion of the user goal,
• Failure of communication links between the system and important secondary actors,
• Actors violate the system interaction protocol, i.e. they invoke system services in the
wrong order, or at the wrong time.
1
Addressing these situations is of course not new to our approach. Standard use case
driven requirements engineering techniques usually specify the handling of such situations
in an extension section of the use case.
39
4.2. Attaining Dependability in Requirements Engineering
4.2.2
Recovery Measures
A dependable system must react to exceptions in a well-specified way. Measures to
cope with such situations have to be defined that aim tolerate the situation and resume
normal processing in order to attain required levels of dependability. The recovery measures
may include exceptional interaction steps with the environment which are invoked when an
exception occurs and normal interaction gets interrupted. The set of interactions required
to recover from a particular exception defines a handler.
In our approach, recovery means are defined that attempt to satisfy either the reliability of the system or the safety of the system. Reliability handlers attempts to recover
from an abnormal situation and aims to provide continuity of service. The main intention
is to maintain adequate levels of system reliability and remain in operation as long as required. Safety handlers include measures that are taken to ensure that the system does
not fail in a catastrophic manner. The main goal is to maintain required levels of safety
even if it leads to suspension of normal services that might be hazardous to the users of
the system and the environment.
Having different type of handlers enables quick identification of functionality that
affects safety or reliability of a system, as well as identification of safety-critical parts of
the system. It allows the developer in collaboration with the stakeholders to decide, for
instance, how much resources should be allocated to the development of the functionality
defined in the handler use cases, or to prioritize between safety and reliability in case of
conflict.
4.2.3
Associating Exceptions and Handlers
In case of an occurrence of an exceptional situation, the base behavior is put on
hold or abandoned, and the interaction specified in the handler is started. A handler can
temporarily take over the system interaction, for instance to perform some compensation
activity, and then switch back to the normal interaction scenario. This is similar to the
resumption model described in Section 2.6.4, and hence we refer to the relationship as
an interrupt & continue relationship. Some exceptional situations, however, cannot be
handled smoothly, and cause the current goal to fail. We define such dependencies as
interrupt & fail relationships, which are similar to the termination models discussed in
Section 2.6.4.
40
4.3. Exceptional Service Outcomes
4.2.4
Fault Assumptions
During requirements elicitation, the developer can assume that the system itself always
behaves according to specification – in other words, it will not contain any faults, and
will therefore never fail. As the development continues into design and implementation
phases, this assumption is most certainly not realistic. Dependability assessment and fault
forecasting techniques have to be used to estimate the reliability of the implemented system.
If needed, fault tolerance mechanisms have to be built into the system in order to increase
system dependability.
Although the system is assumed to function perfectly, a dependable system cannot
assume that it will operate in a fault free environment. Actors can fail to provide essential
input to the system: for instance, a floor sensor in an elevator system might not tell the
system when the cabin has reached the destination floor. Actors can also fail to provide
services that the system under development requests from them. If this service is essential,
then the system under development must be able to compensate for such an actor failure,
and the need for this compensation must be documented in the system requirements.
Even if the actors are reliable, the communication between the system under development and the actors might fail due to physical damage, electromagnetic perturbations,
faults in the network protocol, etc.
Finally, in certain situations it might be impossible for the system to provide a requested functionality due to environmental constraints or business rules. For example, it
might be impossible to withdraw money from an empty bank account. Such a situation can
also be looked at as an interaction protocol violation: the user should not have requested
to withdraw money from the empty bank account in the first place.
Our dependability-driven requirements elicitation process, DREP (presented in Chapter 6), considers environmental faults, communication problems and protocol violations in
detail, since they affect the interaction of the system with the environment significantly.
4.3
Exceptional Service Outcomes
Very often, an exceptional situation that arises while a system is providing service
makes it impossible for the system to complete the task at hand. For instance, the system
might be relying on an external device to perform a certain action, but the device is
malfunctioning. The reliability of the service, or maybe even system and user safety are at
41
4.3. Exceptional Service Outcomes
stake. We believe that when the original service cannot be provided, a dependable system
should strive to handle the current situation and attempt to provide partial service, if
possible. The advantage of doing this is threefold:
• Satisfying the User : If the system cannot provide the requested service, the user
might still be satisfied with some degraded form of service. Providing well-defined
partial service is better than providing no service at all.
• Predictability: If the current situation prevents the system from providing full service,
it is important to define precisely what the system can and will provide in the current
situation.
• Reliability: When evaluating the reliability of a system, any observable deviation
from a system’s specification is considered a failure. If, however, in addition to
defining the normal outcome for each service, a specification also includes definitions
of degraded outcomes for each service, then it is possible to consider the degraded
outcomes when evaluating a system’s reliability.
Very often, an exceptional situation that arises while a system is providing service
makes it impossible for the system to complete the task at hand. These service-related
exceptions have many natures as discussed earlier in Section 4.2.1. In the event of such
exceptions, the current system state makes the provision of the service impossible. To
prevent such a situation, a dependable system should of course not offer services it can
foreseeably not provide. This can be done by switching into a degraded or exceptional
operation mode as described in Section 4.4. However, sometimes the impossibility of providing a service can only be determined once more information is available. For example,
a system might offer the service Buy Book, but once the user specifies which book to buy
the system realizes that this particular book is currently out of stock.
When the requested service cannot be provided, a dependable system should strive
to handle the current situation and attempt to provide partial service, if possible. Partial
service, or degraded service outcome as we call it, happens when a service does not deliver
what it initially promised, but yet provides something that potentially satisfies the requester
of the service. A degraded outcome is better than a complete failure to deliver the service.
For example, in an elevator system, the elevator might miss the user’s requested destination floor due to the malfunctioning of, for instance, the floor detection sensor. In
this case, instead of abandoning, the system can still attempt to stop the elevator at a
neighboring floor. Especially in a highrise building this degraded outcome could still be
helpful.
42
4.4. Exceptional Modes of Operation
In an online bookstore, a user might request to buy a book that is currently out of
stock. The system can suggest to place an order and ship the book as soon as the order is
fulfilled at a discounted price.
When using the DispenseDrink service of a vending machine, one could imagine that
the water heating system fails. In this case, the system could suggest to provide a cold
drink instead, especially if for some reason the machine can not return the user’s money.
A web browser might encounter an error when parsing the HTML code for a page.
Rather than not displaying anything, the browser could decide to inform the user about the
problem, and then display that parts of the web page that have been decoded successfully.
In addition to success, failure, and degraded, another possible type of outcome of a
user goal is abandoned. To correctly calculate reliability, it is important to separate the
situations in which the user voluntarily abandons the goal from the situations in which
the service fails. A service that is successfully cancelled upon user request represents a
correct and reliable system behavior. For example, if the user requests for the elevator at
a certain floor and then decides to not take the elevator, the TakeElevator goal is said to
be abandoned and not failed.
4.4
Exceptional Modes of Operation
In addition to handling an exceptional situation preventing normal service by trying
to achieve partial service, a dependable system should also evaluate the effects of the
encountered problem on future service provision of the system. In the case where the
current situation might affect future services, the system should switch from its normal
mode of operation into a different mode in which the services that are affected by the
problem are not offered anymore. Doing this, again, has many advantages:
• Satisfying the User: If the system pretends to be able to provide normal service, the
user expectations might be too high. A dependable and trustworthy system does not
promise to deliver services it cannot provide. To satisfy the user, provided services
and service quality should be made clear to the user upfront. It is then up to the
user to decide if these services are adequate or not.
• System Safety: It might be too dangerous to attempt to provide service in case
of previous problems. In the case where the safety of the system is threatened,
for instance due to the failure of important devices, unsafe services should not be
attempted.
43
4.4. Exceptional Modes of Operation
• Reliable Service: Trying to continue to provide normal service in situations where
there are foreseeable problems dramatically reduce the reliability of the system.
Defining different degraded modes of operation offering different sets of services makes
it possible to calculate and specify system reliability for each mode.
Whenever a dependable system has encountered difficulties performing a requested
service due to some exceptional situation, the effect of the encountered problem on future
service provision of the system has to be evaluated. If the reliability or safety of future
service provision is threatened, then a mode switch is necessary. Switching to a different
operation mode allows the system to signal to the environment that the services offered
by the system have changed, and reject any requests for services that cannot be performed
with sufficient reliability or safety.
We introduce four kinds of operation modes in this section. To formalize the definition
of modes, we define the modes and the services in each mode using set theory.
4.4.1
Kinds of Services
A service, s, is provided to satisfy a user goal. A service is always associated to the
goal of an actor (either primary or exceptional). The services SSystem that are provided
by a system can be split into two disjoint subsets: N and E. The subset N contains all
services that are provided by the system under normal circumstances: the system’s purpose
is to provide the services in N . The set E contains all services that the system provides in
order to react to an exceptional situation: the services in E are typically only provided by
the system in order to ensure safety until the exceptional situation is resolved.
SSystem = N ∪ E and N ∩ E = ∅
Modes of Operation A system provides a set of services to its users, but not always all
of the services are available, and the quality of delivery of each of the provided services
may vary.
A mode, M , represents a state of the system during which a specified set of services
is provided with a given reliability and safety.
More formally, if SM represents a set of services, then a mode, M , is a triplet:
M = (SM , rel, saf )
where SM ⊆ SSystem , rel : SM → [0, 1], and saf : SM → [0, 1]
44
4.4. Exceptional Modes of Operation
where rel(s) represents the minimum reliability that is guaranteed when providing a
service s and saf (s) represents the minimum probability of upholding the desired
safety level when providing a service s in this mode.
4.4.2
Kinds of Operation Modes
We define modes to be of four types: normal, degraded, emergency, and restricted.
The type of a mode is defined by the kind of services that are offered in the mode.
Normal mode In a normal mode, the services that the system was built to fulfill are
available and correctly functioning. A system might have more than one normal mode,
and switches between these modes upon request of the user or to accommodate changes
in the environment. For example, a cell-phone can be put into a child-safe mode, in which
the only service offered is to place local calls.
M is a normal mode ≈ normalM ode(M )
normalM ode(M ) ⇔ SM ⊆ N
Degraded mode
A degraded mode of operation of a normal mode offers only limited
services. Some services of the normal mode are still provided as is. Some services are
provided, but with a lower degree of reliability and safety. In this case, the service is said
to be offered with degraded quality of service (QoS).
For example, bad weather conditions might prevent a video camera from capturing
clear pictures, or transmission problems might prevent the captured images from reaching the central computer. In this case, the detection and recognition services of a video
surveillance system might temporarily be less reliable.
In the elevator system, a jammed door might prevent the elevator cabin from picking
up or depositing passengers on a particular floor. As a result, the TakeElevator service
offered is less reliable for users that want to reach that specific floor, since the cabin will
only stop at a neighboring floor.
A web browser running low on memory might switch into a mode where only textual elements from webpages are displayed and graphical elements and other media are
suppressed to save memory.
Finally, degraded modes also include modes in which some services are intentionally
suspended because they cannot be provided with sufficient reliability or safety. In a flight
control system, for example, normal mode of operation may be denied after the system
45
4.4. Exceptional Modes of Operation
detected one or more communication failures with devices. The system would switch to an
alternate degraded mode where only minimal computer-mediated control is available.
Another example of a degraded mode can be found in an ATM system. During weekends there is usually no maintenance performed on ATM machines. When the deposit slot
reaches it’s maximum capacity, most ATM machines disable the deposit service and only
offer the withdraw service until the deposit slot has been emptied. Hence the system is in
a degraded mode where it is not offering deposit services.
More formally, degraded modes of operation are defined as follows:
Mi = (SMi , reli , safi )
Mj = (SMj , relj , safj )
Mi is a degraded mode of Mj ≈ degradedM ode(Mi , Mj )
degradedM ode(Mi , Mj ) ⇔ SMi ⊆ SMj
and ∀s ∈ SMi (reli (s) ≤ relj (s) and safi (s) ≤ safj (s))
and (∃s ∈ SMi |reli (s) < relj (s) or ∃s ∈ SMi |safi (s) < safj (s))
Emergency mode
In an emergency mode, normal services are suspended and only emer-
gency services, possibly initiated by a new exceptional actor, are available. The system is
in a state in which it cannot provide any of its normal services anymore, not even in a degraded form. This is usually due to safety reasons. For example, in case of a fire alarm, an
elevator system does not handle user requests anymore, but moves all the elevator cabins
to the ground floor.
M is an emergency mode ≈ emergencyM ode(M )
emergencyM ode(M ) ⇔ SM ⊆ E
Restricted mode
In a restricted mode, a combination of emergency services and normal
services are offered. The system is in an exceptional state in which only a subset of the
normal services are available and the functions of particular emergency services are also
required. For example, in an automated electronic highway toll collection system, critical
road conditions might require the system to restrict vehicles from entering the highway.
Emergency services such as activating the road barriers are carried out. However, the exit
service needs to be active to allow the vehicles already on the highway to continue.
M is a restricted mode ≈ restrictedM ode(M )
restrictedM ode(M ) ⇔ ∃s ∈ SM |s ∈ N and ∃s ∈ SM |s ∈ E and SM ⊂ N
46
4.5. Summary
4.5
Summary
We believe that when developing reliable systems, exceptional situations that the
system might be exposed to have to be discovered and addressed at the requirements
elicitation phase. Exceptional situations are less common and hence the behavior of the
system in such situations is less obvious. Also, users are more likely to make mistakes when
exposed to exceptional situations.
This chapter is focused on concepts that are necessary to address exceptions in requirements development. We introduced two types of exceptions: context-affecting exceptions
(exceptional situations arising in the environment)and service-related exceptions (exceptional situations that might prevent the system from providing the desired functionality to
the actor). We proposed the use of reliability handlers and safety handlers to cope with
the exceptions. The relationships, interrupt & continue and interrupt & fail, are defined
to specify how the exception affects the execution of the user goal.
Each scenario in our requirements describe the sequence of interaction between the
system and the environment that lead to the fulfillment of a user’s goal. The failure
of an interaction would lead to a service-related exception being detected and signaled
to the calling use case. The associated handler is then invoked. Once the exception is
handled, normal processing continues. We have defined four outcomes: success, abandoned,
degraded, and failure. Success outcome is reached if exceptions (if any) are handled and
the desired service is delivered. The abandoned outcome is produced if the user decides
not to avail the service anymore and abandons the goal. If an exception leads to provision
of degraded services and only satisfies the user goal partially, then we define a degraded
outcome. Finally, if the handler is unable to recover from the exceptional situation or if no
handler is defined, then the exception is signaled to the higher-level use case and a failure
outcome is produced.
If an exceptional situation can lead to the degradation of provision of future services
or if the system safety is threatened, we advocate to switch the system to a degraded mode
of operation in which only those services are offered that can be provided with satisfying
reliability and safety. Apart from increasing system reliability and safety by not attempting
to provide potentially problematic services, user dissatisfaction is also prevented. The
system does not promise what it cannot deliver.
47
4.5. Summary
The concepts presented in this chapter are general in nature. They have been defined
in a process-independent way and can be used as such within any requirements engineering
method.
48
CHAPTER 5
Integrating Dependability in Requirements Models
Model-based requirements development involves the use of various modelling formalisms, such as use cases, sequence diagrams, scenario charts, state diagrams. Some of
the existing approaches based on aspect-oriented requirements modelling and goal-oriented
requirements engineering have addressed dependability concerns and abnormal behaviour
to some extent. Such approaches addressing exceptions in requirements are discussed in details in Chapter 11. Our approach to addressing dependability in requirements is described
in the previous chapter. We have defined concepts that need to be taken into account when
developing dependable systems. The next step is to define means to integrate the concepts
into requirements engineering and to create a notation scheme to represent the concepts.
UML (discussed in Chapter 2) defines a notation for specifying, constructing, visualizing,
and documenting the artifacts of a software-intensive system. UML is intentionally processindependent. However, it offers a variety of diagrams that unify the scores of graphical
modeling notations that existed in the software development industry in the 80’s and 90’s.
Our approach is supported by UML-based graphical models. The artifacts of requirements
development phase aim to produce a complete, consistent, and unambiguous description
of the problem domain and the functional requirements of the system. The models focus
on describing what a system does, rather than how it does it.
This chapter introduces our requirements elicitation and specification models, and
elaborates on how we integrate dependability attributes and exception handling into the
models, namely use cases, activity diagrams, and communication diagrams. Section 5.1 and
Section 5.2 present our proposed extensions to use cases and activity diagrams, respectively,
from a notational perspective. The sections also include a discussion on how we integrated
our concepts into the UML metamodel. The extended notations are illustrated using a
49
5.1. Dependability in Use Cases
subsystem of the Elevator Control System case study in Section 5.5. Section 5.6 gives a
summary of this chapter.
5.1
Dependability in Use Cases
Our requirements development journey begins with use case models. The informal
requirements are molded into a semi-formal and structured use case model which comprises
of use cases and a use case diagram.
We define a textual use case template that the analyst has to fill out when elaborating a
use case. It is based on the template used by the object-oriented, UML-based development
method Fondue [189]. Using a predefined template forces the developer to document all
important features of a use case, e.g. the primary actor (the one that wants to achieve
the goal), the level of the use case, the potential concurrent execution of the use case
(Frequency & Multiplicity section) [116], the main success scenario (a numbered step of
interactions between the system and external actors) and the extensions.
The extension section of standard use cases may contain alternative ways that achieve
the primary actor’s goal, but often also describe situations in which the primary actor’s
goal is not achieved. Since we want to make a clear distinction between normal interaction
and exceptional interaction, the extensions of the standard use cases should only describe
alternative ways to achieve the goal, or interactions in which the primary actor voluntarily
abandons his goal with the system. This voluntary abortion is documented by stating “user
goal abandoned” at the end of the extension section.
Just like the steps in the main success scenario, extension steps are numbered. The
number is the same as the interaction step number of the main success scenario to which
the extension defines an alternative, followed by the letters ’a’, ’b’, ’c’, etc.
In order to address dependability concerns in use cases, it is necessary to integrate
means to identify the threats to dependability and then to achieve dependability. At the
use case level, error detection involves detection of exceptional situations by means of
secondary actors such as sensors and time-outs. System recovery at the use case level
involves describing the interactions with the environment that are needed to continue to
deliver the current service, or to offer a degraded service, or to take actions that prevent a
catastrophe. The former two recovery actions increase reliability, whereas the latter ensures
safety.
50
5.1. Dependability in Use Cases
5.1.1
Integrating Exception Handling in Use Cases
Exceptions in Use Cases Each user-level use case describes a unit of functionality that
the system under development provides to a particular actor. It details all interaction steps
that an actor has to perform in order to achieve his/her goal. The successful completion
of user goal may be threatened due to service-related exceptions. All possible exceptions
that can arise during an interaction due to service-related problems need to be realized
and specified in the use case. The exception should be associated with the corresponding
interaction in the use case.
Context-affecting exceptions which arise in the environment, interrupt service provision
and might lead to the change of user goals. They are not interaction-specific exceptions
and hence cannot be detected and realized in a use case. They might affect many or all
user goals, and hence have to be integrated at a higher level.
Handlers in Use Cases If the handling requires exceptional interaction steps with the
primary actor or other secondary actors, then a handler use case (see below) must be
defined. The handler is then linked to the context, i.e. the use case in which the exception
can occur. Upon reception of the exception, the normal interaction is interrupted and the
exceptional interaction begins.
Just like it is possible to encapsulate several steps of normal interaction in a separate
subfunction-level use case, an exceptional interaction that requires several steps of handling
can be described separately from the normal system behavior in a handler use case. The
major advantage of doing this is that from the very beginning, exceptional interaction and
behavior is clearly identified and separated from the normal behavior of the system. This
distinction is even more interesting if it can be extracted at a glance from the use case
diagram (see Section 5.1.3).
Separation of handlers also enables subsequent reuse of handlers. Just like a subfunctionlevel use case can encapsulate a subgoal that is part of several user goals, a handler use case
can encapsulate a common way of handling exceptions that might occur while processing
different user goals. Sometimes even, different exceptions can be handled in the same way.
Handler use cases for context-affecting exceptions, i.e. handlers that describe exceptional goals, are self-contained, just like standard use cases. But of course, handlers can
include sub-level handler use cases.
51
5.1. Dependability in Use Cases
For each identified exception, a handler use case outline has to be established describing how the system is supposed to react or recover from that situation. As mentioned in
Chapter 4, a handler can be further classified as a safety or reliability handler depending on
the concern it attempts to satisfy. A handler can also be linked to one or several contexts,
i.e. use cases during which the exceptional situation can occur. Upon occurrence of the
exception, the current interaction is interrupted and the exceptional interaction begins. In
an elevator system, for example, in case of a fire outbreak signalled by a smoke detector,
standard elevator operation is interrupted. To ensure safety, the elevators are brought to
the ground floor.
Just like in standard exception handling, where exception handlers are associated with
exception handling contexts, handler use cases apply to a base use case, in this case any
standard use case or other handler use case.
5.1.2
Representing Exceptions and Handlers in Textual Use Cases
We have extended traditional use cases with concepts of exceptions and handlers.
Figure 5–1 illustrates how we integrate exceptions into the textual use case template. The
identified exceptional situations are associated with the occurring interaction, and specified
in the extensions section of a use case. All identified situations are defined with a unique
exception name. The handler use case template is similar to the traditional use case
template, with the < <handler> > stereotype included in the use case name (see Fig. 5–
2). Textual use cases only include service-related exceptions. Context-affecting exceptions
occur at a higher level and hence are represented in the use case diagram and not in
individual use cases.
5.1.3
Representing Exceptions and Handlers in Use Case Diagrams
The model we are focusing on in this section is the use case diagram.
In parallel to the elaboration of the individual use cases and handlers, we propose
to build an extended exception-aware use case diagram providing a detailed and precise
summary of the partitioning of the system into normal and exceptional interactions.
Whereas individual use cases are text-based, the UML use case diagram provides a
concise high level view of all (or a set of) use cases of a system. It allows the developer
to graphically depict the use cases, the actors that interact with the system, and the
relationships between actors and use cases.
52
5.1. Dependability in Use Cases
Use Case: ...
PrimaryActor: ...
Intention: System wants to ....
Level: Summary/User-goal/Subfunction
Main Success Scenario:
1. System requests ....
2. System receives ....
3. System detects ....
...
...
7. System receives confirmation ....
Use case ends in success OutcomeLabel.
Extensions:
2a. Exception{ExceptionName} Use case ends in f ailure OutcomeLabel.
3a. Exception{ExceptionName} Use case continues in degraded OutcomeLabel at step .
7a. Exception{ExceptionName} Use case ends in f ailure OutcomeLabel.
Figure 5–1: Exceptional Use Case Template
Handler Use Case: HandlerName < <handler> >
Handler Class: Reliability / Safety
Contexts & Exceptions: UseCaseName{ExceptionName}
PrimaryActor: ...
Intention: User wants to ....
Level: ...
Frequency & Multiplicity: ...
Main Success Scenario:
1. ....
2. ....
3. ....
4. ....
Figure 5–2: Handler Use Case Template
In a use case diagram, standard use cases appear as ellipses (see Fig. 5–3), associated
with the actors whose goals they describe. We propose to identify handler use cases with a
< <handler> > stereotype , which differentiates them from the standard use cases. To allow
developers to identify exceptional behavior at a glance, handler use cases can be represented
in the use case diagram with a special symbol or using a different color. We also suggest
classifying a handler as a < <safety handler> > or a < <reliability handler> >.
A handler that is attached to a context use case is shown by a directed relationship
(dotted arrow) in the diagram. This relationship is very similar to the standard UML
53
5.1. Dependability in Use Cases
< <extends> > relationship. It specifies that the behavior of the context use case may be
affected by the behavior of the handler use case in case an exception is encountered. Similar
to the explicit extension points introduced in UML 2.0, the context use case can specify
the specific steps in which the exception might occur, but does not need to. In the latter
case, the exceptional situation can affect the base processing at any time.
In case of an occurrence of an exceptional situation, if the current goal is put on hold,
the relationship is tagged with a < <interrupt & continue> > stereotype. In case the
exception leads to failure of the current goal, the dependency is tagged with < <interrupt
& fail> >.
The < <interrupt & continue> > and < <interrupt & fail> > relationships also differ from the < <extends> > relationship in the sense that they apply also to all sub use cases
of a base use case.
Finally, the exceptions that activate the handler use case are added to the interrupt
relationship in a UML comment. The notation follows the same notation that was introduced in UML 2.0 to specify extension points for use cases. Fig. 5–4 shows a sample of our
extended use case diagram.
The constraints associated with the extended use case diagram include the following:
• a summary-level use can include one or more user-goal level use cases,
• a user-goal level use case can include one or more sub-function level use cases,
• a specific exception can occur in one or more use cases,
• a handler can be associated with more than one use case,
• a handler can call other handlers,
• an exceptional actor can only be associated with a handler use case (not other use
cases),
• an exception can only be attached to a dependency relationship between a use case
and a handler, and
• all dependencies between use cases and handlers have to be either of type interrupt
& continue or interrupt & fail.
5.1.4
Representing Degraded Outcomes in Use Cases
As discussed in Chapter 4, exceptional use cases can have four possible types of outcome. The outcomes are expressed within the use case templates with the use of the
following syntax.
54
5.2. Dependability in Activity Diagrams
System
summary level
use case
<<include>>
System
<<include>>
<<include>>
secondary
actor
user-goal
level
<<include>>
Exception:
{CAFailure}
<<include>>
f>>
<<safety handler>>
<<reliability handler>>
user-goal
level
handler
secondary
actor
Actor A
Actor Pr
<<i&
>>
i&c
<<
handler
<<include>>
<<include>>
<<include>>
sub-function level
<<include>>
<<include>>
sub-function
level
<<include>>
secondary
actor
Actor B
Exception:
{AFailure}
>
c>
i&
<<
Exception:
{BFailure}
<<
i&
c>
>
c>
i&
>
<<
Exception:
{CFailure}
<<reliability handler>>
<<reliability handler>>
<<reliability handler>>
handler
handler
handler
secondary
actor
secondary
actor
Figure 5–3:
Template
Standard Use Case Diagram
Figure 5–4:
Template
Extended Use Case Diagram
• success: Use case ends in success OutcomeLabel
• degraded success: Use case continues in degraded OutcomeLabel at step step
number or Use case ends in degraded OutcomeLabel
• failure: Use case ends in f ailure OutcomeLabel
• abandoned: Use case ends in abandoned OutcomeLabel
Fig 5–1 shows a use case template with possible degraded outcomes.
5.2
Actor C
>
sub-function
level
sub-function
level
c>
sub-function
level
<<exceptional>>
Actor Pr Exc
sub-function
level
i&
<<
secondary
actor
summary-level
use case
Exception:
{SFailure}
user-goal
level
user-goal
level
<<include>>
secondary
actor
primary
actor
Dependability in Activity Diagrams
Use cases are in general text-based, and can hence be effectively used as a communi-
cation means between technical as well as non-technical stakeholders of the software under
development. In order to elaborate a detailed and more formal specification, use cases are
typically refined and then depicted using activity diagrams and/or interaction diagrams.
As aptly described by Leimerman in [132], the activity diagrams are used as the visual
blueprints for the system functionality described in use cases, by the stakeholders’ and the
development team.
Activity diagrams can be used to formalize use case scenarios and provide a graphical representation of the flow of the use cases. It is also possible to show data flow
along with control flow by integrating domain model concepts in the activities. Activity
diagrams include constructs that allow modelling of exceptional behaviour. We have integrated exception handling concepts in UML activity diagrams to allow us to represent our
dependability requirements.
55
5.2. Dependability in Activity Diagrams
5.2.1
Integrating Exceptions and Handlers in Activity Diagrams
Service-related exceptions detected in use cases are mapped to outcomes in activities.
This type of exception can show up in leaf-level nodes, sub-activities, and parent activities.
An exception occurrence leads to a change in the flow of control in the activity when an
exception handler takes over. The handler use cases are mapped to handler activity nodes,
and are associated to the exceptions or appear in a higher-level activity if the exception is
propagated up and handled by the parent activity.
Context-affecting exceptions show up in the top-level activity diagrams (like in use
cases). They are events which interrupt the activity flow and transfer control to an exceptional activity, i.e., a safety handler activity or reliability handler activity.
5.2.2
Representing Exceptions and Handlers in Activity Diagrams
We have extended UML activity diagrams with two main concepts: handler nodes,
which are stereotyped activity nodes, and outcomes, which are represented using output
pins (discussed in 5.2.3). One use case is mapped to one activity diagram possibly including ever sub-activities. A service-related exception is modelled in an activity diagram by
using exception pins, and handlers are modelled using handler nodes. A context-affecting
exception is modeled using an interruptible activity region, an accept event, an interrupting
edge, and a handler node. The transformation rules to map use cases to activity diagrams
are presented in Chapter 8.
The main elements of activity diagrams used to model exceptional use cases are outlined here, and are graphically shown in Fig. 5–5.
• Call action node represents an activity behaviour. If it contains nested behaviour
that is specified in a sub-activity, the node is tagged with a rake icon.
• Input and output pins are used to create an interface for control flow and data
flow between activities.
• Send signal event is an action node used to model requests from one actor to
another. In our case we use it to depict the situation in which the system sends a
service request or message to an external actor.
• Accept event is an action node that models inputs from an actor.
• Accept time event is a node used to model a timer. It is and labelled with the
time constraint.
56
5.2. Dependability in Activity Diagrams
• Fork transition represents transitions when one activity triggers two or more activities and is depicted using a fork node.
• Activity regions are created to model boundaries for interruptible activities, and
allow modelling of interrupts and asynchronous events.
• Control flow is a directed edge used to model the flow of the activities.
• Interrupting edge is an edge used to model the flow of an activity following an
interrupt.
• Exception pin is a type of output pin used to model exceptions occurring within
activities.
• Handler node represents a handler activity and is shown using a call action node
with the stereotype < <handler> > .
• Outcomes are modelled as return parameters of the activity, and hence visualized
as ActivityParameterNodes or output pins.
Activity
call
action node
SubActivity
send signal
<<handler>>
call
action node
accept event
accept
time event
exception
pin
<<success>> <<degraded>> <<failure>> <<abandoned>>
Figure 5–5: Elements of Activity Diagrams
5.2.3
Representing Degraded Outcomes in Activity Diagrams
An activity node representing a use case interaction block can have a success or a failure
outcome. The entire activity however can also end in a degraded success or abandoned
outcome, as defined in the corresponding use case.
In activity diagrams the outcomes are modelled as return parameters of the activity,
and hence visualized as ActivityParameterNodes or output pins. The type of outcome is
identified with the predefined stereotypes success , degraded , f ailure ,
57
5.3. Dependability in Interaction Models
and abandoned , and is represented with a green pin, an orange pin, a red pin, and
a gray pin as shown in Fig. 5–5 to give a clear visual picture of the flow and outcomes.
The exceptional nature of degraded and failure outcome flows is depicted using exceptional
pins.
To prevent confusion, data flow is always separated from control flow, i.e., if the
activity requires input or output parameters, separate input and output pins are used.
5.3
Dependability in Interaction Models
While activity diagrams provide a blueprint of the system functionality by detailing
the control flow of all interactions with the system, there is also the need for elaborating a
model that precisely defines the system boundary. During design, state and behaviour that
lies within the system boundary must be implemented. Messages that cross the system
boundary, i.e. input messages sent by external actors to the system, or output messages
that the system sends to an external actor represent the system’s interface. During design,
means of communication between the environment and the system have to be elaborated
for each message that is part of the system interface. In our work, we use communication
diagrams to define the system boundary and specify the system interface.
As mentioned in Chapter 3, communication diagrams are a type of UML interaction
diagrams that is used to provide a view of the structural aspects of system interactions.
Actors are connected via links which serve as communication channels for sending and
receiving messages. They are quite suitable for modelling the system context at a high
level without using message sequencing.
In this thesis, we use black-box communication diagrams as our interaction diagram to
define the system boundary and interface. This is similar to the Fondue environment model
which is also used to define the system boundaries and interface. The model is designed
rather than discovered. It is based on the activity model and/or the use case model, and
requires elements from the domain model to allow complete specification of the interactions
as parameterized messages.
5.3.1
Integrating Exceptions and Handlers in Interaction Models
The system is modelled as a reactive entity that interacts with other active, reactive
and passive entities called actors. The system is just a name for the actor that is being
58
5.3. Dependability in Interaction Models
analyzed. The environment is the set of actors with which a system communicates. The
actors communicate with the system by sending input messages and by receiving output
messages.
The interactions in the use cases or the corresponding activities in the activity diagrams are mapped to messages in the communication diagram. Send request interactions
become output messages, and receive event interactions become input messages.
Service-related exceptions that arise during the interactions and cannot transparently
be handled by the system are shown as part of the message signature. Since the same
exception may arise in different interactions, we distinguish it by adding the use case
context or the handler context to the message signature. The same exception might have
different levels of consequences on the system dependability, or depending on the context
an interaction might be associated with different levels of reliability or safety, and therefore
specification of the context is useful for the design phase. For some interactions, after the
system sends the request, the response is expected within a certain period of time. If no
response is received within the deadline, an exception is detected by the system. Such
interactions are mapped to timed messages. When a response is received for which the
system is waiting, the timer is cancelled.
Use case interactions affecting either or both reliability and safety are identified in the
communication diagram as messages tagged with reliability or safety. Dependability concepts integrated in the model assists designers in understanding the criticality of messages,
and hence implement them in a reliable manner.
Context-affecting exceptions in essence are events that occur in the environment, and
which are signalled to the system by means of an interaction. Such exceptions are defined
in the system based on input messages received. Some messages categorized as exceptional
in nature, and the system is made aware of it by some external actor. An exceptional
message sent by an exceptional operator is a message created due to an exception.
Messages in communication diagrams are either synchronous or asynchronous. At
the requirements analysis level, details about the type of message (synchronous or asynchronous) can be ignored since the focus is not on the detailed semantics of message sending
but on the fact that messages are being passed [9]. Hence messages can be shown as synchronous or asynchronous at this phase, and then distinguished and detailed during the
design phase. We show messages as asynchronous in our interaction models.
59
5.3. Dependability in Interaction Models
5.3.2
Representing Exceptions and Handlers in Interaction Models
The black-box view of the system interactions with the environment is represented
using an object instance for the system entity, and actor instances (same as in use cases) for
the entities that interact with the system. Message passing is shown via a communication
channel depicted using a link or line between the system entity and an actor. A directed
line along with a message label is attached to the communication link. The directed line
can be used to represent synchronous or asynchronous messages. In our diagrams, all the
messages are asynchronous in nature. Return messages are shown with a dashed directed
line.
We have extended the syntax of communication diagrams to allow modelling of dependability concerns (reliability and safety), exceptions, and handlers, as shown in Table 5–3.
We have added the use case to the message signature to show the context of the interaction
(message: Context). In order to distinguish between use case and handler interactions and
exceptions, handler use cases are shown in italics in the message signature (message: Context). Each interaction which was earlier annotated in use cases with reliability or safety
tags are shown as messages tagged with <<r>> and/or <<s>>. Messages which are associated with deadlines are depicted with a timed message pin (hourglass symbol) attached
at the beginning of the message. Exceptions are shown using a triangular exception pin
(as used in activity diagrams). Exceptions which occur due to a missed deadline are shown
with a timeout pin (hourglass symbol with a line down the center). Exceptional actor entities are annotated with the stereotype <<exceptional>>. Internal time-triggered events
are shown inside the system entity under the stereotype label <<time-triggered>>.
The UML syntax for message names in communication diagrams as defined in [164] is
as follows:
<messageident> ::= ([<attribute> ‘=’] <signal-or-operation-name>
[‘(‘[<argument> [‘,’<argument>]* ‘)’] [‘:’ <return-value>]) |‘*’
<argument> ::= ([<parameter-name> ‘=’] <argument-value>) |
(<attribute> ‘=’ <out-parameter-name> [‘:’<argument-value>]) |‘-’
We have revised the syntax of message names in our extended communication diagrams, and it is defined as follows:
([<attribute> ‘=’] <‘<<’safety-tag‘>>’> <‘<<’reliability-tag‘>>’> <timed-message-pin>
<signal-or-operation-name> [‘(‘[<argument> [‘,’<argument>]* ‘)’]
60
5.4. Requirements Metamodels
[‘:’ <context> ‘{’ <exception-pin> <exception-id> [‘,’<exception-pin> <exception-id>]* ‘,’
<timeout-cancel-pin> <signal-name> [‘,’<timeout-cancel-pin> <signal-name>]* ‘}’]) |‘*’
The messages are added to the diagram based on the the use case interactions or the
activity events. The send request and receive event interactions are viewed as output and
input messages. They can also be mapped from activity diagrams in a straightforward
manner by translating the send signal action and the accept event action nodes in the
leaf-level activities to output and input messages respectively.
5.4
Requirements Metamodels
In this section, we construct meta-models for our requirements development formalisms
within the dependable reactive systems domain.The meta-models support our requirements
engineering approach, and explicitly describe how our use cases and activity diagrams and
communication diagrams can be built.
5.4.1
Textual Use Case Metamodel
UML does not define a meta-model for textual use cases since they are meant to be
informal models written in plain text. In our case however, we follow a specific template
and give specific guidelines so that users are able to define well-formed use cases. We use
use cases for the purpose of eliciting requirements and dependability concerns, and for
creating a basis of further specification and analysis. Our use cases have to be written and
structured in a specific format to allow them to be deciphered correctly and transformed
to other formalisms downstream.
We have defined a meta-model of textual use cases based on the Fondue use case
template as mentioned in Section 5.1. Our meta-model is shown in Fig. 5–6. StandardUseCase is defined as a type of UseCase, and has an association relationship with one
PrimaryActor. PrimarActor and SecondaryActor are defined as types of Actor. UseCase
is composed of one MainScenario section and an Extensions section. MainScenario has a
composition ordered association with MainStep which models the sequence of interactions
in a main success scenario. Extensions is composed of zero to many ExtensionBlock. Each
ExtensionBlock is again composed of one or more ordered steps. A Step can be of several
types: Interaction, Invocation, Condition, or ControlFlow. Every interaction is either a
SendRequest or a ReceiveEvent, and is associated with a SecondaryActor. An instance of
61
5.4. Requirements Metamodels
MainScenario is associated with exactly one Outcome. ExtensionBlock may be associated
with one or several Outcome.
goal
1..*
Standard
Use Case
Header
name:
scope:
intention:
level:
freqNmul:
precondition:
postcondition:
1
Use Case
0..1
1
0..*
1
1
actor
Primary
Actor
scenario
Main
Scenario
Extensions
Secondary
Actor
participant
1
{ordered}
0..*
{ordered}
1..*
Actor
Main Step
Extension
Block
alternate
{ordered}
1..*
Extension
Step
result
1
Outcome
0..*
result
Step
event 0..*
Interaction
Send
Request
Invokation
Condition
Receive
Event
Figure 5–6: Textual Use Case Metamodel
62
Control Flow
5.4. Requirements Metamodels
We extended the meta-model shown in Fig. 5–6 to allow meta-modelling of exceptional use cases. The extended meta-model in Fig. 5–7 includes elements to model exceptions and handlers in textual use cases. In addition to StandardUseCase, we added two
other subclasses of Use Case: ExceptionalUseCase and Handler Use Case which inherits
all properties and associations of use cases. Extensions is defined to be either an AlternateBlock (containing alternate behaviour) or an ExceptionalBlock (containing exceptional
behaviour). ExceptionalBlock is associated to one or many Exception. The Actor class has
been extended with two subclasses: ExceptionalPrimaryActor and ExceptionalSecondaryActor which are associated to HandlerUseCase and ExceptionalUseCase respectively.
The meta-model covers the structure and elements of use cases as we deploy them,
but is not meant to be interpreted as a workflow language for use cases.
5.4.2
Exceptional Use Case Diagram Metamodel
Fig. 5–8 shows how all the extensions to use case diagrams required to model dependability mentioned in Section 5.1.3 are integrated with the UML 2.0 metamodel.
HandlerUseCase is defined as a stereotyped extension of UseCase, and therefore inherits all properties and associations of standard use cases. An Interrupt relationship is
modeled in a similar way as Extend and Include relationships. An Interrupt relationship,
however, must be associated with exactly one HandlerUseCase (triggeredHandler ), and
interrupts exactly one standard or handler use case (interruptedCase). The two different
interrupt relationships, i.e. interrupt and continue and interrupt and fail, are modeled as
subclasses of Interrupt. Finally, Exception inherits from RedefinableElement, just as ExtensionPoint does. An Interrupt relationship can be triggered by one or multiple exceptions
(triggeredException).
5.4.3
Activity Diagram Metamodel
Our activity diagrams are based on the UML 2.0 activity diagram meta-model. We
did not have to extend or modify the meta-model. The constructs available were adequate
for modelling our exceptional use cases. The activities meta-model contains numerous
elements, packages, and dependencies. For details on the abstract syntax of the metamodel, please refer to the UML superstructure [164].
63
5.4. Requirements Metamodels
excGoal
Extended
Header
class:
contextNexc:
1
1..*
Header
name:
scope:
intention:
level:
freqNmul:
precondition:
postcondition:
Use Case
Main
Scenario
0..1
Extensions
0..*
Primary
Actor
Secondary
Actor
participant
{ordered}
0..*
{ordered}
1..*
1
Main Step
Actor
excActor 0..*
Exceptional
Primary Actor
1..*
Standard
Use Case
1
1
actor
goal
1..*
Exceptional
Use Case
1
scenario
1
goal
Handler
Use Case
Extension
Block
Alternate
Block
alternate
Exceptional
Secondary
Actor
{ordered}
1..*
Extension
Step
excParticipant 0..*
Exceptional
Block
excScenario
defExc
result
0..*
result
Step
event 0..*
Interaction
Send
Request
1..*
Exception
1
Outcome
1
Invokation
Condition
Receive
Event
Figure 5–7: Exceptional Use Case Metamodel
64
Control Flow
5.4. Requirements Metamodels
Redefinable
Element
Behavioured
Classifier
Classifier
ownedUseCase
{subsets
ownedMember}
Extension
Point
1..*
{ordered}
extensionLocation
triggering 1..*
Exception
* useCase
<<stereotype>>
Handler
UseCase
extension
{subsets source}
1 1
extend {subsets ownedMember} * *
extended
Case
{subsets
target}
Exception
0..1 * subject
1
useCase
*
extensionPoint
1
{subsets ownedMember}
Actor
addition
{subsets
target}
1
*
1 includingCase
{subsets source}
include {subsets
* ownedMember}
1
interrupted
1
Case
{subsets target}
*
*
*
Extend
Include
Interrupt
triggeredHandler
{subsets source}
1..*
0..1
condition
0..1 {subsets ownedElement}
Named
Element
Constraint
Directed
Relationship
Interrupt
AndContinue
Interrupt
AndFail
Figure 5–8: Extended Use Case UML 2.0 Metamodel
5.4.4
Communication Diagram Metamodel
We have adapted the UML communication diagram meta-model by appending model
elements with stereotypes and icons to represent exceptions, timed messages, and message
contexts. The only model element that needs customization is the Message element and
some of its attributes. For details on the abstract syntax of the meta-model, please refer
to Chapter 14 of the UML superstructure [164]. A simplified form of the interactions
meta-model is shown in [74].
We extended the meta-model syntax in the following manner. The model elements
adapted are shown in Fig. 5–9.
• The enumerated list of MessageSort is appended with a new message sort, asynchTimedSignal, which is a variation of asynchSignal. The semantic meaning would be “a message
was generated by an asynchronous send action with a deadline associated”.
• The Message class is extended with a mandatory attribute: MessageContext.
The context type might be use case or handler use case. In the latter case, the
context is shown visually using italics.
• The Message class is extended with an optional attribute: MessageConcern. A
message can be associated to reliability, safety, and/or timing using this attribute.
65
5.5. Case Study: Elevator Control System
Message
<<eAttribute>> /messageKind: MessageKind
messageSort: MessageSort
messageConcern: MessageConcern[]
messageContext: MessageContext
messageException: ExceptionName[]
timerCancel: MessageName
<<enumeration>>
MessageSort
synchCall
asyncCall
asynchSignal
asynchTimedSignal
createMessage
deleteMessage
reply
<<enumeration>>
MessageKind
complete
lost
found
unknown
<<enumeration>>
MessageContext
use case
handler use case
<<enumeration>>
MessageConcern
reliability
safety
timing
Figure 5–9: Communication Diagram Meta Model: Adapted Model Elements
The first two concerns are visually shown using stereotypes <<r>> and <<s>>. A
timed message is depicted with a deadline (hourglass icon).
• The Message class is extended with optional attributes: MessageException. The
notation to use for the exception is an exception pin (tiny triangle) followed by the
exception name within braces. This should be preceded by a MessageContext.
• The Message class is extended with optional attributes: timerCancel. In case of
a receive event message, if a timer was associated to the corresponding send request
message, the message is appended with the send event identifier and tagged with a
timer cancel pin (hourglass icon with a vertical line across).
5.5
Case Study: Elevator Control System
In this section, we illustrate our requirements elicitation and specification models by
means of a case study. The modelling notations introduced in this chapter are depicted by
using a subset of the Elevator Control System (ECS) case study: Elevator Arrival. The
complete case study is presented in Chapter 9.
An elevator control system is a hard real-time application requiring high levels of
dependability. In our case study for the sake of simplicity, there is only one elevator
cabin that travels between the floors. The job of the development team is to decide on
the required hardware, and to implement the elevator control software that processes the
66
5.5. Case Study: Elevator Control System
user requests and coordinates the different hardware devices. Initially, only “mandatory”
elevator hardware has been added to the system:
• a motor that the elevator control software can use to make the elevator cabin go up,
go down or stop
• a cabin door that the elevator control software may ask to open and close
• floor sensors that detect when the cabin is approaching a floor
• two buttons on each floor (except for the top and ground floors) to call the lift, one
for going up, one for going down
• a series of buttons, one for each floor, inside the cabin
5.5.1
Elevator Arrival Subsystem: Standard Use Cases
Standard use case-driven requirements elicitation applied to the elevator control system results in the use case diagram shown in Fig. 5–10. In the elevator system there is
initially only one primary actor, the User. A user has only one goal with the system: to
take the elevator to go to a destination floor. The primary actor (User ) is the one that
initiates the TakeElevator use case. All secondary actors (the Door, the Motor, the Exterior and Interior Floor Buttons, as well as the Floor Sensors) that collaborate to provide
the user goal are also depicted.
To ride the elevator the User enters the cabin, selects a destination floor, waits until
the cabin arrives at the destination floor and finally exits the elevator.
CallElevator and RideElevator both include the ElevatorArrival use case. Fig. 5–11
shows the details of Elevator Arrival, the subfunction-level use case that describes how
the system interacts with the external devices, i.e., sensors, motor and door, to direct the
elevator cabin to the desired floor.
5.5.2
Elevator Arrival Subsystem: Exceptional Use Cases
Fig. 5–12 shows a sample of an exceptional use case. The ElevatorArrival standard use
case (Fig. 5–11) is refined to include exceptional behaviour that can interrupt the elevator
arrival subfunction. Development of the use case is carried out by applying the process described in Chapter 6. The extensions section of the use case template specifies what is to be
done when exceptional situations can occur. The service-related exceptions that can occur
during the execution of the use case, MotorStartFailure, MissedFloor, MotorStopFailure,
and DoorStuckClosed, are shown in the extensions section of the use case in Fig. 5–12.
67
5.5. Case Study: Elevator Control System
0..*
Elevator Control System
Take
Elevator
>>
<<
de
clu
in
clu
de
in
<<
>>
User
Call
Elevator
Ride
Elevator
<<
>
inc
lud
e>
lud
e>
>
inc
<<
Motor
1
Door
1
Elevator
Arrival
2..*
Floor
Sensor
Figure 5–10: ECS: Standard Use Case Diagram
Use Case: ElevatorArrival
Primary Actor: N/A
Intention: System wants to move the elevator to the User ’s destination floor.
Level: Subfunction
Main Success Scenario:
1. System asks motor to start moving the cabin in the direction of the destination floor.
2. System detects elevator is approaching destination floor.
3. System requests motor to stop.
4. System opens door.
Use case ends in success ReachedDestination.
Figure 5–11: ECS: Elevator Arrival Use Case
The possible outcomes of the user goal along with the outcome type are also specified in
the use case.
As shown in Fig. 5–12, our use cases adhere to a pre-defined template and structure.
Every numbered step either describes a basic interaction between the environment (one or
several actors) and the System, or references an included subfunction-level use case. Basic
interactions are classified as either input interactions, or output interactions.
68
5.5. Case Study: Elevator Control System
Use Case: ElevatorArrival
Primary Actor: N/A
Intention: System wants to move the elevator to the User ’s requested floor.
Level: Subfunction
Main Success Scenario :
1. System asks Motor to start moving towards the destination floor.
2. Movement Sensor informs System that cabin is moving.
3. Approaching Floor Sensor informs System that the cabin is approaching destination floor.
4. System requests Motor to stop.
5. Floor Sensor informs System that elevator is stopped.
6. System requests Door to open.
7. Door Sensor informs System that door is open.
Use case ends in success ReachedDestination.
Extensions :
2a. Exception{MotorStartFailure}
2a.1 Use case continues at step 1.
2a.1a Retried 3 times. Use case ends in f ailure MotorFailure.
3a. Exception{MissedFloor }:
3a.1 System chooses to approach a neighboring floor.
Use case continues in degraded DifferentFloor at step 1.
5a. Exception{MotorStopFailure}
5a.1 Use case ends in f ailure MotorFailure.
7a. Exception{DoorStuckClosed }
7a.1 Use case continues at step 6.
7a.1a Retried 3 times. Use case ends in f ailure DoorStuckClosed.
Figure 5–12: ECS: ElevatorArrival Exceptional Use Case
5.5.3
Elevator Arrival Subsystem: Exceptional Use Case Diagram
In parallel with the elaboration of the individual use cases and handlers, we proposed
to build an extended exception-aware use case diagram providing a detailed and precise
summary of the partitioning of the system into normal and exceptional interactions.
Fig. 5–13 shows a partial use case diagram of ECS that depicts the services offered. The
diagram in Fig. 5–13 uses the exceptional use case formalism (described in Section 5.1.3)
to depict the reliability and safety handlers that take control in exceptional situations to
guarantee dependable operation of the elevator.
5.5.4
Elevator Arrival Subsystem: Degraded Outcomes
This subsection illustrates how degraded outcomes can be expressed within use case
templates. The ElevatorArrival use case can end in four possible outcomes: ReachedDestination, MotorFailure, DifferentFloor, DoorStuckClosed. The first outcomes is the success
69
5.5. Case Study: Elevator Control System
0.
.*
Elevator
Operator
1
Elevator Control System Exception:
{EmergencyOverride}
Exception:
{EmergencyStop}
Movement
Sensor
1
Door
Sensor
2.
.*
Floor
Sensor
Take Elevator
<<interrupt
& fail>>
>
e>
lud
inc
<<
User
Emergency
<<interrupt &
continue>>
<<
<<include>>
inte
rru
pt &
<<include>>
fail
Cabin
Button
1
>>
<<safety handler>>
Emergency
Brake
Ride Elevator
Call Elevator
<<i
<<include>>
ncl
ude
>
Exception:
{MotorStopFailure}
Floor
Button
1
>
*
Elevator
Arrival
Exception:
{DoorStuckClosed}
Appr Floor
Sensor
1
<<reliability handler>>
Motor
1
User
1
<<safety handler>>
<<safety handler>>
ReturnTo
GroundFloor
0..
*
Retry
Door
pt &
rru >>
inte
<< ntinue
co
<<interrupt &
continue>>
<<reliability handler>>
Retry
Motor
Exception:
{MotorStartFailure}
<<i
nt
con errup
tinu t &
e>>
Exception:
{MissedFloor}
<<reliability handler>>
Redirect
Elevator
Stop
Button
1
Emergency
Display
1
Brake
Door
Figure 5–13: ECS: Partial Exceptional Use Case Diagram
outcome produced if the elevator successfully arrives at the requested destination. MotorFailure and DoorStuckClosed are failure outcomes which result due to exceptional behaviour of external devices. The outcome, MotorFailure, results due to either MotorStartFailure or MotorStopFailure exception.
An interesting exceptional situation is MissedFloor. It can occur instead of step 3 of
the main success scenario. If the floor sensor of the destination floor is broken, the system
might receive a message from a sensor of a different floor, or no message at all. Once this
exceptional situation is detected, the system chooses a neighboring floor, and instructs the
motor to move to that floor instead. The degraded outcome of the Elevator Arrival use
case is reached at the end of the scenario. If the main success scenario completes step 7,
but the reached floor is not the requested floor, then the use case ends in the degraded
outcome DifferentFloor.
70
5.5. Case Study: Elevator Control System
5.5.5
Elevator Arrival Subsystem: Activity Diagrams
The exceptional use cases of ECS are mapped to activity models by applying the
transformation rules defined in Chapter 8. The ElevatorArrival activity and one of its
subactivities StopMotor are shown here to illustrate the syntax and semantics of the specification model used to represent exceptional use cases. The activities are only briefly
discussed in this chapter. A more detailed description is included in Chapter 9.
Stop Motor
Stop Motor Motor Stopped
10ms
<<failure>>
MotorStopFailure
<<success>>
Stopped
Figure 5–14: ECS: Stop Motor Activity Diagram
The Stop Motor activity depicted in Fig. 5–14 illustrates the construction of the leaf
activities of our mapping. It specifies that first a StopMotor signal is sent (to the Motor actor) depicted by the StopMotor SendSignalAction. Then the System waits for a
MotorStopped acknowledgement signal (from the MotionSensor actor) modelled using the
AcceptSignalAction MotorStopped. If this signal is received (in time), the activity ends
successfully (depicted by a success stereotyped output pin). If on the other hand
the deadline (10ms) passes and no signal has been received, then the activity fails (shown
by a f ailure stereotyped output pin).
Fig. A–5 shows StopMotor in the context of ElevatorArrival. After a successful StopMotor, the flow of ElevatorArrival continues to the activity OpenDoor. If StopMotor fails,
however, ElevatorArrival also fails (modelled by f ailure MotorFailure). The ElevatorArrival activity has 4 different outcomes, as mapped from the use case outcomes.
It can either succeed ( success ReachedDestination), provide a degraded outcome
71
5.5. Case Study: Elevator Control System
Elevator Arrival
Start Motor
<<success>>
Started
Wait for Event
Approaching
Dest. Floor
<<success>>
TryAgain
<<failure>>
MotorStart
Failure
<<handler>>
Retry Motor
<<failure>>
RetryFailure
<<success>>
TryDifferentFloor
<<failure>>
MissedFloor
<<handler>>
Redirect Elevator
<<success>>
FloorDetected
Stop Motor
<<failure>>
MotorStopFailure
<<success>>
Stopped
Open Door
<<success>>
TryAgain
<<failure>>
DoorStuck
Closed
<<handler>>
Retry Door
<<success>>
Opened
<<failure>>
RetryFailure
[else]
[reachedFloor =
desiredFloor]
<<success>>
ReachedDestination
<<degraded>>
DifferentFloor
<<failure>>
DoorStuckClosed
<<failure>>
MotorFailure
Figure 5–15: ECS: Elevator Arrival Activity Diagram
( degraded DifferentFloor ), or fail ( f ailure DoorStuckOpen or f ailure MotorFailure).
The degraded outcome is provided in the case where the WaitForEventApproachingDestFloor activity fails with MissedFloor. In this case, the RedirectElevator handler
72
5.5. Case Study: Elevator Control System
activity directs the cabin to a neighboring floor. After successfully stopping and opening the door, the ElevatorActivity then ends in the degraded outcome degraded DifferentFloor, since the reached floor is different from the requested floor.
A final example that illustrates the use of modelling activity outcomes and in particular degraded outcomes can be seen in the activities CallElevator and RideElevator (figures
shown in Chapter 9). Both activities include the ElevatorArrival activity. In the context
of CallElevator, a DifferentFloor degraded outcome of ElevatorArrival results in failure,
since the cabin never reaches the floor where the user waits. In the context of RideElevator, however, a degraded outcome of ElevatorArrival results in a degraded outcome of
RideElevator : since the cabin has stopped at a neighboring floor, the user just has to walk
up or down one flight of stairs.
5.5.6
Elevator Arrival Subsystem: Exceptional Communication Diagram
Fig. 5–16 shows a partial exception-aware communication diagram of the Elevator
Control System. The diagram is created based on the interactions defined earlier in this
section, and hence only includes message exchanges between the system and its environment that are part of Elevator Arrival. The actors are added based on the actors defined
in Fig. 5–13. The input and output messages are defined based on the exceptional use case
interactions, Fig. 5–12. The actors which are associated to the elevator arrival interactions include motor, door, door sensor, movement sensor, at floor sensor, and approaching
floor sensor. The EmergencyBrake handlers defined for the MotorStopFailure exception
communicates with additional actors EmergencyBrake and EmergencyDisplay. The exceptions associated with each event are listed at the end of the message, such as exception
DoorStuckClosed which might occur during the OpenDoor interaction. The exception is
detected using a timeout mechanism, and hence a timer symbol is attached to the message.
If the doorOpened message is received from the actor DoorSensor within deadline, the exception does not occur and the timer associated to the event is cancelled (shown next to
the input message doorOpened: ElevatorArrival.
The reliability and safety values are meta information, and hence not shown in the
model.
73
74
<<r>>
: Door
<<s>> <<r>>
: Motor
1
doorOpened: ElevatorArrival{
motorStopped: EmergencyBrake{
motorStopped: ElevatorArrival{
motorStarted: ElevatorArrival{
1
openDoor}
: Door
Sensor
: Movement
Sensor
1
stopMotor}
stopMotor}
startMotor}
: At Floor
Sensor
1
: Approaching
Floor Sensor
*
MissedFloor}
reachedFloor: ElevatorArrival
: exception, <<s>>: safety-critical, <<r>>: reliability, handlers are shown in italics
<<time-triggered>>
: Elevator Control System
apprFloorDetected: ElevatorArrival {
Figure 5–16: ECS: Partial Exceptional Interaction Diagram
: timeout,
DoorStuckClosed}
: timed message,
openDoor: ElevatorArrival{
stopMotor: EmergencyBrake
MotorStopFailure}
MotorStartFailure}
stopMotor: ElevatorArrival{
startMotor: ElevatorArrival{
<<s>> turnOn: EmergencyBrake
<<s>> activate: EmergencyBrake
<<s>> <<r>>
<<s>> <<r>>
1
: Emergency
Display
: Emergency
Brake
1
1
5.5. Case Study: Elevator Control System
5.6. Summary
5.6
Summary
This chapter is focused on formalisms and notations that are necessary to integrate
exceptions in requirements development. We presented use case models, activity diagrams,
and communication diagrams to be used during requirements elicitation and specification
of dependable systems.
We integrated dependability concerns and means in use cases by extending the syntax
and semantics of traditional use cases. We proposed exceptional use cases that can drive
the elicitation of reliability and safety requirements. An exceptional use case captures
basic, alternate, and exceptional flows on execution using text (in most cases English). We
extended the standard use cases template to allow specification of exceptions, handlers, and
exceptional outcomes. The relationships, < <interrupt & continue> > and < <interrupt
& fail> >, are defined to specify how the exception affects the execution of the user goal.
We also show how to extend UML use case diagrams to separate normal and exceptional
behavior. This allows developers to graphically show the dependencies among standard
and handler use cases. The extensions to the notation are summarized in Table 5–1.
The use cases can become very complex, and hence are not always trivial to understand. Hence, we propose using activity diagrams as our requirements specification artifact.
As stated by Anderson in [6]: although we talk of requirements, a use case model is in fact
a specification at some level of detail and accuracy. Although we talk of analysis, in fact
synthesis is the key; those involved are co-creating a specification that satisfies the client’s
requirements. We synthesize our use case model and express the scenarios using UML 2.0
activity diagrams. The activity diagram formalism offers constructs to model conditional
flow, hierarchy, and exceptional flow and hence provide an effective base for representing
our exceptional use cases. We have integrated exception handling concepts in activity diagrams with the help of UML stereotypes, and have shown how degraded service outcomes
can be specified precisely in the diagrams. The resulting activity diagrams give a graphical
representation of the scenarios, and form a more formal and unambiguous specification.
The activity diagram notations used are summarized in Table 5–2.
The activity diagrams however should not be seen as a replacement for use case diagrams, but as a means of summarizing the interaction flow and supplementing the use case
models. The models must be maintained and consistency must be ensured. Modifications
in use cases should reflect a change in activity diagrams.
75
5.6. Summary
Table 5–1: Use Case Diagrams: Summary of Notations
Graphical Symbol
Standard
Name
use case
use case
actor
includes relationship
extends relationship
dependency
< <includes> >
< <extends> >
Extensions
Exception:
{Name}
exception
exceptional actor
<<exceptional>>
<<reliability handler>>
handler
reliability handler
<<safety handler>>
handler
< <interrupt & continue> >
< <interrupt & fail> >
safety handler
interrupt & continue relationship
interrupt & fail relationship
We propose complementing the activity model with an interaction model, communication diagrams in our case. The activity model includes several activity diagrams which
detail the interactions. The interactions are classified as input or output messages to and
from the system, and shown in one view as a communication diagram. We extend the
formalism to allow modelling of dependability attributes (reliability and safety), threats
(exceptions), and means (handling) as messages. Table 5–3 gives a summary of the notation
used in our interaction model formalism.
We have defined a meta-model for textual use cases (based on the Fondue use case template), and have extended the meta-model with constructs necessary to model exceptional
use cases. We have discussed how we adapted the UML 2.0 activity diagram meta-model
to allow us to model exceptional use cases as activity models, and also how we extended the
communication diagram meta-model to address dependability concerns. Our extensions to
use cases, activity diagrams, and communication diagrams have been illustrated using a
small example from the Elevator Control System case study.
76
5.6. Summary
Table 5–2: Activity Diagrams: Summary of Notations
Graphical Symbol
Standard
Name
Activity
activity
call
action node
call action node
send signal
send signal action
accept event action node
accept time event action node
[condition]
[condition]
decision node
merge node
fork node
join node
pin
exception pin
control flow edge
interrupting edge
interruptible region
Extensions
<<handler>>
handler node
handler node
<<success>>
success outcome
<<degraded>>
degraded success outcome
<<failure>>
failure outcome
<<abandoned>>
abandoned outcome
77
5.6. Summary
Table 5–3: Communication Diagrams: Summary of Notations
Graphical Symbol
Standard
Name
: System
<<time-triggered>>
system entity
actor
communication channel
message: Context
asynchronous message
message: Context
message return
Extensions
message: Use Case Context
message: Handler Context
message and context
message and handler context
timed message pin
timer cancel pin
exception pin
reliability tag
safety tag
<< r >>
<< s >>
<<exceptional>>
exceptional actor
78
CHAPTER 6
DREP: A Dependability-Oriented Requirements
Engineering Process
When developing dependable systems, software developers need to address dependability concerns and threats, and integrate means to attain required levels of dependability.
When using a standard software development process to develop systems, there is no guarantee that such situations and concerns are considered during development. Whether the
system can handle these situations or not depends highly on the imagination and experience of the developers. In addition, even if the application can actually deal with these
special situtations, the particular way that the developer chose to address that situation
might not be the one that a typical user of the system would expect if it was not explicitly
agreed upon and documented in the requirements. As a result, the final application might
not function correctly in all possible situations or react in unexpected ways. This can at
best annoy or confuse the user, but can also have more severe repercussions. A user that
somehow expects the system to react to an exceptional situation in a certain way, but then
realized that the system behaves differently, could panic and do something really bad.
During the development of dependable systems, nothing should be left to chance.
Following the idea of integrating exception handling into the software life cycle [81, 55],
this work describes an extension to standard use case-based requirements development
that leads the developers to consider dependabaility issues early on. Our approach focuses
in particular on reliability and safety concerns. We believe that thinking about behaviour
or events that affect the reliability or safety of the system has to start at the requirements
phase, because it is up to the stakeholders of the system to decide how they expect the
system to react to exceptional situations. Only with exhaustive and detailed user feedback
79
6.1. A Dependability-Oriented Requirements Engineering Process
is it possible to discover and then specify the complete system behavior in a subsequent
analysis phase, and decide on the need for employing fault masking and fault tolerance
techniques for achieving run-time dependability during design.
This chapter describes our Dependability-Oriented Requirements Engineering Process (DREP) that leads the developers to consider dependability issues early on during
software development. The process is based on the concepts and notations introduced in
Chapter 4 and 5. DREP leads developers to consider exceptional situations, degraded services and outcomes, recovery measures, and exceptional modes of operations (as defined
in Chapter 4) following a goal-driven approach . The artifacts created when applying the
process use the use case and activity diagrams notations described in Chapter 5.
The chapter is structured as follows: Section 6.1 describes our proposed process. Section 6.2 presents DREP in the context of model-driven engineering. The process is illustrated by means of the ECS case study in Section 6.3. Section 6.4 gives a summary of our
process.
6.1
A Dependability-Oriented Requirements Engineering Process
Our Dependability-Oriented Requirements Engineering Process (DREP) targets the
development of dependable reactive systems. It defines for each of the requirements development activities detailed steps or tasks that lead the developer to pay particular attention
to system safety and reliability when performing requirements elicitation, specification and
analysis. The activities outlined in the requirements process does not necessarily have to
follow a strict sequence. More often, the elicitation, specification, and analysis tasks are
quite interleaved, and iterative in nature. Usually, requirements analysis continues during
specification, and it is quite usual to have new requirements being discovered throughout
the process. The following subsections describe the different activities in detail.
The basic tasks carried out as part of these activities in DREP are outlined in a
hierarchical manner in Fig. 6–1. To clearly illustrate our extensions, the tasks that are
part of standard use case analysis are shown in boxes with dashed line borders.
6.1.1
Requirements Elicitation and Discovery
Task 1: Discovering Actors, Goals, and Modes The first task is divided into several
sub-tasks.
80
6.1. A Dependability-Oriented Requirements Engineering Process
Services
Exceptional Services
Handlers
1.1 Brainstorm
Services/Goals,
and Outcomes
Actors
Modes
Exceptions
1.5 Brainstorm
Modes
2.1 Brainstorm
Context-Affecting
Exceptions
Reliability &
Safety
1.2 Brainstorm
Actors
2.2 Define New
Exceptional
Detection Actors
1.3 Classify
Services/Goals and
Actors
3.1 Discover &
Classify
Exc. Services
1.4 Decompose
Services into
Subgoals
3.2 Decompose
Exc. Services into
Subgoals
5.1 Design Goal
Interaction Steps
5.4 Design Handler
Interaction Steps
5.2 Specify Goal
Outcomes
5.5 Specify Handler
Outcomes
3.3 Discover New
Exceptional
Secondary Actors
4.1. Elicit Expected
Rel. & Safety
for Services
4.3. Discover
Exceptional Modes
4.2. Document Rel.
& Safety
of Sec. Actors
5.3 Define New
(Exceptional)
Secondary Actors
6.1 Document
Expected Rel. &
Safety for Actors
5.6 Add Mode
Switches to
Handler Steps
6.3 Define
Service-Related
Exceptions
6.2 Annotate
Subgoal & Handler
Steps w/ Rel & Saf
7.1 Create/Revise
DA-Chart
7.2 Perform
Rel. & Safety
Analysis
7.3 Compare
Dependability
Analysis Results
8.1 Add Detection
Actors
8.2 Add Detection
Interaction Steps,
Update Outcomes
8.3 Add Detection
Interaction Steps
for Handlers
9. Define Rel. or
Safety Handler
11.1 Create
Standard Use Case
Diagram
11.2 Create
Exceptional Use
Case Diagram
10. Define
Degraded Modes
11.3 Create
Summary Actor List
12.2. Create Mode
Summary
12.1. Create
Exception
Summary Table
11.4 Document
Achieveable Rel. &
Safety for Services
13. Create Activity
Diagrams
14. Construct
Communication
Diagram
Requirements Elicitation and Discovery
Requirements Definition and Specification
Dependability Assessment
Requirements Summary and Documentation
Dependability-based Refinement
Figure 6–1: Task Structure of DREP
81
6.1. A Dependability-Oriented Requirements Engineering Process
1.1 Brainstorm services/goals and outcomes
1.2 Brainstorm actors
1.3 Classify services/goals and actors
1.4 Decompose services into subgoals
1.5 Brainstorm modes
The first activity in use case based requirements elicitation consists in establishing a
list of actors and stakeholders, with a special emphasis on primary actors, i.e. external
entities in the environment that interact with the system in the pursuit of a well defined
goal. Secondary actors are also documented during this brainstorming activity, if their use
is indeed part of the requirements and is not already part of the solution domain.
For each of the discovered goals, a use case outline is written. This outline consists in
a textual summary of the goal, an explanation of the context in which the primary actor
wants to achieve the goal, and a clear description of the value or service that the system has
to provide to satisfy the primary actor. Complex goals can be split into several subgoals to
form a hierarchy [43], in which case a use case outline is written for each of the subgoals.
The goals are further classified as normal services or other special services.
The brainstorming activity can also lead the developer to discover that a given service
might have several acceptable outcomes, i.e., the system can satisfy the goal of the primary
actor in multiple ways.
Finally, during this task, the developer should also consider possible modes of operation
to be offered by the system. An operation mode (discussed earlier in Chapter 4) is defined
by the set of services that the system offers when operating in that mode During normal
operation, a system should try and provide all of the services it is intended to provide at
any given time. There is no need to artificially create different normal modes of operation.
Some systems, however, need more than one normal mode of operation, and allow the user
to switch between these modes by request or to accommodate changes in the environment.
For example, a cell-phone can be put into a child-safe mode, in which the only service
offered is to place local calls. When the creation of different normal modes is necessary,
then the developer should ensure that the set of services offered within a normal mode is
coherent.
Task 2: Discovering Context-Affecting Exceptions Task 2 involves carrying out the
following two sub-tasks.
2.1 Brainstorm context-affecting exceptions
82
6.1. A Dependability-Oriented Requirements Engineering Process
2.2 Define new exceptional detection actors
In this step, the developer has to focus on context-affecting exceptional situations
(defined in Chapter 4 Section 4.2.1), i.e., situations that change the context in which the
system operates. Certain context changes might require a dependable system to adapt in
order to continue to provide reliable and safe service.
Context-affecting exception discovery is done in a top-down manner, starting at the
system-level.
System Level At the system level, the analyst should focus on what could prevent the
system as a whole from being operational. Interesting things to consider include:
the operational needs of the system, e.g. power source, accessibility, connectivity;
and anything that will draw away the attention of an actor, e.g. emergencies, safety
concerns, malicious behavior.
Use Case Level At the use case level, the analyst should consider situations that could
(temporarily) change the goal of the primary actor (without considering the failure of
individual interactions contained within). Sometimes it even makes sense to consider
sub-function level use cases and how their interaction could be interrupted due to
external conditions.
Interaction Step Level There are rarely context-affecting exceptions that are discovered
at the interaction step level. This is due to the fact that these exceptional situations
occur in the environment, and therefore can happen anytime. It only makes sense to
relate them to a single interaction step if all other interaction steps of the use case
are not affected by the exception.
To help discover these situations, we have framed the following questions that developers should address:
• What situations / conditions / changes in the environment make it impossible for the
entire system to provide safe service? In such situations, should the system provide
some other service?
• What situations / conditions / changes in the environment prevent the system from
satisfying a primary actor’s goal (or subgoal)? In such situations, can the system
partially fulfill the service?
• What situations take priority over the primary actor’s goal?
• What situations / conditions / changes in the environment could make the primary
actor change his goal? In such situations, how can the primary actor inform the
system of the goal change?
83
6.1. A Dependability-Oriented Requirements Engineering Process
For each exceptional situation that is discovered, a named exception is defined, together
with a small text that describes the situation in more detail. All discovered exceptions are
documented in an exception table.
This activity typically leads to the discovery of new exceptional goals. Often, the
occurrence of the situation cannot be detected by the system without help from the environment, which means that new exceptional actors have to be introduced. For example, in
an elevator system where safety is the main concern, in case of a fire outbreak in the building, the elevator operator or a smoke detector, both exceptional actors, should activate the
fire emergency mode of the elevator control software.
Task 3: Eliciting Handlers for Context-Affecting Exceptions
This task is split into the
following sub-tasks.
3.1 Discover and classify exceptional services
3.2 Decompose exceptional services into subgoals
3.3 Discover new exceptional secondary actors
For each identified context-affecting exception in Task 2 , a handler use case outline
has to be established describing how the system is supposed to react or recover from that
situation. A handler can be further classified as a safety or reliability handler depending on
the concern it attempts to satisfy. A handler can also be linked to one or several contexts,
i.e. use cases during which the exceptional situation can occur. Upon occurrence of the
exception, the current interaction is interrupted and the exceptional interaction begins. In
an elevator system, for example, in case of a fire outbreak signalled by a smoke detector,
standard elevator operation is interrupted. To ensure safety, the elevators are brought to
the ground floor.
Task 4: Eliciting Dependability Expectations and Discovering Exceptional Modes
This
task is split into the following sub-tasks.
4.1 Eliciting dependability expectations for each service
4.2 Document provided reliability and safety of mandatory secondary actors
4.3 Discover exceptional modes of operation
For dependable systems, it is at this phase important to discover the requirements
with respect to safety and reliability for each service that the system provides. This
is done in sub-task 4.1. Mission and safety-critical systems often have to comply with
safety standards, but even if the requirements do not require compliance with a standard,
84
6.1. A Dependability-Oriented Requirements Engineering Process
stakeholders and primary actors explicitly or implicitly expect a certain degree of safety and
reliablility from a dependable system. To document the desired dependability, reliability
and safety annotations have to be added to the use case outlines that, for each goal, specify
the desired probability of successful achievement of the goal, as well as the maximum
tolerable probability of occurrence of a safety violation. Probabilities in requirements
models are further discussed in Chapter 7.
The desired safety and reliability values should be elicited not only for the normal
services of the system, but also for the new exceptional goals discovered in Task 2.
It is important to note here that in the real world, 100 percent dependability is never
achievable. If the specified safety and reliability are too high, then it might be impossible (or
too expensive) to implement a system that fulfills the requirements. It is hence important
that the stakeholders decide on acceptable risks at this point.
In sub-task 4.2, , for each service offered by a mandatory secondary actor, the developer
has to document the service’s reliability and safety properties. If the secondary actor is a
piece of hardware, then the reliability can be found in the specification manual.
Sub-task 4.3 concentrates on exceptional modes of operation. Whenever a dependable
system has encountered difficulties performing a requested service due to some exceptional
situation, the effect of the encountered problem on future service provision of the system
has to be evaluated. If the reliability or safety of future service provision is threatened,
then a mode switch is necessary. Switching to a different operation mode (an exceptional
mode) allows the system to signal to the environment that the services offered by the
system have changed, and reject any requests for services that cannot be performed with
sufficient reliability or safety. We have earlier addressed exceptional modes of operation in
the behavioural models used in DREP, and details can be found in Chapter 5.
While normal modes of operation have been discovered in Task 1.5, this task concentrates on the discovery of emergency and restricted modes (please refer to Chapter 4 for
definitions of modes).
To discover emergency and restricted modes, all context-affecting exceptions identified
in Task 2.1 need to be considered. In a new context, some of the services provided under
normal circumstances might not be adequate anymore. Therefore, the developer should
reflect on the impact of the context change on each of the services provided by the system.
If the safety of normal services is threatened by a situation, then an appropriate exceptional
or emergency mode should be defined.
85
6.1. A Dependability-Oriented Requirements Engineering Process
If during this task new modes of operation have been defined, then it is important
to specify the expected reliability and safety of each service (see Task 4) provided in each
mode.
It is important to note that mode definitions are not based on the developer’s creativity.
Each mode has to be validated with the stakeholders to check if, according to them, the
services provided in the mode form a coherent set, and that the provided levels of reliability
and safety for each service are sufficient.
6.1.2
Requirements Definition and Specification
Now that the goals and subgoals have been identified, detailed use case descriptions
have to be elaborated for each of them. We suggest to describe use cases with a pre-defined
template as done by others [189], which forces the developer to explicitly document all
relevant features. Use cases are described in Chapter 2.
Reactive systems only perform work or produce output after they receive an input
event. Therefore, the main parts of our use case template consist of a numbered list of individual base interaction steps, each one describing either an input interaction – an external
actor decides to send a message/data/event to the system – or an output interaction – the
system sends a message/data/event to an external actor. If a use case is decomposed into
subfunction-level use cases, a step can also be a reference to a lower level use case, which
in turn describes the base interaction steps that leads to the completion of the subgoal. In
any case however, a use case describing a user goal could be flattened into a sequence of
base interaction steps, if needed.
Task 5: Designing Interactions
Interaction design in DREP is comprised of several sub-
tasks.
5.1 Design goal interaction steps
5.2 Specify goal outcomes
5.3 Define new (exceptional) secondary actors
5.4 Design handler interaction steps
5.5 Specify handler outcomes
5.6 Add mode switches to handler steps
The standard way of achieving a goal is described in the main success scenario part of
the template. The ordering of the individual interaction steps are often dictated by logic,
86
6.1. A Dependability-Oriented Requirements Engineering Process
by required usage patterns, by user interfaces, or by protocols enforced by secondary actors
interacting with the system. Where flexibility exists, the stakeholders should be consulted
to choose the most adequate interaction pattern.
When designing the goal interaction steps, it is also necessary to define the service
outcome. The main success scenario of a user goal can end in only one possible way, and
the use case should clearly show this. From the users’ perspective, the goal outcome can
be one of the following: success , f ailure , or abandoned 1 . If alternate
scenarios are available, it is also necessary to specify the outcome of all such alternate
paths, and to document them in the use case extension section.
When the requested service cannot be provided, a dependable system should strive
to handle the current situation and attempt to provide partial service, if possible. Partial
service, or degraded service outcome (introduced in Chapter 4 Section 4.3) as we call it,
happens when a service does not deliver what initially promised, but yet provides something
that potentially satisfies the requester of the service. A degraded outcome is better than a
complete failure to deliver the service.
Intuitively, a service provision can only result in a degraded outcome when an exceptional situation has occurred. Reacting to such an exceptional situation, and providing a
well-defined outcome can only be done within a handler use case. Therefore, after the detailed interaction steps of a handler have been designed, the outcome of the handler should
be clearly defined. Handlers can end in success , degraded or f ailure .
Whenever an exception has lead to the definition of a new mode, then the steps of the
handler that addresses the exception have to be updated to indicate a mode switch. In
general, mode switches should be performed as soon as possible, i.e. as soon as it becomes
apparent that the provision of the current services at the required reliability and safety
level can not be sustained.
1
To correctly calculate reliability, it is important to separate the situations in which the
user voluntarily abandons the goal from the situations in which the service fails. A service
that is successfully cancelled upon user request represents a correct and reliable system
behavior
87
6.1. A Dependability-Oriented Requirements Engineering Process
Task 6: Defining Service-Related Exceptions and Effects on System Reliability and
Safety
This task focuses on discovering service-related exceptions and documenting de-
pendability values.
6.1 Document expected reliability and safety for actors
6.2 Annotate subgoal and handler steps with reliability and safety
6.3 Define service-related exceptions
The successful completion of a user goal may be threatened due to service-related
exceptional situations, defined in Section 4.2.1 of Chapter 4. . Possible service-related
exceptions can be discovered most effectively following a bottom-up approach.
To this
aim, DREP requires the developer to examine each individual base step of a use case,
sub-use case or handler, and reflect on the consequences that a failure of the step has on
reliability, i.e. the achievement of the goal, and on system safety.
Interaction Step Level Each sub-level use case must be looked at step by step, and every
interaction classified into either an input or an output interaction. Then, depending
on the kind of interaction, the following issues have to be considered:
• Input Problems: If omission of input from an actor can cause the goal to fail,
then, once the omission has been detected, different options of handling the
situation have to be considered. For instance, prompting the actor for the input
again after a given time has elapsed, or using default input are possible options.
Safety considerations might make it even necessary to temporarily shutdown
the system in case of missing input. Invalid input data is another example of
input problem that might cause the goal to fail. Since most of the time the
actors are aware of the importance of their input, a reliable system should also
acknowledge input from an actor, so that the actor realizes that she is making
progress in achieving her goal.
• Output Problems: Whenever an output triggers a critical action of an actor,
then the system must make sure that it can detect eventual communication
problems or failure of an actor to execute the requested action. For example,
the elevator control software might tell the motor to stop, but a communication
failure or a motor misbehavior might keep the motor going. Again, additional
hardware, for instance, a sensor that detects when the cabin stopped at a floor,
or timeouts might be necessary to ensure reliability.
Use Case Level Once every step has been inspected, the analyst should concentrate on
system-detected exceptions that prevent the execution of sub-function level goals. It
88
6.1. A Dependability-Oriented Requirements Engineering Process
might help to ask the opposite question: what preconditions must be fulfilled in order
to achieve the sub goal?
System Level There are rarely system-detected exceptions that prevent the entire system
from providing its services, unless the entire system functionality depends on, for
instance, a single secondary actor.
For guidance in addressing the above cases, the developer should answer the following
questions:
• If this step is omitted, will the goal fail? If yes, the step should be annotated with a
reliability tag, together with the probability of success of the step.
• If this step is omitted, is the safety of the system threatened? If yes, the step should
be annotated with a safety tag, together with the corresponding safety level and the
probability of success of the step.
A named exception should be defined for each service-related exceptional situation, together
with a small text that describes the situation in more detail. For example, in an elevator
system, a motor failure, i.e. the situation in which the motor does not react to commands
anymore because of a hardware or communication failure, is a serious threat to safety and
reliability. The identified exception is then added to the exception table of environmental
exceptions for documentation reasons.
6.1.3
Dependability Assessment
Task 7: Assessing Safety and Reliability The sub-taks involved in the assessment phase
are listed here.
7.1 Create/revise DA-Chart
7.2 Perform reliability and safety analysis
7.3 Compare dependability analysis results with expected dependability values
Our proposed model-based approach for assessing the safety and reliability of our use
cases is described in Chapter 7. Since each interaction step in a use case is annotated
with a probability reflecting its chances of success, and a safety tag if the failure of the
step hampers the system safety, it is possible to map the use case to a formalism that
is well-suited for dependability analysis. For this purpose, we developed the DA-Charts
formalism, which is a probabilistic extension of part of the statecharts formalism. We
have implemented our formalism in the AToM3 tool [52] to provide support for automatic
dependability analysis. The tool allows a developer to create a DA-Chart that corresponds
89
6.1. A Dependability-Oriented Requirements Engineering Process
to the use cases established in Tasks 1 - 6. The tool also verifies the formalism constraints
and ensures that the mapping rules are adhered to. Based on path analysis of the DACharts, the tool quantitatively determines probabilities of reaching safe or unsafe states, or
achieving the goal, providing a degraded success, or failing. For details on the DA-Charts
formalism and the dependability analysis see Chapter 7.
The dependability determined by the tool can now be compared with the dependability
required by the stakeholders as determined in Task 4. If the analysis reveals an acceptable
level of reliability and safety, i.e. the calculated reliability and safety values are higher
or equal to the required reliability and safety values, then the requirements engineering
process is complete, and a summary specification can be established (see tasks 11 and 12).
Otherwise, the requirements need to be refined with handler use cases that address the
service-related exceptions. This is described in Tasks 8, 9 and 10.
6.1.4
Dependability-based Refinement
Based on the output of our analysis tool, the service-related exceptions that have significant negative effect on the system’s reliability and safety can be identified. To improve
the situation, the following tasks should be performed for each one of them. Depending
on the cost factor, the tasks can be carried out for for one of the exceptions, and then the
assessment can be redone, followed by another iteration if needed.
Task 8: Specifying Detection Mechanisms
Once the developer determined which ex-
ceptional situation should be handled, it is important to carry out the following tasks.
8.1 Add detection actors
8.2 Add detection interaction steps and revisit goal outcomes
8.3 Add detection interaction steps for handlers
Before any recovery actions can be taken by the system, the exceptional situation has
to be detected. The developer should investigate if the current actors and their interactions
make the detection possible, and if not, adapt the interaction pattern or even add secondary
detection actors to the system’s environment.
Detection is usually done differently for input and output interactions. Omission
of input to the system can usually be detected using timeouts. Invalid input data can
be detected with checksums, etc (discussed in Chapter 2). In both cases, no additional
detection actors have to be introduced. The use case has to be updated by adding the
90
6.1. A Dependability-Oriented Requirements Engineering Process
discovered exception to the extension section of the template as an alternative to the
essential input step. If necessary, new use case outcomes might have to be defined.
Output failure is more difficult to handle. Whenever a system output triggers a critical
action of an actor, then the system must make sure that it can detect eventual communication problems or failure of an actor to execute the requested action. This very often
requires additional hardware, e.g. a sensor, to be added to the system. The job of this new
actor is to inform the system that the essential actor successfully executed the system’s
request. This new acknowledgement step has to be added to the main success scenario
after the essential output step in the use case or handler, and an exception representing
the failure of the output, detected by a timeout while waiting for the acknowledgement, is
added to the extension section as an alternative to the acknowledgement step. For example,
an elevator control software might request the motor to stop, but a communication failure
or a motor misbehaviour might keep the motor going. Additional hardware, for instance,
a sensor that detects when the cabin stopped at a floor, might be necessary to detect the
motor failure. Once the motor failure is detected, recovery measures can be taken toensure
safety or reliability.
Task 9: Specifying Handler Use Cases
If the exception puts the user in danger, then
measures must be taken to put the system in a safe state. If the exception threatens the
successful completion of the user goal, reliability is at stake. It should then be investigated
if the system can recover and meet the user goal in an alternative way.
In any case, exceptional interaction steps with the environment are performed during
recovery, and hence must be specified in a separate reliability or safety handler use case2 .
Very often, actors – especially humans – are “surprised” when they encounter an exceptional situation, and are subsequently more likely to make mistakes when interacting with
the system. Exceptional interactions must therefore be as intuitive as possible, and respect
the actor’s needs.
2
Separation of handlers also enables subsequent reuse of handlers. Just like a
subfunction-level use case can encapsulate a subgoal that is part of several user goals,
a handler use case can encapsulate a common way of handling exceptions that might occur
while processing different user goals. Sometimes even, different exceptions can be handled
in the same way.
91
6.1. A Dependability-Oriented Requirements Engineering Process
If the goal of the primary actor cannot be achieved, then it is of paramount importance
to inform him of the situation by an appropriate output interaction. In some cases, it might
not be possible to satisfy a user’s goal completely, but a dependable system can instead
offer a degraded form of service. For example, a user might order a product online and
request for delivery before a certain date. If the system is unable to satisfy this request,
the user might be offered the option to pick-up the order at the store instead. The handler
use case should then define a new degraded outcome for this situation.
If omission of input from an actor can cause the goal to fail, then, once the omission
has been detected, different options of handling the situation have to be considered. For
instance, prompting the actor for the input again after a given time has elapsed, or using
default input are possible options. Safety considerations might make it even necessary to
temporarily shutdown the system in case of missing input.
Invalid input data is another example of input problem that might cause the goal to
fail. Since most of the time the actors are aware of the importance of their input, a reliable
system should also acknowledge input from an actor, so that the actor realizes that he is
making progress in achieving his goal.
Task 10: Defining Degraded Modes
For each of the service-related exceptions identified
in Task 6.3 and handled in Task 9, the developer should evaluate the effects that the
service-related exception has on future requests for the same service or other services that
could be affected by the exception. In the case where these effects lower the reliability and
safety of the service below the required level specified by the current mode, a degraded
mode should be defined. Degraded modes are discussed in Chapter 4.
Iteration To complete this iteration, every interaction step of the newly defined handler
of Task 9 must again be elaborated (Task 5.4), the outcomes must be specified (Task 5.5),
and the essential steps tagged with reliability probabilities and safety information (Task
6.2). Finally, the developer can re-analyze the updated use cases (Task 7) to determine if
the required safety and reliability requirements can now be satisfied.
6.1.5
Requirements Summary and Documentation
To begin with the requirements documentation, the following tasks are suggested.
Task 11: Creating a Use Case Summary
92
6.1. A Dependability-Oriented Requirements Engineering Process
11.1 Create standard use case diagram
11.2 Create exceptional use case diagram
11.3 Create summary actor list
11.4 Document achievable reliability and safety for services
To begin with in this phase, a standard use case diagram based on the actors and
goals defined earlier should be created. Use case diagrams and the notations used in the
diagrams are elaborated in Chapter 5.
In addition to the standard use case diagram, we propose to use the exceptional use
case diagram notation which extends standard use case diagrams with exceptions and handlers. To summarize the exceptions and handlers in the use case contexts, an exceptional
use case diagram should be constructed using the notations specified in Chapter 5.
In addition, a list of all primary and secondary actors, both normal and exceptional,
should be developed. For each service to be provided by the system, it is necessary to
document the reliability and safety that can be achieved.
Task 12: Creating Summary Tables
12.1 Exception summary table
12.2 Mode summary table
For traceability and documentation reasons, all discovered context-affecting and servicerelated exceptions are recorded in a table during tasks 2 and 6. As a summary, the entries
in this table already contains a small textual description of the exceptional situation should
be complemented with the exception contexts in which the exception can occur, the associated handler(s), and the mechanism for detecting the exception.
Finally, the mode table is created to summarize all modes of the system. The mode
table can of course also be created earlier and updated iteratively whenever a new mode
is defined. For each mode the table includes a mode name, a description of the mode,
followed by a list of services that are provided in the mode. For each service, the service
name, the expected minimal reliability, and the expected minimal safety are given.
Task 13: Constructing Activity Diagrams
Once the use cases have been refined and
the stakeholders are in agreement with the requirements elicited, it is necessary to create
more formal and precise models which serve as the requirements specification artifacts.
The exceptional use case models are mapped to activity diagrams for this purpose. The
93
6.2. DREP and Model-Driven Engineering
activity model formalism used is detailed in Chapter 5. We define transformation rules
that facilitate the mapping process in Chapter 8.
Instead of creating the activity diagrams at the end, the models could also be constructed incrementally. The initial use cases could be mapped to activity diagrams, and
the activity diagrams could be used as the requirements models to drive the dependability assessment process. At present, refinements following the assessment would require
both the use cases and the activity diagrams to be updated. This is discussed further in
Section 6.2.1.
Task 14: Constructing the Communication Diagram Once the elicitation is complete
and the use case model and activity model are created, the final task is to construct the
system interface by means of a black-box communication diagram (discussed in Chapter 5). The process of mapping to our exceptional communication diagram is described in
Chapter 8.
6.2
DREP and Model-Driven Engineering
Task 1.
Discovering
Actors, Goals, and
Modes Task 2.
Discovering
Context-Affecting
Exceptions
Task 3.
Eliciting Handlers
for Discovered
Exceptions
Task 5.
Designing Use
Case and Handler
Interactions
Task 6.
Defining ServiceRelated Exc and
System Rel & Saf
Task 4.
Eliciting Dep
Expectations and
Exceptional Modes
Use Case: ...
Use Case: ...
Dep. Exp.: 99.999%
Dep. Exp.: 99.999%
Standard Use Cases + Dependablity Expectations
UseCase: ...
UseCase: ...
Primary Actor: ...
Primary Actor: ...
Secondary Actors: ...
Secondary Actors: ...
Dep Exp.: 99.999%
Dep Exp.: 99.999%
Main:
Main:
1. ... Rel.: 99.83%
1. ... Rel.: 99.83%
2. ... Rel.: 99.91%
2. ... Rel.: 99.91%
Safety: L2
Safety: L2
3. ... Rel.: 99.94%
3. ... Rel.: 99.94%
Extensions:
Extensions:
1a. Exception {..}
1a. Exception {..}
1b. Exception {..}
1b. Exception {..}
3a. Exception {..}
3a. Exception {..}
Task 7.
Assessing Safety and
Reliability
Task 8.
Specifying
Detection
Mechanisms
Task 9.
Specifying
Handler Use
Cases
Task 10.
Defining Degraded
Modes
Door
Open
Open 0.95 Detect
OpDet
Failed
Exceptional Use Cases
*
DA-Charts
1
>>
de
ra
eg
pt
ru
er
int
<<
>>
ail
&f
Exception:
{UndetectedEntry,
UndetectedExit}
pt
ru
&d
er
Task 13.
Constructing
Communication
Diagram
*
Exception:
{UnregisteredVehicle}
int
Task 13.
Constructing
Activity Diagrams
EntryGantry
<<
Task 12.
Summarizing
Exception Table and Mode Table
Markov Chains
Mini 407 System
TakeHighway
Task 11.
Summarizing Use
Cases and
Handlers
Succ
1
1
0.05
<<reliability handler>>
<<reliability handler>>
ChargeMinimalTrip
AlertPolice
1
ExitGantry
+
Exceptions
____|____
____|____
____|____
+
Modes
____|____
____|____
____|____
<<s>> activate: EmergencyBrake
Mode Table
+
+
<<s>> turnOn: EmergencyBrake
1
Activity Diagram
motorStarted: ElevatorArrival{ startMotor}
<<time-triggered>>
openDoor: ElevatorArrival{ DoorStuckClosed}
1
doorOpened: ElevatorArrival{ openDoor}
Communication Diagram
Figure 6–2: DREP and Modelling Formalisms: Summary
The left hand side of Fig. 6–2 shows a summary of the tasks of our dependability-aware
requirements engineering process.
The arrows illustrate that the developer is expected to go through several iterations
of the process, refining the use cases and handlers if the assessment task reveals that the
94
reachedFloor: ElevatorArrival
1
<<s>> <<r>>
Exception Table
: System
1
Police
Exceptional Use Case Diagram
*
6.2. DREP and Model-Driven Engineering
required system reliability or safety cannot be achieved within the current environment
with the chosen interactions.
The iteration proceeds as follows. The assessment tool determines how severely each
service-related exception affects system safety and service reliability. Among the servicerelated exceptions, the developer should start by addressing an exception that can be
detected (with reasonable effort / costs), and for which a handling strategy that ensures
safety or reliability can be envisioned. The exception to begin with might be one which
requires immediate attention, or is safety-critical (in cases where safety is a priority). Then
tasks 8 and 9 are executed, adding detection capabilities and handlers to the system. To
complete this iteration, every interaction step of the newly defined handler of task 9 must
again be elaborated (Task 5.4), the outcomes must be specified (Task 5.5), and the essential
steps tagged with reliability probabilities and safety information (Task 6.2)3 . Finally, the
developer can re-analyze the updated use cases (Task 7) to determine if the required safety
and reliability requirements can now be satisfied.
It should be noted here that the calculated dependability numbers do not represent the
final system safety and reliability. They have to be interpreted as the maximal dependability
of the system if it were to be implemented without any flaws (see section 6.2.2). Hence the
calculated numbers should be higher than the required ones specified for each service in
Task 4.
The difference between the calculated and the required values determines how much
effort has to be put into the design and implementation phases. If the difference is small,
then stringent quality assurance, such as formal methods and proofs, extensive testing,
or fault tolerance techniques, has to be employed by the implementors in order to assure
that the internal flaws of the system are minimal. However, the employment of such
techniques during design and implementation is costly, both in resources and development
time. The higher the difference between the calculated dependability numbers and the
required ones, the less important is a flawless design and implementation of the system.
Hence, dependability-oriented refinement of the use cases should only be stopped after
careful consideration.
3
If new exceptional goals have been discovered, the developer might even be required
to go back to Task 1 to brainstorm new secondary actors that are needed to achieve the
new exceptional goals.
95
6.2. DREP and Model-Driven Engineering
6.2.1
Tool Support
In order to use our dependability-aware requirements engineering process efficiently,
tool support is necessary. This is especially true for the probabilistic analysis of system
reliability and safety. DREP relies heavily on the idea of model-driven engineering (as
defined by OMG [157]), in which models of the system under development are built, and
then incrementally modified and transformed as the development progresses from requirements elicitation to analysis, design and implementation. At each phase, our process uses
the modelling formalisms and notations that are most appropriate to express the concern
at hand. The different modelling formalisms used in our requirements engineering process
are shown in the right hand side of Fig. 6–2. The arrows depict the model transformations
that occur when moving from one phase of the process to the next.
Currently, our tool (see Chapter 7) supports the creation of DA-Charts. The mapping
to Markov chains and the dependability assessment is automated. Automating the process
of creating the DA-Charts would be a very desirable feature. The use cases could drive
the creation of the DA-Charts, or on the other hand as mentioned in Task 13 (Section 6.1)
activity diagrams could be the intermediate models and could be used as the source for the
transformation to DA-Charts. Fig 6–3 shows a task structure that serves as a better alternate when tool support is available. This topic is addressed in more details in Chapters 8
and 12.
Task 1.
Discovering
Actors, Goals,
and Modes Task 2.
Discovering
Context-Affecting
Exceptions
Task 5.
Designing Use
Case and Handler
Interactions
Task 3.
Eliciting Handlers
for Discovered
Exceptions
Task 6.
Defining ServiceRelated Exc and
System Rel & Saf
Task 4.
Eliciting Dep
Expectations and
Exceptional Modes
Use Case: ...
Use Case: ...
Dep. Exp.: 99.999%
Dep. Exp.: 99.999%
Standard Use Cases + Dependablity Expectations
UseCase: ...
UseCase: ...
Primary Actor: ...
Primary Actor: ...
Secondary Actors: ...
Secondary Actors: ...
Dep Exp.: 99.999%
Dep Exp.: 99.999%
Main:
Main:
1. ... Rel.: 99.83%
1. ... Rel.: 99.83%
2. ... Rel.: 99.91%
2. ... Rel.: 99.91%
Safety: L2
Safety: L2
3. ... Rel.: 99.94%
3. ... Rel.: 99.94%
Extensions:
Extensions:
1a. Exception {..}
1a. Exception {..}
1b. Exception {..}
1b. Exception {..}
3a. Exception {..}
3a. Exception {..}
Task 7.
Constructing
Activity Diagrams
Task 8.
Assessing Safety and
Reliability
Task 9.
Specifying
Detection
Mechanisms
Task 10.
Specifying
Handler Use
Cases
Task 11.
Defining
Degraded Modes
OpDet
Failed
Activity Diagram
>>
de
ra
pt
ru
er
int
<<
>>
ail
&f
Exception:
{UndetectedEntry,
UndetectedExit}
pt
*
ru
&d
er
eg
int
Task 13.
Constructing
Communication
Diagram
Exception:
{UnregisteredVehicle}
<<
Task 13.
Summarizing
Exception Table and Mode Table
Markov Chains
1
TakeHighway
Task 12.
Summarizing Use
Cases and
Handlers
DA-Charts
Mini 407 System
EntryGantry
Succ
1
1
0.05
Exceptional Use Cases
*
Door
Open
Open 0.95 Detect
<<reliability handler>>
<<reliability handler>>
ChargeMinimalTrip
AlertPolice
1
ExitGantry
+
Exceptions
____|____
____|____
____|____
+
Modes
____|____
____|____
____|____
+
Exception Table
Mode Table
: System
<<s>> turnOn: EmergencyBrake
1
motorStarted: ElevatorArrival{ startMotor}
<<time-triggered>>
openDoor: ElevatorArrival{ DoorStuckClosed}
1
doorOpened: ElevatorArrival{ openDoor}
Communication Diagram
Figure 6–3: DREP and Modelling Formalisms: Alternate Task Structure
96
reachedFloor: ElevatorArrival
1
<<s>> <<r>>
Police
Exceptional Use Case Diagram
*
<<s>> activate: EmergencyBrake
1
6.3. Case Study: Elevator Control System
6.2.2
Discussion and Limitations
Our process helps the developer to discover potential exceptional situations that the
system under development might be exposed to, and then guides the developer to investigate together with the stakeholder how the system should react in order to provide
its services in the most reliable and safe way. Our approach is based on use cases that
even non-technical people can read and understand, which makes getting feedback from all
concerned stakeholders very easy.
As a result, however, our approach is also limited by the expressiveness of use cases.
Use cases focus strictly on the interactions between the system and the environment. Hence,
our dependability analysis only takes into account how the failures of actors and communication links affect the reliability and safety of the system under development. It does not
consider failures internal to the system. The calculated dependability numbers represent
the best achievable safety and reliability of the system if it were implemented without any
flaws. If the numbers are too low, the developer should refine the interactions between
the system and the actors, or even add new actors to the environment, to increase the
achievable dependability of the system under development.
At this level of abstraction our approach cannot address internal flaws of the system.
Use cases treat the system under development as a black box, and therefore no internal
details are defined yet. Hence it is impossible to reason about conceptual system state, and
even less to define invariants or pre- and postconditions on that state for system services.
To do this, a domain model describing conceptual system state must be created, and
the use case models produced using our approach have to be mapped to operations that
work with that system state. Popular development processes, e.g. the Unified Process
[106], suggest to use graphical modelling formalisms such as activity diagrams or sequence
diagrams for this purpose, together with OCL [217] constraints to express invariants, preand postconditions. If formal techniques are to be used to analyze system properties,
a detailed system specification should be derived from our models using an appropriate
formalism, e.g. B [1].
6.3
Case Study: Elevator Control System
We introduced the Elevator Control System (ECS) case study in Chapter 5. Please
refer to Section 5.5 of the chapter for background on the case study. In this section, we apply
97
6.3. Case Study: Elevator Control System
DREP to the ECS case study to elicit and specify dependability-focused requirements of
the elevator control system.
6.3.1
Requirements Elicitation and Discovery
Task 1: Discovering actors, goals, and modes
In the ECS, there is initially only one
primary actor, the User. A User has only one goal with the system, namely to take the
elevator to go to a destination floor (defined as TakeElevator ). Taking an elevator involves
first calling the elevator (if it is not already available) and then riding it to reach the
destination floor. Hence TakeElevator includes two user subgoals as shown in Fig. 5–
10: CallElevator and RideElevator. Both these goals require the functionality to direct
the elevator to a specific floor which could be either the calling floor or the desired user
destination floor. This sub-functionality is defined as ElevatorArrival.
Our ECS only has one normal mode of operation since there is only one primary
goal, taking the elevator, that needs to be satisfied at all times. Some elevators might
have different or limited services available during rush hour, and hence might require the
definition of two normal modes: standard mode and rush hour mode.
Task 2: Discovering Context-Affecting Exceptions Once the standard goals are defined,
we need to identify events that might occur in the environment that have priority over taking the elevator (i.e., over satisfying the TakeElevator user goal) and that can threaten
system dependability unless addressed by the system. In the elevator system, a fire outbreak in the building causes the elevator operator, an exceptional actor, to activate the
fire emergency mode. Another priority situation can arise at the user’s end if the user feels
unsafe inside the elevator and wishes to stop the movement of the cabin. In this case, the
system temporarily halts the current service and activates the emergency brakes.
Hence, we define two context-affecting exceptions: EmergencyStop which is signaled
by the User actor pushing the emergency button in the elevator, and EmergencyOverride
which is signaled by the ElevatorOperator using the emergency override key on the ground
floor. Both exceptions can interrupt the normal system operation at any time, so their
context is TakeElevator.
Task 3: Eliciting Handlers for Context-Affecting Exceptions
An emergency stop occur-
ing in TakeElevator interrupts and fails the primary goal. As a first handling step, the
98
6.3. Case Study: Elevator Control System
emergency brakes are activated. Then the pending requests are cleared. Subsequently, the
User can toggle off the emergency button to reactivate the elevator.
The EmergencyOverride exception interrupts and fails the TakeElevator user goal. In
such a situation all elevator cabins go down to the lowest floor to prevent casualties or
physical damage. Activating the emergency behavior is an exceptional goal for the elevator
operator, since this happens only in rare occasions.
Task 4. Eliciting Dependability Expectations and Discovering Exceptional Modes
We
define 4 safety levels for the ECS:
• level 0 - without effects,
• level 1 - minor effects that lead to upsetting or annoying the elevator users or increasing load on operators,
• level 2 - major effects that lead to minor injuries of users,
• level 3 - dangerous effects that lead to serious injuries, physical damage, or monetary
loss,
• level 4: catastrophic effects that lead to loss of human lives, or system destruction.
The reliability of TakeElevator should be high, e.g. 0.9999. During an emergency, the
chances of a level 3 or level 4 violation should be less than 0.00001, level 2 safety violation
should be very small, e.g. 0.00001, and a level 1 safety violation should be rare, 0.001. The
required reliability of the emergency behavior should be very high, e.g. 0.99999.
As mentioned earlier, the system only offers one normal mode which includes all
services associated to taking the elevator: CallElevator and RideElevator. In Task 2, the
context-affecting exception EmergencyOverride was identified which requires emergency
services such as sending elevators to the ground floor to be carried out.
In such a
situation, the system is not in a position to offer any of the regular services. Therefore,
when such an exceptional situation arises the system needs to switch to a emergency mode
FireSafety which only offers the ReturnToGroundFloor emergency service.
6.3.2
Requirements Definition and Specification
Task 5: Designing Interactions The interaction steps required for the TakeElevator goal
are described in the user-goal level use case TakeElevator shown in Fig. 6–4. As we can
see from the main success scenario, the User first calls the elevator (step 1), and then
99
6.3. Case Study: Elevator Control System
rides it to the destination floor (step 2). The potential concurrent use of the elevator is
documented in the Frequency & Multiplicity section.
Use Case: TakeElevator
Scope: Elevator Control System
PrimaryActor: User
Intention: The intention of the User is to take the elevator to go to a destination floor.
Level: User Goal
Frequency & Multiplicity: A User can only take one elevator at a time. However, several Users may
take the elevator simultaneously.
MainSuccessScenario:
1. User CallsElevator.
2. User RidesElevator.
Use case ends in success TripSuccessful.
Extensions:
1a. The cabin is already at the floor of the User and the door is open. User enters elevator; use case
continues at step 2.
1b. The user is already inside the elevator. Use case continues at step 2.
Figure 6–4: ECS: TakeElevator Use Case
The CallElevator use case is shown in Fig. 6–5. To call the elevator, the User pushes
the up or down button and waits for the elevator cabin to arrive.
Use Case: CallElevator
PrimaryActor: User
Intention: User wants to call the elevator to the floor that he / she is currently on.
Level: Subfunction
Main Success Scenario:
1. User pushes button, indicating in which direction he / she wants to go.
2. System acknowledges User ’s request.
3. System schedules ElevatorArrival for the floor the User is currently on.
Use case ends in success ElevatorArrived.
Extensions:
2a. The same request already exists. System ignores the request. Use case ends in success.
Figure 6–5: ECS: CallElevator Use Case
The RideElevator use case is shown in Fig. 6–6. To ride the elevator the User enters
the cabin, selects a destination floor, waits until the cabin arrives at the destination floor
and finally exits the elevator.
Since we want to make a clear distinction between normal interaction and exceptional
interaction, the extensions of the standard use cases of the ECS only describe alternative
ways to achieve the goal (as shown in step 2a of Fig. 6–5), or interactions in which the
100
6.3. Case Study: Elevator Control System
Use Case: Ride Elevator
PrimaryActor: User
Intention: The User wants to ride the elevator to a destination floor.
Level: Subfunction
Main Success Scenario:
User enters elevator.
1. User selects a destination floor.
2. System acknowledges User ’s request.
3. System requests Door to close.
4. System receives confirmation that door is closed.
5. System schedules ElevatorArrival for the destination floor.
6. User exits the elevator at destination floor.
Use case ends in success ReachedUserDestination.
Extensions:
1a. User does not enter elevator. System times out and closes door. Use case ends in abandoned RideAbandoned.
1b. User does not select a destination floor. System times out and closes door. System processes
pending requests or awaits new request. Use case ends in abandoned RideAbandoned.
6a. User selects another destination floor. System acknowledges new request and schedules
ElevatorArrival for the new floor. Use case continues at step 5.
Figure 6–6: ECS: RideElevator Use Case
primary actor voluntarily abandons the interaction (as shown in steps 1a and 2a of Fig. 6–
6). The outcomes of each use case are clearly identified in the main success scenario and
in the extensions section.
CallElevator and RideElevator both include the Elevator Arrival use case earlier
shown in Fig. 5–11. It is a subfunction level use case that describes how the system directs
the elevator to a specific floor: once the system detects that the elevator is approaching
the destination floor, it requests the motor to stop and opens the door.
Fig. 6–7 shows the handler UserEmergency that handles the exception EmergencyStop.
Handler use cases have an additional field in the use case template named Contexts & Exceptions that is used to document by which exception occurring in what context the handler is
triggered. In our case, an emergency stop occuring in take elevator interrupts and fails the
goal of the use case. As a first handling step, the emergency brakes are activated. Then the
pending requests are cleared. Subsequently, the User can toggle off the emergency button
to reactivate the elevator.
The EmergencyOverride exception is handled by the ReturnToGroundFloor handler
use case, which interrupts and fails the TakeElevator use case. Since both of these handlers
attempt to satisfy user safety, we label the handlers as safety handlers. This is shown in
the Handler Class field in the template.
101
6.3. Case Study: Elevator Control System
Handler Use Case: UserEmergency
Handler Class: Safety
Contexts & Exceptions: TakeElevator{EmergencyStop}
PrimaryActor: User
Intention: User wants to stop the movement of the cabin.
Level: User Goal
Frequency & Multiplicity: Since there is only one elevator cabin, only one User can activate the emergency at a given time.
Main Success Scenario:
1. System initiates EmergencyBrake.
2. System clears all pending requests.
3. User toggles off Emergency Stop Button.
4. System deactivates Brakes and awaits the next request.
Use case ends in success ElevatorAvailable.
Handler Use Case: ReturnToGroundFloor
Handler Class: Safety
Contexts & Exceptions: TakeElevator{EmergencyOverride}
PrimaryActor: Elevator Operator
Intention: Elevator Operator wants to call the elevator to the ground floor because the elevator operation
is too dangerous.
Level: User Goal
Frequency & Multiplicity: Only one ReturnToGroundFloor use case can be active at a given time.
Main Success Scenario:
System switches into emergency mode FireSafety.
1. System clears all requests and asks Motor to go down.
2. System detects that elevator is approaching the ground floor.
3. System requests Motor to stop.
4. System opens elevator Door.
Use case ends in success ReachedGroundFloor.
Figure 6–7: ECS: UserEmergency and ReturnToGroundFloor Handler Use Case
Task 6: Defining Service-Related Exceptions and Effects on System Reliability and
Safety
We begin in a bottom-up way by examining each step in the ElevatorArrival use
case to determine how essential its contribution is in order to achieve the goal. For example,
step 2 involves the floor sensor informing the system that the elevator is approaching a
floor. This is an input interaction, and its omission leads to an exceptional situation. A
floor sensor defect might cause the elevator to miss a destination floor! In step 4, the system
requests the door to open. If the door fails to open, the user goal might not succeed.
We see that failure of these interactions can affect reliability of the system. The reliability tag is attached to each of these steps to enable the developer to identify tasks that
102
6.3. Case Study: Elevator Control System
Use Case: ElevatorArrival
Primary Actor: N/A
Intention: System wants to move the elevator to the User ’s requested floor.
Level: Subfunction
Main Success Scenario :
1. System asks Motor to start moving towards the destination floor. reliability
2. System detects cabin is approaching destination floor. reliability, safety-critical
3. System requests Motor to stop. reliability, safety-critical
4. System requests Door to open. reliability
Use case ends in success ReachedDestination.
Extensions :
1a. Exception{MotorStartFailure}
2a. Exception{MissedFloor }
3a. Exception{MotorStopFailure}
4a. Exception{DoorUnresponsive}
4b. Exception{DoorFailure}
Figure 6–8: ECS: Annotated ElevatorArrival Use Case
require special measures in order to provide smooth services. The mentioned steps are classified as reliability (and not safety) concerns since service failure does not necessarily lead
to critical conditions. The service-related exceptions that can occur in the ElevatorArrival
context are defined as MissedFloor, MotorStartFailure, MotorStopFailure, and DoorFailure.
In order to realize effects on system safety, we tag critical steps of ElevatorArrival
with a safety index between 1 and 4 defining the effect of failure (see Task 7 in 6.1). In
step 2, the system requests the motor to stop. This is an output interaction that requests
a service from a secondary actor, in this case the motor. In case the motor malfunctions
and does not stop, serious (level 3) or even disastrous (level 4) consequences can occur.
Also, it is very unsafe to open the door while the elevator is still moving. Therefore it is
essential that the developer provides measures to put the system in a safe state in case such
a failure occurs. The ElevatorArrival use case with the dependability tags and exceptions
is shown in Fig. 6–8.
Next, looking at the parent use case RideElevator, we realize that another exceptional
situation that might occur and effect system safety is when there are too many passengers
in the elevator. If we are unable to detect overweight and allow the cabin to continue, this
can lead to a significant failure (level 3) since there is a risk of a motor breakdown. We
can also identify a problem that might prevent the goal from succeeding: the elevator door
might be stuck open, for instance because an obstacle prevents it from closing. In the case
103
6.3. Case Study: Elevator Control System
Use Case: Ride Elevator
PrimaryActor: User
Intention: The User wants to ride the elevator to a destination floor.
Level: Subfunction
Main Success Scenario:
User enters elevator.
1. User selects a destination floor.
2. System acknowledges User ’s request.
3. System requests Door to close. reliability, safety-critical
4. System receives confirmation that door is closed. reliability
5. System schedules ElevatorArrival for the destination floor.
User exits the elevator at destination floor.
Use case ends in success ReachedUserDestination.
Extensions:
1a. User does not enter elevator. System times out and closes door. Use case ends in abandoned RideAbandoned.
1b. User does not select a destination floor. System times out and closes door. System processes
pending requests or awaits new request. Use case ends in abandoned RideAbandoned.
4a. Exception{DoorStuckOpen}
4b. Exception{Overweight}
5a. User selects another destination floor. System acknowledges new request and schedules
ElevatorArrival for the new floor. Use case continues at step 5.
Figure 6–9: ECS: Annotated RideElevator Use Case
of RideElevator, the two possible exceptions are defined as DoorStuckOpen and Overweight.
The RideElevator use case with the dependability tags and exceptions is shown in Fig. 6–9.
In the CallElevator use case, an exceptional situation might be that the system fails
to acknowledge the user’s request. Since we assume reliable communication, the reason
behind the lack of acknowledgment is possibly due to a damaged floor button light. Such
a failure is insignificant and does not effect the user goal, and hence is not defined as an
exception.
6.3.3
Requirements Analysis
Task 7: Assessing Safety and Reliability In this section, we only state the results of
the first iteration of the dependability assessment. The interested reader is referred to
Chapter 7 for details. It reveals that system safety and reliability cannot be met with
the current interaction: MotorStopFailure and MissedFloor have to be handled in order
to improve safety; DoorFailure and MissedFloor have to be addressed in order to improve
reliability.
104
6.3. Case Study: Elevator Control System
6.3.4
Dependability-based Refinement and Iteration
Based on our dependability assessment results, we carry out the following tasks and
attempt to improve system reliability and safety by addressing the most significant exceptions occurring during ElevatorArrival which is the core functionality of the ECS.
Task 8: Specifying Detection Mechanisms Detecting that a floor has been passed (exception MissedFloor ) can be done in two ways. If the situation is caused by a broken floor
sensor, then the following floor sensor can serve as a detection mechanism. If the situation
is due to a motor failure, then a timeout (the lack of reception of a floor sensor message)
can be used as a detection mechanism.
Therefore, an additional detection step and the
exception are added to the use case. To detect the exception DoorFailure, we have to
introduce a new sensor that detects when a door successfully opened. This results in an
additional acknowledgment step and exception in the extension section.
The exception raised in the RideElevator use case, DoorStuckOpen, can be detected
using timeouts.
In the ECS, a handler needs to be defined if the safety index associated to a failure
is 2 or greater. Such policies are usually defined by the stakeholders’. The analysis of the
use cases in task 7 lead to the discovery of two critical exceptions: MotorStopFailure and
Overweight. To detect a motor failure, an additional sensor that monitors the cabin speed
is added to the system. This also makes it possible to detect when the cabin stopped,
and therefore when it is safe to open the doors. To detect an overweight condition, weight
sensors need to be used which signal an exception if the total weight is greater than the
capacity of the motor.
The use cases again are updated with the necessary acknowledgment steps and exception extensions. The resulting refined, reliable and safe version of the ElevatorArrival use
case is shown in Fig. 5–12.
Task 9: Specifying Handler Use Cases
The system-detected exception MissedFloor re-
quires some forward error recovery measure to be taken. Degraded service can be provided
by redirecting the elevator to a nearby floor. A handler is defined, RedirectElevator (shown
in Fig. 6–10), that stops the cabin at the next floor. Therefore the use case ends in the
degraded outcome DifferentFloor.
105
6.3. Case Study: Elevator Control System
The DoorFailure exception is handled by displaying a message to the user informing
him/her of the situation. It is up to the user then to try again, to try another floor, or call
the elevator operator.
The exception raised in the RideElevator use case, DoorStuckOpen, is handled by the
DoorAlert handler use case (Fig. 6–11). The handlers defined are accordingly labelled as
reliability handlers.
The Overweight exception is handled by a OverweightAlert handler (shown in Fig. 6–
12) which alerts the users of the problem by turning on a buzzer. The motor failure during
elevator arrival is addressed by the EmergencyBrake handler (shown in Fig. 7–6) which
attempts to put the system in a safe state by halting the elevator immediately.
We also need to consider the possibility of the handlers failing and the consequences
of such failures. The step-by-step analysis of the use cases is recursively applied to all the
Handler Use Case: RedirectElevator
Handler Class: Reliability
Context & Exception: ElevatorArrival{MissedFloor}
PrimaryActor: N/A
Intention: System redirects the elevator to a different floor because the destination floor is unreachable.
Level: Subfunction
Main Success Scenario:
1. System cancels request to stop at destination floor.
2. System schedules a new request to stop at next floor.
Use case ends in success ElevatorRedirected.
Figure 6–10: RedirectElevator Handler Use Case
Handler Use Case: DoorAlert
Handler Class: Reliability
Primary Actor: N/A
Context & Exception: TakeElevator{DoorStuckOpen}
Intention: System wants to alert the passengers that there is an obstacle preventing the door from closing.
Level: Subfunction
Main Success Scenario:
1. System displays “door open”.
2. System turns on the buzzer.
3. System requests the door to close.
Step 3 is repeated until the door closes.
4. System detects that the door is now closed.
5. System turns off the buzzer.
6. System clears the display.
Use case ends in success DoorClosed.
Figure 6–11: ECS: DoorAlert Handler Use Case
106
6.3. Case Study: Elevator Control System
Handler Use Case: OverweightAlert
Handler Class: Safety
Context & Exception: RideElevator{Overweight}
Primary Actor: N/A
Intention: System wants to alert the passengers that there is too much weight in the elevator.
Level: Subfunction
Main Success Scenario:
1. System displays “overweight”.
2. System turns on the buzzer.
3. System detects that the weight is back to normal.
4. System turns off buzzer.
5. System clears display.
Use case ends in success WeightNormal.
Handler Use Case: EmergencyBrake
Handler Class: Safety
Context & Exception: TakeElevator{MotorStopFailure},
ReturnToGroundFloor{SafeReturnFailure}
PrimaryActor: N/A
Intention: System wants to stop operation of elevator and secure the cabin.
Level: Subfunction
Main Success Scenario:
1. System stops motor.
2. System activates the emergency brakes.
3. System turns on the emergency display.
Use case ends in success BrakesActivated.
Figure 6–12: ECS: OverweightAlert and EmergencyBrake Handler Use Cases
handlers, because handlers may themselves be interrupted by exceptions. While handling
the EmergencyOverride exception, there might be a motor failure resulting in a highly
unsafe condition. For safety reasons, the system can then put on the emergency brakes
instead of remaining in operation. In our system, the EmergencyBrake, OverweightAlert,
DoorAlert, and RedirectElevator handler use cases all wait until the situation is resolved.
In case the problem persists for a certain amount of time, the elevator control system
should notify an elevator operator. This step can also be taken if safe return to ground
floor is not possible during a fire. The elevator operator can then evaluate the situation
and, if necessary, call a service person. This functionality is described in the handler use
case CallElevatorOperator shown in Fig. 6–13.
Task 10: Defining Degraded Modes In the ECS, a jammed door might prevent
the elevator cabin to from picking up or dropping off passengers on a particular floor. As
a result, the TakeElevator service is less reliable for users that want to reach that specific
floor, since the cabin will only stop at a neighboring floor. The system is hence only
107
6.3. Case Study: Elevator Control System
Handler Use Case: CallElevatorOperator
Handler Class: Safety
Context & Exception: EmergencyBrake{ElevatorStoppedTooLong},OverweightAlert{OverweightTooLong},
DoorAlert{DoorStuckOpenTooLong}, RedirectElevator{RedirectionFailure},
ReturnToGroundFloor{SafeReturnFailure}
Intention: The system wants to alert the elevator operator, so that the elevator operator can come and
assess the damage.
Level: Subfunction
Main Success Scenario:
1. System cancels all pending requests.
2. System displays “calling operator “.
3. System calls operator.
Use case ends in success OperatorInformed.
Figure 6–13: ECS: CallElevatorOperator Handler
able to offer the service with degraded quality of service, and switches to a degraded mode
FloorXNotServed.
6.3.5
Requirements Summary
Task 11: Creating a Use Case Summary The standard use case diagram is shown in
Fig. 5–10.
Fig. 6–14 shows the use cases, exceptions and handlers related to TakeElevator by
means of an extended use case diagram. All exceptional interactions are tagged with
the < <handler> > stereotype along with the handler class safety or reliability, and all
exceptional situations that trigger these interactions are documented using notes attached
to the < <interrupt> > relationships.
Task 12: Creating Summary Tables
The exception table for the ECS with the detailed
descriptions of each exception is presented in Table 6–1.
The mode summary table only contains three modes: the normal operation mode, the
emergency mode FireSafety, and the degraded mode DegradedReliability.
Task 13: Constructing Activity Diagrams Starting from TakeElevator, all the usergoal and subfunctional level exceptional use cases and handler uses have to be mapped
to Activity Diagrams. The ElevatorArrival activity diagram in shown in Fig A–5. The
complete set of activity models of the ECS are presented in Chapter 9.
108
109
Appr Floor
Sensor
>
Elevator
Arrival
<<
on
&c
rr
inte
Exception:
{RedirectionFailure}
RetryDoor
<<reliability handler>>
<<interrupt & continue>>
Exception:
{DoorFailure}
<<interrupt & fail>>
l>>
Exception:
{DoorUnresponsiveTooLong}
fail
>>
CallElevator
Operator
<<safety handler>>
User
1
0..*
Buzzer
Display
1
Brake
1
Emergency
Display
1
Stop Button
1
<<interrupt & fail>>
Emergency
Brake
<<safety handler>>
<<include>>
User
Emergency
Exception:
{ElevatorStoppedTooLong}
<<
int
err
up
<<interrupt & fail>>
t&
<<interrupt & fail>>
Overweight
Alert
<<safety handler>>
Exception:
{OverweightTooLong}
DoorAlert
<<reliability handler>>
rupt & fai
<<inter
Exception:
{MotorFailure}
<<safety handler>>
Exception:
{SafeReturnFailure}
Exception:
{DoorStuckOpenTooLong}
<<interrupt & continue>>
Exception:
{DoorStuckOpen}
<<interrupt & fail>>
e>
>
tin
u
>>
Exception:
{Overweight}
pt
up
t&
Exception:
co
nti
nu
{DoorUnresponsive}
e
Ride Elevator
<<include>>
rru
<<
inte
Take Elevator
<<interrupt & fail>>
Exception:
{EmergencyStop}
Elevator Control System
Figure 6–14: ECS: Exceptional Use Case Diagram
Redirect
Elevator
<<reliability handler>>
e>>
d
clu
<<in
<<interrupt & fail>>
<<interrupt & continue>>
e>
Door
Sensor
lud
*
Exception:
{MissedFloor}
Call Elevator
ReturnTo
GroundFloor
inc
Floor
Sensor
2..*
Door
Motor
1
1
<<
Movement
Sensor
1
Floor
Button
1
Cabin
Button
1
>
<<safety handler>>
e>
lud
Elevator
Operator
inc
1
Exception:
{EmergencyOverride}
<<
0..*
6.3. Case Study: Elevator Control System
6.3. Case Study: Elevator Control System
Exception
Emergency
Stop
Description
An emergency situation in the
elevator cabin makes the User
want to stop the elevator
An external emergency situation, for example a fire outbreak, makes the operation of
the elevator too dangerous.
Due to a floor sensor or communication failure, the elevator control does not get notified when the cabin approaches
or stops at a floor
Context
Take
Elevator
Elevator
Arrival
Redirect
Elevator
Motor
Start
Failure
Due to a motor or communication failure, the motor does not
react to start requests
Take
Elevator
Retry
Motor
Motor
Stop
Failure
Due to a motor or communication failure, the motor does not
react to requests
Take
Elevator
- OR ReturnTo
Ground
Floor
Emergency
Brake
Door
Stuck
Open
The door does not respond to a
close request because of a door
failure, a communication failure or an obstacle blocking the
door
There is too much weight in the
elevator for safe operation
The door does not respond to a
close request because of a door
failure, a communication failure or an obstacle blocking the
door
The emergency brakes have
been active for too long
Take
Elevator
DoorAlert
Ride
Elevator
Elevator
Arrival
- OR Redirect
Elevator
Emergency
Brake
Overweight sensor in the
elevator cabin
Timeout expires after an
open request has been sent
to the door
The door has been open for too
long
Door
Alert
Overweight
Alert
none
- OR Call
Elevator
Operator
Call
Elevator
Operator
Call
Elevator
Operator
The elevator has been overloaded for too long
Overweight
Alert
Call
Elevator
Operator
Timeout
Emergency
Override
Missed
Floor
Overweight
DoorFailure
Elevator
Stopped
TooLong
Door
Stuck
Open
TooLong
Overweight
TooLong
Take
Elevator
Handler
User
Emergency
Detection
Triggered by User actor
pressing the emergency
button
ReturnTo
Triggered by ElevatorOpGroundFloor erator actor using the
emergency override key.
Sensor detects elevator is
approaching a floor beyond destination floor
- OR timeout expires after a
stop request has been sent
to motor
timeout expires and no
sensor input has been received after a start request
has been sent to motor
Sensor detects elevator is
approaching a floor beyond destination floor after a stop request has been
sent to motor
- OR timeout expires and no
sensor input has been received after a up/down request has been sent to motor
Timeout expires after a
close request has been sent
to the door
Timeout
Timeout
Table 6–1: ECS: Exception Summary Table
110
6.4. Summary
Task 14: Constructing the Communication Diagram
All the interactions defined in the
CallElevator and RideElevator use cases, their sub-functional use cases, and handlers have
to be mapped to input and output messages between the system and the environment.
The ECS interaction diagram is show in Fig. 6–15.
6.4
Summary
Early discovery of dependability concerns allow developers to discover and then doc-
ument how the users of the system expect the system to react in every situation, which
ultimately results in a more dependable system and saves considerable development costs.
To this aim, we propose an approach that extends use case-based requirements elicitation,
focusing on system reliability and safety. We define a task-based process for developing
requirements that leads a developer to systematically investigate potential exceptional situations that the system may be exposed to.
Our task-based process begins with eliciting user goals and dependability expectations,
and then discovering context-affecting exceptions. Recovery goals that dictate the system
behaviour in such situations are defined in handler use cases. The process then goes on to
give guidance on designing interactions to satisfy each of the discovered user and handler
goals. The defined use cases are then examined step-by-step for reliability and safety related issues, and the associated interactions are annotated with reliability and safety tags
and probabilities. The identified issues are labelled and documented as exceptions. As the
next phase, the process suggests to analyze the use cases by using a probabilistic dependability analysis technique. The assessment results might show the need for increasing the
dependability, and hence lead to further refinement. The refinement tasks require revisiting the use cases and integrating appropriate exception detection and recovery means. In
the final phase, the use cases, exceptions, and handlers are summarized in graphical and
textual forms. Activity diagrams are constructed based on the use cases to provide a more
formal and unambiguous view of the the requirements. The requirements development
phase ends with the construction of a communication diagram which defines the system
interface based on the interactions in the use cases and activity diagrams.
It should be noted that the process does not obligate developers to use probabilistic
measures for assessment. Details about the assessment approach, and the results and
benefits of applying it to a reactive system, are given in Chapter 7. We nevertheless
111
floorRequest}
<<r>>
<<r>>
<<s>> <<r>>
MotorStopFailure}
: timeout,
:Buzzer
<<s>> off: OverweightAlert
<<s>> on: OverweightAlert
off: DoorAlert
on: DoorAlert
: timed message,
MotorStopFailure}
1
<<time-triggered>>
: Elevator Control System
<<s>> haltSystem: ReturnToGroundFloor
:Door
1
displayWeightStatus}
doorClosed: DoorAlert{
openDoor}
closeDoor}
openDoor}
closeDoor}
doorOpened: ReturnToGroundFloor{
doorClosed: RideElevator{
doorOpened: ElevatorArrival{
stopMotor}
stopMotor}
sendDown}
stopMotor}
MissedFloor}
MissedFloor}
startMotor}
motorStopped: ReturnToGroundFloor{
motorStopped: EmergencyBrake{
motorStarted: ReturnToGroundFloor{
motorStopped: ElevatorArrival{
motorStarted: ElevatorArrival{
reachedFloor: ElevatorArrival
apprFloorDetected: ReturnToGroundFloor {
apprFloorDetected: ElevatorArrival {
<<r>> callOperator: DoorAlert{
exitBuildingWarning}
<<r>> callOperator: EmergencyBrake
<<r>> callOperator: ReturnToGroundFloor
<<r>> callOperator: OverweightAlert{
<<r>> callOperator: RideElevator
: exception, <<s>>: safety-critical, <<r>>: reliability, handlers are shown in italics
:Weight
Sensor
1
: Emergency
Stop Button
1
Figure 6–15: ECS: Exceptional Interaction Diagram
stopMotor: ReturnToGroundFloor{
MotorStartFailure}
stopMotor: EmergencyBrake
sendDown: ReturnToGroundFloor{
<<s>> <<r>>
stopMotor: ElevatorArrival{
MotorStartFailure}
DoorStuckOpentooLong,
EmergencyOverride}
startMotor: ElevatorArrival{
exitBuildingWarning: DoorAlert{
displayWeightStatus: OverweightAlert{
OverweightTooLong}
displayDoorStatus: DoorAlert
clearDisplay: DoorAlert
displayFailure: DoorAlert
displayOverweight: RideElevator
clearDisplay: OverweightAlert
floorReqAck: RideElevator{
RideAbandoned}
callReqAck: CallElevator
floorRequest: RideElevator{
: Motor
<<s>> <<r>>
1
: Display
<<s>>
: Cabin
Button
*
*
: Floor
Button
callRequest: CallElevator
<<s>> detectWeight: OverweightAlert
*
DoorStuckClosed}
<<s>> turnOff: UserEmergency
<<s>> turnOn: EmergencyBrake
weight: OverweightAlert
: Emergency
Display
closeDoor: DoorAlert
1
: Emergency
Brake
DoorStuckOpen}
closeDoor: RideElevator{
<<r>>
openDoor: ElevatorArrival{
<<s>> <<r>>
<<exceptional>>
: Fire Operator
<<s>> activate: EmergencyBrake
<<s>> deactivate: UserEmergency
1
<<s>> off: UserEmergency
on: UserEmergency
DoorStuckClosed}
openDoor: ReturnToGroundFloor{
112
<<s>>
1
: Door
Sensor
: Movement
Sensor
1
: At Floor
Sensor
1
: Approaching
Floor Sensor
*
1
: Elevator
Operator
*
6.4. Summary
6.4. Summary
highly recommend developers interested in concrete dependability values to refer to and
apply our technique by using our DA-Chart modelling formalism.
To aid developers in following the process and in ensuring that important tasks are
not overlooked, we have included a checklist in Appendix B that lists in order all phases
and tasks in DREP. Each designer should use his own copy of the checklist which serves
as a log of the tasks carried out by him.
DREP has been illustrated using the Elevator Control System case study in this chapter. The case studies used to demonstrate our process are discussed in Chapter 9. For
further clarifications on how our process can be applied, please refer to the 407 Express
Toll Route case study in Section 9.2.
Based on our dependability-oriented requirements models, a specification that considers all exceptional situations and user expectations can be elaborated during a subsequent
analysis phase. This specification can then be used to decide on the need for employing
fault masking and fault tolerance techniques when designing the software architecture and
during detailed design of the system.
113
CHAPTER 7
Dependability Requirements Assessment Method
Rigorous requirements elicitation methods such as DREP proposed in Chapter 6 lead
the analyst to define handler use cases that address exceptional situations that threaten
system reliability and safety. These handler use cases allow exceptional interactions that
require several steps of handling to be described separately from the normal system behaviour. But is it enough to only define handlers for exceptions that can interrupt the
normal system functionality? What about exceptions that interrupt the handlers themselves? Do we need handlers for handlers? To answer these questions there must be a way
to assess the reliability and safety of system interactions with its interactions.
For this purpose, this chapter proposes a model-driven approach for assessing and
refining use case-based requirements to ensure that the specified functionality and the
chosen interactions meet the dependability requirements of the system. To carry out the
analysis, the requirements models are mapped to DA-Charts (Dependability Assessment
Charts), a probabilistic extension of parts of the statecharts formalism. The assessment
is then based on a tool that performs probability analysis of the model.
The chapter is organized as follows: Section 7.1 describes our model-driven approach
for assessing and refining system dependability. Section 7.2 discusses probabilities in use
case-based requirements. Section 7.3 presents our probabilistic statecharts formalism used
for dependability assessment. Tool support for our formalism is discussed in Section 7.4.
Section 7.5 discusses the assessment method, and Section 7.6 illustrates our proposed
analysis method by means of the Elevator Control System case study. Section 7.7 gives a
summary of DA-Charts and our assessment approach.
114
7.1. Model-Driven Dependability Assessment of Requirements
7.1
Model-Driven Dependability Assessment of Requirements
7.1.1
Dependability Assessment Methods
Dependability assessment approaches are typically of two types: quantitative assessment or qualitative assessment [76]. Qualitative assessment focuses on abnormal or undesirable events (faults, errors, and failures), and evaluates the potentiality and consequences of
the events. Fault Mode and Effect Analysis (FMEA) [165] and Fault Tree Method [130][128]
are examples of such approaches . Quantitative approaches, on the other hand, are focused
on measuring the reliance that can be placed on the services to be delivered (as per the
definition of dependability [12]). Our approach is quantitative in nature, and we define dependability measurements and techniques in order to compute the values of these measurements [76]. There are several existing methods for carrying out quantitative dependability
assessment including fault simulation, reliability block diagrams, and non-deterministic
state graph models.
• Fault simulation [76] involves injecting a model with faults and then analyzing the
model by comparing it with the fault-free version of the model, as applied in [228].
This approach is usually used at the design-level to measure the dependability of the
design as encoded in the model and then, if necessary, to measure the effectiveness
of introduced fault tolerance mechanisms.
• Reliability Block Diagrams [76] can be used to compute the global reliability of a
system containing components if the reliability values of individual components are
known. The components can be structured in series or in parallel.
• Non-deterministic state graph models [76] such as Markov graphs are state-based
graphs in which the transition from one state to another is probabilistic. They are
used to determine probabilities of reaching an end state from a given initial state.
Stochastic Petri nets are also used to carry out such analysis.
For our purpose we carry out analysis based on non-deterministic state graph models,
namely Markov models. To begin with, the requirements models are mapped to DA-Charts
(Dependability Assessment Charts), a probabilistic extension of part of the statecharts
formalism. Based on the DA-Chart, we implicitly build a Markov model that represents
the DA-Chart model. The assessment is then performed through probability analysis of
the Markov model obtained by transforming the DA-Charts models. This mapping and
analysis is supported by a tool as will be discussed later.
115
7.1. Model-Driven Dependability Assessment of Requirements
7.1.2
Assessment using DA-Charts
We propose a model-driven approach for assessing and refining use cases to ensure
that the software under development is able to meet the dependability requirements of the
system as defined by the stakeholders once it has been designed and implemented.
To put the assessment into context, we summarize our proposed process (described in
Chapter 6) in Fig. 7–1. The analyst starts off with standard use case-driven requirements
elicitation. Once the exceptional use cases are defined, the use cases are extended with
reliability and safety annotations. Next, each use case is mapped to a DA-Chart. Th
detailed mapping from use cases to DA-Charts is described in Chapter 8. This mapping
could be automated (see Section 7.7), but for now it has to be done manually. The DACharts are then analyzed by our dependability assessment tool and a report is produced.
The implementation of the tool using meta-modelling is described in Section 7.4.
The source requirements model can be either use cases or activity diagrams (presented
in Chapter 5). In this chapter, we discuss the construction of DA-charts directly from use
cases. But according to the preference of the analyst, the mapping of use cases to activity
diagrams can be an intermediate step, following which the DA-Charts can be created based
on the activity models. However, this would require the activity diagrams to be updated
every time a dependability assessment leads to changes in use cases. With complete tool
support, this would indeed be an effortless practice but currently since we create the
activity diagrams manually we employ use cases to drive our assessment method. Once
the evaluation is complete we map the exceptional use cases to activity diagrams, our
requirements specification artifact.
It is important to note that our process should be used in an iterative, model-driven
engineering context. The assessment tool can only obtain a numerical result when all the
external hardware components of the system under development are known. Often, not
all external hardware components are pre-determined when software development starts.
Usually, after an initial requirements elicitation phase, the use cases have to be refined
and updated during a high-level design phase, in which decisions are made on how users
are to interact with the system, which indirectly determines the use of specific hardware
components. Only once all external hardware components are known, and only if the
failure probabilities of these components are known (or can be estimated), our assessment
approach and tool can be used.
116
7.2. Probabilities in Requirements Models
The dependability assessment that our tool produces provides valuable information
to the designer of the system. Our approach calculates maximal achievable reliability and
safety, if the system were to be implemented with the chosen hardware components and
fault-free software. These maximal numbers can be compared to the required reliability and
safety values that the stakeholders expect. The maximal numbers have to be higher than
the required numbers, otherwise no implementation can ever satisfy the requirements.
If this is not the case, the tool can point out the interaction steps that affect reliability
and safety the most. Several options can then be investigated. It is possible to increase
the reliability of the secondary actors involved in these steps by, for instance, buying more
reliable hardware components, or employing redundant hardware and voting techniques.
Alternatively, the use cases have to be revisited and refined. First, the system must be
capable of detecting the exceptional situation. This might require the use of time-outs, or
even the addition of detection hardware to the system. Then, handler use cases must be
defined that compensate for the failure of the actor, or bring the system to a safe halt.
The analyst can perform the refinements in the annotated use cases or on the DA-Charts.
After the changes, the effects on the system reliability and safety are determined by rerunning the probabilistic analysis. The refinement process is repeated until the maximal
numbers are higher than the required numbers, i.e. the dependability requirements are
satisfiable.
The difference between the maximal numbers and the required ones is also an interesting piece of information that can be very valuable to the designers of the system. It
gives an indication of how “faulty” their implementation can be while still able to fulfill the
dependability requirements. This knowledge can influence the designers to use stringent
quality assurance techniques, or intensive testing procedures, or employ fault forecasting
approaches to estimate if the flaws in the implementation are acceptable. The numbers
can also help the designers to justify the costly use of fault tolerance techniques such as
n-version programming or recovery blocks.
7.2
Probabilities in Requirements Models
In order to quantitatively assess the dependability of a system, we need to quantify
the term reliance in the context of the system to be developed. At the requirements level,
the degree of reliance is dependent on the occurrence of failure of services to be delivered
and the uncertainty of this occurrence is represented with probabilistic values.
117
7.2. Probabilities in Requirements Models
Refine if necessary
1. Step:
Standard
Use Cases
UseCase: ...
Primary: ...
Main:
1. ...
2. ...
3. ...
2. Step:
Exceptional
Use Cases
UseCase: ...
Primary: ...
Main:
1. ...
Extension:
1a. Excep..
3. Step:
Annotated
Exceptional Use Cases
4. Step:
Mapping to
DA-Charts
UseCase: ...
Primary: ...
Main:
1. Rel:99%
Extension:
1a. Excep..
5. Step:
Dependability
Analysis
Dependability
Report
Figure 7–1: Model-Driven Process for Assessment and Refinement of Use Cases
A service failure is the result of the failure of one or more interactions (defined as use
case steps) between the system and external agents. Hence for the purpose of analysis,
we annotate each use case step with a reliability value. The value associated with each
interaction step represents the probability with which the step succeeds. If we assume
a perfect software (which we do in this phase of software development), the success and
failure of each interaction depends on the quality of the hardware device (such as motor,
sensor, etc.) with which the system interacts. The reliability of each hardware component
can be obtained from the manufacturer. If the secondary actor is a software system, its
reliability is also either known or can be determined statistically.
We quantify reliability of a component using the success or failure probability, which
is the likelihood that the system succeeds or fails when a service request is made. This is
essentially the probability of failure on demand (POFOD). For example, a POFOD of 0.01
implies that 1 in 100 service requests may result in failure. However other metrics such
as MTTF (mean time to failure) can be used to define reliability [202]. The type of the
system is a factor in determining the metric to use. Hardware reliability is often specified
with MTTF, which is the operational lifetime of a component, and is measured with time
units. Therefore, there is a need to eventually integrate the notion of time in our reliability
definition and analysis technique to be able to cater to various kinds of reactive systems
(as discussed in Chapter 12).
Using our process DREP (described in Chapter 6), the analyst discovers exceptional
situations, and defines exceptional use cases and handler use cases to address the situations. Then, each use case step that represents an interaction with a secondary actor is
118
7.3. DA-Charts
annotated with a probability value that specifies the chances of success of the interaction.
Additionally, each interaction step is annotated with a safety tag if the failure of that step
threatens the safety of the system (dependability annotations have been addressed in Task
4 in DREP described in Chapter 6).
7.3
DA-Charts
In this section, we introduce DA-Charts (short for Dependability Assessment Charts),
a probabilistic extension of the statecharts formalism introduced by David Harel [90].
7.3.1
Statecharts
The statecharts formalism is an extension of Deterministic Finite State Automata
with hierarchy, orthogonality and broadcast communication [91]. It is a popular formalism
for the modelling of the behaviour of reactive systems. It has an intuitive yet rigorously
defined notation and semantics. It is the basis for documentation, analysis, simulation,
and code synthesis. Many variants of statecharts exist, including the one that is part of
the UML standard [164].
7.3.2
Extending Statecharts with Probabilities
We extend the statecharts formalism with probabilities to enable dependability assessment. While stochastic petri nets is an established formalism with clearly defined
semantics, statecharts seem a more natural match for our domain. This, thanks to their
modularity, broadcast, and orthogonality features. Statecharts also make it possible to
design visually simple and structured models.
Statecharts are event-driven. State transitions occur if the associated event is triggered
and any specified condition is satisfied. Given the event, a source state has only one possible
target state. In the formalism we propose, DA-Charts, when an event is triggered, a state
can transition to one of two possible target states: a success state and a failure state.
When an event is triggered, the system moves to a success state with probability p and to
a failure state with probability 1-p. In most real-time systems, the probability of ending up
in a success state is closer to 1 and the failure state probability is closer to 0. For example,
if a motor in a mechanical system is asked to stop, it might stop with a probability of
0.999 and it might fail to stop with probability 0.001. As in statecharts, a transition may
119
7.3. DA-Charts
broadcast events. The event that is broadcast can be different depending on whether the
transition leads to a success state or a failure state. Hence, the outcome of the event might
vary.
DA-Charts Syntax
The statecharts notation is extended to include probabilities. In tradi-
tional statecharts, state transitions are annotated with event[condition]/action. The event
denotes a message which triggers the transition if the guard condition holds true. Here,
action represents the operation that is carried out when the transition is executed.
The standard transition is split into two transitions, each annotated with the probability that the event associated with the transition leads to a success state or a failed state.
The notation used for this purpose adds an attribute next to the event: event[condition]
{probability} /action. Absence of the probability attribute denotes a probability of 1. The
P
constraint is defined as
outgoing P = 1.
DA-Charts Semantics
Finite State Automaton: Unlike statecharts, DA-Charts are non-
deterministic due to the addition of probabilities in state transitions. Our formalism requires adaptation of the various features of the statecharts semantics to support the notion
of non-determinism. In particular there is non-determinism in both the end states and in
which events are broadcast.
Orthogonality: In DA-Charts, orthogonal components model the concurrent behaviour
of actors in the environment. For example, in an elevator system, we might want to model
the different hardware devices (motor/sensors) as orthogonal components. However, DACharts have the constraint that events cannot be triggered simultaneously in orthogonal
components.
Broadcast: The broadcasting feature is used in DA-Charts to enable sequencing of
events. In a real-time system, the system progresses with time and some devices can only
react provided that some required event has occurred. In the elevator system, the door
should only be opened if the floor sensor detects that the destination floor has been reached.
Depth: DA-Charts supports a limited form of hierarchy. Hierarchical states within the
system component reflect the user goal / sub-goal hierarchy. The probability of success of
a goal depends on the reliability values of its sub-goals.
120
7.3. DA-Charts
History: When external events or environmental hazards are considered in DA-Charts,
history states would be useful when the system needs to return to a prior state after handling such a situation. For example, a user inside an elevator might request an emergency
stop but after servicing the request, the system might want to resume normal functionality.
DA-Charts Constraints
Our DA-Chart formalism is constrained by the following:
• Every DA-Chart must contain a system component describing the behaviour of the
software of the system. No probabilities are allowed in the system component, since
at the requirements level we assume a fault-free implementation.
• Each secondary actor is modelled by an orthogonal component. Each service that an
actor provides can either succeed or fail, which is modelled by two transitions leading
to either a success or a failed state, annotated with the corresponding probabilities.
• To monitor the safety constraints of the system, an additional orthogonal safetystatus component is created. Whenever the failure of an actor leads to an unsafe
condition, a toUnsafe event is broadcast to the safety-status component. Other
quality constraints can be modelled in a similar manner.
• Orthogonal components are required to react to unique event names. Hence, an event
broadcast from one component becomes a narrowcast to a particular component.
• Each DA-Chart must contain a outcome component including states representing
the four possible outcomes of the user goal which are success, degraded, failure, and
abandoned.
7.3.3
Mapping Exceptional Use Cases to DA-Charts
As already explained in Section 7.1.2, during requirements elicitation, the developer
can assume that the system itself, once it has been built, will always behave according to
specification - in other words, it will not contain any faults, and will therefore never fail. As
the development continues into design and implementation phases, this assumption is most
certainly not realistic. Dependability assessment and fault forecasting techniques have to
be used to estimate the reliability of the implemented system. If needed, fault tolerance
mechanisms have to be built into the system to increase its dependability.
Although the system is assumed to function perfectly, a reliable system cannot assume
that it will operate in a fault free environment. Hence, at this point we need to consider
121
7.3. DA-Charts
the possible failure of (secondary) actors to perform the services requested by the system
that affects the dependability of the system.
To begin the analysis, DA-Charts need to be created to represent the use cases. Each
use case is mapped to one DA-Chart. The exceptions that are mapped to the DA-Chart
are service-related exceptions. We define transformation rules to map the use cases to
DA-Charts in Chapter 8.
7.3.4
Other Features of DA-Charts
Hierarchies in DA-Charts
Our use cases are hierarchical in nature: summary-level use
cases include user-goal use cases which in turn include other user-goals or sub-functional
level use cases. To be able to model such use cases as DA-Charts, we need support for hierarchy in DA-Charts. Introducing hierarchy in DA-Charts enables the modeller to express
the structure of hierarchical use cases directly without the need for manual flattening.
We use composite states in a restricted manner in order to model the hierarchal structure of states in DA-Charts. The root-level user goal use case is mapped to the System
component. The included use cases are mapped to composite states inside System. The
probability analysis is carried out in a bottom-up manner by first calculating the probability of satisfying the leaf-level goal. The reliability is then propagated up and the value
is used to compute the probability of reaching a success outcome in the higher-level goal.
An example of a DA-Chart with hierarchy is shown in Fig. 7–11.
Cycles in DA-Charts Currently, the probability analysis approach is restricted to acyclic
models. It is however possible to analyze a use case with a finite number of loops by
mapping it to a DA-Chart with additional states to model each iteration. This is later
discussed in Section 7.6 and exemplified in Fig. 7–10.
Modelling Context-Affecting Exceptions with DA-Charts In DA-Charts, transitions in
the system component are triggered based on the behaviour of secondary actors which
is probabilistic in nature. However, we do not consider randomness introduced due to
external environmental events, such as a fire outbreak. This would require us to make the
transitions probabilistic, and consider timing aspects.
122
7.4. Tool Support for DA-Charts
When a context-affecting exception occurs, the exception interrupts the current service
and either causes termination of the service or it is put on hold. The user goal fails or is
suspended and an exceptional goal takes over in order to handle the exceptional situation.
In the first case, a new goal is initiated and hence a new DA-Chart needs to be
created to represent this use case and the probability of success of the exceptional goal can
be computed. In the ECS, when the EmergencyOverride exception occurs due to a fire,
the current TakeElevator goal and all requests are cancelled and the ReturnToGroundFloor
goal takes over. Hence, system dependability depends on the success of the handler now.
The system does not offer any other service until it is instructed to switch back into normal
mode.
In the other situation, once the handling is carried out, the system should continue with
the provision of services. The user goal that was suspended needs to be reinitiated by calling
the service again. For example, in case of the exception EmergencyStop, once the user
emergency is handled the elevator is available again and the system can continue processing
the remaining requests. In such a case, TakeElevator is restarted and ElevatorArrival is
rescheduled with the same destination floor, but with a different start floor as parameter.
Hence, system dependability needs to be calculated for the new goal now.
7.4
Tool Support for DA-Charts
7.4.1
AToM3 : A Tool for Multiformalism and MetaModelling
To allow rapid development of visual modelling tools, we use AToM3 , A Tool for
Multi-formalism and Meta-Modelling [54, 52]. The tool allowed us to create a prototype
without requiring extensive time and effort. Moreover, there already existed a statechart
metamodel implementation. Formalisms and transformations are modelled using metamodels and graph transformation models respectively. Also, composite types and the user
interfaces of the generated tools are modelled explicitly. The tool has proven to be very
powerful, allowing the modelling of known formalisms such as Petri Nets [53].
123
7.4. Tool Support for DA-Charts
7.4.2
DA-Charts Implementation in AToM3
From the syntactic point of view, DA-Charts uses a simple extension of the statecharts
syntax: a simple edge is extended by adding a probability attribute which becomes a PEdge, so the action and the target depend on the outcome of a probabilistic experiment.
A traditional edge can be seen as a P-Edge whose probability is 1.
We implement tool support for DA-Charts by extending the meta-model of the DCharts
formalism (a variant of Statecharts) described in [68]. This is done in three steps as follows.
First, probability is added as a float attribute to the Hyperedge relationship of the existing
DCharts meta-model (an Entity-Relationship diagram). The default value of probability
is 1. Two constraints are added. One constraint allows users to only set the probability
of a transition to a value in the range [0,1]; the other checks if the total probability of
all transitions from the same source node and triggered by the same event is exactly 1.
AToM3 allows for the subsequent synthesis of a visual DA-Charts modelling environment
from this meta-model. Second, a Probability Analysis (PA) module which can compute
probabilities of reaching a target state is implemented. The algorithm is described in the
next section.
The semantics of a DA-Chart are described informally as follows. When an event
occurs, all P-Edges which are triggered by the event and whose guards hold are taken.
The system then leaves the source node(s), chooses one of those P-Edges probabilistically,
executes the action of the chosen P-Edge, and enters the target node(s).
We extend the AToM3 visual modelling environment of the DCharts formalism to
include features that allow DA-Charts to be modelled and assessed. Fig. 7–2 shows a
snapshot of the tool used for visually creating and editing DA-Charts. The environment
supports syntax-directed modelling. At the top of the window, a menu bar is available
which comprises of graphical elements (such as basic state, composite state) used to create statechart models. An additional button (PA) which invokes the probability analysis
module is added to the visual modelling environment. When the source and target states
for an analysis is specified, the traversed path is highlighted in green. The results following
an analysis is displayed in a pop-up window as shown in Fig. 7–2.
7.4.3
Probability Analysis of DA-Charts in AToM3
To carry out probability analysis of the DA-Chart model, the Markov chain corresponding to the DA-Chart is constructed. A Markov chain is a sequence of states of a
124
7.4. Tool Support for DA-Charts
system, such that the future state can be deduced based only on the current state, and
is completely independent of the past state. The chain can be described as a directed
graph, with the state transition probabilities shown along each edge. This provides a
map of the traversed paths, and allows the probability along a path to be calculated in a
straightforward manner.
Given a source state (consisting of a tuple of source nodes) and a target state, the
probability to reach the target from the source is computed by finding all paths that lead
from the source to the target state. The probability of each path is calculated as the
product of all transition probabilities. The total probability is then computed by adding
the probabilities of all paths.
A probabilistic analysis algorithm based on the above observations has been implemented in AToM3 . It requires four arguments, model M containing all elements, such as
components, nodes and edges, a tuple of node names of the source state S, a tuple of node
names (so far we only support specifying one node) of the target state T, and a tuple of
nodes of the default state D. It then produces a float value in the range [0, 1], which corresponds to the probability of reaching the target state when starting at the source state.
The algorithm is shown below in pseudocode form.
probAnalysis(M, S, T, D):
//construct a map to speed up the process to find transitions
//triggered by a given event
e_map = {} //init a map: event -> a list of tuples
//for each tuple: the triggered transition and the source node
for each node in M:
for each transition starting from the node:
e = get the event that triggers the transition
t_list = e_map[e]
t_list.append((node, transition))
p = 0 //the base probability
//probability of all transitions are added
for each transition starting from the source S:
p += computeProb(transition, T, e_map, D)
return p
//computeProb(trans, target, e_map, cur_state) computes
//accumulated probability starting from target node to current
//transition trans using e_map (depth-first);
125
7.4. Tool Support for DA-Charts
//cur_state keeps track of the current state of the system
computeProb(trans, target, e_map, cur_state):
update cur_state w.r.t. trans
c_p = get the probability of trans
if next node of trans is target:
return c_p
else:
p = 0 //the base probability
for each event e in actions of trans:
//get the list of transitions (and their source nodes)
//triggered by e
t_list = e_map[e]
for each (n, t) in t_list:
if n in cur_state:
p += c_p * computeProb(t, target, e_map, cur_state)
return p
An analyst wanting to compute, for instance, the reliability of the system has to
first press the PA button, and then select the target state that symbolizes the successful
completion of the goal, after which a pop-up dialog shows the result and all possible paths
leading to the target state are highlighted in the model.
Fig. 7–2 shows an example DA-Chart model in AToM3 . The model consists of three
components: System, D1 and D2. The default state is (s5, s1, s8) and the only transition
which can happen initially is the one from s1 to s2. The probability of reaching (s3,
*) (“*” means we do not care about the reached state in other orthogonal components
when the system ends in the state containing s3 ) from (s5, s1, s8) is 99.95% which is
the combination of the probabilities along two possible paths: Ts1→s2 , Ts5→s6 , and Ts2→s3
for path one; Ts1→s2 , Ts5→s7 , Ts2→s4 , Ts8→s9 , and Ts4→s3 for path two. The computation
performed is:
Ptotal = (Ps2→s3 × Ps5→s6 + (Ps4→s3 × Ps8→s9 ) × Ps2→s4 × Ps5→s7 ) × Ps1→s2
7.4.4
(7.1)
Discussion
Scaleability
It is common for requirements to be much less complex than the eventual
detailed design and ultimately code which will satisfy these requirements. Nevertheless,
126
7.4. Tool Support for DA-Charts
Figure 7–2: Example DA-Chart Model in AToM3
to be of industrial relevance, our approach should scale to much larger problems than the
example presented here.
There are two aspects to scaleability. On the one hand, from an expressiveness point
of view, the modeller should be able to describe complex systems intuitively and modularly.
On the other hand, from a computational point of view, the analysis algorithm should scale
well with the size of the models.
Our approach leads to one statechart orthogonal component per actor in the requirements, one orthogonal component to model the safety status of the system, as well as
one orthogonal component modelling system behaviour. The latter system behaviour is
obtained from the collection of use cases. Thus, the number of orthogonal components
will grow linearly with the number of actors. The number of possible interactions between
orthogonal components is determined by both the number of components and the number
of states in those components. This can in principle lead to a combinatorial explosion of
the number of possible interactions. These possibly unanticipated interactions are however
inevitable and what makes our approach appealing: the DA-Charts model allows the modeller to represent individual actor component behaviour in relative isolation; the analysis
127
7.5. Dependability Analysis with DA-Charts
algorithm will subsequently compute all possible interactions and the resulting probabilities
of reaching undesired (e.g., unsafe) states.
Limitations Breaking down large problems in a modular, hierarchical fashion is a common
approach to tackle complexity. Our visual modelling environment does allow hierarchical
DA-Charts to be constructed, but our probability analysis implementation needs to be
extended to take hierarchies into account. It should be noted that this exercise is nontrivial: the semantics of nesting (including priorities) in the presence of probabilities needs
to be intuitive to the modeller as well as precisely defined. The model could indeed be
flattened and then mapped to a markov chain thus allowing dependability assessment to
be carried out. However, the ideal solution would be to allow analysis of the hierarchical
model. Another limitation of our implementation is that at present it does not provide
support for loops or cycles in the model.
It should be noted that use cases as currently in use are not very hierarchical in
nature. It is indeed rare for use cases to have a hierarchical depth of more than three.
To tackle complexity, it is also possible to deal with individual goals in isolation, thus
reducing the complexity of the overall model. In addition to that, use cases describe very
specific scenarios (in which every step consists of a single interaction). As such, they
severely restrict the number of possible interactions between orthogonal components. This
drastically reduces the complexity of the analysis.
AToM3 ’s ability to refer to sub-models (through references) makes it easier to deal with
large numbers of orthogonal components. Each orthogonal component can be modelled
visually, in isolation and later combined into an overall model.
Past experience with AToM3 has shown that it scales well to medium-sized problems
(in the order of thousands of model entities). The main bottleneck lies in the fact that
AToM3 is currently a purely visual modelling environment. For analysis purposes, display
and layout of models is totally un-necessary and prohibits the use of truly large models.
7.5
Dependability Analysis with DA-Charts
To begin the probabilistic analysis, the DA-Chart to be assessed is flattened and
the corresponding Markov chain is created that includes the states, the outcomes, and
the reliability values of the success and failure of the actor components. The automatic
128
7.5. Dependability Analysis with DA-Charts
creation of the Markov chain by the tool is hidden from the modeller, who only views the
final results of the assessment.
7.5.1
Degraded Outcomes in DA-Charts
DA-Charts can model the different outcomes of user goals as defined in Chapter 4.
During the construction of the models, an orthogonal component named Outcome is added
that includes four states, success, degraded, failure, abandoned, along with an initial state.
An event is broadcast when the end state is reached or when an exception is encountered,
which leads to the transition from the initial state to the final outcome in the Outcome
component.
7.5.2
Safety Analysis
In order to carry out assessment of system safety, we add yet another orthogonal
component in the DA-Chart with three states, normal, safe, unsafe. On occurrence of an
exceptional event that threatens the safety of the system, the event toUnsafe is broadcast
which triggers a transition of the normal state to the unsafe state.
7.5.3
Reliability Analysis
To evaluate the reliability level that can be attained, it is necessary to measure the
probability of reaching the end or success state and hence completing the user goal successfully. This can be obtained by calculating the probability of reaching the state success
in the Outcome component using Markov chains. The probability of reaching any other
outcome, such as degraded or failure can be computed in a similar manner. It should be
noted that in our approach we assume that the timeliness requirements are being met and
hence success of a user goal is only dependent on reaching the end state and not also on
meeting deadlines.
7.5.4
Markov Chains
For the purpose of carrying out dependability analysis, the DA-Charts model is first
mapped to the corresponding Markov Chain. The Markov Chain, as shown in Fig. 7–5, is a
map of all possible paths that can be traversed in the DA-Chart model. Based on this map,
the probability of reaching success or failures states can be computed in a straightforward
129
7.6. Case study: Elevator Control System
manner. It should be noted that each state in the Markov chain denotes a tuple of states
in the flattened state machine model.
7.6
Case study: Elevator Control System
We demonstrate our approach by applying it to a subset of the Elevator Control
System (ECS) case study: Elevator Arrival. We introduced the ECS case study and the
ElevatorArrival subfunctionality in Chapter 5. The analysis of the basic use case following
the approach in Chapter 6 leads to the discovery of some critical exceptions that interrupt
the normal elevator arrival processing.The ElevatorArrival use case along with possible
exceptions that can occur are shown in Fig. 6–8.
7.6.1
Analyzing Exceptions in the Elevator Arrival Use Case
At this point, the standard use case has been already analyzed for exceptional situations that can arise while servicing a request. As discussed in Section 6.3, several failures
might occur: the destination floor might not be detected (MissedFloor ); the motor might
fail (MotorFailure); or the door might not open at the floor (DoorFailure and DoorUnresponsive).
To detect whether the elevator is approaching a floor, we need to introduce a sensor,
ApprFloorSensor. To detect a motor failure, an additional sensor, AtFloorSensor is added.
It detects when the cabin stopped, and therefore when it is safe to open the doors. To
detect whether the door opened, we need to use another sensor, DoorSensor.
Fig. 7–3 shows the updated version of the ElevatorArrival use case that includes the
added acknowledgment steps and the exception extensions. Some steps are annotated
with (assumed) probabilities of success: the ApprFloorSensor and the AtFloorSensor have
failure chances of 2% and 5% respectively. The DoorSensor has a 5% chance of failure.
The motor has a 1% chance of failure. In this example scenario, we assume that the
motor always starts. However if an exception MotorStartFailure is considered, a detector
MovementSensor needs to be added.
The door failure might be permanent in nature, or might be a transient one that
disappears over time. The door has a failure chance of 1% in cases of both permanent and
transient failure. In addition, each step is tagged as Safety-critical if the failure of that
step threatens the system safety.
130
7.6. Case study: Elevator Control System
Use Case: ElevatorArrival
Intention: System wants to move the elevator to the User ’s destination floor.
Level: Subfunction
Main Success Scenario:
1. System asks Motor to start moving towards the destination floor.
2. Approaching Floor Sensor informs System that cabin is approaching destination floor.
reliability:0.98, safety-critical
3. System requests Motor to stop. reliability:0.99, safety-critical
4. Floor Sensor informs System that elevator is stopped. reliability:0.95
5. System requests Door to open. reliability:0.98
6. Door Sensor informs System that door is open. reliability:0.95
Use case ends in success ReachedDestination.
Extensions:
2a. Exception{MissedFloor}
4a. Exception{MotorStopFailure}
6a. Exception{DoorUnresponsive}
6b. Exception{DoorFailure}
Figure 7–3: ECS: Refined ElevatorArrival Use Case
7.6.2
The DA-Charts Model of the Basic Elevator Arrival System with Failures
We first model the initial ElevatorArrival use case shown in Fig. 7–3 as a DA-Chart
according to the process described in Section 7.3.3. The result is shown in Fig. 7–4. The
model consists mainly of six orthogonal components which model the behaviour of the
system (System), a motor (Motor), a door (Door), and three sensors (ApprFloorSensor,
AtFloorSensor, and DoorSensor ). An additional orthogonal component is used to monitor
the safety outcome of the system. Note that the system itself has no randomness.
To clarify the model, one of the components is briefly explained here. The Motor is
initially ready (in the mtr ready state). After it is triggered by the System (by the start
event), it acknowledges the System’s request (by broadcasting startAck ) and goes into
running mode (by transitioning to the mtr started state). When the motor is asked to stop
(by the stop event), the Motor will either stop itself successfully (going to mtr stopped ) and
send an acknowledgement (by broadcasting stopAck ), or fail to stop (going to mtr failed
and broadcasting motorFailure and toUnsafe). The chances of success and failure are 99%
and 1% respectively.
When the floor sensor informs the System that it has reached the destination floor,
the System sends the openDoor request to the Door. The open door operation has a 98%
chance of succeeding, a 1% chance of failing, and a 1% chance of failing transiently, i.e.
131
7.6. Case study: Elevator Control System
ElevatorArrival
System
Motor
ApprFloorSensor
sys_ready
mtr_ready
start/startAck
apFlrSnsr_ready
/start
startAck{0.02}/missedFloor;toUnsafe
startAck{0.98}/apFlrSnsrD
mtr_started
stop{0.01}/motorFailure
stop{0.99}/stopAck
sys_started
apFlrSnsr_ack
apFlrSnsrDetected/stop
apFlrSnsr_failed
AtFloorSensor
mtr_stopped
missedFloor/toFailure
mtr_failed
Door
sys_stopped
atFlrSnsr_ready
openDoor{0.01}/doorUnresponsive
atFlrSnsrFailure/toFailure
floorReached/openDoor
stopAck{0.05}/atFlrSnsrFailure
stopAck{0.95}/floorReached;toSafe
motorFailure/toFailure
door_ready
openDoor{0.98}/openAck
sys_at_floor
atFlrSnsr_ack atFlrSnsr_failed
openDoor{0.01}/doorFailure
DoorSensor
door_opened
doorFailure/toFailure
door_failed
doorSnsrFailure/toSuccess
door_sn_ready
openAck{0.95}/doorOpened
Status
openAck{0.05}/doorSnsrFailure
normal
toUnsafe
toSafe
safe
door_sn_ack
doorOpened/toSuccess
door_sn_failed
Outcome
unsafe
goalTermination
toSuccess initial
toFailure
toAbandonned
toDegraded
success abandonned degraded failure
Figure 7–4: ECS: DA-Chart Model of the Elevator Arrival Use Case with Failures
not responding. The Door sends an acknowledgment to the door sensor (by broadcasting
openAck ) once it opens successfully.
7.6.3
The Markov Chain of the Basic Elevator Arrival System with Failures
For the purpose of carrying out dependability analysis, the DA-Charts model is first
mapped to the corresponding Markov Chain. The Markov Chain representing the Elevator
Arrival DA-Chart, shown in Fig. 7–5, is a map of all possible paths that can be traversed
in the DA-Chart model. Based on this map, the probability of reaching success or failures
states can be computed in a straightforward manner. It should be noted that each state in
the Markov chain denotes a tuple of states in the flattened state machine model. The tuple,
which represents orthogonal states that the state machine can occupy simultaneously, is
collapsed and shown as a single state in Fig. 7–5.
132
7.6. Case study: Elevator Control System
Ready
1
Start
Sent
1
Motor
Started
0.98
Appr
Detect
1
Stop
Sent
0.99
0.01
0.02
AprDet
Failed
1
0.95
Stop
Detect
0.05
Motor
Failed
1
Motor
Stoppd
StoDet
Failed
1
1
0.01
Door
Failed
Open
Door
Open
Sent 0.98 Open 0.95 Detect
0.01
1
0.05
Door
Unresp
Succ
1
OpDet
Failed
1
1
Failure
Figure 7–5: ECS: Markov Chain of the Elevator Arrival Use Case with Failures
7.6.4
Evaluating Dependability of the System
Safety Analysis We want to ensure the safety levels maintained by the elevator arrival
system. The system is unsafe if the approaching floor sensor fails to detect the destination
floor (because then the system never tells the motor to stop), or if the motor fails to stop
when told to do so. This is why the failure transition in the ApprFloorSensor component,
as well as the failure transition in the Motor component broadcast a toUnsafe event that is
recorded in the Status component. It is interesting to note that actually achieving the goal
of the use case has nothing to do with safety. Our tool then calculates that the probability
of reaching the state safe from the initial system state (sys ready) is 97.02%, which is the
combination of the probabilities along two possible paths.
As shown in Fig. 7–5, a failure of the door sensor does not lead to an unsafe state, if
the door opens successfully on reaching the destination floor. This is because the elevator
is already at the floor and the door opens when instructed by the system. The person
riding the elevator is not stuck inside and hence no dangerous situation is created due to
the door sensor failing and not recognizing that the door is already open.
Reliability Analysis Our tool calculates a reliability (probability of reaching the success
outcome state) of 90.3256%.
A failure of the AtFloorSensor would prevent the system from knowing that the destination floor is reached, and hence the system cannot request the door to open. Otherwise,
if the system is informed that the floor has been reached, the system is able to request the
door to open. However, the door might fail to open due to a fault in the door mechanism.
133
7.6. Case study: Elevator Control System
In both the failure cases, the person riding the elevator would be stuck inside the cabin,
and hence the goal fails.
In Fig. 7–5 it can be seen that the System transitions to the success outcome state even
when it receives the doorSnsrFailure event. This is because the door opens successfully at
the destination floor and permits the person inside the cabin to leave the elevator. The
goal of the person which was to take the elevator to a destination floor is achieved.
7.6.5
Refining the Elevator Arrival Use Case
For a safety-critical system like the elevator control system, a higher level of safety
is desirable. Safety can be increased by using more reliable or replicated hardware, but
such hardware might not be available or might be too costly. Another possibility is to
initiate an action that can prevent catastrophes from occuring. To illustrate this approach,
we focus on the motor failure problem. To remain in a safe state even if the motor fails,
it is necessary to use additional hardware like an emergency brake. This behaviour is
encapsulated in the EmergencyBrake safety handler (shown in Fig. 7–6).
Handler Use Case: EmergencyBrake
Handler Class: Safety
Context & Exception: ElevatorArrival{MotorFailure}
Intention: System wants to stop operation of elevator and secure the cabin.
Level: Subfunction
Main Success Scenario:
1. System requests Motor to stop.
2. System activates the Emergency Brakes. reliability:0.999, safety-critical
3. System turns on the Emergency Display.
Figure 7–6: ECS: EmergencyBrake Handler Use Case
7.6.6
The DA-Charts Model of the Safety-Enhanced Elevator Arrival Use Case
The DA-Chart model of the elevator arrival system is updated to reflect the use of
emergency brakes (see Fig. 7–7). Another orthogonal component to model the behaviour
of the emergency brakes is added. The brake used has a 99.9% chance of success.
The updated DA-Chart model is again mapped to the corresponding Markov chain
model in AToM3 . Based on the updated map, the tool generates new dependability values.
134
7.6. Case study: Elevator Control System
Figure 7–7: ECS: DA-Chart Model of the Elevator Arrival System with Failures and Safety
Handlers
Safety Analysis
A probability analysis of the updated model shows a significant improve-
ment in the safety achieved by the system. It is now safe 97.9942% of the time, which
evaluates to an increase of 0.9742%. The safety would be even more improved if the
missedFloor exception would be detected and handled.
Reliability Analysis
The modifications in the model have not changed the reliability of
the system. The following section addresses the reliability concern.
135
7.6. Case study: Elevator Control System
7.6.7
Refining the Elevator Arrival Use Case to Improve Reliability
The use case could be further refined so that the elevator detects when the AtFloorSensor fails
1
, and then the system could redirect the elevator to the nearest floor. Even
though the original goal of the user is not satisfied, the system attempts to provide reliable service in a degraded manner. Alternately, the reliability can also be improved if the
door failure problem is handled. If the door failure is of a permanent type, then recovery
would involve calling a service person to repair the problem. However, if the door did not
open due to a temporary failure, the system can attempt to retry opening the door. This
exception handling behaviour is described in the RetryDoor Handler, shown in Fig. 7–8.
Handler Use Case: RetryDoor
Handler Class: Reliability
Context & Exception: ElevatorArrival{DoorUnresponsive}
Intention: System wants to retry opening the elevator door.
Level: Subfunction
Main Success Scenario:
1. System requests door to open. reliability:0.98
2. System receives confirmation that door is opened. reliability:0.95
Figure 7–8: ECS: RetryDoor Handler Use Case
7.6.8
The DA-Charts Model of the Reliability-Enhanced Elevator Arrival Use
Case
The DA-Chart model of the elevator arrival system is updated once again to show
the behaviour of the system following a door failure (see Fig. 7–9). A new state is introduced, sys retry. When the door neither opens nor transitions to the door failed state, it is
presumed that the door mechanism failed temporarily. The system then goes into a retry
mode (sys retry) and requests the door to open again. If the door fails to respond the
second time, or if the failure evolves into a permanent one, the system moves to a failed
state.
1
This can, for instance, be done using a time-out.
136
7.6. Case study: Elevator Control System
Figure 7–9: ECS: DA-Chart Model of the Elevator Arrival System with Failures and Reliability Handlers
A probability analysis of the reliability-enhanced model shows an increase of 0.9033%
in the reliability of the system. As mentioned above, handling the AtFloorSensor exception
can further improve the reliability level.
7.6.9
Discussion
We have only shown one safety-related refinement of the ElevatorArrival use case to
demonstrate our assessment method and tool. As mentioned earlier, handling the MissedFloor exception improves both safety and reliability of the system. The extended DA-Chart
addressing this exception is shown in Fig. 7–10. The system reschedules the elevator cabin
with a new floor request. In the DA-Chart, a start event is broadcast and the Outcome
component moves into the degraded state. Many other exceptions affect the dependability
of the elevator system, for example exceptional situations that occur due to overweight
137
7.6. Case study: Elevator Control System
Figure 7–10: ECS: DA-Chart Model of the Elevator Arrival System with Failures and
Dependability Handlers
or further problems during handling. However, such issues can be easily modelled in DACharts following our defined process, and can then be subjected to probability analysis.
The proposed assessment approach can be easily scaled for more complex systems.
A hierarchical DA-Chart of the RideElevator use case is shown in Fig. 7–11. RideElevator calls the ElevatorArrival sub-use case. The model hence includes the ElevatorArrival
component (Fig. 7–10). The CallElevator DA-Chart is also created in a similar manner.
The TakeElevator DA-Chart includes the CallElevator in a composite state followed by
RideElevator in another composite state.
Assessment and refinement is supposed to be an iterative process, and can be continued
as long as it is realistic and feasible, until the expected system safety and reliability is met.
Thanks to our tool support, iterations are not time-consuming, and immediate feedback is
given to the analyst of how changes in the use cases affect system dependability.
138
7.7. Summary
RideElevator
Motor
System
ApprFloorSensor
mtr_ready
sys_idle
newReq
start/startAck
apFlrSnsr_ready
startAck/missedFloor
mtr_started
stop{0.99}/stopAck
startAck{0.98}/apFlrSnsrDetected
sys_active
/closeDoor
doorStuckOpen/toFailure
stop{0.01}/motorFailure
apFlrSnsr_ack apFlrSnsr_failed
sys_in_op
doorClosed
mtr_stopped
AtFloorSensor
mtr_failed
ElevatorArrival
Door
atFlrSnsr_ready
openDoor{0.01}/doorUnresp
sys_ready
stopAck{0.05}/atFlrSnsrFailure
/start
stopAck{0.95}/floorReached;toSafe
door_opened
closeDoor{0.98}/closeAck
openDoor{0.01}/doorFailure
sys_started
missedFloor/toDegraded
apFlrSnsrDetected/stop
openDoor{0.98}/openAck
door_closed
door_failed
closeDoor{0.02}/doorFailure
sys_handling
door_sn_idle
openAck{0.95}/doorOpened
openAck{0.05}/doorSnsrFailure
sys_stopped
EmergencyBrake
eb_ready
activateEB{0.001}/toUnsafe
atFlrSnsrFailure/activate
floorReached/openDoor
closeAck{0.95}/doorClosed
door_sn_waiting
motorFailure/activateEB;t
activateEB{0.999}/toSafe
eb_activated
eb_failed
door_sn_failed
closeAck{0.05}/doorSnsrFailure
sys_at_floor
Status
atFlrSnsr_failed
atFlrSnsr_ack
DoorSensor
/start
doorUnresponsive/openDoor
doorFailure/toFailure
Outcome
doorSnsrFailure/toSuccess
normal
toSafe
doorFailure/toFailure
doorOpened/toSuccess
toUnsafe
safe
toAbandonned
sys_retry
doorOpened/toSuccess
unsafe
toFailure
initial
toDegraded
toSuccess
doorSnsrFailure/toSuccess
abandonned degraded
success
failure
goalTermination
usergoalTermination
Figure 7–11: ECS: Hierarchical DA-Chart Model of Ride Elevator
Using our requirements elicitation and analysis process, we discovered exceptions and
defined additional use cases and reliability and safety handlers for the elevator control
system. Fig. 6–14 illustrates the relationships between the use cases, exceptions, and
handler by means of an extended use case diagram.
7.7
Summary
We have proposed a model-based approach for analytically assessing the safety and
reliability of requirements based on use cases. The contribution mainly lies in the combined
Outcome
use of exceptional use cases, probabilities, statecharts, and dependability analysis. Each
eb_activated
eb_failed
toSuccess
Status
initial
toFailure
interaction step in a use case is annotated with a probability reflecting its chances of
normal
toUnsafe
success, and a safety tag if the failure of the step hampers the system safety. The use cases
toSafe
safe
success
unsafe
139
failure
7.7. Summary
are then mapped to DA-Charts, a probabilistic extension of the statechart model. Precise
mapping rules have been suggested. We have implemented our formalism in the AToM3
tool to provide support for visual modelling and automatic dependability analysis. The
tool also verifies the formalism constraints and ensures that the mapping rules are adhered
to. Based on path analysis, the tool quantitatively determines probabilities of reaching
safe or unsafe states. The assessment allows the analyst to decide if the dependability
constraints of the system are met. If not, the use cases have to be refined. This implies
introducing additional interaction steps, discovering exceptions and applying handlers that
dictate the system behaviour in such situations. At each refinement step, our tool provides
immediate feedback to the analyst on the impact of the changes on system dependability.
Context-affecting exceptions, hierarchies, and cycles in DA-Charts have been addressed and are discussed further in Chapter 12.
140
CHAPTER 8
Model Transformations in DREP
In Chapter 6, we proposed a use case-driven Dependability-Oriented Requirements Engineering Process (DREP) that systematically guides the developer to consider reliability
and safety concerns of reactive systems. DREP relies heavily on the idea of model-driven
engineering (as defined by OMG [157]), in which models of the system under development
are built, and then incrementally modified and transformed as the development progresses
from requirements elicitation to analysis, design and implementation. At each phase, our
process uses the modelling formalisms and notations that are most appropriate to express
the concern at hand. The different modelling formalisms used in our requirements engineering process are shown in Fig. 6–2. The arrows depict the model transformations that
occur when moving from one phase of the process to the next.
This chapter focuses on the transformation of exceptional use cases to activity diagrams and DA-Charts (as shown in Fig. 6–2), and complements our process, DREP. The
chapter is organized as follows. Section 8.1 discusses the characteristics of our transformation approaches. Section 8.2 gives the transformation rules for mapping exceptional use
cases to activity diagrams, and Section 8.3 defines transformation rules to map use cases
to DA-Charts. Section 8.4 illustrates our approach using the elevator control system case
study. Section 8.5 gives a summary of our transformation approaches.
141
8.1. Model Transformation: Characteristics
8.1
Model Transformation: Characteristics
Model mapping is an essential constituent in our process. To move from one phase
of requirements development to another, we explicitly need to define the rules of transformation that facilitate the translation of requirements elicitation models to requirements
specification models and then further on to requirements analysis models.
Our transformation approach is discussed in this section based on the criteria defined
by Mens and Van Gorp [150].
The source and target artifacts are UML-based behaviour models defined at a level
of abstraction appropriate for requirements models. We begin with exceptional use cases,
which are extensions of traditional use cases, and then transition to our dependability
assessment charts or to our exception-aware activity diagrams. The DA-Charts are used
for assessing and refining the use cases. Once the use cases are finalized, they are mapped on
to activity diagrams. The activity diagrams can then be used as an input for a subsequent
design phase, and the exceptions can be mapped to design artifacts as outlined in [115].
Number of source and target models
We perform a many-to-one model transformation.
The textual use case and the use case diagram are mapped to activity diagrams or to
DA-Charts.
Technical space
Our approach falls in the MDA technical space, which uses the MOF as
meta-model, and supports UML.
Endogenous versus exogenous transformation
We translate a model from one formalism,
namely use cases, to another modelling formalism, activity diagrams or DA-Charts. Since
the models are expressed in different formalisms, we define a translation which is exogenous.
Horizontal versus vertical transformations Since our source and target models are defined at two different levels of abstraction, our transformation is vertical in nature. Our
target models are constructed gradually using successive refinement steps.
Syntactic versus semantic transformations
Our approach considers both the syntax and
the semantics of the source model during the mapping process.
142
8.2. Model Transformation: From Exceptional Use Cases to Activity Diagrams
Level of automation
Currently our transformation is performed manually. However, the
very precise and clear mapping rules allow it to be carried out automatically using tool
support.
Preservation
Our mapping transforms use cases to activity diagrams, i.e. a model that
can be used as a more formal requirements specification artifact. Therefore, it is very
important to ensure that the meaning of the requirements as defined initially with use
cases, and the completeness of the requirements are preserved during the transformation
process. Generally this is ensured by construction, which is simplified by the rule-based
representation.
8.2
Model Transformation: From Exceptional Use Cases to Activity Diagrams
In this section we focus on mapping our semi-formal requirements elicitation and
definition model, use cases, to a more formal specification, activity diagrams.
8.2.1
The Source Model: Exceptional Use Cases
The source of the transformation are use case models. We introduced the exceptional
use cases formalism in Chapter 5 which extends traditional use cases with exception handling concepts. We have defined context-affecting exceptions, service-related exceptions,
and handlers in Chapter 5. Figure 5–1 illustrates how we integrate exceptions in textual use
cases. As shown in Sections 5.5 and 6.3, our use cases adhere to a pre-defined template and
structure. Every numbered step either describes a basic interaction between the environment (one or several actors) and the System, or references an included subfunction-level use
case. Basic interactions are classified as either input interactions, or output interactions.
The extensions to the notation are summarized in Table 5–1. We have also integrated
our extensions with the UML 2.0 use case diagram metamodel as shown in Fig. 5–8, and
have defined meta-models for textual use cases and exceptional use cases (Fig. 5–6 and 5–7).
The transformation rules are defined based on the elements defined in the meta-model.
143
8.2. Model Transformation: From Exceptional Use Cases to Activity Diagrams
8.2.2
The Target Model: DREP Activity Diagrams
The target models in this transformation are activity diagrams, which are presented
in Chapter 5 Section 5.2. The activity diagram notation is summarized in Fig. 5–2. Our
activity diagrams use elements which exist in the UML 2 meta-model. We have integrated
concepts of exceptions, handlers, and degraded outcomes in activity models using the
existing notation.
8.2.3
Transformation Definition
As defined in Kleppe et al. [118]: A transformation definition is a set of transformation
rules that together describe how a model in the source language can be transformed into a
model in the target language. A transformation rule is a description of how one or more
constructs in the source language can be transformed into one or more constructs in the
target language.
Prior to attempting the transformation of any use case to activity diagrams following
our rules, the use case has to be pre-processed to ensure that it adheres to the wellformedness rules described in Section 8.2.1.
The process of mapping use cases to activity diagrams involves a few basic tasks.
We have defined transformation rules (following the transformation definition in [118]) for
carrying out the translation. The rules are specified in structured English, and the natural
language allows the rules to be understood and applied by developers without the need to
know any specialized language. This is especially helpful since the transformation is at the
requirements analysis level, and is currently performed manually. Figure 8–1 illustrates
the mapping process.
Our transformation proceeds in a top-down manner starting at each user-goal level
use case. The transformation definition includes the following rules.
Rule 1 Mapping the main success scenario;
Rule 2 Mapping use case exceptions to activity exceptions;
Rule 3 Mapping use case handlers to handler activities;
Rule 4 Mapping use case outcomes to activity outcomes;
Rule 5 Mapping the extensions;
Rule 6 Constructing the base activities;
Rule 7 Constructing the subactivities;
Rule 8 Mapping context-affecting exceptions.
144
8.2. Model Transformation: From Exceptional Use Cases to Activity Diagrams
Activity EA
Use Case: EA
Primary Actor: ...
Intention: ...
...
...
Main Success Scenario:
...
Activity EA
Use Case: EA
...
...
Main Success Scenario:
1. System requests ...
2. Actor notifies ...
...
Call Action
Node
Activity EA
Use Case: EA
...
...
Main Success Scenario:
...
Extensions:
2a. Exception{...}
...
System
Exception:
{SFailure}
Activity EA
SummaryUseCase
Exception:
{CAFailure}
<<i&
f>>
c>>
<<i&
Actor Pr
<<handler>>
Call Action
Node
<<include>>
<<reliability handler>>
Call Action
Node
<<safety handler>>
HandlerName
HandlerName
UseCase
<<include>>
<<include>>
Actor A
UseCase
<<
i&
c>
Exception:
{BFailure}
i&c>
>
<<
i&c>
>
UseCase
Exception:
{AFailure}
<<
Actor B
Exception:
{CFailure}
Actor C
>
Use Case: EA
...
Main Success Scenario:
...
Extensions:
2a. Exception{...}
2a.1...
2a.1a...
Call Action
Node
<<reliability handler>>
<<reliability handler>>
<<reliability handler>>
HandlerName
HandlerName
HandlerName
Use Case: EA
...
Main Success Scenario:
1.
2.
...
Use Case ends in <<success> ...
Activity EA
Call Action
Node
Extensions:
2a. Exception{...}
2a.1...
2a.1a...
Use case ends in <<failure>>...
...
...
<<handler>>
Call Action
Node
<<success>> <<degraded>> <<failure>>
SubActivity
Use Case: EA
...
...
Main Success Scenario:
1. System requests ...
2. Actor notifies ...
...
Activity EA
Call Action
Node
Figure 8–1: Mapping a use case model to an activity model
145
8.2. Model Transformation: From Exceptional Use Cases to Activity Diagrams
The master rule to transform each use case is as follows:
mapUseCaseToActivity()
N = createInitialNode()
mapMainSuccessScenario(N)
mapOutcome(success, main)
mapExtensions(N)
Rule 1: Mapping the main success scenario To begin with, use case steps specifying
related interactions are grouped into send-receive pairs, receive events, invocations of subfunction level use cases, change of control flows, or others (steps that do not describe an
interaction). The groups are mapped to call action nodes and control flows.
groupRelatedInteractions()
//each group is labelled with a type SR, S, R, SUB
SR = identify send-receive blocks
S = identify independent system requests //send signal
R = identify independent receive events //accept events
SUB = identify sub use cases
U = remaining steps not identified as interactions
return group
mapMainSuccessScenario(N)
group = groupRelatedInteractions()
for each group excluding U {
if group type = SR, S, or SUB
create a call action node in N
if group type = R
create a dummy call action node in N
label node with "wait for event"
if group type <> SUB
createPin(outputPin, success, outcomeName)
create control flow edge
for each step in group U
//U includes steps such as
//"use case continues at step n"
if step changes flow of scenario
create control flow edge
connect edge to the activity node
//node associated with the interaction
//specified in the step
146
8.2. Model Transformation: From Exceptional Use Cases to Activity Diagrams
createPin(type, outcome, name)
if type != exceptionPin
create an output pin
else
create an exception pin
label pin with name
tag pin with outcome type
//the pin is tagged with one of the stereotypes:
//<<success>>, <<degraded>>, <<failure>>, <<abandoned>>
Rule 2: Use case exceptions to activity exceptions Exceptions are associated to the
activity corresponding to the block that contains the step that triggers the situation, by
attaching exception pins to the node.
mapExceptions(initNode)
A = locate corresponding activity in initNode
createPin (exceptionPin, failure, label) in A
Rule 3: Use case handlers to handler activities
A handler (or handling interactions in
the extensions) is mapped to a call action node with stereotype handler .
mapHandling ()
if no handling means specified
H = locate handler in the use case diagram
create call action node for handler
label with handler name
tag with stereotype <<handler>>
create control flow edge to connect handler to associated exception pin
Rule 4: Use case outcomes to activity outcomes
The outcome of the main scenario
is mapped to an output pin labelled with the stereotype success and the outcome
identifier. Alternate scenarios can end in four possible outcomes: success, abandoned,
degraded, failure.
mapOutcome(outcome, scenario)
if scenario = main and outcome = success
if pin exists
merge to existing pin using a decision node
else createPin (outputPin, success, label)
if scenario = extension
if outcome = success
connect to success flow
147
8.2. Model Transformation: From Exceptional Use Cases to Activity Diagrams
if outcome = abandoned
if pin exists
merge to existing pin using a decision node
else
createPin(outputPin, abandoned, label)
create control flow edge to pin
if outcome = degraded
create merge node //at the end of success flow
createPin(outputPin, degraded, label)
create control flow edge
connect edge from merge node to pin
if outcome = failure
if pin exists
merge to existing pin using a decision node
else
createPin(exceptionPin, failure, label)
create control flow edge to pin
Rule 5: Mapping the extensions
The extension section of a use cases may contain
interactions, exceptions, and handlers which map to call action nodes and pins.
mapExtensions(initNode)
for each step in the extensions
//also for all sub steps
if an exception is defined
mapExceptions(initNode)
mapHandling()
mapOutcome(outcome, extension)
if step specifies a control flow decision
create control flow edge
connect to specified step
Rule 6: Constructing the base activities
The base activity is of one of the four types
initially identified. A new activity diagram is created, with an activity labelled using the
same name that was used in the call action node in rule 1. The output pins (rule 1) and
exceptional output pins (rule 4), if any, are added.
createBaseAcivity(type)
//leaf-level activities
N = createInitialNode()
create initial node in N
148
8.2. Model Transformation: From Exceptional Use Cases to Activity Diagrams
if type = SR //send-receive pair
SE = create send signal event node in N
AE = create accept event node in N
TE = create accept time event node in N
create a fork node
connect initial node to SE
connect SE to AE and TE via the fork node
tag TE with the deadline
attach all output pins and exceptions pins
//inherit from calling activity
create zigzag control flow edge
from TE to the exception pin
if type = R //receive event
AE = create accept event node in N
TE = create accept time event node in N
create a fork node
connect initial node to the fork
connect fork node to AE and TE
tag TE with the deadline
attach all output pins and exceptions pins
//inherit from calling activity
create zigzag control flow edge
from TE to the exception pin
if type = S //system request event
SE = create send signal event node in N
//inherit from calling activity
attach all output pins and exceptions pins
connect SE to output pin
if exception pin exist
connect SE to pin
create zigzag control flow edge
from TE to the exception pin
Rule 7: Constructing the subactivities
Subactivities that represent sub-use cases are
constructed in the same manner as an activity.
constructSubactivity()
if activity type <> leaf-level
mapUseCaseToActivity() //master rule
else
createBaseActivity()
149
8.3. Model Transformation: From Exceptional Use Cases to DA-Charts
Rule 8: Mapping context-affecting exceptions A final task is to integrate contextaffecting exceptions in activity diagrams. These exceptions do not show up in the textual
use cases, but can be found in the use case diagram.
mapContextAffectingExceptions()
CA = locate exceptions in the use case diagram
for each CA
A = identify activity associated to the CA
R = create interruptible activity region in A
E = create the exceptional accept event node in R
H = locate handler in use case diagram
create stereotyped call action node in A outside R
connect E to the handler node with an interrupting edge
8.3
Model Transformation: From Exceptional Use Cases to DACharts
In this section we focus on mapping use case models to our assessment modelling
formalism, DA-Charts. As discussed in Chapter 7, the DA-Charts are used to evaluate the
probability of success of user goals and considers service-related exceptions only. Hence
mapping of context-affecting exceptions are not covered in this transformation definition.
8.3.1
The Source Model: Exceptional Use Cases
In this mapping, we also start with the exceptional use cases. The source model
formalism has been discussed earlier in Section 8.2.1.
8.3.2
The Target Model: DA-Charts
The syntax and semantics of DA-Charts are explained in Chapter 7 Section 7.3. The
constraints of our charts are also defined in the section. Use cases are mapped to DA-Chart
elements which include components, states, transitions, events, and probabilistic events.
8.3.3
Transformation Definition
Our transformation proceeds in a top-down manner starting at each user-goal level
use case. The transformation definition includes the following rules.
Rule 1 Mapping the main success scenario;
150
8.3. Model Transformation: From Exceptional Use Cases to DA-Charts
Rule 2 Mapping the extensions;
Rule 3 Mapping use case exceptions to DA-Chart exceptions;
Rule 4 Mapping use case outcomes to DA-Chart outcomes;
Each use case is mapped to one DA-Chart. As mentioned earlier, the DA-Chart has
a single orthogonal system component that models the behaviour of the system, one outcome component that records the goal outcome, one safety-status component that records
unsafe states, and one probabilistic orthogonal component for each secondary actor. The
exceptions that are mapped to DA-Chart are service-related exceptions.
The master rule to map each user goal use case to a DA-Chart is specified below in
pseudo-code.
mapUseCasetoDAChart()
create an orthogonal component named System
createSafetyStatusComponent()
createOutcomeComponent()
mapMainSuccessScenario()
create safetyStatusComponent()
create an orthogonal component named Safety-Status
add an initial state
add a safe state for each safety level
add an unsafe state
create transitions to states with events toSafe and toUnsafe
createOutcomeComponent()
create an orthogonal component named Outcome
add success, degraded, failure, abandoned states
add transitions TS, TD, TF, TA
add event toSuccess to TS
add event toFailure to TF
add event toDegraded to TD
add event toAbandoned to TA
Rule 1: Mapping the main success scenario Each step in the use case is mapped to
a transition in the system component, as well as a transition in the actor involved in the
step. An appropriately named event is created, e.g. floorDetected or stopMotor.
Revisiting the use case meta-model in Chapter 5 Fig. 5–7, it defines a step to be of
one of five types: send request interaction, receive event interaction, invocation, condition,
or control flow. To start off the mapping process, the type of a step is identified. A step
that describes an input sent by an actor A to the system is mapped to:
151
8.3. Model Transformation: From Exceptional Use Cases to DA-Charts
• an action, e.g. floorDetected, on the success transition in the component modelling
the reliability of A. The probability annotation p from the step is added to the success
transition, the probability 1-p is added to the failure transition.
• an event in the system that moves the system to the next state.
A step that describes an output sent by the system to an actor A is mapped to:
• an action in the system, e.g. stopMotor,
• an event within the component modelling the behaviour of A, that leads to a success
state and a failure state. A probability annotation p from the step is added to the
success transition, the probability 1-p is added to the failure transition.
A final state, goalTermination, is created and all transitions end in this state.
identifyStepType()
S = identify send request
R = identify receive request
SUB = identify sub-use case invokation
U = remaining steps specifying control flow or condition
return stepType
mapMainSuccessScenario(N)
create composite state in System
for each step ms
stepType = identifyStepType()
identify associated secondary actor A
if component A does not exist
create component to represent A
if stepType = S
create a target state, N, inside System
create a transition, T, to N
add action to T
create a target success state, SA, in A
create a transition to state SA
add event, E, to transition
add probability, p, to transition
if stepType = R
add an event in A
create transition, T, to success state
tag event on T with probability of success
add action on transition leading to success state
create a target state, N, inside System
152
8.3. Model Transformation: From Exceptional Use Cases to DA-Charts
create transition to N
add event on transition leading to N
if stepType = U
if step is a control flow step
add transition to destination node
if step specifies outcome
if outcome is the final user goal outcome
add final state, goalTermination, in System
create transition, TS, with action toSuccess to connect to goalTermination
else
add termination state in the composite state in System
mapExtensions(ms, N, SA)
Rule 2: Mapping the extensions
Each extension block associated with a main step has
to be mapped to the DA-Chart. If the extension block contains alternate behaviour or
interactions, it is mapped to transitions and events in the chart in the same way as when
mapping the success scenario. If the block contains an exception, it is mapped according
to Rule 3.
mapExtensions(mainStep, N, SA)
for each extension block associated with the step mainStep
if an exception is defined for mainStep
failureTransition = mapException(N, SA)
if alternate behaviour is defined
mapUseCaseStep()
out = identify outcome defined for extension block
mapOutcome(out, failureTransition)
Rule 3: Mapping use case exceptions to DA-Charts exceptions Each exception associated with the step is mapped to a failure action, e.g. motorFailure, and attached to the
failure transition of the corresponding actor. If a step is tagged as Safety-critical, the failure
transition broadcasts an event toUnsafe which is recorded in the safety-status component.
mapException()
create a target failure state, F, in A
create a transition, TF to state F from state SA
attach event, E, to transition TF
add failure probability, 1-p, to transition TF
add action, FA, to be broadcast, to TF
add transition, TT, with event FA to termination state inside System
add action toFailure to transition TT inside System
153
8.4. Case Study: Elevator Control System
if step is tagged as safety-critical
add action toUnsafe to transition TF
return TT
Rule 4: Mapping use case outcomes to DA-Chart outcomes
A step defining the
outcome of the main success scenario is mapped to an action in the system (toSuccess) which triggers the state change to the success state in the outcome component.
A step defining an outcome in the extensions section is mapped to an action (toSuccess/toDegraded /toAbandonned /toFailure) which triggers the change to the appropriate
state in the outcome component.
mapOutcome(goalOutcome, T)
connect transition T to goalTerminated state
if outcome = success
add toSuccess action to T
if outcome = degraded
add toDegraded action to T
if outcome = failure
add toFailure action to T
if outcome = abandoned
add toAbandoned action to T
At the requirements and analysis levels, transformations might require some degree of
manual intervention to take into account concerns such as incompleteness, inconsistency,
and ambiguity [150]. The above rules can be used to create an initial DA-Chart model.
However, once the assessment is carried out, further refinements of the use cases may be
necessary and handlers might need to be defined. The DA-Chart model of the user goal
would then have to be revised with new states, events, and components to model the
handling of exceptions. Due to the feedback loop in our process, it is important to keep
track of the changes (or decisions) made to a DA-Chart in a particular refinement which
allows the next refinement to be based on the same parameters.
8.4
Case Study: Elevator Control System
We use the elevator control system (ECS) case study as an example to illustrate our
model transformation approach.
154
8.5. Summary
8.4.1
ECS: Use Case Models
Fig. 5–13 shows a partial use case diagram of ECS that depicts the services offered.
The diagram in Fig. 5–13 uses the exceptional use case formalism to depict the reliability
and safety handlers that take control in exceptional situations to guarantee dependable
operation of the elevator.
The main service provided by the elevator control system is Take Elevator. It is split
into Call Elevator and Ride Elevator, which both include Elevator Arrival. The steps of a
use case are described in textual form in a use case template. Fig. 5–12 shows the details
of Elevator Arrival, the subfunction-level use case that describes how the system interacts
with the external devices, i.e., sensors, motor and door, to direct the elevator cabin to the
desired floor.
8.4.2
ECS: Activity Diagrams
The exceptional use cases of ECS are mapped to DREP activity models by applying
the transformation rules defined in Section 8.2.3. The Stop Motor activity depicted in
Fig. 5–14 illustrates the construction of the leaf activities of our mapping. Fig. A–5 shows
the mapped parent activity ElevatorArrival.
8.4.3
ECS: DA-Chart Models
The ECS exceptional use cases are mapped to DA-Charts using the mapping process
outlined in Section 8.3. The initial ElevatorArrival DA-Chart is shown in Fig. 7–4, and a
subsequent RideElevator DA-Chart is shown in 7–11.
8.5
Summary
In this chapter we presented transformation definitions to map our requirements elic-
itation model to our specification and assessment models.
We started with a step-by-step algorithm that transforms dependability-oriented use
cases into activity diagrams. The proposed mapping facilitates the construction of more formal requirements specification models, which can be used as the basis for further analysis.
The source use case models are presented in the form of textual use case descriptions that
adhere to a pre-defined template and structure. Handler use cases describe how situations
155
8.5. Summary
that threaten the system safety or reliability are dealt with. The use cases and handlers are
mapped to activities in the target activity diagram model by respecting the use case hierarchy in the source model, if any. Individual use case steps describing corresponding system
input and output are grouped and mapped to leaf activities. The detection of exceptional
situations is done using signals or timeouts, and the switch from normal to exceptional
activities is achieved using exceptional output pins and exceptional control flows. Since
the proposed algorithm describes a complete mapping from use cases to activity diagrams,
we believe that the transformation is automatable.
The second transformation defined supports the mapping of use cases to dependability
assessment charts. The rules support mapping of user-goal level use cases to DA-Charts
comprising of several components for modelling behaviour of the system, the safety status,
the goal outcome, and the secondary actors involved. Exceptions in use cases are mapped
to events in the DA-Chart which lead to a transition to the failure outcome state (in case
no handling is defined). As with the mapping to activity diagrams, this transformation
can also be automated.
In a similar manner, it is also possible to define transformation rules for constructing
communication diagrams from use cases and activity diagrams.
156
CHAPTER 9
Case Studies
We used three case studies in the dependable reactive systems domain to demonstrate
our work: the Elevator Control System (ECS), the 407 Express Toll Route (ETR) System,
and the Crisis Management System (CMS). The case studies are non-trivial in nature and
of considerable size.
The ECS is a de-facto case study used in the software engineering and real-time system
fields. We have however based our problem statement on the version of the case study
described and used by the researchers at the EPFL School of Computer and Communication
Sciences as a case in the reactive system domain [188]. We used the ECS to help us
develop our approach, the process, the extensions to the modelling formalisms, and the
transformations. The ECS being a typical reactive system with most interactions mainly
between the system and the external actors formed an excellent base to build our approach.
The system requirements specification that we have developed includes 4 use cases and 9
actors. DREP lead to the discovery of 13 exceptions, and we defined an additional 8 use
cases as handlers for the exceptions.
The 407 ETR is an operational system in Ontario, Canada. Our source for the problem
statement is the 407 ETR official home page [67]. Other details were obtained from [179].
We spent a few weeks applying our requirements elicitation process on the ETR system, and
then worked for approximately 3 weeks (accumulated) to create the specification (activity
diagram and communication diagram models). We created 11 use cases for the ETR
using the DREP requirements elicitation methodology. We discovered 14 actors (which
includes 2 exceptional actors) that interact with the system. Application of DREP to
the TakeHighway user goal uncovered 11 exceptions for which we defined 10 handlers.
In addition, considerable effort was required to design the case study and experiments
157
9.1. Elevator Control System
to evaluate our process in an academic setting. The experiments, discussed in details in
Chapter 10, were carried out in 2 terms over 2 years.
The CMS project was initiated by the University of Luxembourg. The project is
about the development of a software product line of crisis management system for the city
of Luxembourg. The case study focuses on one software product in particular: the car crash
crisis management system. Our initial source for the problem definition was an existing
requirements specification document [187] that described the main functionalities of the
system but did not consider dependability concerns or other non-functional requirements.
Professors and researchers at Luxembourg with domain knowledge on crisis management
and on the automobile industry were interviewed for further clarifications and refinements
of the problem statement. We spent 3 full weeks on the requirement elicitation of the CMS.
We identified 12 actors, developed 22 use cases, discovered 14 exceptions, and defined 15
handlers to address the exceptions.
Table 9–1 summarizes each study in terms of the number of use cases developed,
number of actors identified, and the exceptions identified.
Table 9–1: Summary of Case Studies
use cases
actors
exceptions
handlers
ECS
4
9∗
13
8
407 ETR
11
14∗
11+
10+
CMS
22
12
14
15
* includes exceptional actors
+
only in TakeHighway
This chapter begins with a review of the ECS case study in Section 9.1 which was used
to illustrate our work in the previous chapters. To further illustrate our approach, DREP
is applied to the 407 ETR case study in Section 9.2. The CMS case study requirements
elicitation is described in Chapter 9.3.
9.1
Elevator Control System
In this section, we discuss how we used the Elevator Control System case study to
develop and demonstrate our work.
158
9.2. 407 ETR System
9.1.1
Problem Statement
The target system is an embedded system which controls the movement of a single
cabin elevator and opens the cabin’s door based on the requests of users and events from
the other components. The ECS problem statement is detailed in Section 5.5 of Chapter 5.
9.1.2
Requirements Development
We demonstrated our process by applying it to the Elevator Control System (ECS)
case study in Chapter 6. We walk through the process and discuss the requirements
development of the ECS in a step-by-step manner in Section 6.3. We started with the
requirements elicitation and discovery phase, and defined the user goal TakeElevator which
includes two subgoals CallElevator and RideElevator. Task 2 defined two context-affecting
exceptions, EmergencyStop and EmergencyOverride, and exceptional actors required to
signal the exceptions. In Task 3, recovery measures were explored that handle the contextaffecting exceptions. The following task focused on eliciting dependability expectations and
exceptional modes of operation, leading to the definition of the emergency mode FireSafety.
The second phase of DREP concentrated on designing the interactions, and discovering
possible service-related exceptions that can arise during the interactions. The use cases for
the user goals and the handlers were designed, and several exceptions were discovered.
In the third phase, we assessed the safety and reliability satisfied by the requirements.
The dependability assessment of the ECS is discussed in details in Chapter 7.
In the fourth phase, based on the assessment results, the requirements were refined
to improve the safety and reliability levels. Mechanisms to detect the exceptions, and
measures to handle the exceptions were introduced.
In the final phase, the design of the dependability requirements was summarized with
a use case diagram, exception table, mode table, activity diagrams, and communication
diagram. The models are presented in Chapter 6 and Appendix A.1.
9.2
407 ETR System
In this section, we illustrate DREP with the 407 Express Toll Route (ETR) System.
159
9.2. 407 ETR System
9.2.1
Problem Statement
The 407 ETR is a highway that runs east-west just North of Toronto, and was one of the
largest road construction projects in the history of Canada. The road uses a highly modern
Electronic Toll Collection system that allows motorists to pass through toll routes without
stopping or even opening a window. The ETR system is a hard real-time application
requiring high levels of dependability.
Each highway entry and exit point is equipped with a gantry (see Fig. 9–1). A gantry
includes several hardware components: a vehicle detector, a locator antenna, a read/write
antenna, cameras, lights, and a laser scanner. Every vehicle using the route passes under
a gantry at entry and at exit.
The most cost-efficient way to pay for highway use is to open an account with the
407 ETR system. Billing information (name and address) is saved with the account. Once
an account is created, vehicles can be registered with it. Vehicles can be registered with
the 407 ETR system, in which case the driver is issued a small electronic tag, called a
transponder, to be attached to the windshield. When the vehicle enters the highway, it
passes under the overhead gantry. The hardware devices of a gantry include a vehicle
detector, a locator antenna, a read/write antenna, cameras, lights, and a laser scanner.
The locator antenna determines if the vehicle is equipped with a transponder. Next, the
read/write antenna reads the account number from the transponder and the point of entry,
time and date is recorded. In addition, as a vehicle passes under the gantries, the system
uses laser scanners to determine the class of vehicle (e.g. light vehicle, heavy single unit
vehicle, heavy multiple unit vehicle). It does this by measuring the height, width and depth
of each approaching vehicle. A check is made to verify that the class of vehicle corresponds
to the one registered for this particular transponder. The same process occurs when the
vehicle exits the highway. The entry and exit data are then matched and the transponder
account holder is debited. When the route is exited, the transponder gives a green signal
followed by four short beeps to indicate a successful completion of the transaction.
Unregistered vehicles are identified by their license plate number. When a motorist
without a transponder enters the highway and passes under the two tolling gantries, the
system triggers a set of digital cameras to take pictures of the rear number plate of the
vehicle from different angles. In order to get good images, a set of lights are turned on
before the images are taken. At the same time, the laser scanners are activated to classify
the vehicle in order to determine the trip charge and tell the toll collection system whether
160
9.2. 407 ETR System
Figure 9–1: 407 ETR Gantry and Transponder (Reproduced from [67][179])
to charge for a passenger or commercial vehicle. The owner of the vehicle is identified by
electronic access to government records. The cameras and lights have been tested to ensure
accuracy, even in blizzards and rainstorms. However, if the video correlation and image
processing fails to determine the license plate with sufficient probability, a human operator
has to look at the pictures to make the call.
9.2.2
Requirements Elicitation and Discovery
Task 1: Discovering actors, goals, and modes In the ETR system there is initially only
one primary actor, the Driver. The summary-level use case UseHighway is shown in Fig.
9–2. When interacting with the system, the driver has the goal of registering (RegisterVehicle), taking the highway (TakeHighway), payment of bills (PayBill ), and cancelling
the registration (CancelRegistration). These goals can be further split into subgoals as
summarized in Fig. 9–2.
The 407 ETR system only has one normal mode of operation since there is only one
primary goal, using the highway, that needs to be satisfied at all times.
Task 2: Discovering Context-Affecting Exceptions
In the ETR system, an accident
on the highway or extreme weather leading to critical road conditions, would require the
highway operator, an exceptional actor, to temporarily close parts of the highway. In this
case, an emergency barrier needs to be activated to ensure that motorists are not given
access to the highway, and also the display boards along the highway should be updated
with a highway closed message. Activating the emergency behavior is an exceptional goal
for the operator, since this happens only in rare occasions. In this task, we identified a
161
9.2. 407 ETR System
407 Express Toll Route (ETR) System
Postal
Service
1
>>
de
in
clu
Register
Vehicle
<<
Government
Computer
*
>>
lude
c
<<in
TakeHighway
R/WAntenna
*
Operator
Terminal
*
Locator
Antenna
*
Camera
UseHighway
<<
inc
lud
Cancel
Registration
PayBy
CreditCard
PassThrough
Gantry
<<
inc
d
lu
nc
Bank
*
PayBy
Check
<<include>>
i
<<
Driver
1
>
PayBill
>
e>
*
e>
<<include>>
1
<<include>>
Process
Registered
Vehicle
CreditCard
Company
*
VehicleDetector
lud
e>
>
*
Classify
Vehicle
Process
Unregistered
Vehicle
LaserScanner
*
Lights
Figure 9–2: 407 ETR: Standard Use Case Diagram
context-affecting exception: HighwayUnavailable which is signaled by the HighwayOperator
exceptional actor when he receives the request from the Roadside Motorist Assistant Patrol.
Task 3: Eliciting Handlers for Context-Affecting Exceptions
After a discussion with the
stakeholders it has been decided that closing the highway in case of emergencies is done
by activating barriers that prevent new vehicles from entering the highway at the closed
sections. The vehicles on the highway are to be informed of the situation by displaying
messages on message boards. We therefore identified new secondary actors, the Barrier,
and the Message Board.
Task 4. Eliciting Dependability Expectations and Exceptional Modes
We define 3
safety levels for the 407 ETR: level 0 - without effects, level 1 - cars end up in a traffic
jam / increased load on operators, level 2 - cars are damaged / system components are
damaged. The reliability of TakeHighway and PayBill should be high, e.g. 0.999 (one
of 10000 cars can fail to pay for a trip). Other services, e.g. registering and cancelling,
require a reliability of 0.995. During an emergency, the chances of a level 2 safety violation
should be very small, e.g. 0.00001, and a level 1 safety violation should be rare, 0.001. The
required reliability of the emergency behavior should be very high, e.g. 0.99999.
162
9.2. 407 ETR System
As mentioned earlier, the system only offers one normal mode which includes all
services associated to taking the highway, i.e. TakeHighway, RegisterVehicle, PayBill, and
CancelRegistration.
In task 3, the context-affecting exception HighwayUnavailable was identified since critical road conditions might require the system to restrict vehicles from entering the highway.
Emergency services such as activating the road barriers are carried out. However, the exit
service needs to be active to allow the vehicles already on the highway to continue. Therefore, when such an exceptional situation arises the system needs to switch to a restricted
mode ExitOnly.
9.2.3
Requirements Definition and Specification
To demonstrate how the process is applied to create the requirements specification,
we discuss the user-goal level TakeHighway, and the subgoals PassThroughGantry and
ProcessRegisteredVehicles in this chapter. The remaining use cases are presented in Appendix A.2.
Task 5: Designing Interactions The interaction steps required for TakeHighway are
detailed in Fig. 9–3. To take the highway, the Driver enters the highway, and then exits it by
passing through gantries. If the vehicle has a transponder, then the device beeps and blinks
green after the driver exits the highway. The ProcessRegisteredVehicle use case, shown in
Fig. 9–4, describes how the system communicates with the transponder, and verifies the
class of the vehicle. The sub-functional level uses cases that describe the processing of
unregistered vehicles and the classification of vehicles are shown in Appendix A.2.
The extension section of TakeHighway on purpose describes only alternative ways to
achieve the goal, since exceptional interaction will be shown later.
Fig. 9–5 shows the handler ActivateBarrier that handles the exception HighwayUnavailable. Handler use cases have an additional field in the use case template named
Contexts & Exceptions that is used to document by which exception and in what context
the handler is triggered. In our case, a HighwayUnavailable exception occurring puts the
system in a restricted mode, at which time the system only allows exits but does not allow
new goals to start. As a first handling step, the emergency road barriers are activated.
Then the message boards are updated with a warning message. Subsequently when the
road conditions improve, the Operator can deactivate the barriers and grant access to the
163
9.2. 407 ETR System
Use Case: TakeHighway
Scope: 407 ETR System
Level: User Goal
Intention in Context: The intention of the Driver is to drive a vehicle from one location to another by
taking the 407 ETR highway.
Multiplicity: One Driver can only drive one vehicle at a time on the highway. However, different Drivers
can take the highway simultaneously.
Primary Actor: Driver
Secondary Actor: RWAntenna, GovernmentComputer, OperatorTerminal
Main Success Scenario:
1. Driver enters highway, passing through gantry.
2. Driver exits highway, passing through gantry.
3. System retrieves the driver’s vehicle record based on trip information*.
4. System determines the amount owed based on the trip information and adds the transaction to the
vehicle’s records.
5. System informs Driver by sending a signal to the RWAntenna of successful completion of transaction.
Use case ends in success CrossedHighway.
Extensions:
3a. Vehicle is unregistered and does not have a record yet.
3a.1. System sends licence plate information to GovernmentComputer.
3a.2. GovernmentComputer sends vehicle information and owner’s address to System.
3a.3. System creates a new vehicle record. Use case continues at step 4.
3b. Vehicle is unregistered and licence plate is unrecognizable.
3b.1. System displays pictures on OperatorTerminal.
3b.2. OperatorTerminal sends licence plate information to System. Use case continues at step 3.
5a. Vehicle is not registered. Use case ends in success UnregisteredVehicleProcessed.
*Trip Information Details: A complete trip information record includes entry and exit time and place,
measured and obtained vehicle classification, transponder account or licence plate information or licence
plate images.
Figure 9–3: 407 ETR: TakeHighway Use Case
highway once again. Since the handler attempts to satisfy user safety, we label the handler
as a safety handler. This is shown in the Handler Class field in the template.
Task 6: Defining Service-Related Exceptions and Effects on System Reliability and
Safety
We begin in a bottom-up way by examining each step in the ProcessRegisteredVe-
hicle use case to determine how essential it’s contribution is in order to achieve the goal.
For example, step 1 involves the locator antenna notifying the system that a vehicle with
a transponder is passing by. This is an input interaction, and its omission leads to an
exceptional situation. An antenna defect would cause vehicles to be incorrectly identified
as unregistered vehicles. Therefore, the step is annotated with a reliability tag together
with the failure probability. Next, if the read/write antenna malfunctions, the registration
information associated with the transponder would be inaccessible. Malfunctioning lights
164
9.2. 407 ETR System
Use Case: ProcessRegisteredVehicle
Scope: 407 ETR System
Level: Sub-Function
Intention in Context: The System communicates with the transponder to identify the approaching vehicle.
Multiplicity: The System must be able to process multiple registered vehicles simultaneously.
Primary Actor: N/A
Secondary Actor: LocatorAntenna, R/WAntenna
Main Success Scenario:
1. LocatorAntenna notifies System that it detected an approaching vehicle with transponder.
2. System asks R/WAntenna to obtain account information from transponder.
3. RWAntenna informs System of account information.
4. System records account information for the trip.
5. System turns on the Lights.
6. System triggers the Cameras.
7. Cameras send images to System.
8. System determines licence plate information based on images.
Use case ends in success RegisteredVehicleProcessed.
Extensions:
1a. The approaching vehicle does not have a transponder. Use case ends in f ailure TransponderUnavailable.
Figure 9–4: 407 ETR: ProcessRegisteredVehicle Use Case
or cameras also hinder the success of the goal, so they are tagged as well. The exceptions that arise are defined as LocatorAntennaFailure, RWAntennaFailure, LightFailure,
and CameraFailure.
In TakeHighway, the government computer might fail to send the requested information back to the system. The operator might fail to respond when a picture is sent to him.
The transponder might not react to the acknowledgement signal sent by the read/write antenna. The service-related exceptions identified in this task that occur in the TakeHighway
context are named as GovernmentComputerUnavailable, OperatorFailure, and TransponderUnreachable. Reliability tags are attached to each of these steps. None of the steps is
safety-critical.
We also need to consider the possibility of the handlers failing and the consequences
of such failures. While handling the HighwayUnavailable exception, the barrier might fail
to get activated resulting in a highly unsafe condition. Step 3 in Fig. 9–5 is therefore
annotated with a safety tag and corresponding probability, and the extensions section is
appended with a BarrierFailure exception.
165
9.2. 407 ETR System
Handler Use Case: ActivateBarrier
Handler Class: Safety
Context & Exception: TakeHighway{HighwayUnavailable}
Level: Usergoal
Intention in Context: The operator wants to temporarily stop access to the highway.
Multiplicity: The System must be able to process multiple registered vehicles simultaneously.
Primary Actor: Operator
Secondary Actor: Barrier
Main Success Scenario:
System switches into restricted mode ExitOnly.
1. System activates barriers at entry gantries.
2. System displays ”Highway Unavailable” at message boards on highway.
3. Operator informs System that highway is accessible again.
4. System deactivates barriers.
5. System clears message boards.
System switches back to normal mode.
Use case ends in success HighwayAvailable.
Figure 9–5: 407 ETR: ActivateBarrier Handler Use Case
9.2.4
Requirements Analysis
Task 7: Assessing Safety and Reliability The probabilistic analysis of the system is not
elaborated here for space reasons. It reveals that system safety and reliability cannot be met
with the current interaction: BarrierFailure has to be handled in order to improve safety,
GovernmentComputerUnavailable, OperatorFailure and TransponderUnreachable have to
be addressed in order to improve reliability.
9.2.5
Dependability-based Refinement and Iteration
We use the TakeHighway use case and the exceptions occurring in it to illustrate the
tasks in this section.
Task 8: Specifying Detection Mechanisms We first address the reliability issues in the
TakeHighway use case. To begin with, detecting unavailability of the government records
(exception GovernmentComputerUnavailable) can be done by using a timeout (the lack of
reception of a message), as discussed in Section 6.1.4. The OperatorFailure exception can
also be detected in a similar manner. To detect the exception TransponderUnreachable, we
need to know whether the read/write antenna was able to reach the transponder. Hence,
an additional acknowledgement step is needed. Detecting a failed entry is done when an
166
9.2. 407 ETR System
exit is detected. Detecting a failed exit is done using a timeout. The updated use case is
shown in Fig. 9–6.
Use Case: TakeHighway
Scope: 407 ETR System
Level: User Goal
Intention in Context: The intention of the Driver is to drive a vehicle from one location to another by
taking the 407 ETR highway.
Multiplicity: One Driver can only drive one vehicle at a time on the highway. However, different Drivers
can take the highway simultaneously.
Primary Actor: Driver
Secondary Actor: RWAntenna, GovernmentComputer, OperatorTerminal
Main Success Scenario:
1. Driver enters highway, passing through gantry.
2. Driver exits highway, passing through gantry.
3. System retrieves the driver’s vehicle record based on trip information*.
4. System determines the amount owed based on the trip information and adds the transaction to the
vehicle’s records.
5. System informs Driver by sending a signal to the RWAntenna of successful completion of transaction.
reliability
6. System receives confirmation from RWAntenna that the driver was notified.
Use case ends in success CrossedHighway.
Extensions:
3a. Vehicle is unregistered and does not have a record yet.
3a.1. System sends license plate information to GovernmentComputer.
3a.2. GovernmentComputer sends vehicle information and owner’s address to System. reliability
3a.2a. Exception{GovernmentComputerUnavailable}. Use case ends in f ailure GovtComputerFailure.
3a.3. System creates a new vehicle record. Use case continues at step 4.
3b. Vehicle is unregistered and license plate is unrecognizable.
3b.1. System displays pictures on OperatorTerminal.
3b.2. OperatorTerminal sends license plate information to System. Use case continues at step 3.
reliability
3b.2a. Exception{OperatorFailure}. Use case ends in f ailure OperatorFailure.
4a. Exit unsuccessful.
4a.1a. If entry was successful, minimum trip charge is added to vehicle’s records. Use case ends in
degraded MinimalTrip.
4a.1b. If entry was unsuccessful as well, use case ends in f ailure .
4b. Entry unsuccessful.
4b.1a. If exit was successful, minimum trip charge is added to vehicle’s records. Use case continues
in degraded MinimalTrip at step 4.
5a. Vehicle is not registered. Use case ends in success .
6a. Exception{TransponderUnreachable}. Use case ends in degraded DriverNotNotified.
Figure 9–6: Updated TakeHighway Use Case
To increase safety, we need to find a mechanism to detect the failure of the barrier. To
this intent, we introduced an additional sensor which detects when a barrier is closed. A
malfunctioning barrier can therefore be detected by the absence of the acknowledgement.
The ActivateBarrier handler use case is updated with the detection and acknowledgement
step (not shown for space reasons).
167
9.2. 407 ETR System
Task 9: Specifying Handler Use Cases
In the case where an exit or entry of a vehicle is
not detected, it is impossible to determine the length of the vehicle’s trip. Therefore, the
driver is billed for a minimal charge, shown in the TakeHighway use case in Fig. 9–6 with
the degraded outcome MinimalTrip (steps 4a.1a and 4b.1a).
If the transponder is unreachable, the driver can not be notified of the success of the
transaction. Therefore the use case ends in the degraded outcome DriverNotNotified (step
6a).
We know that the government computer is highly reliable and available, and therefore
failures reaching the government computer are probably of temporary nature. Therefore
the service-related exception GovernmentComputerUnavailable is handled by resending the
request. The handler defined for this task is shown in Appendix A.2.1. The OperatorFailure
exception can be handled in a similar manner, resending the request to the operator again
or by trying another operator terminal.
In case of a malfunctioning transponder, the client is notified of the problem. He is
given a grace period within which to service the transponder, and during which time he
will not be charged a video toll charge. The handler defined for this purpose, WarnClients,
is shown in Appendix A.2.1. The handlers defined in this task are accordingly labelled as
reliability handlers.
In case of the BarrierFailure exception, the system should immediately notify an
operator. The operator can then evaluate the situation and, if necessary, call a service
person and inform the patrol officers. This functionality is described in the safety handler
use case CallHighwayPatrol.
Task 10: Defining Degraded Modes In the 407 ETR system, even if the hardware of
some entry or exit gantries are malfunctioning, it was decided that the highway should
continue to operate (and charge minimal trips for vehicles that enter or exit through malfunctioning gantries).
Bad weather conditions might prevent a video camera from capturing clear pictures,
or transmission problems might prevent the captured images from reaching the central
computer. In this case, the detection and recognition services of a video surveillance
system might temporarily be less reliable. In such a situation, the system would switch to
a degraded mode DegradedReliability.
168
9.3. Car Crash Crisis Management System
9.2.6
Requirements Summary
The summary models are included in Appendix A.2. The exceptional use case diagram
is shown in Fig. A–17 and the DREP activity diagrams are shown in Section A.2.2. The
exception table and mode table are presented in Tables A–2 and A–3 respectively. Finally,
the interaction diagram is shown in Fig. A–24.
9.3
Car Crash Crisis Management System
The domain of the case study is crisis management systems (CMS). Our requirements
elicitation process is applied to the CMS in this section.
9.3.1
Problem Statement
The need for crisis management systems has grown significantly over time. A crisis can range from major to catastrophic affecting many segments of society. Natural
disasters (e.g. earthquakes, tsunamis, twisters, fire, floods, etc.), terrorist attacks or sabotage (explosions, kidnapping, etc.), accidents (plant explosion, pollution emergency, a car
crash, etc.), and technological disruptions are all examples of emergency situations that
are unpredictable and can lead to severe after-effects unless handled immediately. Crisis management involves identifying, assessing, and handling the crisis situation. A crisis
management system facilitates this process by orchestrating the communication between
all parties involved in handling the crisis. The CMS allocates and manages resources, and
provides access to relevant crisis-related information to authorized users of the CMS.
The user requirements outlined in this section are based on [187]. The general objectives of a crisis management system (CMS) include the following:
• To help in the coordination and handling of a crisis;
• To ensure that an abnormal or catastrophic situation does not go out of hand;
• To minimize the crisis by handling the situation using limited resources;
• To allocate and manage resources in an effective manner;
• To identify, create, and execute missions in order to manage the crisis;
• To archive the crisis information to allow future analysis.
Crisis Scenario (of a Car Crash Crisis Management System)
A crisis management sce-
nario is usually triggered by a crisis report from a witness at the scene. A coordinator, who
169
9.3. Car Crash Crisis Management System
is in charge of organizing all required resources and tasks, initiates the crisis management
process. The coordinator has access to the camera surveillance system. The surveillance
system is an external system used to monitor traffic on highways or other busy routes. The
cameras are installed only in specific locations. If a crisis occurs in locations under surveillance, the crisis management system can request video feed that allows the coordinator to
verify the witness information.
A super observer, an expert in the field (depending on the kind of crisis), is assigned
to the scene to observe the emergency situation and identify the tasks necessary to cope
with the situation. The tasks are crisis missions defined by the observer. The coordinator
is then required to process the missions by allocating suitable resources to each task.
Depending on the type of crisis, human resources could include firemen, doctors,
nurses, policemen, and technicians, and hardware resources could include transportation
systems, computing resources, communication means (such as PDAs or mobile phones),
or other necessities like food or clothes. Animals, for instance police dogs, are also used
as resources in some situations. The human and animal resources act as first-aid workers.
Each first-aid worker is assigned a specific task which needs to be executed to recover from
the abnormal situation. The workers are expected to report on the success or failure in
carrying out the missions. The completion of all missions would allow the crisis to be
concluded.
Scope of the CMS
A crisis management system (CMS) should include the following
functionalities:
• initiating a crisis based on an external input from a witness,
• processing a crisis by executing the missions defined by a super observer and then
assigning internal and/or external resources,
• wrapping-up and archiving crisis,
• authenticating users,
• handling communication between coordinator/system and resources.
CMS replace existing crisis management systems that a) still manually keep track of
important crisis-related information and that b) operate largely without automated support
for crisis resolution strategies in order to respond to a crisis.
Car Crash Crisis Management System
In some of the models presented, we have focused
on one particular CMS: the car crash crisis management system. The car crash CMS
170
9.3. Car Crash Crisis Management System
includes all the functionalities of general crisis management systems, and some additional
features specific to car crashes such as facilitating the rescuing of victims at the crisis scene
and the use of tow trucks to remove damaged vehicles.
A car crash is defined in Wikipedia as following:
A car accident or car crash is an incident in which an automobile collides with
anything that causes damage to the automobile, including other automobiles,
telephone poles, buildings or trees, or in which the driver loses control of the
vehicle and damages it in some other way, such as driving into a ditch or rolling
over. Sometimes a car accident may also refer to an automobile striking a
human or animal.
Our Car Crash CMS addresses car crashes involving single or multiple vehicles, humans, or other objects. This case study is however limited to management of human
victims only and does not provide rescue missions specifically for animals. First-aid animal
workers are not included in the scope of this case study either.
Car crash specific functionalities include the following:
• facilitating the rescue mission carried out by the police by providing them with detailed information on the location of the crash;
• managing the dispatch of ambulances or other alternate emergency vehicles to transport victims from the crisis scene to hospitals;
• facilitating the first-aid missions by providing relevant medical history of identified
victims to the first-aid workers by querying data bases of local hospitals;
• facilitating the medical treatment process of victims by providing important information about the crash to the concerned workers, i.e. paramedics, doctors, upon arrival
at the hospital;
• managing the use of tow trucks to remove obstacles and damaged vehicles from the
crisis scene.
The actors involved in the Car Crash CMS are defined in this section.
• Coordinator oversees management of the crisis by coordinating the resources and
communicating with all the CMS employees and external workers.
• Super Observer is dispatched to the crisis scene to evaluate the situation and define
the necessary missions to cope with the crisis.
• CMS Employee is an internal human resource who is qualified and capable of
performing missions related to his field of expertise. The worker acts as a facilitator
171
9.3. Car Crash Crisis Management System
actor when he is in charge of or operating local resources (for example, tow trucks or
ambulances).
• External Worker is an external resource who is specialized and capable of performing missions related to his field of expertise. The worker acts as a facilitator actor
when he is in charge of or operating external resources (for example, police trucks or
fire trucks).
• System Admin is the specialist who maintains the system and creates all profiles
of workers and resources to feed the crisis management database.
• Witness is the person who reports the crisis by calling the crisis management center.
• Phone Company is an external entity contacted for verification of witness purposes.
• Surveillance System is an external entity which monitors traffic in highways and
cities with the use of cameras.
9.3.2
Requirements Development
We discuss the elicitation and specification of dependability requirements in this section. The CMS artifacts are presented in Appendix A.3.
Definition of Use Cases, Exceptions, and Handlers
To begin with the user goals and
actors of the CMS are elicited. Fig. A–25 shows the use cases related to the summarylevel goal Manage Crisis in the Car Crash CMS, by means of a use case diagram. The
use cases defined are: ManageCrisis, InitiateCrisis, CreateCrisis, ProcessCrisis, ProcessMission, AssignInternalMission, RequestExternalResource, ExecuteSuperobserverMission,
CreateMission, ReportMissionOutcome, ConcludeCrisis, RequestLogin, SendMessage, Respond, and AuthenticateUser.
Note on the communication using PDAs and SMS: The RequestLogin, Respond
and SendMessage subfunction-level use cases are used whenever communication takes place
between the system and a CMSEmployee. In the following use cases, all interactions with
CMSEmployee are annotated with:
•
C
•
R
if the communication is directed from the System to a CMSEmployee as specified
in the RequestLogin subfunction-level use case,
if the communication is directed from the CMSEmployee to the System in a secure
and authenticated way as specified in the Respond subfunction-level use case, or
172
9.3. Car Crash Crisis Management System
•
S
if the communication is directed from the System to a CMSEmployee in a secure
and authenticated way as specified in the SendMessage subfunction-level use case.
Following the elicitation of the standard use caes, exceptional use cases are created by
applying the DREP process (Chapter 6 to the Car Crash CMS case study. When applying
DREP, the developer is lead to discover all kinds of exceptional situations that the system
might be exposed to. Once exceptional situations have been identified, the stakeholders
can decide on the appropriate behavior that the system should exhibit in such a situation.
This handling behavior is described in handler use cases. DREP also introduces the notions
of degraded service outcome and exceptional operation modes.
Fig. A–26 in Appendix A.3 shows the use cases, exceptions and handlers related to
the user goal ManageCrisis in the Car Crash Crisis Management System, by means of an
extended use case diagram.
Elicitation of Context-Affecting Exceptions and Handlers
When brainstorming context-
affecting exceptions, several situations were discovered that affect the context in which the
system operates, and that require the system to react in a certain way to continue to
provide reliable and safe service. The situations are:
• Severe Weather Conditions: Bad weather makes helicopter transportation impossible.
• Strike: A strike affects the availability of CMS employees and external workers.
• Risk of Explosion: Leaking gas and open fire threatens the safety of workers.
• VIP Victim: One of the crash victims is a VIP (such as for instance, the president).
Handling of the crisis should therefore be coordinated by the appropriate office.
• Criminal Case: The reason for the crash is of criminal nature, and therefore the
rescue missions have to be carried out accordingly.
To detect and to handle the above situations, we added the following exceptional
actors: WeatherInformationSystem, NationalCrisisCenter. The seven handler use cases
defined are SuspendHelicopterActivities, PrepareForStrike, ActivateStrikeMode, ManageExplosionRisk, ContactNationalCrisisCenter, VIPTreatment, and ApplyCrimeNorms. The
detailed handler use cases that describe the functionality that the reliable car crash CMS
is to provide are described in Appendix A.3.1.
For each step in the standard use cases was also assessed for effects on reliability
and safety. The identified interactions in the use cases and handlers are annotated with
reliability and safety tags. Service-related exceptions are defined and specified in the
extensions section of the use case. Detection actors and interaction steps for detection
173
9.3. Car Crash Crisis Management System
have been added where necessary, and goal outcomes have been visited. Corresponding
handlers are also presented that specify recovery actions.
Design of Specification Models We give one example on how in DREP a use case is
represented using activity diagrams. Fig. A–27 shows the activity diagram created by
based on the use case Assign Internal Resource already presented in Appendix A.3.1. The
interested reader is referred to Chapter 8 where we have defined precise transformation
rules that make it possible to automate this mapping.
The AssignInternalResource activity is composed of several subactivities beginning
with DetermineMostAppropriateEmpl. After succcessfully selecting a CMSEmployee, the
flow of AssignInternalResource continues to the activity RequestLogin. If DetermineMostAppropriateEmpl fails, the parent activity also fails. Next if the login is successful, it is followed by the activity SendMissionInformation. On a successful outcome, the system waits
for a reply from the employee which is part of the activity AwaitingMissionAcceptance. If
the login in unsuccessful or if the mission information is not transmitted successfully, the
activity AssignInternalResource restarts by choosing an alternate worker.
The AssignInternalResource activity has two different outcomes. It can either succeed
( success MissionAssigned ) or fail ( f ailure EmplUnavailable).
If desired, all use cases can be transformed into activity diagrams following the same
mapping rules to create a complete specification of the system’s behavior using activity
diagrams.
Summary of Exceptions and Modes
In order to summarize the behavior of the Car
Crash CMS in exceptional circumstances, Table A–4, A–5, and A–6 list all exceptional
situations that the system can be exposed to. For each exception, the table contains a
small textual description of the exceptional situation, the context in which the exception
can occur, the associated handler use cases, if any, and the mechanism for detecting the
exception, if any.
Whenever a dependable system has encountered difficulties performing a requested
service due to some exceptional situation, the effect of the encountered problem on future
service provision of the system has to be evaluated. If the reliability or safety of future
service provision is threatened, then a mode switch is necessary. Switching to a different
operation mode allows the system to signal to the environment that the services offered
by the system have changed, and reject any requests for services that cannot be performed
174
9.4. Summary
with sufficient reliability or safety. We briefly discuss the different modes of operation in
the Car Crash CMS.
Normal mode The crisis management system has one normal mode of operation in which
all the normal and recovery services are offered.
Emergency mode Due to a complete city-wide power outage, the coordinator is unable
to manage crisis situations. The System only offers the service of forwarding calls
reporting crisis to the National Crisis Centre, and switches to a Blackout.
Degraded mode Due to severe weather conditions and low visibility, the system switches
to a mode, NoHelicoptersAvailable, where the helicopter service is not available.
In strike conditions, some internal or external resources may not be available. For
example, the fire station worker union might be on strike, and hence no firemen might
be available for missions. The system is then in a mode, ReducedServiceProvision
where limited rescue services are available.
The summary tables are included in Appendix A.3.3 and A.3.4.
9.4
Summary
This chapter demonstrated the use of our methodology on the Elevator Control Sys-
tem, 407 Express Toll Route, and the Crisis Management System case studies. The ECS
is a safety-critical system, whereas the other two are more concerned with reliabiity. We
discuss how we discover reliability and safety concerns and threats in these systems, and
how the concerns are addressed by DREP. The elicitation of context-affecting exceptions
and service-related exceptions in each system is explained. Safety and reliability handlers
are designed for each system. For each case study, we present the exceptional use case
model, the specification models, and the summary exception and mode tables.
175
CHAPTER 10
Evaluation of Proposed Process
The research hypothesis defined in Chapter 1 states the following: A requirements engineering process catered to dependable systems can help developers create a more complete
specification, and ultimately increase the ability of a system to avoid service failures that
are more frequent and severe than is acceptable to the user.
The hypothesis can be decomposed into three claims: completeness, acceptability,
applicability. To validate these claims, we use a series of case studies. The claims addressed
by the different studies are shown in Table 10–1. The characteristics of each study are listed
in Table 10–2. External participants in Table 10–2 specifies if the study used subjects not
directly involved in the development of the approach. Replication refers to whether the
study employed multiple subjects to work on the same approach.
Table 10–1: Claims Addressed by Case Studies
Study
ECS
407 ETR
CMS
e-health
Claims
completeness, acceptability
completeness, applicability
applicability
applicability
Table 10–2: Characteristics of Case Studies
Study
ECS
407 ETR
CMS
e-health WIS
External Participants
yes
yes
yes
yes
176
Replication
no
yes
no
no
10.1. Methodology
Due to the nature of this software engineering research work, we employ a combination
of qualitative and quantitative methods for evaluating our proposed approach. Case studies
from the real-time and dependable system literature are used to validate our research
work. We have applied our requirements development process to a Elevator Control System
(ECS), the 407 Express Toll Route (ETR) System, and the Crisis Management System
(CMS). Our intention is to build up a weight of evidence [186] to support our hypothesis.
As stated by Seaman in reference to the aim of qualitative and quantitative research: “a
hypothesis is never proven, but evidence, in the form of statistically significant results from
different settings and different researchers, is built up to support it” [186].
This chapter is structured as follows: Section 10.1 discusses the research methodology used to validate our work. Section 10.2 presents the Elevator Control System (ECS)
study. Section 10.3 describes the experiment carried out with the 407 Express Toll Route
(ETR) System. Section 10.4 outlines the Crisis Management System (CMS) study, and
Section 10.5 briefly reports on an e-Health case study carried out by software engineering
academics which used our process. Finally, Section 10.6 summarizes the evaluation of our
proposed process.
10.1
Methodology
We use the case study research strategy as the methodology to validate our work.
Case studies are concerned with how and why types of research questions, do not require
control of behavioural events, and focus on contemporary events [224].
Case studies
are an observational empirical method, which is used for exploratory investigations. It
is a powerful and widely popular method that is used “to understand, to explain, or to
demonstrate the capabilities of a new technique, method, tool, process, technology, or
organizational structure” [167].
We perform case studies to monitor the effectiveness of standard and depedabilityoriented requirements elicitation methods, in order to validate our completeness and applicability claims. We begin with an exploratory study using by applying DREP to the
ECS, and then carry out a confirmatory study with the 407 ETR system. The empirical
study was conducted using academic courses, in a similar manner to the empirical validation of software development processes carried out by Ciolkowski et al [42]. As stated
in [42], “although an academic setting is not representative of industrial organizations,
177
10.2. Elevator Control System(ECS) Case Study
the information gathered there can help organizations to decide upon alternatives to improve current software engineering processes”. To build up diverse evidence to support the
applicability claim, we applied DREP to the CMS case study.
Our dependability assessment approach is validated using the observational method,
assertion [226], since the the goal is to show that the particular method works and can be
applied to a case study of considerable significance.
We have tried to follow the guidelines for empirical research presented by Kitchenham
in [117]. To begin with, each case study is briefly introduced. The research questions
addressed by the study and the theory behind the questions are stated, and the study
setting is described. The results of the study and the validity of the results are then
discussed.
10.2
Elevator Control System(ECS) Case Study
The elevator control system (ECS) is an embedded control system which is required to
be highly safety-critical and at the same time needs to provide reliable service. The system
is representative of our target domain since it falls under the real-time reactive systems
domain.
In this case study, the author of the thesis took on the role of a requirements engineer.
The subject of the study has not been previously involved in the development of elevator
control systems.
10.2.1
Theory
The research carried out as part of this study is exploratory in nature. The ECS case
study was mainly used to investigate the completeness and acceptability claims.
The research questions that the study attempted to investigate are as follows:
• Can a dependability-oriented process help developers capture more exceptions?
• Is a process more effective than just a notation-based approach?
• Can the use of a dependability-oriented process lead to a system that can justifiably
be trusted (in other words, increase the ability to avoid service failure)?
• How do developers ensure that the requirements are acceptable to the users?
178
10.2. Elevator Control System(ECS) Case Study
10.2.2
Study Design
Three subjects participated in this study: two Ph.D. students and one Masters student
in Software Engineering. All the subjects had a high level of familiarity with software
development and modelling.
The study was split into three parts: application of a generalized RE approach, application of the exceptional use case approach, and application of DREP.
Applying General RE
Applying a standard RE method to elicit and specify the require-
ments of an ECS is important to allow us to compare our process to existing good practices.
For this study, we required the use of a standard development method and we chose Fondue
which is a development process for reactive systems. Instead of designing the requirements
from scratch, we based the comparison on use cases existing in the literature defined by
Shane Sendall in his Ph.D. thesis [188]. His work is based on the same ECS problem
statement. The author of [188] has a high level of expertise in requirement engineering
and reactive systems. He has worked on the creation of the ANZAC approach by evolving the Fondue process and adapting it towards real-time systems. He also has in-depth
knowledge on specification of behaviour of reactive systems. Therefore, we believe the ECS
requirements models defined by Sendall are well thought-out and detailed, and at the least
representative of requirements that can be gathered by using a generalized RE process.
We use the coding [186] strategy to extract quantitative data from the requirements
models, mainly the use cases which includes qualitative data. The author inspected the
requirements carefully to determine, as best as she could, whether any abnormal behaviour
or concerns that might lead to an exception were addressed. When specific concerns or
constraints were not defined, it was necessary to determine if the specification could be
deemed to include abnormal behaviour or exceptional situations.
Applying the Exceptional Use Cases Approach
This part of the study was carried out
by the author of this thesis in collaboration with a Masters student working in the same research area. Both subjects had a software engineering background and were well-conversant
with UML, and use cases. The Masters student was very familiar with exception handling,
and the Ph.D. student had a in-depth knowledge in dependability and fault tolerance. The
task at hand was to create exceptional use cases by addressing dependability concerns as
discussed in Chapter 4 and then applying the exceptional use cases technique introduced
179
10.2. Elevator Control System(ECS) Case Study
in Chapter 5. The subjects began by individually brainstorming the requirements based on
the problem statement, and then jointly continued to define use cases which later evolved
into exceptional use cases. The work was carried out over a few weeks during which time
the subjects discussed their findings and made decisions about the models. A software
engineering professor participated in the discussions and was part of the decision-making
process.
Applying DREP
The subject in the final part of the study was primarily the author of
the thesis. The work comprised of two elements: development of the requirements and
assessment of the requirements. To develop the requirements models, the subject began
with the problem statement of the ECS and applied the elicitation tasks defined in DREP
(Chapter 6). The first phase comprised of creating the DREP use cases which defined the
system interactions as well as the exceptions.
The next phase involved the probabilistic analysis of the use cases defined in the first
phase. The work in this phase was carried out in collaboration with a Masters student
with a strong background in model-based development. The author mapped the use cases
to DA-Charts, and then created the DA-Charts using the AToM3 tool which was extended
with support for dependability assessment (Chapter 7). The DA-Chart approach is validated by construction. The probability analysis was also worked out manually so as to
validate the results produced by the tool. Based on the results, the use cases were further
refined with handler use cases which addressed situations which affected the safety of the
system. To further evaluate the assessment approach, the DA-Charts were revised and
the probability analysis was run once again. The assessment results were considered and
further enhancements to the model were required to improve the system reliability. New
exceptions and handlers evolved, and a revised DA-Chart was produced.
The initial elicitation of the use cases required approximately 48 working hours spread
out over a week. The assessment and the following refinements were carried out over a few
weeks.
10.2.3
Results
Several observations were made based on the study.
• A generalized process is not always effective for development of dependable systems
even when used by an experienced and knowledgeable requirements engineer.
180
10.2. Elevator Control System(ECS) Case Study
• Using a dependability-oriented approach or notation helps requirements engineers
produce a more complete specification.
• Using a dependability-oriented process which provides guidelines and dependability
support produces a more complete and precise specification.
• For dependable systems, means to assess the dependability that can be attained by
the system under development allows stakeholders to validate the requirements.
General RE Process
In the use cases designed using a standard RE process, no excep-
tional situations are specified explicitly. The timing requirements that are specified as part
of the use cases can be said to indirectly address some exceptional situations.
In the use case Enter Cabin (Fig 9.2 included in Appendix C), one timing requirement
is as follows.
Step 4: “the system must decide in 0.1 seconds if it is to stop the cabin”.
The same requirement is also specified in Step 5 in Fig 9.3([188]). The interpretation was:
if this requirement is not met, i.e. a motor stop request is not sent on time, then the
destination floor may be missed (which we define as exception MissedFloor ).
Another timing requirement specified in Fig 9.3 is as follows.
Step 6: “The door is guaranteed to stay open for at least 5 seconds”.
This case was interpreted as: if there is a problem with the door (which we define as an
exception Door Stuck Closed ), then this concern is not satisfied.
It was a surprising revelation that even with knowledge of the target domain the
requirements elicited did not address reliability and safety issues that might lead to user
goal failures. Interestingly, the Fondue use cases addressed the fact that a user goal may
be abandoned. However, the result was not considered as part of the study.
Exceptional Use Cases Approach
The exceptional use cases were inspected and the
exceptions uncovered were listed. Addressing dependability concerns and having a definite
approach for specifying the concerns were seen to have a positive effect on the subjects.
Several vital exceptional situations and corresponding recovery measures were defined.
DREP In addition to the exceptions defined using the exceptional use cases approach, the
DREP use case model included several other exceptions and associated handlers making
the specification more complete and precise in comparison to the above approaches. The
study demonstrates that having a notation or a profile is not as effective as when having
181
10.2. Elevator Control System(ECS) Case Study
Figure 10–1: ECS: Validation Results
a process accompanying the modelling technique. We believe this is because well-defined
guidelines were available along with a task checklist (shown in Appendix B) which ensure
that designers do not forget significant concerns during elicitation and specification. Moreover the assessment approach included as part of DREP, leads designers and stakeholders
to really understand the requirements as well as the level of dependability that can be
satisfied by the elicited requirements. This method also helps in clarifying situations, and
in defining exceptional situations and recovery measures in an iterative manner for which
a lot of thought is given over time.
Comparison
We inspected the requirements models developed using each approach, and
collected data by determining the extent to which exceptional situations had been addressed
in each part of the study. The DREP models are included in Appendix A.1. Fig. 10–1
shows a comparison of the results obtained by each approach of the number of exceptions
discovered.
The ECS study also acted as a prestudy, and allowed us to plan future experiments
based on the information gathered during the study.
182
10.3. 407 Express Toll Route (ETR) System Case Study
10.2.4
Validity
The investigator had a vested interest in the positive evaluation of the study, since the
dependability-oriented RE practices employed are created by the researchers themselves.
To avoid bias in the comparative study, the study based on the standard development
process, Fondue, was not carried out by either of the subjects working on the dependability
requirements elicitation. Instead, an existing specification was taken from the literature
that served as the base for comparison.
The use of coding for interpreting the specification can lead to a loss of information [186]. Hence the process of analyzing the requirements was repeated by two individuals
(both software engineers) and then compared for discrepancies.
The results of the study provide a weak ground for validation since the study was
not a replicated one. It is also threatened by investigator bias, due to the involvement
of the subjects in the development of the methods. Hence, the results obtained might
be better than what may be expected from unassociated subjects. However, since the
main intention was to evaluate the improvement that can be attained with the use of a
dependability-oriented process, we made sure that the application of the standard method
was not carried out by either of the two subjects and can be seen to be independent of
bias.
With regards to the assessment approach, it was to be validated by assertion. The
author of the thesis is both the experimenter and the subject of the study. The study
showed that the DA-Charts were successfully created and analyzed in an iterative manner,
which allowed for feedback from the users. The study has the possibility of being potentially
biased. However, the DA-Charts are directly mapped from the requirements, and therefore
the validity of the results depend on the validity of the requirements developed. We do not
forsee any significant threats to the validity of the approach. The results have been and
can always be compared by carrying out the probability analysis manually.
10.3
407 Express Toll Route (ETR) System Case Study
In the second case study, the goal was to carry out a confirmatory study as a follow-on
to the exploratory ECS study. We conducted an empirical study in an academic environment to validate our completeness and applicability claims but this time by using replication
and external participants. The target system, the 407 Express Toll Route (ETR) System,
183
10.3. 407 Express Toll Route (ETR) System Case Study
is mainly concerned with system reliability and is within our dependable reactive systems
target domain.
Since in our study we aim to evaluate whether a dependability-oriented process works
better than a standard approach or process, the process is the state variable [172]. We
view the standard approach or process (Fondue) as the control process, and DREP as the
experimental one.
10.3.1
Theory
The experiment was designed to address the following research questions:
1. Can a dependability-oriented process help developers create a more complete requirements specification?
2. Can the process be applied to various systems in the dependable reactive system
domain?
The theory behind the first question is that with a developer following a process which
provides precise guidelines focused on abnormal behaviour and dependability concerns can
help elicit and specify requirements of a dependable system in a more effective manner
than a generalized process.
The second question is associated with the applicability claim. The underlying theory
is that such a process can be deemed useful if it is applied to representative systems in the
target domain and produces a complete and accurate specification.
10.3.2
Study Design
We carried out two separate experiments, both as part of an assignment in an undergraduate/graduate object-oriented software development course. The subjects of the
study were software engineering students of McGill University with a background in objectorientation and software development but with a minimal or non-existent background in
requirements analysis and dependability. The subjects being final year undergraduate or
graduate students had experience working on major development projects. Several students had industry experience as programmers/software developers. The subjects selected
were representative of junior software designers working in industry.
Each part of the study was divided into two phases: the training phase and the
development phase.
184
10.3. 407 Express Toll Route (ETR) System Case Study
Experiment 1
In the first part of the experiment, the training phase included a 6 hour
lesson that introduced a group of 20 students to requirements elicitation with use cases.
As part of the use case module, the group was required to complete exercises on use cases
to develop skills, for which an additional 3 hours were alloted.
Following the training, in the development phase they were asked to define use cases
for the 407 ETR system using the standard use case template described in [189]. This first
set of use cases is labelled standard in the following evaluation.
The second part of the experiment again commenced with the training phase during
which the students were presented with our exceptional use case notation as proposed in
Chapter 5 and the necessary preliminaries as detailed in Chapter 4. The training was
delivered in a one hour lecture period. The subjects were given a second part of the
assignment which initiated the second development phase. The subjects had to develop
and extend their use cases by analyzing the cases for exceptional situations. They were
required to document their results in an exception table, listing all exceptions discovered,
their contexts, possible detection mechanisms, and handlers. This second set of use cases
is labelled EUC Notation in the following evaluation.
Experiment 2 The second experiment was carried out using the same case study, but with
a different subjects. The subjects were again undergraduate/graduate software engineering
students. The experiment began with the training phase during which the subjects were
introduced to use cases over a period of 3 hours. The subjects were then presented with our
dependability-driven requirements engineering process, DREP (as described in Chapter 6),
in a one hour lecture. Subsequently, the development phase began in which the students
were asked to apply the task-based process to the 407 ETR system and elaborate use cases,
handlers and a summarizing exception table following the guidelines outlined in Chapter 6.
10.3.3
Results
As illustrated in Appendix A.2, our specification of the 407 ETR includes 10 exceptional scenarios. We inspected the students submissions and analyzed the exceptions
discovered by the members of each group. The results of the study are shown in Fig. 10–2
and 10–3.
Fig. 10–2 illustrates the measured improvements when using DREP as opposed to the
standard use cases approach. In the first experiment using the standard use cases, about
185
10.3. 407 Express Toll Route (ETR) System Case Study
67% of the students did not identify any exceptional situations. None of the students
were able to identify context-affecting exceptions. Using DREP, students of the second
experiment were able to discover an additional 64.45% exceptions on average, and 96%
discovered the context-affecting exception HighwayUnavailable. It is not surprising that
none of the students using standard use cases discovered the BarrierFailure exception,
since this exception is revealed only after revisiting and analyzing a handler use case.
Fig. 10–3 shows that students who applied DREP achieved even better results than
those who just used the exceptional use case concepts and notation. Using DREP, the students of the second experiment were able to discover an additional 21.3% of the exceptions
compared to the students in the first experiment using the exceptional use case notation
only. It is to be noted that, using the exceptional use case notation, the designer is not led
to carry out the refinement and iteration tasks, and hence the results obtained by students
of the first experiment were based on one iteration only. Iterations (as suggested in task 8
and 9) would probably have improved the use cases further.
Three groups had defined a general exception “device failure” for failures of gantry
components. This was considered in the results, since we believe that examining the scenario a little further would have lead to splitting up this exception into CameraFailure,
LightFailure and LaserScannerFailure. There was one surprise in the experiment results:
using our process, fewer number of students were able to discover the exceptional situation TransponderUnreachable. We believe that this is due to the fact that in our process
exceptions are discovered by analyzing the use case interactions step by step. If the standard use case is incomplete to begin with, i.e. if the analyst forgets a normal interaction,
this omission propagates further on and associated exceptions do not appear. A careful
inspection of the main success scenario of the TakeHighway use case of the students of
the second experiment revealed that indeed many students had forgotten to include the
acknowledgment step where the system informs the driver of the successful completion of
the transaction in the base use case.
The study results pointed out a weakness in our process. To address this issue, we
need to revise task 5 (designing interactions) of the process. As part of this task, it is
important to specify clearly in the use case template the list of secondary actors, if any is
associated with the use case. When designing the interactions, it has to be ensured that any
secondary actor listed is included in at least one of the interactions. If it does not appear,
then either the actor is irrelevant and the list needs to be revised, or essential interactions
186
10.3. 407 Express Toll Route (ETR) System Case Study
Figure 10–2: Validation Results: Standard Use Cases versus DREP
(with the secondary actor) are missing. Enforcing this rule would aid developers in defining
complete scenarios, and in discovering possible exceptions.
The successful classroom study can be taken as a good indication that our process has
potential. It would of course be useful to conduct a similar experiment in an industrial
setting.
Interpretation
If we revisit our research questions, the first question posed was whether
a dependability-oriented RE process can aid in creating a more complete specification
with regards to dependability concerns in the system. As the results show, using DREP
does in reality lead to the discovery and definition of concerns that can possibly threaten
the dependability of the system. Use-case driven elicitation without proper guidance and
methodology is not an effective technique for requirements development of dependable
systems. We also saw that using a dependability-oriented approach, such as the exceptional
use cases approach, is not as effective if it is not accompanied by a process model. This
is because the approaches depend on the extent to which the designers are themselves
dependability-aware. Using a process such as DREP takes a lot of weight off the designers
187
10.3. 407 Express Toll Route (ETR) System Case Study
Figure 10–3: Validation Results: Exceptional Use Cases versus DREP
shoulder and does not require designers with years of field experience to carry out the
elicitation.
The second question was regarding the applicability of the process. The results show
that the process accounted for the concerns that were relevant in an ETR system.
10.3.4
Validity
Industrial software development projects are in general large, complex, and costintensive. For feasibility reasons, researchers rely on such synthetic environment experiments which involve replicating projects in a smaller artificial setting that simulates the
environment of real industrial projects [226]. Such experiments are often associated with
low external validity since they are not always representative of the real world. One threat
to external validity is a large difference in the group size involved in the task which reduces
the strength of the results reported. However, in our case we do not expect a big difference
188
10.4. Crisis Management System (CMS) Case Study
in the team size carrying out the tasks. Another point of concern is the background of the
subjects used in the experiment. While the expertise level of subjects in academic settings
do not represent professionals in the industry, it has been studied that the difference between students and professional developers is not of major significance in most cases [97].
Academic studies have medium to high statistical significance and low personnel cost in
comparison to industrial studies [42]. Another positive side is that, such studies allow participants to gain insight into new technologies and methodologies and gather experience in
applying such means. Successful studies may also encourage researchers and practitioners
to employ the demonstrated methods.
Considering the internal validity of the study, there is a possibility that the behaviour
and work carried out by the subjects might actually be effected by external factors such as
prior knowledge or expertise, or investigator bias during the study. To minimize such effects
we chose a population with subjects having similar levels of background and expertise. The
subjects were instructed to work on their own and not to share or discuss their results with
other subjects or with people not participating in the experiment. Investigator bias during
the study was reduced by ensuring that the investigator had no active involvement in
the training phase. The training was carried out by a professor who took no part in the
investigation. The problem statement and the tasks to be carried out were delivered to the
subjects as a written document to make sure that no information other than the problem
definition was passed to the subjects.
The work was carried out as take-home assignments to be completed within one week.
Hence, the time taken by each designer have varied a lot. The results might be skewed
depending on the time spent on understanding the problem, brainstorming, and eliciting
the requirements. However, our intention was not to evaluate how fast the requirements
can be elicited but to find out how effectively it can be done. Even in reality, the time
taken to carry out a task might vary depending on the quality of the designer.
10.4
Crisis Management System (CMS) Case Study
To build a weight of evidence, we used yet another case study: the Crisis Management
System (CMS). The study adds strength to the validity of our applicability claim. The
CMS is representative of our target domain but is different than the systems covered in
the other case studies. It is a workflow management system which monitors and allocates
tasks to employees working in a crisis situation. The majority of the actors in the system
189
10.4. Crisis Management System (CMS) Case Study
are humans, and hence the level of unpredictability is high. Unlike the ECS, it is not an
embedded system and is neither a safety-critical system. However, the CMS is required to
provide reliable services since service failures might lead to consequences which range from
minor to disastrous.
The requirements development was carried out by two groups. The first group (referred
to as Group 1 hereafter) consisted of two professional software engineers, and the second
group (referred to as Group 2) included two software engineering researchers (one of whom
was the author of the thesis) with a strong software engineering background but with no
industry experience.
10.4.1
Theory
The research question that the case study attempts to address is whether a dependabilityoriented RE process can be used to develop requirements of various types of systems within
the target domain.
The theory underlying the question is that the process DREP includes concepts and
guidelines which allow consideration of dependability concerns and threats in different
types of systems in the reactive system domain.
10.4.2
Study Design
The study was carried out by the author of the thesis (the primary researcher) during a
research visit at the University of Luxembourg. The task at hand was to refine an existing
requirements specification of the CMS for software product lines by considering attributes
and threats to system dependability. Software engineers from the industry were hired to
create a specification of the CMS according to a problem statement verbally delivered
to the engineers by the founder of the project (the professor who conceived the idea of a
CMS). According to the information received, two experienced software engineers had been
assigned to the project. They had a strong background in software development but lacked
expertise in requirements engineering (as is the usual case in industry). The identity of the
engineers are not revealed here.
Since a well-defined problem statement was not available, the researcher interviewed
the professionals involved in the project to gain an insight into the application domain. The
interviews and the existing specification was used to derive a refined problem statement.
The researcher then started the use case-based requirements elicitation from scratch by
190
10.4. Crisis Management System (CMS) Case Study
applying DREP in a step-by-step manner. The standard use cases were first created,
following which the use case model was refined with exceptions and handlers. Surprisingly,
the guidelines seemed even more effective than expected. The researcher was led to take
into consideration various aspects of the system and helped in defining essential contextaffecting exceptions in addition to the service-related exceptions.
10.4.3
Results
The use case specification created using DREP was much more precise and meaningful.
The models are included in Appendix A.3. Some context-affecting exceptions were revealed
when applying DREP which constitutes as vital concerns in a CMS. The process also lead
to the definition of recovery measures (handlers) when required. A significant increase was
seen in the elicitation of service-related exceptions which pose threats to system dependability. The exceptional situations defined by group 1 were all related to authentication
and login failures. These are the common exceptions which arise in almost all systems, and
which are usually always considered by developers at the design and implementation levels.
No application-specific exceptions were discovered by group 1. This is not so surprising
since a lot of developers are usually not exposed to exceptions at that level, and do not
have any guidelines to go by to steer them in the right direction. Fig. 10–3 shows the
results produced by the use of standard use-case based RE (group 1) and DREP (group
2).
The requirements document developed by the company is confidential, and hence is
not reproduced in this thesis. In the specification created by group 1, the functional
requirements also were not completely and accurately defined. This might be due to the
quality of the engineers. But when using DREP, since the elicitation begins with standard
use cases and dependability-oriented guidelines, it was possible to discover requirements
exhaustively in a structured manner.
Table 10–3: CMS: Validation Results
Subject
Group 1
Group 2
Context-Affecting
Exceptions
0
5
Service-Related
Exceptions
5
49
191
Handlers
1
12
10.5.
e-Health Insulin Pump Web Information System Case Study
The results support our applicability claim since the use of DREP helped in the discovery and definition of requirements in the target domain.
10.4.4
Validity
Since the specification created by the consulting firm was available, the dependability
threats that were considered in it were also included in the new specification. Therefore, it
is possible that the resulting DREP-based requirements turned out to be better than what
may be expected if there had been no older existing requirements to base them on. Also,
the results might indicate a better than average use of the process since the subject using
DREP was the inventor of the approach. However this does not deter the validity of the
study, since the aim of the study was not to evaluate the degree of the improvements but
rather to demonstrate that the methodology in question can help in producing an improved
specification.
10.5
e-Health Insulin Pump Web Information System Case Study
DREP has been used to perform requirements elicitation of an e-health Web Information System (WIS) by researchers at LASSY, University of Luxembourg. The e-health
system under development is a Fault-tolerant Insulin Pump (FTIP) System which is used
to provide insulin therapy to diabetes patients. FTIP is a safety-critical embedded control
system which falls within our target domain. It is a dependable system requiring dependability threats and concerns to be considered early on during development. Elicitation with
DREP allowed the researchers to describe user goals and system interactions, discover pertinent exceptional situations that may arise in the environment or in the system, and define
detection means and recovery measures. The dependability assessment was not carried out,
which might have demonstrated a need for further refinements of the requirements. The
results have been published in the Service Oriented Computing and Applications (SOCA)
journal [16]. The results produced by DREP were used as input to the design phase which
began with the design of coordinated atomic actions (CAA). The exceptions derived using
DREP were mapped to the potential errors in CAAs.
It should be noted that the researchers made no contact with the authors of the
methodology, and relied on existing research papers to learn about the method before
applying it.
192
10.6. Summary
This work demonstrates how DREP or elements of DREP can be plugged into a
development process, and further supports our claims regarding the applicability of DREP.
10.6
Summary
It is a difficult yet necessary task to carry out empirical validation of software process
improvement. While several methodologies can be employed such as controlled experiments, case studies, assertions, and surveys, it is at times still not possible to establish
solid conclusions based on research findings especially for development methodologies which
have an unbounded solution space. There are high expectations associated to the evaluation of such methods which ideally are to be carried out in an industrial setting. However,
an industrial study can be quite time-consuming and expensive. An alternate cost-effective
solution is to conduct studies in an academic setting, and that is one of the techniques that
we employ to evaluate our work. As stated by Notkin, “Let’s not strangle ourselves, and
our chances of having an influence, by hiding behind a few specific approaches to evaluation
of our work. Rather let’s be demanding but flexible in this dimension” [216].
We intended to evaluate our requirements development process, DREP, in general and
our assessment approach, DA-Charts, in particular. With regards to the assessment, we
needed to establish that it was possible indeed to assess the dependability of the requirements with the use of our approach. It is possible to carry out further studies to investigate
the usefulness and effectiveness of the method, and we discuss this in Chapter 12.
We conducted three case studies to allow us to evaluate DREP. We used case studies
in the dependable reactive system domain including the Elevator Control System, the 407
ETR System, and the Crisis Management System. The studies were carried out to build
a weight of evidence to support our claims: completeness, applicability, and acceptability.
The studies were conducted either as part of research work or software engineering courses
at the university level. Even though an academic study is not entirely representative of an
industrial study, it provides results which to a certain extent can be relayed to an industrial
context. It should be noted that there are also threats to the validity of industrial studies.
According to [42], “contextual independence is hard to realize in the same organizations,
long duration is expensive, people communicate with each other, people object to process
changes, and competition among teams and managers are common”.
Our methodology was used by a team of software engineering researchers at the University of Luxembourg to help elicit and define requirements of a Fault Tolerant Insulin
193
10.6. Summary
Pump System. The system is very much part of our target domain, and the requirements
derived further adds weight to the usefulness and applicability of our process.
Other studies could have been carried out to investigate the cost of using our method.
It is a given that there is a cost incurred when addressing dependability concerns and integrating dependability means during development, due to the need for additional resources
and an increased effort during the lifecycle phases. However, depending on the type of
the system, there is at times no other right choice than to employ dependability means.
The cost can be minimized by considering such means early on, and not just in an ad-hoc
manner during late design or implementation. According to Davis (see Fig. ??), the cost to
fix errors increases significantly with each phase in the lifecycle. Hence, cost estimates are
difficult to gather in such projects where the cost is actually spread out over the lifetime
of the use of the product and not just over the development period. It remains that addressing means such as fault prevention and fault tolerance increases development cost but
decreases the cost that is usually incurred during the maintenance and evolution phases.
As stated by Tichy [216], “I think we should give up on correlating volume metrics with
cost estimates. ... Instead we need to figure out better models of software development
processes to achieve better estimates”.
To conclude, as demonstrated by the studies, our dependability-oriented RE process
improves the current state of the art with regards to requirements development processes
in the dependable reactive system domain.
194
CHAPTER 11
Related Work
In this chapter, we present an overview of the literature related to the thesis. The
review includes requirements engineering (RE) approaches which address dependability attributes (primarily reliability and safety) or concerns such as non-functional requirements
(NFRs), threats to dependability by means of exceptions (also known as obstacles, negative scenarios, undesired or abnormal behaviour), means to achieve dependability (such
as fault tolerance, fault prevention, or specific mechanisms like exception handling), and
methods to assess dependability attainable by requirements. Many formal methods exist
for dependable systems, all of which are not taken into account in this review. There
might be numerous existing RE and SE approaches which might touch on an aspect of our
work such as model mapping and safety analysis, but for space reasons we concentrate on
approaches that directly address dependability during requirements development only.
The related work is categorized into four groups: Section 11.1 discusses approaches
which address dependability concerns, threats, or means in requirements modelling, Section
11.2 overviews methodologies which provide process support for requirements elicitation or
for specific RE phases, Section 11.3 describes statechart-based techniques for carrying out
probability analysis of requirements, and Section 11.4 presents approaches which support
transformation of requirements models.
11.1
Dependability in Requirements Models
Although until today not much concrete work have addressed dependability, quite a
few approaches have been proposed which address representation of dependability from the
early stages of developments for various target domains. This section presents a range of
195
11.1. Dependability in Requirements Models
such approaches. Several work have considered dependability under the blanket concept
NFR while others have addressed specific concerns related to dependability such as exceptional behaviour, system failures, degraded services and outcomes, and use of different
modes of operations. Many approaches are UML-based ones. Some use UML extensions
to provide support for fault-tolerance. The extensions include mechanisms to incorporate
stereotypes, tagged values, constraints, and profiles in the model.
11.1.1
Non-Functional Requirements
Jürjens presented a UML-based method in [109] for the development of cost-effective
and dependable safety-critical systems. The approach uses the UML extension mechanisms to incorporate safety attributes in a UML models.
The mechanisms consider
crash/performance failures and value failures which may cause message loss, delay, or corruption. Several the stereotypes with associated tags and constraints are defined including
risk, crash, redundancy, critical, error handling, etc. The stereotype <<risk>>, for example, can be used to describe a risk that arises in the physical level with the tag {failure},
and <<error handling>> provides an object for handling errors in the subsystem level
and is associated with the tag {error object}. The approach also enables analysis of the
UML model with a prototypical XMI-based tool to check if it satisfies the requirements.
The tool is described in details in [109]. The goal of our work is similar to his which is
to allow developers without adequate safety (dependability in our case) background to deploy safety engineering knowledge which is made available with a standardized modelling
language or notation. The approach discussed here considers non-functional requirements
during the design phase in terms of safety. Jürgens has also proposed using UML to develop security-critical systems [110]. Previously, he has also, in collaboration with others,
described some approaches for systems development using UML which consider various
criticality requirements.
Popp and Jürjens [174] extend use cases to model requirements of security-critical
systems by extending the UMLsec [108] profile. The approach does not start with the
elicitation of use cases but works with an existing use case specification by refining the use
cases with security concerns.
Gomaa and Shin [79][196] propose an approach that aids in evolving non-secure applications to secure applications. The UML-based requirements and architecture models
196
11.1. Dependability in Requirements Models
are extended to address security concerns. The main functionality and the security functions are modeled separately to allow for better maintainability. Security requirements are
defined using use cases, and then mapped to architecture and represented with connectors.
Mylopoulos et al. [160] describe a process-oriented framework for specifying nonfunctional requirements of information systems using a goal-oriented approach. The goals
are defined using predicate logic and then decomposed and refined into goal graphs. Chung
et al. [37] presents the NFR framework which is also a goal-oriented approach but focused
on NFRs. NFRs are referred to as softgoals, “goals that need to be addressed not absolutely but in a good-enough sense” [38]. Such softgoals are usually represented in terms
of other softgoals. They use the notion of satisficing, and “a softgoal is said to satisfice
(instead of satisfy) another softgoal”. Each softgoal is associated with a label denoting
the degree of satisficing and a criticality level. The framework advocate the use of catalogues for identifying NFRs. The advantage of using a goal-oriented representation is
that the the NFRs can be refined into more concrete terms and then operationalized.The
softgoals initially defined justify the operationalization. The non-functional requirement
knowledge-base defined by Chung is included in Appendix D.
Cysneiros et al. [46] presents an interesting approach for addressing the need to capture
non-functional requirements (NFR) at the early stages of development, by integrating NFR
into conceptual models, specifically into the entity-relationship (ER) and object-oriented
(OO) models. The proposed method describes the use of the LEL (Language Extended
Lexicon), discussed in [45], and a NFR taxonomy (shown in Appendix D) to elicit the
requirements. A LEL-NFR tool is required that captures terminologies relevant to the
target field, referred to as the UoD (Universe of Discourse). This tool along with the
NFR taxonomy is used to derive the NFR knowledge-base for a particular domain. These
NFR are decomposed and represented in graphs which a slight variants of Chungs NFR
graphs [37]. Finally, the NFR are integrated into the conceptual models. In ER models, a
NFR is shown in a rectangle with the UoD labeled over it, and connected to the relevant
entity or relationship. In the OO model, NFRs are added to class diagrams by attaching
two rectangles to the right bottom of the class with the UoD name in one and the NFR
name in the other. In [46], this approach has been applied to UML, starting from use cases
to class diagrams, sequence diagrams, and collaboration diagrams.
Hill [93] presents an approach based on the work by Chung [37] for quantifying NFRs
on the basis of domain knowledge. The domain analysis and goal refinement techniques
are extended to consider performance-related NFRs.
197
11.1. Dependability in Requirements Models
Moreira et al. [156] proposes a method for representing cross-cutting quality attributes
in use case diagrams. The concerns such as security, availability relevant to the domain
are identified by analyzing the requirements. The paper does not include any details about
how the concerns can be discovered. The concerns are then weaved into the use cases and
detailed in interaction models.
Some AOM approaches have been developed that cater to requirements engineering
in general such as [176], while other specific AOM approaches exist for modelling nonfunctional software concerns (such as [77]) or dependability features (such as [177][72]).
Whittle et al. [218] focuses on representing cross cutting concerns (including non-functional
concerns) during requirements development. The issues of aspect modelling in scenariobased requirements elicitation are addressed.
11.1.2
Fault Tolerance and Exception Handling
Berlizev et al. [21][22] present CORA, an analysis method for fault-tolerant systems
that uses UML models to specify normal and abnormal system behaviour. A CORA analysis model comprises of an activity model, a domain model, and an operational model. The
activity model extends and refines the use cases described during requirements elicitation,
and expresses the system’s behavior in terms of sequence of operations, signals, deviations
and recovery. CORA activity diagrams are used to precisely specify each use case with
all deviations and possible outcomes including degraded service outcomes. The domain
model precisely defines concepts and signals manipulated by use cases and operations.
The operation model specifies in detail each system operation: informal descriptions, parameters, return values and pre/postconditions. However CORA does not address model
transformation, and no mapping algorithm is discussed.
Laibinis et al. [123] uses redundancy patterns as support for integrating fault tolerance
into use cases. They suggest refining use case diagrams with recovery measures using the
standard UML notation. They only focus on error recovery mechanisms, and do not discuss
detection techniques or requirements elicitation methods that need to be used.
De Lemos et al. [55] emphasize the separation of the treatment of requirements-related,
design-related, and implementation-related exceptions during the software life-cycle by
specifying the exceptions and their handlers in the context where faults are identified. The
description of exceptional behavior is supported by a cooperative object-oriented approach
198
11.1. Dependability in Requirements Models
that allows the representation of collaborative behavior between objects at different phases
of the software development.
Bail [14] extends usage models which are based on extended state models to allow
normal and exceptional behaviour to be specified in one model. The normal and exceptional responses are associated with a probability of occurrence. The specification enables
verification of the system to ensure that reliability requirements are satisfied. According
to Bail, the integrated model makes it possible to test both normal and exceptional behaviour at the same time and hence testing takes up less time and is more reliable. The
approach is similar to ours in the sense that we also assign probabilities of success and
failure to our events. However, [14] does not address elicitation of the requirements. He
works with a state-based specification and refines the state machine by adding states to
represent erroneous behaviour. The approach might be useful at the analysis or design
phase to uncover further design-level exceptional concerns. A shortcoming of the approach
as stated in the paper is that developers are not familiar with such methods of elicitation
which combines normal and exceptional behaviour into one model and hence they might
get confused and not not accomplish a precise specification of even the core system functionality. Our method does not interfere with the elicitation of functional behaviour since
it begins with use-case driven elaboration of functional requirements and then continues
with the development of exceptional behaviour.
Wirfs-Brock [223] presents an approach for integrating exception handling in objectoriented software development by defining the roles, responsibilities, and collaborations
of objects. The philosophy behind her work is very similar to ours. However, her approach does not include support to elicit exceptional behaviour. It provides guidance in
addressing the defined exceptional requirements and ensuring that fault-tolerance means
are integrated during design to handle the exceptions and possible system failures. The
approach complements our work on requirements development. The author distinguishes
between use cases exceptions and object exceptions, and in her approach takes the use-case
requirements (normal and exceptional) and translates it to an appropriate design solution.
The author provides guidelines to help developers delve into the design phase to uncover
possible design-level exceptions.
Cin [40] proposes an UML profile, the UML Dependability Mechanisms Profile (DMP),
for fault-tolerant real-time systems to aid in the development of dependability mechanisms.
The profile extends the UML notation by including three packages with modelling elements to specify common dependability features. He defines the Stochastic Quantitative
199
11.1. Dependability in Requirements Models
requIRement Language [39] for specification of dependability and performance concerns
using English language constructs. The SQIRL specification can then form the basis for
the evaluation of stochastic models [100] (discussed in Section 11.3.2. Similar to what we
claim, he states that it is difficult for even developers with a mathematical background
to compile correct requirements specifications using a a mathematical stochastic language.
NFRs specified in English-like structured text are unambiguous and can allow for better communication with others. [44] presents another profile for modelling reliability of
component-based systems. A profile for goal-oriented and use case-driven representation
of functional and non-functional requirements is presented in [208].
The above-mentioned profiles are not standardized UML profiles. Two noteworthy
profiles which consider non-functional concerns such as fault tolerance, QoS are the UML
Profile for Modeling QoS and Fault Tolerance Characteristics and Mechanisms [85] and the
UML Profile for Modeling and Analysis of Real-time and Embedded Systems (MARTE) [84]
(which is intended to replace the UML Profile for Schedulability, Performance and Time
(SPT) [83]).
11.1.3
Exceptional Outcomes and Modes of Operation
Degraded services and degraded modes of operation are usually not discussed and
addressed in current requirements engineering processes. Most work that incorporate such
concepts at the architecture or design phases.
Shelton and Koopman [195] consider employing alternative functionalities to complement graceful degradation techniques for attaining higher levels of dependability in distributed embedded systems. The concept is similar to what we define as degraded services.
The alternatives are integrated during system architecture by defining redundant functions
that are offered when the normal functionality cannot be provided. The proposed approach
is for integrating techniques for improvements at the architecture level.
Srivastava et al. [205] proposes a system architecture for distributed applications
which provides dynamic fault tolerance solutions based on the mode of operation. The
architecture takes into account the mode specification from a QoS perspective.
Shea and Johnson [193] discusses degraded modes of operations in the rail and air
traffic system domains. Operations are categorized as normal, abnormal, or degraded, and
key relationships between these different modes are shown. The paper is primarily focused
200
11.1. Dependability in Requirements Models
on the reasons due to which system operators attempt to continue service provision under
degraded or unsafe circumstances thus undermining system safety.
Lygeros et al. [140] presents an architecture design that addresses degraded modes
of operations of an automated highway system. The proposed architecture monitors the
system capabilities, and performs fault handling when necessary. A control hierarchy is
used, and specific control strategies for degraded modes are defined. The approach is mainly
to be used at the design phase, and does not offer guidelines that would allow developers
to consider and define such modes during requirements elicitation and specification.
Axelsson [13] proposes an UML-based approach for the development of embedded
real-time systems. In addition to integrating notions of time and derivation to model the
physical environment, he prescribes addressing possible different modes of operation by
modelling the behaviour in a particular mode as invariants in state machines.
Iliasov et al. [101] proposes the structuring of specifications of fault-tolerant systems
with modes. Modes of operation are defined formally and representations of modes in the
state-based formalism Event-B is described. According to the authors, structuring with
modes leads to better system structuring and definition of functionality. In our work,
we have introduced the notion of modes and defined a useful categorization but have not
formally modelled modes.
Lee et al. [125] advocate structuring system execution based on idealized fault-tolerant
components (IFTC) as illustrated in Fig. 12–1. An IFTC offers services that may return
replies to the component that made a service request. If a request is malformed, the
component signals this by raising an interface exception, otherwise it executes the request
and produces a reply. If an internal exception or local exception signaling an error occurs,
error processing is activated in an attempt to handle the error. If it can be dealt with,
normal processing in the component resumes; if not, the component itself signals its failure
by a failure exception.
Our system services described by use cases can be seen as IFTCs. The well-defined
outcomes correspond to the IFTCs service replies, interface and failure exceptions. In
IFTCs, though, the generic failure exception signals to the caller that the component has
failed in an uncontrolled way, i.e. there are no guarantees on the current state of the
component. In our case, failure just signals the failure of provision of the service. This is
discussed in more details in Chapter 12.
Our approach is different from the above for several reasons. We have defined several types of service outcomes and modes of operation in the context of requirements
201
11.2. Dependability-Oriented Requirements Engineering
engineering. We help the designers to elicit, specify, and analyze outcomes and modes
with a well-defined process that they can follow. We have integrated specific tasks in
our dependability-oriented requirements development process to address modes, outcomes,
and mode switching. Furthermore, we provide specific techniques to address and model
degraded outcomes and modes of operation in behavioural models. Our process also gives
support for automatic dependability analysis with tool support. The reliability and safety
levels achieved when degraded outcomes are offered can also be evaluated with the help of
DA-Charts.
11.1.4
Review
Our work sets itself apart from the work described above because we address integral concepts related to dependability in our work, and provide means to specify and
model the elements and notions. We have integrated reliability and safety concerns in all
phases of requirements development with elicitation models (use cases), assessment models
(statechart-based formalism), and specification models (activity diagrams and communication diagrams). We propose notational extensions to the models, and clearly define how the
elements in the extended dependability models can be mapped to downstream requirements
model in order to create a more formal representation of the system behaviour.
11.2
Dependability-Oriented Requirements Engineering
11.2.1
Use-Case Based Approaches
Alternate or unexpected behaviour in use cases are mentioned in earlier work including
Cockburn[43] and Schneider et al.[185]. However, not many approaches have concretely
integrated notions of service failures and dependability in RE.
According to Robertson [180], requirements engineers need to be creative and not
only base their work on what the stakeholders’ ask for. Inventing requirements makes the
difference in the product or business and gives the much needed edge over the competitors.
Along these lines, Maiden [142] argues that “many of the useful products that we take for
granted today, did not come from the stakeholders’ imagination, but from an invention”.
However, most current mainstream RE practices do not advocate creativity or highlight
inventions as being a core element of the RE process. Maiden also states that “requirements
analysts lack processes and models that can be applied to guide their creative processes”.
202
11.2. Dependability-Oriented Requirements Engineering
Our work addresses this lack in the state of the art in RE practices, and we define a
methodology that supports invention of functional and dependability requirements.
Maiden and Robertson [143][144] addressed this need for a creativity-driven approach
and proposes a scenario-driven requirements engineering process, RESCUE, for inventing
requirements using brainstorming and creativity workshops. RESCUE aids in the definition on both functional and non-functional requirements. The process is use-case based,
and the techniques such as storyboarding are used to refine the use cases. Exceptional
behaviour, such as human agent mistakes, machine failures, and interaction failures, are
defined with the help of an exceptions database which comprises of classes of abnormal
behaviour and state in socio-technical systems. The elicitation of exceptional behaviour
is somewhat limited to the contents of the database. The process was applied to an Air
Traffic Management System in [141] and most of the creativity techniques were found to be
effective, however reports on discovery of exceptional behaviour was not explicitly provided.
Sindre et al. [197][198] define misuse cases, and provide methodological support for
eliciting security requirements. Alexander [3] proposes using misuse cases to document
and analyze negative scenarios, primarily scenarios that threaten the security or safety
of the system. The paper describes concepts and modelling constructs along with tool
support that can be used for this purpose. The method is very useful and is similar to
our exceptional use cases. However, the support for eliciting and analyzing exceptional
situations is quite minimal, and requires much imagination and experience. The approach
focuses on use cases and does not extend to other requirements models. Concepts such
as degraded service outcomes or degraded operation modes in use cases are not discussed.
We on the other hand use UML-based models and provide a rigorous process to aid in
development of models for elicitation, analysis, and specification. Other researchers have
worked with misuse cases. Ebnenasir et al. [65] propose an approach based on misuse
cases for modelling of failsafe fault tolerance. The approach introduces faults in a model
and defines unsafe and at risk use cases to allow analysis.
McDermott and Fox [147] propose abuse cases which adapt use cases specifically to
address security requirements. An abuse case is a use case of a goal that might have harmful
effects in terms of security. Standard use case diagram notation is used to represent the
abuse cases which are shown separately in an abuse case diagram. Similar to our objective,
they intended to develop an approach which produced models that are easy to understand
and can serve as a means of communication between developers and customers.
203
11.2. Dependability-Oriented Requirements Engineering
Rubira et al. [182][69] present an approach that incorporates exceptional behavior in
component-based software development by extending the Catalysis method [62]. The requirements phase of Catalysis is also based on use cases, and the extension augments them
with exception handling ideas. Catalysis is a methodology for developing object-oriented
software based on the notion of components. The Catalysis method does provide a way of
representing exceptions, but does not explicitly consider the elaboration and transformation of exceptional behavior during software development. Catalysis uses a concept called
collaboration, which represents related actions between objects. The proposed approach
depends on this feature to identify the interactions occurring among components, which
are structured as idealized fault-tolerant components (IFTC) (discussed in Section 11.1.3).
The paper aims to extend Catalysis with provisions for specifying exceptional behavior
in the requirements phase, and then mapping them onto design and implementation. To
begin with, in the requirements phase exceptions are added to use-case specifications in
an informal manner. During the architecture phase, the system is structured with IFTCs
and the propagation of exceptions is clearly modeled. In the following design phase, collaborations are defined from use-cases, where the pre- and post conditions are mapped to
actions, which include refinements of the defined exceptions. A template is used to describe
the collaboration, and class hierarchies of normal and exceptional behavior are produced.
Following the design, ways to move on to implementation are suggested in [182]. Rubira et
al. identify the problem of explicitly representing exception handling in the use case specifications, and defines the need to find better solutions for integrating exceptional behaviour
in use cases. Our proposed notations and process address this issue and would very well
complement their approach. Although this approach makes use-case specification more
complex, it provides a way for achieving dependability to some extent in component-based
systems with the use of an error recovery mechanism.
Hawkins [92] proposes extending use cases and interaction diagrams for requirements
development of distributed system architectures. He provides a universal list of questions
to support elicitation of NFRs such as fault tolerance, timing, and security. The questions
are however not aimed at elaboration of application-specific concerns but rather of common
non-functional aspects of the system. Kaiya et al. [113] describe a use-case based method
for prioritizing NFRs according to associated stakeholders’.
204
11.2. Dependability-Oriented Requirements Engineering
11.2.2
Goal-Oriented Approaches
Lamsweerde [47][49] proposes the KAOS method, which is a goal-oriented approach
for requirements elaboration. It addresses quality-of-service issues, and present a high-level
approach for specifying requirements and deriving the design based on refinements. Similar
to the principles of our work, the authors stress on addressing exceptional behaviour,
defined as obstacles, during requirements engineering [213][214][212]. To begin with, goals
are elaborated using goal graphs, from which the functional requirements are derived.
Obstacles are generated from the goal specifications. The obstacles are then analyzed and
refined if needed. Strategies for resolving the obstacles are then defined, and the goal
structure is updated with the newly introduced goals. Goals and obstacles are expressed in
a formal temporal language, and thus it requires time and expertise to develop correct and
complete specifications. [214] briefly discusses informal obstacle identification but detailed
guidelines are not provided, and informal or semi-formal techniques for resolution and
elimination of obstacles are not offered. Darimont also states in his thesis [48] that one
of the weaknesses of KAOS is that the guidance provided to developers for carrying out
goal composition/decomposition is insufficient. While the KAOS process can be used in
general, DREP is defined specifically for the dependable reactive systems domain.
Anton [7] in her Ph.D. thesis presents a goal-based requirements analysis method
(GBRAM) for the specification of information systems. But her approach does not address
exceptional behaviour only goal based analysis.
Lutz and Mikulski [139] take into account changing software and consider how requirements evolve throughout the software development lifecycle of high-integrity embedded
systems. Lutz et al. [136] describe a method for identifying contigency requirements of
safety-critical autonomous systems using obstacle analysis. The work is noteworthy but
is not elaborated further here since the approach deals with evolving requirements during
the operational stage of the software, and is outside the scope of our work.
11.2.3
Failure and Hazard-Driven Approaches
Allenby and Kelly [4] present an approach for eliciting safety requirements by applying hazard analysis on scenarios. The goal is to bring together requirements identification
and hazard analysis to create a more complete specification for safety-critical systems.
The hazard identification process which is carried out with FHA (Functional Hazard Assessment) [153] and HAZOP (Hazard and Operability Study) [158][154] is extended with
205
11.2. Dependability-Oriented Requirements Engineering
support for systematically identifying failure causes. The elements of use cases which describe catastrophic failures are recorded in a table by specifying the failures along with
the type, cause and effect of each failure. Possible handling means are also analyzed using stepwise decomposition. As stated in the paper, exceptional modes of operations are
not considered and hence the failures are not completely captured. Other domain-specific
methods which combine requirements analysis and safety analysis techniques are presented
in [56], [120], [155], and [88].
Leveson [129] presents the hazard analysis approach which is used as part of the
safety-life-cycle process. The risks are realized by considering different failures classes, and
then discovering the failures in the context of the system under development based on
experience and domain knowledge. The causes of hazards are identified and analyzed by
using techniques such as fault trees. Each hazard is then assigned a criticality level and a
probability to enable risk assessment. In comparison to hazard analysis, we believe that
our approach leads to more complete specifications with respect to safety and reliability
concerns.
Fault trees [130][128] are also part of the safety-life-cycle process which comprises of
several phases starting from specification of safety requirements, to design and implementation of safety concerns of critical systems. The initial phase, hazard analysis and risk
assessment [129, 138], has goals similar to our exceptional use cases method. Hazard analysis is carried out to identify the risks, to determine the causes, and then to assess and
mitigate the risks. The analysis is based on fault trees. The risks are realized by considering different failures classes, and then discovering the failures in the context of the system
under development. The hazards are then associated with a criticality level and with the
likelihood of occurrence. Such a technique requires much experience and expertise on the
developers part. In comparison, our use-case based approach is intuitive and provides a
systematic process that allows developers to identify exceptional situations by analysing
the set of interactions between the actors and the system.
FMEA (Failure Modes and Effect Analysis) [165] is a safety analysis technique that
assess the potential failure modes and the effects of the failures. Our approach however
considers possible deviations from normal behaviour.
Lutz and Nikora [137] and Melhart and White [148] summarizes available techniques
for failure assessment and hazard analysis.
206
11.2. Dependability-Oriented Requirements Engineering
11.2.4
Other Approaches
The B formal method [1] covers the development process from the specification to
the implementation phase and is based on a mathematical model of set theory and first
order logic. The method mainly comprises two activities: writing formal texts and proving
the texts. The process evolves from specification to coding using a series of refinements.
The methodology has been used for developing error-free software for critical systems by
focusing on traceability of safety-related constraints. The method is supported by the tools
B-Toolkit and Atelier-B. Modeling tools (B4free), editors, and parsers are also available for
B. The method does not have elicitation support and like most formal methods requires
expertise and background knowledge.
Donzelli and Basili [61][17] propose a framework, UMD (Unified Model of Dependability) for elicitation and analysis of dependability requirements. The framework includes
invariant concepts (issue, scope, and event), semi-invariant concepts (mapping issue to
failure or hazard), and customizable concepts (failure hazards, events classes). Elicitation is carried out based on these UMD concepts, and dependability can be assessed with
measurement models provided as part of UMD. Based on the assessment, refinements can
be performed based on a classification scheme of handling techniques: warning services,
alternative services, mitigation services, recovery behaviour, or occurrence reduction. The
UMD structure is similar to our process model, however UMD only provides a framework
and no process support.
Kaâniche et al. [114][112][111] proposes a dependability-explicit model for the development of critical systems. The authors identify three types of processes which need to
interact and hence is integrated into a single model: the system creation process, the
dependability process, and other supporting processes (e.g., quality assurance and certification). The system creation process includes the traditional development phases: requirements, design, realization, and integration. The dependability process activities, fault
prevention, fault tolerance, fault removal, and fault forecasting, are merged into the development lifecycle. Checklists are provided that detail the activities that are to be carried out
at each phase. During the requirements phase, the additional tasks that need to be carried
out as part of fault prevention include selecting development environment formalisms and
tools, and project planning and risk assessment. Fault tolerance activities involve defining
the system behaviour in the presence of faults including identifying associated dependability attributes, degraded modes of operation, and the failures to be tolerated. Similar
207
11.2. Dependability-Oriented Requirements Engineering
to our work, the objective of the framework is to ensure that dependability concerns are
addressed during software development. However, only a general structure is provided and
no detailed phase-specific guidelines are available to help the developers.
TIRAN (TaIlorable fault toleRANce frameworks for embedded applications) [30][59]
can be used as a cost-effective solution for developing dependable energy and transportation embedded automation systems. It provides user support in the form of a methodology,
which guides users to consider fault tolerance from the early software development stages.
The framework aims to solve problems in fault-affected applications by considering error detection, isolation and recovery, reconfiguration and graceful degradation. The methodology
is used for collecting, specifying, and validating FT requirements, with a characterization
of framework elements, and guidelines for using the framework [209][210][211]. The specification of fault tolerance is based on UML and TRIO (Tempo Reale ImplicitO) temporal
logic, which has been developed by ENEL specifically for real-time systems. The TIRAN
approach concentrates on the computational aspects of achieving dependability. It considers intra-site connections only and assumes a reliable communication. The soft real-time
support available in TIRAN is not adequate for all processes and it also lacks support
for quality-of-service (QoS) levels. can be used as a cost-effective solution for developing
dependable automation systems. It provides user support in the form of a methodology,
which guides users to consider fault tolerance from the early software development stages.
The DepAuDE (Dependability for embedded Automation systems in Dynamic Environments) project [57][58] was developed which aimed to develop a framework which
satisfied the shortcomings in TIRAN. It has been developed primarily for two target application areas: monitoring/control of energy transport and distribution, and distributed
embedded systems. The framework provides methodology support similar to that outlined
in TIRAN, with the inclusion of inter-site communication features for specification, validation, and modeling of requirements. It aims at addressing and tolerating physical faults
and malicious faults.
The TARDIS (Timely and Reliable Distributed Information Systems) [134] is an architectural design framework targeted towards avionics, process control, military, and safety
critical applications. It was developed with the intention of creating a framework which
considered non-functional requirements and implementation constraints from the early
stages of software development. The framework takes into account three categories of
non-functional requirements: dependability, timeliness, and dynamic change management.
However, it does not provide support for requirements specification. [70] describes with an
208
11.3. Model-based Dependability Assessment
example how TARDIS can be applied together with a software development method, which
uses the specification language Z, to develop a real-time data acquisition and display system. Z is extended to consider non-functional requirements, and the real-time logic (RTL)
is used as the notation to define the target environment.
The frameworks TIRAN and DepAuDE are two significant contributions to the development of dependable systems, but cater to a specific domain. The TARDIS project
provides a general high-level design framework that addresses various non-functional requirements, but does not define a step-by-step development process.
11.2.5
Review
Our approach is different from the above for several reasons. Firstly, we help the requirements engineers to elicit, specify, analyze, and refine dependability issues, exceptions
and handlers with a well-defined process that they can follow. DREP focuses on reliability
and safety concerns specifically, and guides analysts to develop a requirements specification document that exhaustively addresses dependability expectations of the stakeholders.
Without a process, the only way a developer can discover exceptions and define recovery
measures is based on only his imagination and experience. Secondly, our process increases
dependability by helping the developers detect the need for adding “feedback” and “acknowledgement” interaction steps to counter communication problems. Additionally, the
process recommends adding hardware to monitor request execution of secondary actors
when necessary. Our handler use cases are stand-alone, clearly separate exceptional behavior from standard behavior, and can be associated with multiple exceptions and multiple
contexts. DREP also gives support for automatic dependability analysis with tool support.
The process is based on semi-formal constructs, and developers do not require expertise in
formal specification languages to define or determine the quality of their requirements. In
addition, communicating with end-users is simpler with use cases.
11.3
Model-based Dependability Assessment
Research has been carried out on analyzing quality of requirements mostly using formal
requirements specification, that is, requirements written in specification languages, and
model checking techniques.
209
11.3. Model-based Dependability Assessment
11.3.1
Probabilistic Statecharts
Jansen et al. [107] proposed a probabilistic extension to statecharts, P-Statecharts,
to aid in formal verification of probabilistic temporal properties. The probability concept in P-Statecharts has two facets: environmental randomness and system randomness.
In our work, we focus on dependable systems in which randomness only comes from the
environment the system is exposed to, rather than from the system itself. Unlike their
formalism, DA-Charts allows different actions to be taken (events to be broadcast) depending on the probabilistically chosen target state, not just on the event which initiates
the transition. Based on the work in [107], the StoCharts approach was later proposed
which extends UML-statecharts with probabilities and stochastic timing features to allow
for QoS modelling and analysis.
Vijaykumar et al. [215] proposed using a probabilistic statechart-based formalism to
represent performance models. The model specified using statecharts is used to generate
a Markov chain from which steady-state probabilities are obtained. Their approach is
concerned with evaluating general performance of models, such as system productivity.
Addouche et al. [2] proposed DAMRTS (Dependability Analysis Models for RealTime Systems) which is an extension of the Schedulability Performance and Time (SPT)
UML profile. It was proposed to help in the specification of real-time systems properties to
allow dependability analysis. Semi-formal techniques have been used for modelling static
and dynamic behaviour. In DAMRTS, the requirements development is carried out using
the following steps: resource identification, malfunctions analysis with fault trees, static
modelling using class diagrams, and dynamic modelling with collaboration diagrams and
extended UML statecharts. The authors have extended statecharts with real-time and
probabilistic aspects. The UML models are then translated to probabilistic time automata
and temporal logic, in order to carry out verification by probabilistic model checking.
Formal semantics are defined for this purpose. Their probabilistic statechart model is
similar to what we propose, however the analysis techniques we use are different. The aim
of the DAMRTS work is primarily to enable verification of probabilistic temporal properties
of dependable real-time systems.
11.3.2
Dependability Analysis
Blum et al. [25] presents the System Availability Estimator (SAVE) package that is
used to build and analyze models to enable prediction of dependability constraints. A
210
11.3. Model-based Dependability Assessment
SAVE model is constructed as a collection of components, each of which can be subject to
failure and repair. The high-level model is then automatically transformed to a Markov
chain model.
Bavuso et al. [19] introduce the Hybrid Automated Reliability Predictor (HARP)
tool developed for prediction of reliability and availability of fault-tolerant architectures.
It is Markov model-based, and provides support for coverage modelling and automatic
conversion of fault trees to Markov models.
Dugan et al. [63] proposes dynamic fault trees which are an extension of fault trees.
Dynamic fault trees are mainly used for analyzing architectural reliability. They include
constructs that allow analysis of systems in which fault tolerance schemes such as redundancy are applied. Expertise in dynamic fault trees is necessary to be able to construct
complex and correct models. However, use cases do not require high-levels of expertise
[146]. They are very intuitive, and hence can be understood by non-technical people as
well. The DA-Charts are also more appropriate in our context, because they can be used to
simulate use case interactions in normal and exceptional scenarios. Our approach is meant
to be used at the requirements level to design, analyze, and improve system specification
once high level hardware design decisions have been made. Dynamic fault trees on the
other hand address design-level issues, such as redundancy, comparing efficiency of cold
spare vs. hot spare, etc..
Cin et al. [41][100] describes a quantitative dependability analysis approach targeting embedded systems. The system behaviour is specified with guarded statechart models
and then mapped to timed, stochastic petri nets to carry out performance evaluation.
The work on dependability evaluation of UML-based designs was carried out under the
European ESPRIT project HIDE (High-levek Integrated Design Environment for Dependability) [26][27]. The main goal of the project was to provide designers with a technique
that allows UML-based specification of dependability, automatic translation of the models to evaluation models, and dependability analysis with the use of formal verification,
quantitative, and timeliness analysis tools. The evaluation results help in making design
decisions and in carrying out design refinements.
11.3.3
Model Checking
Bianco et al. [23] presents an approach for reasoning about reliability and performance
of probabilistic and nondeterministic systems using temporal logics for formal specification
211
11.4. Model Transformation
of system properties and model-checking algorithms for verifying that the system satisfies
the specification. Automatic verification of probabilistic systems using techniques of model
checking are also covered in [94].
Atlee et al. [10] demonstrates a model-checking technique used to verify safety properties of event-driven systems. The formal requirements are transformed to state-based
structures, and then analyzed using a state-based model checker.
The above approaches all depend of formal specifications, and analyses the system
developed to verify whether the specification is satisfied. We, on the other hand, work
solely at the requirements level to determine whether the requirements specification is
adequate and can satisfy the dependability concerns.
11.3.4
Review
Our approach is different in the sense that we begin with informal requirements specification, namely use cases, apply a model-driven process to map the requirements to
statecharts for the purpose of evaluating the safety and reliability achieved by the system,
followed by revisiting and refining the use cases if necessary. Developers do not require
expertise in specification languages to determine the quality of their requirements. Also,
communicating with end-users is simpler with use cases. The probability analysis is completely automated and allows quick generation of dependability-related statistics. Our
model-based assessment is similar to model-checking since we attempt to verify that dependability constraints hold. However, the goal of our work is to evaluate and refine the
requirements of the system, and model analysis is carried out only to serve this purpose.
11.4
Model Transformation
Whittle et al. [219][220] propose use case charts which are based on extended activity
diagrams used for specifying use cases. Algorithms are presented that transform use case
charts into a set of hierarchical state machines which then can be used for simulation,
test generation and validation. The core of the algorithm is the synthesis of hierarchical
state machines from a sequence diagram. The approach does not address dependability
concerns, and does not provide techniques for analysis of quality requirements.
Somé [199] [201] describe an approach for generating state models from use cases in
order to enable early simulation of requirements. An algorithm is defined in [199] that
212
11.4. Model Transformation
maps in a step-wise manner each use case step to states and transitions in the FSM.
An environment is available as part of the approach that allows edition, integration, and
state-machine based simulation of use cases [200].
Gutiérrez et al. [86] propose a method for representing functional requirements by
automatically transforming use cases to activity diagrams. The textual use case requirements are mapped to basic activity diagrams. Almendros-Jiménez and Iribarne [5] present
a method to describe use case-based functional requirements with activity charts. The
source models are use case diagrams and therefore their method is restricted to modelling
sequences of use cases and not the behaviour of each. Similarly, Baudry et al. [18] use
graphical use cases to model requirements. They developed a requirements metamodel,
and a transformation definition in Kermata to allow generation of an executable model.
Besides these, other approaches exist that map scenarios to sequence diagrams and statecharts.
In order to create a more formal representation of the requirements, use cases have been
mapped to sequence diagrams with semi-automatic translations [131] and with automated
transformations [207]. Use cases have also been mapped to Petri Nets in [126]. Reverse
engineering to use cases from other behavioural models have also been addressed in [135]
and [207]. None of these approaches are however dependability-aware and do not consider
any notion of abnormal interactions or exceptions in the mapping.
Dwaikat and Parisi-Presicce [64] provides a mechanism to describe misuse cases [3] in
communication diagrams. The negative scenarios are flagged in the interaction diagrams
using a simple syntactical extension ([out=BAD]: error). The intention is to highlight
such issues so that they can be addressed during detailed design and implementation. The
mapping is minimal and no transformation rules are defined in the paper.
Formalization of use cases by mapping them onto more detailed behavioural models
has been addressed in several research works such as in [178]. However, the approaches
seldom address dependability concerns and provide explicit mapping rules and guidelines.
Our approach is different since we focus on requirements of dependable systems and
hence use dependability-focused behavioural models. Our transformation is also exceptionaware, and the defined rules address functional requirements and dependability concerns
by taking into account exceptional behaviour and exceptional outcomes. As a result the
activity diagrams, state machines, and communication diagrams developed have notions of
exceptions and handlers integrated in them.
213
11.5. Summary
11.5
Summary
While NFRs, dependability, fault tolerance, exception handling, abnormal behaviour
and scenarios have been considered widely in requirements modelling, little to no support is
available in the current literature for discovery and elaboration of requirements. No matter
how effective and precise the modelling techniques are, it is essential to first understand
what needs to be modelled and only then it makes sense to focus on how it can be modelled.
In particular, exception handling in RE is usually not addressed since it is viewed as an
architectural and design level concern.
Many rigorous formal methods exist for dependable systems, but they are not taken
into account in this review since our goal is to define a semi-formal model-driven requirements engineering process. There are numerous existing RE and SE approaches which
might touch on an aspect of our work but we have only reported those approaches which
are directly associated with our work or which have addressed dependability attributes,
threats, and means during requirements development. Research work (software development approaches, methods, process, techniques, frameworks, and middleware) in the
dependability field spanning the remaining phases of the lifecycle are overviewed in [159].
Hurlbut [99] provides a comprehensive survey of approaches for describing and formalizing
use cases. [36] and [162] presents the state of the art in RE, and also discusses research
directions. France [72][73] overviews model-driven development research work, discusses
the need for associating MDE and SE, and elaborates on possible future research in the
area.
Finally, the survey shows that there is a need for process-oriented approaches that
treat dependability as an integral part of requirements development.
214
CHAPTER 12
Conclusion
If the automobile had followed the same development cycle as the computer, a
Rolls-Royce would today cost $100, get a million miles per gallon, and explode
once a year, killing everyone inside. – Robert X. Cringely
We believe that the same follows for dependable systems, and that employing a suitable
development method is imperative for the success of such systems. The motivation of the
work in this thesis is to assist developers in defining the requirements of reliable and safe
reactive systems.
This chapter is divided into three sections: Section 12.1 provides a summary of the
contributions of this thesis, Section 12.2 discusses the advantages and limitations of our
work, and finally Section 12.3 outlines possible future directions of research.
12.1
Summary of Contributions
The central contribution of this thesis is a model-driven requirements development
method for reactive systems that systematically guides developers in creating more dependable systems. The main objective of this thesis was to improve the state-of-the-art of
requirements engineering approaches for dependable systems.
We presented DREP, a dependability-driven requirements engineering process for reactive systems, that introduces concepts that need to be taken into account when developing
dependable systems, in particular services and outcomes, dependability attributes, exceptions, recovery measures, exceptional service outcomes, different modes of operations, and
probabilistic behaviour of external agents. We then explore how the dependability concerns
215
12.1. Summary of Contributions
and means associated to system safety and reliability can be integrated into UML-based
requirements models in particular into use cases, activity diagrams, and communication
diagrams. Use cases drive our elicitation process, activity diagrams provide a more formal
front to represent requirements, and communication diagrams give a view of the system
boundaries. We discuss how we extend the UML meta-model when required to integrate
exceptions and handlers. The concepts and models are then put into context by defining a
requirements engineering process catered towards dependable reactive systems. The iterative process, DREP, is a task-based process comprising of several phases beginning with
elicitation, then moving on to specification using our extended UML-based models, followed
by assessment using DA-Charts of the dependability offered by the specification, leading
to refinement of the specification based on the assessment results, and finally ending with
a requirements summary which includes an exceptional use case diagram, exception table,
mode table, activity diagrams, and a communication diagram. As part of the process, we
provide tool support for modelling and analyzing our probabilistic statecharts, DA-Charts.
We define transformation rules to allow use case models to be mapped to downstream
assessment models and specification models.
The work in this thesis is applied to three case studies: the Elevator Control System,
the 407 Express Toll Route System, and the Crisis Management System. Our initial claims
of completeness, acceptability, and applicability are validated using the three case studies.
The initial exploratory studies with the ECS, followed by the experiments carried out with
the 407 ETR System in an academic setting, and then working with a real-world system
(CMS), allowed us to build a weight of evidence to support our claims. The validation
results show that the proposed approach assists developers in discovering errors and in
defining handling measures in order to avoid service failures, leading to improved system
dependability, and ultimately to a reduction in development time and cost.
Although the work is still at an early stage, a dependability-oriented RE process shows
promise, and based on our experience we have high confidence that it would be of much
benefit in industrial projects.
216
12.2. Critical Review
12.2
Critical Review
12.2.1
Discussion
Our vision was to create a requirements development method that can be used in
practice by mainstream designers and developers without necessarily a degree in math or
computer science. As stated by Parnas, “requirements in mathematical language are no
use unless they are easier to read than the code”. A lot of developers are actually deterred
from considering dependability during early development since most existing processes are
too formal to be in their grasp. Those who use the methods without the required expertise
in most cases end up making many mistakes, and the rest are too intimidated to use them.
This is due to the fact that software engineering industry professionals lack education and
expertise in the area of formal methods. Complex mathematical notations make it difficult
to read and comprehend formal specifications. Resources need to be invested in educating
these professionals, which lead to higher development costs and time. Formal specifications
need to be evaluated either manually or automatically using correctness proofs which tend
to be resource-intensive. Even with tool support, it is essential to ensure that the tools
are error-free in order to produce a correct specification. While it is difficult to integrate
formal methods in the entire development lifecycle, developers can choose to use them in
tasks when necessary.
The above is however not judgement against formal methods. They are indeed of great
use and in some cases are irreplaceable. However, it remains they are not accessible by the
majority of practitioners. These developers then tend to use ad-hoc techniques, notations,
or means to build an application, which is not the product of a well though-out process
and can be crippled in many ways.
In our approach, we apply fault tolerance and fault prevention means at a higher
level of abstraction. Usually such means are used at the design and implementation levels for formal verification, exception handling, checkpointing, rollbacks, redundancy, etc..
However most of these techniques are not applicable at the early stages when the system
details are not known and the system does not even exist. The purpose of requirements
development is to define the problem within its domain and this implies defining what the
system is expected to do. In other words, we define the behaviour of the system. While
defining the system behaviour, we try to uncover the unexpected. In some ways this results
in preventing service failures in the running system (fault prevention). We also attempt
217
12.2. Critical Review
to identify abnormal situations that can crop up, and incorporate means in the system
behaviour such that when something unexpected or unavoidable occurs, the system is prepared and “knowledgeable” enough to handle it and avoid complete service failures (fault
tolerance).
Fault tolerance is different from fault prevention, and involves “acting on the effects
and not on the causes”. This is not due to faults arising at the design and manufacturing
stages which would lead to integration of common fault tolerance techniques such as redundancy, nor is it due to faults in the specification, but it is to address failures which are
unavoidable and “to prevent the appearance of a failure” [76] by offering degraded services
or alternate services to keep the users happy or partially satisfied. The main intent is to ensure that the system can continue functioning in a reasonable manner despite breakdowns
or problems. In this work, we use exception handling as the means to achieve fault tolerance. We however do not consider exception handling in the same light as programmers.
Instead exception handling is viewed at a much higher level of abstraction appropriate
for requirements development, and is addressed in order to identify and handle abnormal
system behaviour.
Fault prevention aims to avoid incompleteness and ensures that the specification is
non-ambiguous. Our elicitation process aims to achieve the first property by ensuring that
the requirements are complete with respect to a particular application domain. Use cases
are employed for this purpose to aid in the brainstorming and discovery process. Next is the
non-ambiguous property. Since use cases are often viewed by many as being ambiguous (we
do claim though that our use cases are structured and readable), we use activity diagrams
to represent the system behaviour in a more precise and unambiguous manner. The main
point of having a complete and non-ambiguous requirements document is to ensure that
suitable feedback can be received from the stakeholders and users, to ensure that everyone
is on the same page, to ensure that unnecessary rework is not required later, and hence
to reduce both development time and cost. Writing a formal specification at this point
is not very helpful, since majority of the client base are unfamiliar with such techniques
and languages. Using a semi-formal method, ideally diagrams and text where necessary,
is the perfect method for getting through to clients and ensuring that the right meaning
is put across, and that the clients actually understand what there is to understand. The
semi-formal specification can be mapped to a formal specification later on or prior to design
if it is necessary to carry out formal verification.
218
12.2. Critical Review
In addition to ensuring that the clients understand the system behaviour design, it is
important to be able to evaluate whether the requirements will actually fulfill the client’s
dependability needs (to satisfy the dependable criteria). We propose DA-Charts for this
purpose which will ideally be automatically created, and executing the assessment shows
clients what level of dependability is attainable by the specification. If the result is not
satisfactory, the designers with cues from the clients go back to the grind, and work on
creating the next iteration of the specification till it is acceptable to the user.
12.2.2
Advantages
As discussed in Chapter 3, our approach can be used on its own to design dependability
requirements of a system or it can complement other software development methods which
do not provide adequate support for requirements engineering.
We envisioned to develop a methodology that can be used by software engineers,
without much expertise in the field of dependable systems or background knowledge in
specialized languages and notations used in formal methods. To that aim, we have used
semi-formal modelling formalisms throughout our process to offer a process that is usable
and applicable, one that developers can easily comprehend and are not wary of using in
their projects. The process ensures that the designers take into account various notions
that might come up in such systems such as exceptional goals, exceptional actors, degraded
outcomes, and degraded modes of operations, and integrate means to address such concerns.
The dependability analysis using markov chains is carried out in a transparent manner.
The designer does not need to be conversant with markov chains. Once the use cases are
mapped to the assessment charts, just pressing a button executes the probability analysis
and provides the dependability numbers to the designer.
The designer also has the option of only using the requirements elicitation process
without going into the assessment task. While we believe that our notations and techniques
can be applied most effectively if they are used as part of DREP, it is also possible to employ
our dependability-aware modelling formalisms with our syntactic and semantic extensions
are part of other approaches.
Our proposed approach is illustrated using case studies from several domains. The
cases can be used as exemplars and allows developers to learn by example and understand
how our process can be applied.
219
12.3. Future Work
12.2.3
Limitations
Like Brooks argues in [32] that there is no one silver bullet, it would be unreasonable
to believe that one approach can do it all.
Our approach is limited to the reactive system target domain. DREP does not cater to
data-intensive systems and transformational systems. We cannot make any claims about
the effectiveness of our process in such contexts.
We have not carried out any cost-effectiveness studies and it still needs to be established whether the cost of using DREP is indeed feasible. This would however differ from
system to system. For systems in which dependability is a crucial factor, stakeholders are
more ready to accept the cost factor associated with using fault tolerance techniques.
Our requirements elicitation process is primarily use case-driven. We use other formalisms only to create specification models. This might be an issue for developers who
would prefer using some other scenario modelling formalism instead of use cases. However,
we believe that use cases are an ideal way to begin discovering and defining requirements
since it helps in defining initial goals and services in the systems and in detailing the system
interactions.
12.3
Future Work
We conclude this thesis by discussing possible extensions to this work.
12.3.1
Design Models
Currently our process is strictly in the RE domain and does not provide support for
the other life cycle phases. One of the most useful extensions to our work would be to
continue our process of integrating dependability into software development by mapping
the dependability requirements to architecture and design models. This might require the
structural UML models, such as class diagrams, deployment diagrams, and component
diagrams to be extended with exception handling constructs. Some research has been
carried out in this direction, and [194] outlines possible ways of integrating exceptions
into Fondue operation schemas and concept models.
Mapping the requirements and analysis models to design models allows concrete fault
tolerance mechanisms to be integrated into the design to ensure that the dependability
concerns defined as part of the requirements are satisfied by the design. Model-based
220
12.3. Future
this by raising an interface exception, otherwise it executes the request and produces a
reply. If an internal exception or local exception signaling an error occurs, error processing is activated in an attempt to handle the error. If it can be dealt with, normal processing in the component resumes; if not, the component itself signals its failure by a
failure exception. It is immaterial whether exceptions are true exceptions in the sense
of exceptions provided by programming languages or are indicated using exceptional
replies to requests. It is even possible that some entity external to the system compoWork
nent observes its failure and initiates appropriate error processing in the users of the
component.
Service
Request
Interface
Exception
Reply
Failure
Exception
Local Exception
Normal Processing
Error Processing
Return to normal
Service
Request
Interface
Exception
Reply
Failure
Exception
Fig. 4: Idealized Fault-Tolerant Component
Figure 12–1: Idealized Fault-Tolerant Component
2.6 Classification of Concurrent Systems
The subsequent parts of the paper present and review the most commonly used soft-
techniques can beware
used
again
at this
phase
ensure
the
expected dependability
faultonce
tolerance
techniques,
classified
based to
on the
differentthat
forms of
concurrency
they support: sequential techniques, independent or loosely-coupled concurrent tech-
levels are maintained.
Although
this is out
of the
scope
of this
thesis, we spent some
niques, competitiveand collaborative
concurrent
techniques,
and hybrid
techniques.
time looking into 3model-driven
fault-tolerant system design, and the work is presented in
Sequential Techniques
[227][228].
3.1 Robust Software
Robust software is often not considered part of software fault tolerance, since it does
not use any for of redundancy. However, it represents the base for achieving any form
12.3.2 Idealized
Fault-Tolerant Components in Requirements Engineering
of dependability.
Robustness is defined as “the extent to which software can continue to operate cordespite the
introduction of invalid
inputs” [8]. Invalid
inputs must
be defined
in in Section 11.1.3
We discussed rectly
idealized
fault-tolerant
components
(IFTC)
[125]
earlier
the specification. They include out of range inputs, inputs of the wrong type or format,
inputs,
wrong sequencing
of input,
and violations
of pre-conditions.
of Chapter 11. A corrupted
software
system
designed
using
the IFTC
approach is split into a set of
Upon detection of such invalid input, several optional courses of action may be
components with taken:
well-defined
interfaces
boundaries
asacceptable
illustrated
requesting new
input from theand
input source,
using the last
value, orin Fig. 12–1. The
using a pre-defined default value.
exception propagation can be clearly modelled using this technique. It is possible to integrate the same ideas in DREP to be better able to structure the system requirements
by having a clear separation between normal and exceptional behaviour. This also allows
critical components to be identified easily, and dependability improvements to be focused
on such components. At the requirements level, the services offered by the use cases and
the outcome of each along with the exceptions and handlers can be viewed as IFTCs. Our
activity diagrams can also be seen as hierarchical IFTCs with each subactivity representing
an IFTC.
We have explored a little in this direction and in this section we draw a parallel between
our way of addressing exceptions in use case-based requirements engineering and IFTCs.
We state how each of the elements in an IFTC (identified in Fig. 12–1) would be viewed
at the requirements level in our use case-based approach.
Our system services described by use cases can be seen as IFTCs.
• Service request refers to a request for a service to satisfy a user goal.
221
12.3. Future Work
• Reply in our case refers to the outcomes of the use case (success, abandoned, degraded, and failure) which correspond to the IFTC service reply. Further questions
that need to be investigated however come up in this regard: Could the exception
also be mapped to reply? Is it that any response from the component, be it a success
outcome or an exception, can be seen as a reply? In the latter case, only when the
component is incapable of producing a reply (in a defined manner), an exception
would be signaled.
• Local exception refers to the service-related exception which triggers the switch to
error processing, i.e. invokes the handlers.
• Interface exception in RE needs to be considered carefully. One concern that
comes to mind is whether interface exceptions actually apply at the use-case level.
We do not consider exceptions due to incorrect request types or incorrect data being
passed. From another point of view, if we think of it as being associated with invalid
service requests then we could say that if a request is made for a service not currently
available (or not offered in the current mode) then we could signal an exception
and inform the user of this. The system however could also be designed such that
unavailable services are not even offered and hence there would be no invalid service
requests.
• Failure exception in our work also needs studied further. In our case, if a handler
is unable to recover from an exceptional situation (or if no handlers are defined for
the purpose), then we signal an exception to the calling use case and end in the outcome failure. If we go by the definition by Lee and Anderson [125] that when normal
activity cannot be resumed the ideal component must signal a failure exception as
indication of normal service being unavailable, then it seems our service-related exceptions correspond to failure exceptions. However, some view failure exceptions in
IFTCs to focus on exceptions signaled to the caller when the component fails in an
uncontrolled way and there are no guarantees on the current state of the component.
The latter case does not match with our ideas since we focus on providing means for
eliciting unforeseen situations that might affect the dependability of the system, and
do not consider unanticipated design faults. Instead of redefining the failure outcome,
one solution would be to define a new failure exception, service failure exception, that
signals the failure to provide the service.
Figure 12–2 shows how our concepts and approach fit with the IFTC approach. The
approach is nested. One IFTC that represents the System includes IFTCs that represent
222
12.3. Future Work
Normal Mode
service success degraded failure
request outcome outcome outcome
interface
exception
failure
exception
service success degraded failure
request outcome outcome outcome
service-related exception
Normal
Processing
Exceptional Mode
context-affecting exception
failure
exception
service-related exception
Exception
Handling
Normal
Processing
recovery
service success degraded failure
request outcome outcome outcome
interface
exception
Exception
Handling
recovery
interface
exception
failure
exception
service success degraded failure
request outcome outcome outcome
recovery
interface
exception
failure
exception
Figure 12–2: Idealized Fault-Tolerant Component in Requirements Engineering
use cases and sub-use cases. Exceptions in sub-use cases (components) are signalled to
higher level or user-goal level use cases. Unlike IFTCs, since our components represent use
cases, requirements-level IFTCs do not have states. Further investigation in this direction
is necessary in order to integrate the concept of IFTCs into DREP in a similar way that
what has been done with exceptions. This would ultimately allow the developer to clearly
define error confinement regions.
12.3.3
Priorities in Use Cases
There are some outstanding issues that need to be addressed as part of the process
of integrating dependability in use case-based requirements elicitation. To begin with,
we need to take into account concurrent exceptions. In DREP, we focused on defining
recovery measures that address individual exceptional situations. The possibility of several
exceptions occurring simultaneously were not taken into account. In such a situation, it
is important to decide on the most appropriate handling means. In order to determine
which situation is more important than the other, the general question of safety versus
reliability is of importance and can give the developer a first indication on how to handle
the situation. Priority can be defined by specifying trade-offs between reliability and safety.
Where safety is of greater importance than reliability, safety-related goals and interactions
can be given a higher priority than reliability-related ones.
223
12.3. Future Work
Another way of resolving concurrent exceptions is by assigning priorities to the exceptions. To this aim, we would have to extend the use case model in order to represent
priorities in use cases. It might be the case that more than one context-affecting exception
can attempt to interrupt service at the same time. For example, in the elevator system,
a user emergency request and an emergency fire override request might occur at the same
time. It might also be that while a user emergency request is being executed (which requires the elevator to temporarily suspend operation), the system receives an emergency
fire override request. In such a case, it is important to know which goal has a higher priority. Such requirements need to be analyzed, and goals need to be prioritized according
to the stakeholders needs. The priority also depends on the criticality of the exceptional
situation.
The priorities can be defined by using the three step technique outlined here. Tables 12–1, 12–2, and 12–3 show the priority tables for TakeElevator in the ECS. All the
exceptions that can occur during the execution of the ElevatorArrival subgoal are listed
in the tables. The exceptions can be taken from the use case diagram or found in the
exception table.
The first table is used to determine the possibility of concurrent exceptions. In Table 12–1, redundant entries are marked with a hyphen (-), if two exceptions can occur
concurrently the entry is marked with a tick (/), and for exceptions which cannot occur
concurrently the entry is marked with a cross (X).
The second table defines the criticality level (critical, high, medium, low) of the situation when two exceptions occur concurrently. In Table 12–2, the combinations which are
not applicable are marked with N/A (shown with - in the previous table), the exceptions
which cannot occur concurrently are shown as Nil (no priority), and otherwise a criticality
level is assigned.
The third table assigns priority to the exceptions by specifying which exception is to
be given a higher priority in such a situation. In Table 12–3, exceptions are prioritized
in cases where concurrent exceptions are applicable. Other circumstances needs to be
explored, such as situations when two exceptions occur at the same time. The resulting
situation might even be so critical that the developer is required to define a new handler
that can address it.
The method outlined needs to be extended to consider multiple concurrent exceptions.
It would be interesting to explore alternate techniques used in the exception handling
community in order to define a suitable approach for assigning priorities in requirements.
224
12.3. Future Work
Table 12–1: ECS: Priority Table 1
EO
ES
DSO
DSOTL
MF
ESTL
EO
/
/
/
/
/
ES
/
X
X
/
/
DSO
/
X
/
/
DSOTL
/
X
/
/
MF
/
/
/
/
-
ESTL
/
/
/
/
-
EO: EmergencyOverride, ES: EmergencyStop, DSO: DoorStuckOpen, DSOTL: DoorStuckOpenTooLong,
MF: MotorFailure, ESTL: ElevatorStoppedTooLong
Table 12–2: ECS: Priority Table 2
EO
ES
DSO
DSOTL
MF
ESTL
EO
N/A
Critical
Critical
Critical
Critical
Critical
ES
High
N/A
N/A
Nil
High
NP
DSO
High
Nil
N/A
N/A
Med
N/A
DSOTL
Critical
Nil
Nil
N/A
Med
N/A
MF
High
Med
Nil
Nil
N/A
N/A
ESTL
Critical
Med
Nil
Nil
N/A
N/A
EO: EmergencyOverride, ES: EmergencyStop, DSO: DoorStuckOpen, DSOTL: DoorStuckOpenTooLong,
MF: MotorFailure, ESTL: ElevatorStoppedTooLong
Table 12–3: ECS: Priority Table 3
EO
ES
DSO
DSOTL
MF
ESTL
EO
EO
EO
EO
MF
ESTL
ES
EO
ES
ES
DSO
DSO
-
DSOTL
DSOTL
-
MF
MF
ES
-
ESTL
ESTL
ES
-
EO: EmergencyOverride, ES: EmergencyStop, DSO: DoorStuckOpen, DSOTL: DoorStuckOpenTooLong,
MF: MotorFailure, ESTL: ElevatorStoppedTooLong
12.3.4
Formalizing Reliability and Safety
Currently in our approach, we quantify reliability of a component using the success
or failure probability, which is the likelihood that the system succeeds or fails when a
service request is made. This is essentially the probability of failure on demand (POFOD).
For example, a POFOD of 0.01 implies that 1 in 100 service requests maybe result in
failure. However other metrics can be used to define reliability: MTTF (mean time to
failure), ROCOF (rate of failure occurrence), and AVAIL (availability) [202]. The type
of the system is a factor in determining the metric to use. Hardware reliability is often
specified with MTTF, which is the operational lifetime of a component. Since hardware
225
12.3. Future Work
failures are usually permanent in nature, the availability of a component also needs to be
considered. AVAIL is defined by the mean time to repair or replace (MTTR) a component.
The MTTF, AVAIL, and ROCOF metrics are measured with time units. Therefore, there
is a need to integrate the notion of time in our reliability definition and analysis technique
to be able to cater to various kinds of reactive systems.
12.3.5
Integrating Timeliness Concerns
Both reliability and safety are associated to timeliness. In case of real-time systems, a
system can be said to be reliable or safe if it satisfies user requests and handles exceptional
situations, and does so within a desired time frame. Hence the notion of time and deadlines
need to be integrated in our dependability analysis technique to be able to address concerns
in real-time systems.
As a possible intermediate step in our process, we have briefly looked into the integration of sequence diagrams in our process, which is a very suitable formalism for representing
timeliness concerns. The lack of hierarchy and interruptible regions in sequence diagrams
however make the model complex to visualize. It is also necessary to extend the syntax
and semantics of sequence diagrams with exceptions and handlers to make it a part of our
process. The use cases which are essentially a sequence of events can be transformed to
the corresponding sequence diagram. The diagram can then be annotated with timeliness
constraints by associating deadlines to critical messages.
This will allow the timeliness constraints specified in the interaction models to be
mapped on to dependability assessment models. Several techniques and model-based formalisms can be explored for this purpose. Some possibilities are as follows: extending DACharts with timing constructs; using timed automata, timed Petri nets, or live sequence
charts; using timed DEVS for timing and probability analysis; or mapping to temporal
logic and using available model-checking tools to perform verification of properties.
Looking into other formalisms for carrying out dependability assessment would also
allow us to compare our DA-Charts technique with other available techniques, and provide
grounds to further evaluate the usefulness and effectiveness of our assessment method.
226
12.3. Future Work
12.3.6
Tool Support
Our approach would be more appealing and easier to apply if tool support is made
available for developers. We plan to develop tool support for our process that would provide a visual modelling environment for our dependability-oriented use cases, and allow
automatic mapping to analysis models for dependability assessment. A UML CASE tool
supporting our process and the extended use case diagrams should allow the developer to
selectively display the normal interactions, the handlers attached to context-affecting exceptions, or the handlers that address service-related exceptions. This makes it possible for
developers to focus on the main functionality, on exceptional functionality, or on recovery
of system-related exceptions. Moreover, automating the process of mapping use cases and
activity diagrams to DA-Charts would be a highly desirable feature, ultimately allowing
developers to work at the level of abstraction with the model (use cases, activity diagrams,
or statecharts) that best suits them. Our tool can then ensure that all representations are
consistently updated. Any changes made to one model would automatically be reflected in
the other models. This would also require the activity diagram formalism to be extended
with reliability and safety values so that the information in each view remains consistent.
A modelling environment for activity and interaction models, with the option of generating the models automatically from the use cases would also be beneficial. We have
already defined the transformation rules to map use cases to downstream models in Chapter 8. The process would then be completely model-driven with tool support, such that
any changes made to the activity diagrams model would automatically regenerate the updated use cases and DA-Chart model. It would also be advantageous to provide automated
support to map DA-Charts back to use cases. This would allow developers who are used
to the DA-Chart formalism to apply reliability and safety increasing modification directly
to the DA-Charts.
Tool support is essential for adoption of our process in an industrial setting, and we
envision that our dependability-oriented requirements engineering process with complete
tool support would be of great appeal and benefit to software engineers.
227
APPENDIX A
Case Study Models
A.1
ECS Case Study
The DREP artifacts of the ECS case study is presented in this section. We do not
walk through the process and discuss how we came up with the models. For details on the
application of the process, please refer to Chapter 6.
A.1.1
DREP Use Case Model
The actors, goals, and the standard use cases are elaborated in Section 6.3.2 of Chapter 6. The standard use cases include Take Elevator (Fig. 6–4), Call Elevator (Fig. 6–5),
Ride Elevator (Fig. 6–6), and Elevator Arrival (Fig. 5–11). Fig. 5–10 shows the standard
use case diagram.
The exceptional use cases are derived by carrying out reliability and safety refinements
using our dependability assessment mechanism with DA-Charts (described in Chapter 7).
The refined Elevator Arrival Exceptional Use Case and the Ride Elevator Exceptional Use
Case is shown in Fig. 6–8 and Fig. 6–9 respectively. The handler use cases designed to
address the service-related exceptions include the following: Redirect Elevator (Fig. 6–10),
Door Alert (Fig. 6–11), Overweight Alert (Fig. 6–12), Emergency Brake (Fig. 6–12), and
Call Elevator (Fig. 6–13). Handlers for context affecting exceptions are shown in Fig. 6–7.
The exceptional use cases diagram is presented in Fig. 6–14 (Chapter 6).
A.1.2
DREP Activity Diagrams
The exceptional use cases are mapped to activity diagrams by applying the transformation rules defined in Chapter 8. The resulting activity diagrams are presented in this
section. To illustrate the transformation, the mapping of the elevator arrival use case to
the corresponding activity diagram is explained in Section 5.5.5 of Chapter 5.
228
A.1. ECS Case Study
TakeElevator
[!available]
[available]
Call Elevator
Ride Elevator
Emergency
Stop
User
Emergency
Emergency
Override
ReturnTo
GroundFloor
Figure A–1: ECS: Take Elevator Activity Diagram
A.1.3
DREP Exception Table
The exception table summarizing the exceptions and handlers defined for the ECS is
given in Chapter 6 Table 6–1.
A.1.4
DREP Mode Table
Table A–1 summarizes the different modes of operations in ECS.
Table A–1: ECS: DREP Mode Table
Mode
Normal
Type
Normal
Fire Safety
Emergency
FloorXNotServed
Degraded
Description
Services
available
and correctly functioning
Fire operator initiates the mode switch
on the event of a fire
Specific floors not
available due to
jammed doors
229
Services
All normal services
available
No normal services
available
Take Elevator service offered with a
degraded QoS
A.1. ECS Case Study
Call Elevator
Call Request
<<success>>
Received
[New Request]
sourceFloor : Floor
<<failure>>
MotorStopFailure
Elevator Arrival
<<failure>>
DoorStuckClosed
reachedFloor : Floor
reachedFloor : Floor
<<success>>
Reached
Destination
<<degraded>>
DifferentFloor
<<success>>
<<degraded>>
<<failure>>
ReachedDestination DifferentFloor DoorStuckClosed
<<failure>>
MotorFailure
<<success>>
DestInQueue
Figure A–2: ECS: Call Elevator Activity Diagram
A.1.5
DREP Communication Diagram
The communication diagram in created based on the requirements specified in the use
cases and activity diagrams. The ECS communication diagram is presented in Chapter 6
Fig. 6–15.
230
A.1. ECS Case Study
Ride Elevator
<<abandoned>>
RideAbandonned
Ride Request
<<success>>
RequestRecvd
<<success>>
DoorClosed
requestedFloor : Floor
<<failure>>
DoorStuckOpen
Close Door
<<handler>>
Door Alert
<<success>>
DoorClosed
requestedFloor : Floor
<<failure>>
DoorStuck
OpenTooLong
requestedFloor : Floor
<<failure>>
MotorStopFailure
Elevator Arrival
<<failure>>
DoorStuckClosed
reachedFloor : Floor
reachedFloor : Floor
<<success>>
Reached
Destination
<<degraded>>
DifferentFloor
<<success>>
<<degraded>>
<<failure>>
ReachedDestination DifferentFloor DoorStuckClosed
<<failure>>
MotorFailure
<<failure>> <<abandoned>>
DoorStuck
Ride
OpenTooLong Abandoned
Figure A–3: ECS: Ride Elevator Activity Diagram
destFloor : Floor
Close Door
Close Door Door Closed
10ms
destFloor : Floor
<<failure>>
DoorStuckOpen
<<success>>
Closed
231
Figure A–4: ECS: Close Door Subactivity
A.1. ECS Case Study
requestedFloor : Floor
Elevator Arrival
<<success>>
TryAgain
destFloor : Floor
<<failure>>
MotorStart
Failure
Start Motor
destFloor : Floor
<<success>>
Started
<<failure>>
RetryFailure
<<success>>
TryDifferentFloor
destFloor : Floor
Wait for Event
Approaching
Dest. Floor
apprFloor : Floor
<<handler>>
Retry Motor
<<failure>>
MissedFloor
<<success>>
FloorDetected
<<handler>>
Redirect Elevator
newFloor : Floor
apprFloor : Floor
<<failure>>
MotorStopFailure
Stop Motor
stoppedFloor : Floor
<<success>>
Stopped
<<success>>
TryAgain
stoppedFloor : Floor
<<failure>>
DoorStuck
Closed
Open Door
reachedFloor : Floor
<<success>>
Opened
<<handler>>
Retry Door
<<failure>>
RetryFailure
[else]
[reachedFloor =
desiredFloor]
reachedFloor : Floor
<<success>>
ReachedDestination
<<degraded>>
DifferentFloor
<<failure>>
DoorStuckClosed
Figure A–5: ECS: Elevator Arrival Activity Diagram
232
<<failure>>
MotorFailure
A.1. ECS Case Study
Ride Request
Call Request
Call Request
Event
Floor request
15ms
<<success>>
Received
sourceFloor : Floor
requestedFloor : Floor
Figure A–6: ECS: Call Request Subactivity
<<abandonned>>
RideAbandonned
<<success>>
RequestRecvd
Figure A–7: ECS: Ride Request Subactivity
approachingFloor : Floor
destFloor : Floor
Start Motor
Stop Motor
Start Motor Stop Motor Motor Stopped
Motor Started
30ms
destFloor : Floor
<<failure>>
MotorStartFailure
<<success>>
Started
15ms
stoppedFloor : Floor
Figure A–8: ECS: Start Motor Subactivity
233
<<failure>>
MotorStopFailure
<<success>>
Stopped
Figure A–9: ECS: Stop Motor Subactivity
A.1. ECS Case Study
destFloor : Floor
stoppedFloor : Floor
Wait for Signal
Approaching Destination Floor
Open Door
Open Door Floor Detected
[!passed]
apprFloor : Floor
[missed]
Motor Stopped
<<failure>>
MissedFloorFailure
<<failure>>
DoorStuckClosed
10ms
<<success>>
FloorDetected
reachedFloor : Floor
Figure A–10: ECS: Approaching Destination
Floor Subactivity
<<success>>
Opened
Figure A–11: ECS: Open Door Subactivity
brakeStatus : Status
Emergency Brakes <<handler>>
buttonStatus : Status
Stop Motor
User Emergency <<handler>>
<<success>
Stopped
Brake
Activated Emergency
Button Off
Activate
Emergency Brakes
Turn On
Emergency Display
brakeStatus : Status
Brake
Deactivated
<<success>>
deactivatedBrakes
buttonStatus : Status
Figure A–12: ECS: Emergency Brake Handler Activity Diagram
234
<<success>>
deactivatedBrakes
Figure A–13: ECS: User Emergency Activity
Diagram
A.1. ECS Case Study
door : Status
Door Alert <<handler>>
door : Status
Display Door
Status
door : Status
<<success>>
displayed
door : Status
Start Buzzer
door : Status
<<success>>
Started
<<success>>
TryAgain
door : Status
Close Door
door : Status
<<failure>>
DoorStuckOpen
<<success>>
normal
<<handler>>
Retry Door
<<failure>
DoorRetryFailure
door : Status
Stop Buzzer
door : Status
<<success>>
Stopped
door : Status
Clear Display
weight : Status
door : Status
<<success>>
cleared
<<failure>>
DoorRetryFailure
<<success>>
DoorOpen
Figure A–14: ECS: Door Alert Handler Activity Diagram
235
A.1. ECS Case Study
currentWeight : weight
Overweight Alert
weight : Status
Display
"Overweight"
weight : Status
<<success>>
displayed
weight : Status
Start Buzzer
weight : Status
<<success>>
Started
<<success>>
TryAgain
weight : Status
Detect Weight
weight : Status
<<failure>>
Overweight
<<success>>
normal
<<handler>>
Recheck Weight
<<failure>>
WeightRetryFailure
weight : Status
Stop Buzzer
weight : Status
<<success>>
Opened
weight : Status
Clear Display
weight : Status
<<success>>
cleared
weight : Status
<<success>>
NormalWeight
<<failure>>
WeightRetryFailure
Figure A–15: ECS: Overweight Alert Handler Activity Diagram
236
A.1. ECS Case Study
groundFloor : Floor
Return To Ground Floor <<handler>>
destFloor : Floor
Clear Requests
destFloor : Floor
<<success>>
cleared
<<success>>
TryAgain
destFloor : Floor
<<failure>>
MotorStart
Failure
Start Motor
destFloor : Floor
<<success>>
Started
<<failure>>
RetryFailure
<<success>> TryDifferentFloor
destFloor : Floor
Wait for Event
Approaching
Dest. Floor
apprFloor : Floor
<<handler>>
Retry Motor
<<failure>>
MissedFloor
<<success>>
FloorDetected
<<handler>>
Redirect Elevator
newFloor : Floor
apprFloor : Floor
Stop Motor
stoppedFloor : Floor
<<failure>>
MotorStopFailure
<<success>>
Stopped
<<success>>
TryAgain
stoppedFloor : Floor
<<failure>>
DoorStuck
Closed
Open Door
reachedFloor : Floor
<<success>>
Opened
<<handler>>
Retry Door
<<failure>>
RetryFailure
reachedFloor : Floor
Halt System
reachedFloor : Floor
<<success>>
halted
[else]
[reachedFloor =
desiredFloor]
reachedFloor : Floor
<<success>>
ReachedDestination
<<degraded>>
DifferentFloor
237
<<failure>>
DoorStuckClosed
<<failure>>
MotorFailure
Figure A–16: ECS: Return To Ground Floor Handler Activity Diagram
A.2. 407 ETR Case Study
A.2
407 ETR Case Study
The DREP artifacts of the ETR case study is presented in this section. The process
is applied to the case study and discussed in Chapter 9 Section 9.2. The use cases which
are not presented in Chapter 9 are shown in Section A.2.1. The activity diagrams are
included in Section A.2.2. The summary exception table and mode table are presented in
Section A.2.3 and A.2.4. The communication diagram is shown in Section A.2.5.
A.2.1
DREP Use Case Model
The exceptional use cases presented in this section are: UseHighway, RegisterVehicle,
PassThroughGantry, ProcessUnregisteredVehicle, ClassifyVehicle, PayByCreditCard, PayByCheck, and CancelRegistration, RetryGovtComp, WarnClients, and ActivateBarrier.
Use Case: UseHighway
Scope: 407 ETR System
Level: Summary
Intention in Context: The intention of the Driver is to use the 407 ETR highway on a regular basis.
Multiplicity: One Driver can only drive one vehicle at a time on the highway. However, different Drivers
can use the highway simultaneously.
Primary Actor: Driver
Secondary Actor: GovernmentComputer
Main Success Scenario:
1. Driver registers vehicle.
Step 2-4 are repeated once a month as long as the vehicle is registered.
2. Driver takes highway.
Step 2 can be repeated any number of times per month.
3. At the end of the month, System sends bill to Driver.
4. Driver pays bill.
5. Driver cancels registration.
Use case ends in success UsedHighway.
Extensions:
1a. Driver uses highway without registering vehicle. Use case continues at step 2.
4a. Driver does not pay bill for 3 consecutive months.
4a.1. System informs GovernmentComputer of refusal to pay the bill. Use case continues at step
2.
Use Case: PassThroughGantry
Scope: 407 ETR System
Level: Sub-Function
Intention in Context: The Driver passes through a entry or exit gantry as part of his trip.
Multiplicity: One Driver can only drive one vehicle at a time through a gantry. However, different Drivers
can pass through the same or different gantries simultaneously.
Primary Actor: Driver
Main Success Scenario:
1. System processes registered vehicle.
2. System classifies vehicle.
Steps 1 and 2 can be performed in any order or in parallel.
3. System records entry time and vehicle information for the trip.
Use case ends in success PassedGantry.
Extensions:
2a. Processing registered vehicle fails.
238
A.2. 407 ETR Case Study
2a.1. System processes unregistered vehicle. Use case continues at step 2.
4a. Both processing were unsuccessful. Use case ends in f ailure .
4b. Classification was unsuccessful. Use case ends in degraded .
Use Case: ProcessRegisteredVehicle
Scope: 407 ETR System
Level: Sub-Function
Intention in Context: The System communicates with the transponder to identify the approaching vehicle.
Multiplicity: The System must be able to process multiple registered vehicles simultaneously.
Primary Actor: N/A
Secondary Actor: LocatorAntenna, R/WAntenna
Main Success Scenario:
1. LocatorAntenna notifies System that it detected an approaching vehicle with transponder.
2. System asks R/WAntenna to obtain account information from transponder.
3. RWAntenna informs System of account information.
4. System records account information for the trip.
5. System turns on the Lights.
6. System triggers the Cameras.
7. Cameras send images to System.
8. System determines licence plate information based on images.
Use case ends in success RegisteredVehicleProcessed.
Extensions:
1a. The approaching vehicle does not have a transponder. Use case ends in f ailure TransponderUnavailable.
1b. Exception{LocatorAntennaFailure}. Use case ends in f ailure LocAntennaFailure.
(2-3)a. Exception{RWAntennaFailure}. Use case ends in f ailure RWAntennaFailure.
3a. R/WAntenna is unable to obtain account information. Use case ends in f ailure .
6a. Exception{LightFailure}: Use case continues in degraded VehicleProcessedWithoutLights at
step 6.
7a. Exception{CameraFailure}: Use case ends in f ailure CameraFailure.
Use Case: ProcessUnregisteredVehicle
Scope: 407 ETR System
Level: Sub-Function
Intention in Context: The System wants to identify the approaching vehicle using the licence plate
information.
Multiplicity: The System must be able to process multiple unregistered vehicles simultaneously.
Primary Actor: N/A
Secondary Actors: VehicleDetector, Cameras, Lights
Main Success Scenario:
1. VehicleDetector notifies System that a vehicle is approaching.
2. System turns on the Lights.
3. System triggers the Cameras.
4. Cameras send images to System.
5. System determines licence plate based on images.
Use case ends in success LicenceNumberIdentified.
Extensions:
3a. Exception{LightFailure}. Use case continues in degraded LightsFailure at step 2.
4a. Exception{CameraFailure}. Use case ends in f ailure CameraFailure.
5a. Exception{LicenceNotReconized}. Use case ends in f ailure RecongitionFailure.
5a.1. System displays pictures on an OperatorTerminal.
5a.2. Operator recognizes picture and sends licence plate information to System.
Use Case: ClassifyVehicle
Scope: 407 ETR System
239
A.2. 407 ETR Case Study
Level: Sub-Function
Intention in Context: The System wants to classify the approaching vehicle as light vehicle, heavy single
unit vehicle, or heavy multiple unit vehicle.
Multiplicity: The System must be able to classify multiple vehicles simultaneously.
Primary Actor: N/A
Secondary Actor: LaserScanner
Main Success Scenario:
1. System activates LaserScanner.
2. LaserScanner sends vehicle dimensions to System.
3. System classifies vehicle and records classification in trip information.
Use case ends in success VehicleClassified.
Extensions:
2a. Exception{LaserScannerFailure}. System records classification failure in trip information. Use case
ends in f ailure ScannerFailure.
Use Case: RegisterVehicle
Scope: 407 ETR System
Level: User Goal
Intention in Context: The goal of the Driver is to register a vehicle with the system, which involves
opening an account and linking a transponder to it.
Multiplicity: A driver registers his vehicles one at a time. However, the system should be able to handle
multiple simultaneous registrations done by different drivers.
Primary Actor: Driver
Secondary Actor: OperatorTerminal, GovernmentComputer, PostalService
Main Success Scenario:
The Driver interacts with the System by calling an Operator.
1. Driver provides System with personal data and vehicle information.
2. System sends vehicle information to GovernmentComputer for verification.
3. GovernmentComputer notifies System that vehicle information is correct.
4. System acknowledges registration to the Driver.
5. System assigns a new transponder to the vehicle, and informs Postal Service to deliver the transponder to the Driver.
6. Driver installs and tests transponder.
7. Driver notifies the System of successful installation of the transponder.
Use case ends in success VehicleRegistered.
Extensions:
3a. Exception{GovernmentComputerUnavailable}. Use case ends in f ailure GovtComputerFailure.
4a. Driver does not have an account with the system yet. System opens a new account for the driver.
Use case continues at step 4.
6a. Transponder installation and testing fails. Driver notifies System of the problem. Use case continues
at step 5.
7a. Driver forgets to acknowledge installation and simply starts using the transponder on the highway.
Use case ends in success .
Use Case: PayByCreditCard
Scope: 407 ETR System
Level: User Goal
Intention in Context: The goal of the Driver is to pay for his trip by credit card.
Multiplicity: Every driver pays for his trips once a month. The system must support concurrent payments
of different drivers, be it by credit card or by check.
Primary Actor: Driver
Secondary Actor: OperatorTerminal, CreditCardCompany
Main Success Scenario:
Driver interacts with System by calling an Operator.
1. Operator provides System with credit card information.
240
A.2. 407 ETR Case Study
2. System contacts CreditCardCompany to validate credit.
3. CreditCardCompany notifies System of successful validation.
4. System notifies Operator of success.
Use case ends in success CreditCardPaymentSuccessful.
Extensions:
2a. Exception{CCCompanyUnavailable}: System notifies Operator. Use case ends in f ailure CCCompanyUnreachable.
3a. Exception{InsufficientCredit}: System notifies Operator. Use case ends in f ailure CreditFailure.
Use Case: PayByCheck
Scope: 407 ETR System
Level: User Goal
Intention in Context: The goal of the Driver is pay for his trip by check.
Multiplicity: Every driver pays for his trips once a month. The system must support concurrent payments
of different drivers, be it by credit card or by check.
Primary Actor: Driver
Secondary Actor: OperatorTerminal
Main Success Scenario:
Driver sends check to Operator.
1. Operator notifies System that check has been received.
Operator cashes check with Bank.
2. Bank notifies System that check has been cleared.
Use case ends in success ChequePaymentSuccessful.
Extensions:
2a. Exception{BouncedCheque}: System notifies Driver. Use case ends in f ailure ChequeFailure.
Use Case: CancelRegistration
Scope: 407 ETR System
Level: User Goal
Intention in Context: The goal of the Driver is to unregister a vehicle and potentially cancel his account
with the 407 ETR system.
Multiplicity: A driver unregisters a vehicle one at a time. The system should be able to handle multiple
concurrent unregistrations of different drivers.
Primary Actor: Driver
Secondary Actor: OperatorTerminal
Main Success Scenario:
Driver interacts with System by calling an Operator.
1. Operator notifies System that Driver wants to cancel his registration for a vehicle.
2. System marks vehicle registration as suspended and does not charge monthly fees anymore.
Driver sends transponder to Operator.
3. Operator notifies System that transponder has been received.
4. System cancels vehicle registration.
5. If Driver has no vehicles registered with the system anymore, System cancels driver account.
Use case ends in success RegCancelled.
Extensions:
3a. Exception{TransponderUsed}: System reactivates registration. Use case ends in f ailure RegNotCancelled.
Handler Use Case: RetryGovtComp
Handler Class: Reliability
Context & Exception: TakeHighway{GovernmentComputerUnavailable}
Level: Subfunctional
Intention in Context: The System wants to notify clients that they might have dis-functional transponders.
241
A.2. 407 ETR Case Study
Multiplicity: The System must be able to process multiple registered vehicles simultaneously.
Primary Actor: N/A
Secondary Actor:
Main Success Scenario:
1. System resends license plate information to the government computer.
Step 1 is repeated 2 times.
2. Government computer sends vehicle information.
Use case ends in success VehicleInfoReceived.
Handler Use Case: WarnClients
Handler Class: Reliability
Context & Exception: TakeHighway{TransponderUnreachable}
Scope: 407 ETR System
Level: Subfunctional
Intention in Context: The System wants to notify clients that they might have malfunctional transponders.
Multiplicity: The System must be able to process multiple registered vehicles simultaneously.
Primary Actor: N/A
Secondary Actor:
Main Success Scenario:
1. System ascertains that the transponder is out of order.
2. System notifies operator that the transponder is not responding.
3. System flags transponder account as temporarily unavailable and cancels the video toll charge.
4. Operator issues a warning letter to the vehicle owner.
5. Owner brings transponder to the office for service.
6. Operator changes status of the account after transponder is serviced.
Use case ends in success TransponderFixed.
Extensions:
5a.1 System warns that grace period is over.
5a.2 System cancels discount of video toll charge.
Handler Use Case: ActivateBarrier
Handler Class: Safety
Context & Exception: TakeHighway{HighwayUnavailable}
Level: Usergoal
Intention in Context: The operator wants to temporarily stop access to the highway.
Multiplicity: The System must be able to process multiple registered vehicles simultaneously.
Primary Actor: Operator
Secondary Actor: Barrier
Main Success Scenario:
System switches into restricted mode ExitOnly.
1. System activates barriers at entry gantries.
2. System displays ”Highway Unavailable” at message boards on highway.
3. Operator informs System that highway is accessible again.
4. System deactivates barriers.
5. System clears message boards.
System switches back to normal mode. Use case ends in success HighwayAvailable.
Extensions:
2a. Exception{BarrierFailure}: Use case ends in f ailure HighwayUnavilableTooLong.
The exceptional use case diagram is shown in Fig. A–17.
242
A.2. 407 ETR Case Study
407 Express Toll Route (ETR) System
<<interrupt&fai>>
<<interrupt&continue>>
<<reliability handler>>
<<
>
nue>
conti
rrupt&
te
<<in
RetryOperator
>
lude>
up
t&c
<<reliability handler>>
ue>>
Exception:
{LightFailure},
{CameraFailure}
fai
l>>
er
ru
tin
on
&c
pt
Exception:
{DetectorFailure}
>
>>
ue
e>
nu
nti
co
pt&
pt&
Exception:
{LaserScannerFailure}
int
ru
int
er
ru
<<
contin
ClassifyVehicle
er
rrupt&
CallHighwayPatrol
int
<<inte
>
<<
>
>
ue
in
t
on
Exception:
{RWAntennaFailure}
<<reliability handler>>
SwitchToSpare
Antenna
<<reliability handler>>
CallServicePerson
Exception:
{BarrierFailure}
<<safety handler>>
de>
ProcessUnregistered
Vehicle
&c
pt
<<reliability handler>>
WarnClient
clu
rru
e
ue
>
<<in
te
in
<<
t
p
rru
Exception:
{Transponder
Unreachable}
tin
<<include>>
<<
>>
ue
in
nt
o
&c
on
PassThroughGantry
<<inc
Exception:
{LocatorAntennaFailure}
UseRWAntenna
err
>
ProcessRegistered
Vehicle
nt
int
<<include>>
Exception:
{OperatorFailure}
<<reliability handler>>
ActivateBarriers
Exception:
{HighwayUnavailable}
<<interrupt&fail>>
Exception:
{GovtCompUnavailable}
i
<<
<<safety handler>>
TakeHighway
RetryGovtComp
<<reliability handler>>
<<reliability handler>>
UseRedundant
Detector
SwitchToSpare
Scanner
Figure A–17: 407 ETR: Exceptional Use Case Diagram
A.2.2
DREP Activity Diagrams
The exceptional use cases are mapped to activity diagrams by applying the transformation rules defined in Chapter 8. The resulting activity diagrams are presented in this
section. For space reasons, all the handler activities and subactivities are not included in
this section.
A.2.3
DREP Exception Table
The exception table summarizing the exceptions and handlers defined for the 407 ETR
is presented Table A–2.
A.2.4
DREP Mode Table
Table A–3 summarizes the different modes of operations in 407 ETR.
A.2.5
DREP Communication Diagram
The communication diagram in created based on the requirements specified in the
use cases and activity diagrams. The 407 ETR communication diagram is presented in
Fig. A–24.
243
A.2. 407 ETR Case Study
Take Highway
Pass Through
Entry Gantry
<<success>>
EnteredHighway
Pass Through
Exit Gantry
<<success>>
ExitedHighway
<<success>>
TryAgain
<<handler>>
Retry Govt
Computer
<<failure>>
GovtConfUnavailable
Process
Transaction
<<failure>>
OperatorFailure
<<failure>>
GovtComputerFailure
<<success>>
TransactionProcessed
<<success>>
TryAgain
<<handler>>
Retry Operator
[unregistered vehicle]
<<failure>>
OperatorFailure
[registeredvehicle]
<<success>>
ClientWarned
Send Green
Signal
<<failure>>
TransponderUnreachable
<<handler>>
Warn Client
<<success>>
SignalSent
[confirmed]
[unsuccessful exit or entry]
[unconfirmed]
<<success>>
CrossedHighway
<<degraded>>
DriverNotNotified
<<degraded>>
MinimalTrip
<<failure>>
GovtComputerFailure
<<failure>>
OperatorFailure
Figure A–18: ETR: Take Highway Activity Diagram
244
A.2. 407 ETR Case Study
Process Registered Vehicle
Detect
Trasponder
Process
Unregistered
Vehicle
<<failure>>
NoTransponder
<<success>>
DetectedVehicle
Wait for Event
Approaching
Vehicle
<<failure>>
LocatorAntennaFailure
<<handler>>
<<success>>
Use
RW Antenna
TryAgain
<<failure>>
AntennaFailure
<<success>>
SpareAvailable
<<failure>>
AccountInfoUnavailable
Get Account
Information
<<handler>>
Switch to Spare
Antenna
<<failure>>
RWAntennaFailure
<<failure>>
SpareFailure
Switch on Lights
<<handler>>
Call Service
Person
<<failure>>
LightFailure
<<failure>>
LightFailure
Get Images
<<handler>>
Call Service
Person
<<failure>>
CameraFailure
[confirmed]
<<failure>>
CameraFailure
[lights working]
<<success>>
RegisteredVehicle
Procesed
[else]
<<degraded>>
VehicleProcessed
WithoutLights
<< failure >>
LightFailure
<<failure>>
CameraFailure
<<failure>>
RWAntenna
Failure
<<failure>>
LocAntenna
Failure
Figure A–19: ETR: Process Registered Vehicle Activity Diagram
245
A.2. 407 ETR Case Study
Process Unregistered Vehicle
Wait for Event
Approaching
Vehicle
Switch on Lights
<<handler>>
Call Service
Person
<<failure>>
LightFailure
<<failure>>
LightFailure
Get Images
<<handler>>
Call Service
Person
<<failure>>
CameraFailure
<<failure>>
CameraFailure
<<success>>
ImageIdentified
Determine
Licence
<<failure>>
Licence
NotRecognized
<<handler>>
Contact Operator
<<failure>>
RecognitionFailure
<<success>>
LicenceNumber
Identified
<< degraded >>
LightFailure
<<failure>>
CameraFailure
<<failure>>
RecognitionFailure
Figure A–20: ETR: Process Unregistered Vehicle Activity Diagram
246
A.2. 407 ETR Case Study
Send Green Signal
Send signal to
RW Antenna RW Antenna
Ack
5ms
<<failure>>
TransponderUnreachable
<<success>>
DriverNotified
Figure A–21: ETR: Send Green Signal SubActivity
Warn Clients <<handler>>
Activate Barrier <<handler>>
Send Transponder
Out of Order
Message
<<success>>
BarrierActivated
<<success>>
Display
Highway
BarrierActivated
unavailable Flag Account &
Cancel Video Toll
Charge
Activate Barrier Issue Letter Highway
Available
timeout
<<failure>>
HighwayUnavailable
TooLong
Deactivate Barrier Receive
Transponder
Clear Message
Board
Update Account
Status
Wait
(grace period)
<<failure>>
GracePeriodOver
<<success>>
ClientResponded
Figure A–22: ETR: Activate Barriers Activity Diagram
247
Figure A–23: ETR: Warn Client Activity Diagram
A.2. 407 ETR Case Study
Table A–2: 407 ETR System: Exception Table
Exception
Description
Context
Handler
Detection
Government
Computer
Unavailable
System unable to access vehicle record
TakeHighway
Retry
Comp
Govt
Timeout on government computer
Operator Terminal Failure
Operator unable to communicate with government
computer
TakeHighway
Retry Operator
Timeout on operator
Transponder
Unreachable
System cannot communicate with the transponder
TakeHighway
WarnClient
Lack of acknowledgement / Timeout
Detector Failure
System does not get info on
incoming vehicles from the
vehicle detector
Process
Unregistered
Vehicle
Use
Redundant
Detector
Locator antenna detects vehicles
Locator
Antenna Failure
System receives no msg
from loc antenna; unable to
identify transponders
Process Registered Vehicle
Use RW Antenna
Timeout on antenna
RW
Antenna
Failure
System does not receive
transponder account information from the RW antenna
Process Registered Vehicle
SwitchTo
SpareAntenna
Timeout on RW antenna
Light Failure
Lights failed to turn on
when taking images
ProcessRegistered
Call Service
Vehicle,
Person
Process
Unregistered
Vehicle
Bad images
Camera Failure
System does not receive
images from the camera
Process
Registered
Vehicle,
Process
Unregistered
Vehicle
Call Service
Person
Timeout on camera
device
Laser Scanner
Failure
System unable to classify
due to lack of message from
scanner
Classify
hicle
SwitchTo
SpareScanner
Timeout on scanner
Highway
Unavailable
System blocks access to
parts of the highway
TakeHighway
Barrier Failure
The barrier fails to get activated
ActivateBarriers Call Highway
Patrol
Ve-
ActivateBarriers Operator request
Timeout on barrier
Table A–3: 407 ETR: DREP Mode Table
Mode
Normal
Type
Normal
Exit Only
Restricted
Degraded Reliability
Degraded
Description
Services available and
correctly functioning
Toll road barred due to
emergency
Bad or no image due to
weather or transmission
problems
248
Services
All
normal
services
available
Only exit services available
Video Surveillance system services offered with
a degraded QoS
accInfo: ProcessRegisteredVehicle{
: Operator
Terminal
: Vehicle
Detector
*
<<r>>
LaserScannerFailure}
OperatorFailure}
licenseInfo: ProcessUnregisteredVehicle{
displayPic}
cancelRegReq: CancelRegistration
displayPic}
OperatorFailure}
licenseInfo: TakeHighway{
displayPic: TakeHighway{
1
<<time-triggered>>
sendBill
: 407 ETR
: timeout,
*
:Postal :CreditCard
Cmpany
Service
1
<<exceptional>>
:MessageBoard
CameraFailure
<<r>>
<<r>>
getVehicleInfo}
licenseInfo}
verifyVehicleInfo: RegisterVehicle{
1
: Bank
1
: Light
*
GovtCompUnavailable}
GovtCompUnavailable}
: GovtComputer
veryfyVehicleInfo}
licenceInfo: RetryGovtComp
getVehicleInfo: TakeHighway{
<<r>>
vehicleInfo: TakeHighway{
vehicleInfo: RetryGovtComp{
vehicleVerified: RegisterVehicle{
BouncedCheque}
LightFailure}
chequeResult: PayByCheck{
LightFailure}
<<r>> lightOn: ProcessRegisteredVehicle{
<<r>> lightOn: ProcessUnregisteredVehicle{
on}
image: ProcessUnregisteredVehicle{
*
: Camera
CameraFailure}
on}
cameraOn: ProcessRegisteredVehicle{
}<<r>>
image: ProcessRegisteredVehicle{
cameraOn: ProcessUnregisteredVehicle{
<<r>>
: exception, <<s>>: safety-critical, <<r>>: reliability, handlers are shown in italics
<<exceptional>>
:RepairTeam
<<s>> activateBarrier: ActivateBarrier
Figure A–24: 407 ETR: DREP Communication Diagram
: timed message,
transponderRcvd: CancelRegistration{
TransponderUsed}
transponderServiced: WarnClients
<<r>>
displayPic: ProcessUnregisteredVehicle{
transponderDown: WarnClients
DetectorFailure}
activateScanner}
: Laser
Scanner
apprVehicle: ProcessUnregisteredVehicle{
*
vehicleDim: ClassifyVehicle{
activateScanner: ClassifyVehicle{
LocatorAntennaFailure}
successSignal}
apprVehicle: ProcessRegisteredVehicle {
: Locator
Antenna<<r>>
*
*
TransponderUnreachable}
transInfo}
successSignal: ProcessRegisteredVehicle{
ackSignal: ProcessRegisteredVehicle{
: RW
Antenna
*
BarrierFailure}
<<s>> activate: ActivateBarrier{
<<exceptional>>
: Barrier
<<s>> displayMessage : ActivateBarriers
TransponderUnreachable}
RWAntennaFailure}
trOut: WarnClient
transInfo: ProcessRegisteredVehicle{
InsufficientCredit}
creditResult: PayByCreditCard{
<<r>>
CCCompanyUnavailable}
{
249
issueLetter : WarnClient{
*
<<r>> creditAmount: PayByCreditCard
*
A.2. 407 ETR Case Study
A.3. Crisis Management System Case Study
A.3
Crisis Management System Case Study
The DREP artifacts of the Crisis Management System (CMS) case study are presented
in this section.
A.3.1
DREP Use Case Model
The CMS standard use case diagram is shown in Fig. A–25. Due to space reasons,
the standard use cases are not included in this appendix. The exceptional use cases along
with the handlers of the CMS are presented here.
Crisis Management System: Car Crash Case Study
1
1
Update
ResDatabase
ManageCrisis
Coordinator
InitiateCrisis
Witness
1
<<include>>
ProcessCrisis
Phone
Company
*
ConcludeCrisis
<<include>>
<<include>>
CreateCrisis
*
ProcessMission
<<include>>
Assign
IntResource
<<include>>
<<include>>
Request
ExtResource
<<include>>
ExecuteMission
Surveillance
System
Observe
*
Rescue
<<include>>
CMS
Employee
System
Admin
<<include>>
<<include>>
<<include>>
1..*
CreateMission
Transport
Super
Observer
ReportMission
Outcome
Remove
Obstacle
<<include>>
<<include>>
Respond
RequestLogin
*
1
GSM
1
<<include>>
External
Resource
System
Update
Availability
<<include>>
Respond, RequestLogin and
SendMessage sub-functional
use cases are included in all of
the above use cases
Authenticate
User
SendMessage
PDA
Figure A–25: Car Crash CMS: Standard Use Case Diagram
Use Case: ManageCrisis
Scope: Car Crash Crisis Management System
Primary Actor: Coordinator
Secondary Actor: SuperObserver, CMSEmployee, ExternalResourceSystem, CommDevice, PhoneCompany, SurveillanceSystem (Witness, ExternalWorker)
Intention: The intention of the Coordinator is to manage a car crash crisis.
Level: Summary
Main Success Scenario:
1. Coordinator initiates the crisis.
2. Coordinator processes the crisis.
3. Coordinator concludes the crisis.
Use case ends in success CrisisManaged.
250
A.3. Crisis Management System Case Study
Extensions:
1a. Coordinater is not logged in. Coordinator authenticates with System. Use case continues at step
1.
(2-3)a. Coordinator instructsR System to terminate the management of the crisis. Use case ends in
f ailure .
Use Case: InitiateCrisis
Scope: Car Crash Crisis Management System
Primary Actor: Coordinator
Secondary Actor: SuperObserver, CMSEmployee/Pilot, (Witness)
Intention: The intention of the crisis coordinator is to record the information provided by the witness,
and to dispatch the most appropriate super observer.
Level: User goal
Main Success Scenario:
Witness places a call to the crisis centre, where it is answered by a Coordinator.
1. Coordinator creates the crisis record based on the witness’ inputs.
2. System processes internal SuperObserver mission.
Use case ends in success CrisisInitiated.
Extensions:
1a. Exception{CrisisNotCreated } Use case ends in f ailure NoCrisisCreated
3a. Crisis location is reachable by standard transportation means.
Use case ends in success CrisisInitiated.
Use Case: CreateCrisis
Scope: Car Crash Crisis Management System
Primary Actor: Coordinator
Secondary Actor: PhoneCompany, SurveillanceSystem, (Witness)
Intention: The Crisis Coordinator intends to create a crisis record.
Level: User goal
Main Success Scenario:
Coordinator requests Witness to provide his identification. If call is disconnected, Coordinator attempts
to call Witness back.
1. Coordinator provides witness information1 to System.
Coordinator requests Witness to provide location of crisis. If call is disconnected, Coordinator attempts
to call Witness back.
2. Coordinator informs System of location of crisis.
Coordinator requests Witness to provide type of crisis. If call is disconnected, Coordinator attempts to
call Witness back.
3. Coordinator informs System of the type of crisis.
4. System provides Coordinator with a crisis focused checklist.
Coordinator probes Witness for crisis information2 . If call is disconnected, Coordinator attempts to
call Witness back.
5. Coordinator provides crisis information2 to System.
System assigns an initial emergency level to the crisis and sets the crisis status to active.
Use case ends in success CrisisRecordCreated.
Extensions:
(1-2)a.Exception{CallDisconnected } Use case ends in f ailure CrisisNotCreated
(3-4)a.Exception{CallDisconnected } Use case ends in degraded NoSpecificCrisisInformation.
(2-5)||.1 System contacts PhoneCompany to verify witness information.
(2-5)||.2 PhoneCompany sends address/phone information to System.
(2-5)||.3 System validates information received from the PhoneCompany.
251
A.3. Crisis Management System Case Study
(2-5)||.3a PhoneCompany information does not match information received from Witness. Use case
ends in goal abandonned FalseID.
(3-4)||.1 System informs Coordinator that crisis location is covered by camera surveillance.
(3-4)||.2 System requests video feed from SurveillanceSystem.
(3-4)||.3 SurveillanceSystem starts sending video feed to System.
(3-4)||.4 System starts displaying video feed for Coordinator.
5a. Camera vision of the location is perfect, but Coordinator cannot confirm the situation that the
witness describes or the Coordinator determines that the witness is calling in a fake crisis. Use case
ends in goal abandonned Hoax.
5b. Exception{CameraFailure}
1 Witness
2 Crisis
information includes the first name, last name, phone number, and address.
information includes the details about the crisis, the time witnessed, etc.
Use Case: ProcessCrisis
Scope: Car Crash Crisis Management System
Primary Actor: Coordinator
Secondary Actor: CMSEmployee,
Intention: The intention of the Coordinator is to process the missions requested by the SuperObserver,
and to cancel or change missions if the situation requires it.
Level: User goal
Main Success Scenario:
Step 1 and 2 are repeated as many times as needed, and in parallel, if needed.
1. System informs Coordinator of missions that are to be executed.
2. Coordinator instructs System to process a specific mission. reliability
3. System informs Coordinator that all missions terminated.
Use case ends in success CrisisProcessed.
Use Case: ProcessMission
Scope: Car Crash Crisis Management System
Primary Actor: None
Secondary Actor: Worker (can be internal or external), ExternalResourceSystem
Intention: The intention of System is to assign and then execute a mission with internal or external first
aid workers.
Level: Sub-functional level
Main Success Scenario:
1. System assigns internal mission to appropriate InternalAidWorker. reliability
2. Worker notifiesR System that he arrived on site.
3. Worker executes mission on site. reliability, safety
4. Worker notifiesR System that he is leaving site.
5. Worker reports on mission outcome. reliability
Use case ends in success MissionProcessed.
Extensions:
1a. Mission can only be executed with the help of external resources.
1a.1 System requests external resources. Use case continues at step 2.
1a.1a Exception{ExtResReqDenied }: SuggestAlternateMissions
1a.1a.1 Use case ends in degraded AlternateMissionsSuggested.
1b. Exception{IntFAWUnavailable}: CompensateWithExternalResource
1b.1 Use case continues at step 2.
1b.1a Exception{CompensatedWithAlternateMissions}: Use case ends in degraded AlternateMissionsSuggested.
252
A.3. Crisis Management System Case Study
2a. System determines that the mission is not performable using standard transportation means.
2a.1 System informs the Coordinator about the problem. reliability
2a.2 Coordinator instructs System to process internal Pilot mission to transport the Worker during
his mission by helicopter.
2a.3 System notifies Worker that Pilot has been assigned. Use case continues at step 2.
2b. SuperObserver notifiesR System that Worker has arrived on site. Use case continues at step 3.
2c. Exception{FAWNeverArrivesOnSite}: CheckWorker
2c.1 Use case continues at step 2.
2c.1a Exception{FAWUnresponsive}: Use case continues at step 1.
3a. Exception{MissionExecFailure}: AddressMissionFailure
3a.1 Use case ends in f ailure MissionFailed.
3a.1a Current mission is an observer mission. Use case continues at step 1.
4a. SuperObserver notifiesR System that Worker has left site. Use case continues at step 5.
4b. Exception{FAWNeverLeavesSite}: CheckWorker
4b.1 Use case continues at step 4.
4b.1a Exception{FAWUnresponsive}:
4b.1a.1 System requestS SuperObserver to check for Worker on site.
4b.1a.2 SuperObserver notifiesR System that Worker is still working. Use case continues at step 4.
4b.1a.2a SuperObserver notifiesR System that Worker has left site. Use case continues at step 5.
5a. Exception{OutcomeNotReported }: Use case ends in degraded MissionWithoutReport.
Use Case: AssignInternalResource
Scope: Car Crash Crisis Management System
Primary Actor: None
Secondary Actor: CMSEmployee
Intention: The intention of System is to find, contact, and assign a mission to the most appropriate
available CMSEmployee.
Level: Sub-functional level
Main Success Scenario:
System selects an appropriate CMSEmployee based on the mission type, the emergency level, location
and requested expertise. In very urgent cases, steps 1 and 2 can be performed for several CMSEmployees
concurrently, until one of the contacted employees accepts the mission.
1. System requestsC the CMSEmployee to login. reliability
2. System sendsS CMSEmployee mission information. reliability
3. CMSEmployee informsR System that he accepts the mission. reliability
Use case ends in success MissionAssigned.
Extensions:
1a. CMSEmployee is already logged in. Use case continues at step 2.
1b. Exception{LoginRequestNotSent, UserNotLoggedIn}
1a.1 System selects the next appropriate CMSEmployee. Use case continues at Step 1.
1a.1a No other CMSEmployee is available. Use case ends in f ailure EmplUnavailable.
2a. Exception{SendFailure}
2a.1 System selects the next appropriate CMSEmployee. Use case continues at Step 1.
2a.1a No other CMSEmployee is available. Use case ends in f ailure EmplUnavailable.
3a. CMSEmployee informsR System that he cannot accept the mission.
3a.1 System selects the next appropriate CMSEmployee. Use case continues at Step 1.
3a.1a No other CMSEmployee is available. Use case ends in f ailure EmplUnavailable.
3b. Exception{ResponseFailure}
253
A.3. Crisis Management System Case Study
3b.1System selects the next appropriate CMSEmployee. Use case continues at Step 1.
3b.1a No other CMSEmployee is available. Use case ends in f ailure EmplUnavailable.
Use Case: RequestExternalResource
Scope: Car Crash Crisis Management System
Primary Actor:
Secondary Actor: ExternalResourceSystem (ERS)
Intention: The System requests a mission from an external resource, such as a fire station, police station
or external ambulance service.
Level: Subfunctional
Main Success Scenario:
1. System sends mission request to ERS, along with mission-specific information*.
2. ERS informs System that request can be processed. reliability
Use case ends in success > RequestAccepted.
Extensions:
2a. ERS notifies System that it partially approves request for resources. Use case ends in degraded PartiallyAcceptedRequest.
2b. ERS notifies System that it does not approve request for resources. Use case ends in f ailure ExtResReqDenied. 2c. Exception{ERSUnreachable}
*Mission-specific information includes things such as the location and emergency level of the mission,
the quantity of vehicles requested, special characteristics of the aid worker or vehicle, etc.
Handler Use Case: SuggestAlternateMissions
Handler Class: Reliability
Context & Exception: ProcessMission{ExtResReqDenied}
Scope: Car Crash Crisis Management System
Primary Actor: None
Secondary Actor: SuperObserver
Intention: The intention of the System is to suggest replacement missions to the SuperObserver.
Level: Subfunctional
Main Success Scenario:
1. System sendsS a message to SuperObserver with a list of replacement missions.
Step 2 is repeated as many times as needed.
2. SuperObserver creates replacement mission. reliability
Use case ends in success MissionCompensated.
Extensions:
2a. SuperObserver informsR System that no replacement missions are possible. safety
2a.1 System suggests to notify NationalCrisisCenter.
Use case ends in f ailure AlternateMissionsUnacceptable.
Handler Use Case: AddressMissionFailure
Handler Class: Reliability
Context & Exception: ProcessMission{MissionExecFailed}
Scope: Car Crash Crisis Management System
Primary Actor: None
Secondary Actor: SuperObserver, Coordinator
Intention: The intention of the System is to report mission failure to the SuperObserver and the Coordinator.
Level: Subfunctional
254
A.3. Crisis Management System Case Study
Main Success Scenario:
Steps 1 and 2 can be performed in any order.
1. System informsS SuperObserver of mission failure.
2. System informs Coordinator of mission failure.
Use case ends in success MissionFailureAddressed.
Extensions:
1a. Current mission is an observer mission. Use case continues at step 2.
Handler Use Case: CompensateWithExternalResource
Handler Class: Reliability
Context & Exception: ProcessMission{FAWUnavailable}
Scope: Car Crash Crisis Management System
Primary Actor: None
Secondary Actor: ERS
Intention: The intention of the System is to try to compensate for the unavailability of CMSEmployees
by requesting an external mission.
Level: Subfunctional
Main Success Scenario:
Steps 1 and 2 can be performed in any order. 1. System requests external resources.
Use case ends in success CompensationSuccessful.
Extensions:
1a Exception{ExtResReqDenied }: SuggestAlternateMissions
1a.1 Use case ends in degraded CompensatedWithAlternateMissions.
Use Case: ExecuteSuperObserverMission
Scope: Car Crash Crisis Management System
Primary Actor: SuperObserver
Secondary Actor: None
Intention: The intention of the SuperObserver is to observe the situation at the crisis site to be able to
order appropriate missions.
Level: User goal
Main Success Scenario:
1. System sendsS a crisis-specific checklist to SuperObserver.
2. SuperObserver feedsR System with crisis information. reliability
3. System suggestsS crisis-specific missions to SuperObserver.
Step 4 is repeated as many times as needed.
4. SuperObserver creates mission. reliability
SuperObserver judges that his presence is no longer needed at the crisis location.
Use case ends in success CrisisObserved.
Extensions:
(2a,4b). Exception{NoMessageFromSO}: CheckWorker
(2a,4b).1 Use case continues at step 4.
(2a,4b).1a Exception{FAWUnavailable}: Use case ends in f ailure ObservationFailed.
4a. SuperObserver informsR System that he judges that the NationalCrisisCenter should be contacted.
4a.1 System suggests to notify NationalCrisisCenter . Use case continues at step 4.
Use Case: CreateMission
Scope: Car Crash Crisis Management System
Primary Actor: Super Observer
255
A.3. Crisis Management System Case Study
Secondary Actor: None
Intention: The intention of the SuperObserver is to create missions based on his observations.
Level: User goal
Main Success Scenario:
1. SuperObserver notifiesR System of the type of mission he wants to create. reliability
2. System sendsS a mission-specific information request to SuperObserver. reliability
3. SuperObserver sendsR mission-specific information1 to System. reliability
4. System acknowledges the mission creation to SuperObserver.
Use case ends in success MissionCreated.
Extensions:
(1,3)a. Exception{NoMessageFromSO}: CheckWorker
(1,3)a.1 Use case continues at step 1.
(1,3)a.2 Exception{FAWUnresponsive}: Use case ends in f ailure MissionCreationIncomplete.
1 Mission-specific
information includes things such as the quantity of vehicles requested, special characteristics
of the aid worker or vehicle, etc.
Handler Use Case: CheckWorker
Handler Class: Reliability
Context & Exception: ManageCrisis{MissionNotificationNotRecd}
Scope: Car Crash Crisis Management System
Primary Actor: None
Secondary Actor: Worker
Intention: The intention of the System is to check if the first aid worker is reachable.
Level: Subfunctional
Main Success Scenario:
1. System sendsS a message to Worker to check if he is reachable.
2. Worker respondsR to the System.
Use case ends in success FAWAvailable.
Extensions:
2a. Exception{FAWUnresponsive}: Use case ends in f ailure FAWUnavailable.
Use Case: ReportMissionOutcome
Scope: Car Crash Crisis Management System
Primary Actor: Worker (can be internal or external)
Secondary Actor: None
Intention: The intention of the Worker is to report to the Coordinator that he has completed his mission.
Level: User goal
Main Success Scenario:
1. Worker informsR System that he has completed his mission. reliability
Use case ends in success OutcomeReported.
Extensions:
1a. Exception{NoMessageFromSO}: CheckWorker
1a.1 Use case continues at step 1.
1a.1a System informs SuperObserver that first aid worker in unavailable. Use case ends in f ailure OutcomeNotReported.
Use Case: ConcludeCrisis
Scope: Car Crash Crisis Management System
Primary Actor: Coordinator
Secondary Actor: None
256
A.3. Crisis Management System Case Study
Intention: The intention of the Coordinator is to inform the System that the crisis has been managed.
Level: User goal
Main Success Scenario:
1. Coordinator informs System that the crisis is over. reliability
Use case ends in success CrisisConcluded.
Extensions:
1a. Exception{CrisisNotConcluded }
Use Case: RequestLogin
Scope: Car Crash Crisis Management System
Primary Actor: None
Secondary Actor: GSM, CMSEmployee
Intention: The intention of the System is to contact the employee to request him to login to the system.
Level: Subfunctional
Main Success Scenario:
1. System send an SMS to the CMSEmployee, requesting him to login. reliability
2. CMSEmployee notifiesR System that he is logged in.
Use case ends in success UserLoggedIn.
Extensions:
1a. Exception{SMSNotSent}. Use case ends in f ailure LoginRequestNotSent.
2a. Exception{ResponseFailure}. Use case ends in f ailure UserNotLoggedIn.
Note: We could try an alternate medium here.
Use Case: SendSMS
Scope: Car Crash Crisis Management System
Primary Actor: None
Secondary Actor: GSM
Intention: The intention of the System is send an SMS.
Level: Subfunctional
Main Success Scenario:
1. System requests the GSM to send an SMS to a given destination. reliability
2. GSM informs System that SMS has been sent.
Use case ends in success SMSSent.
Extensions:
2a. GSM informs System that network is unavailable. Use case ends in f ailure SMSNotSent.
2b. Exception{GSMNotResponsive}: Use case ends in f ailure SMSNotSent.
Use Case: SendMessage
Scope: Car Crash Crisis Management System
Primary Actor: None
Secondary Actor: CMSEmployee
Intention: The intention of the System is to communicate with the user in a secure and authenticated
way using his PDA.
Level: Subfunctional
Main Success Scenario:
1. System sends a message to CMSEmployee via PDA.
Use case ends in success MessageSentViaPDA.
Extensions:
1a. Exception{PDAConnectionFailure}: ToleratePDAFailure
1a.1 Use case ends in success MessageSentViaSMS.
1a.1a Exception{CommunicationImpossible}: Use case ends in f ailure SendFailure}
257
A.3. Crisis Management System Case Study
Handler Use Case: ToleratePDAFailure
Handler Class: Reliability
Context & Exception: SendMessage{PDAConnectionFailure}, Respond{PDAConnectionFailure}
Scope: Car Crash Crisis Management System
Primary Actor: Source (either System or Worker)
Secondary Actor: Destination (either System or Worker)
Intention: The intention of Source is to try to communicate with Destination by SMS.
Level: Subfunctional
Main Success Scenario:
1. Source sends a message to Destination via SMS. reliability
Use case ends in success PDAFailureTolerated.
Extensions:
1a. Exception{SMSNotSent}: Use case ends in f ailure CommunicationImpossible}
Use Case: Respond
Scope: Car Crash Crisis Management System
Primary Actor: CMSEmployee
Secondary Actor: None
Intention: The intention of the CMSEmployee is to communicate securely with the System, for instance
in response to a request.
Main Success Scenario:
1. CMSEmployee sends message to System via PDA.
Use case ends in success MessageSentViaPDA.
Extensions:
1a. CMSEmployee is no longer logged-in.
1a.1 CMSEmployee authenticates with System. Use case continues at Step 1.
1a.1a Exception{AuthenticationFailed,AuthenticationCancelled }: Use case ends in f ailure ResponseFailure.
1b. Exception{PDAConnectionFailure}: ToleratePDAFailure
1b.1 Use case ends in success ResponseSentViaSMS.
1b.1a Exception{CommunicationImpossible}: Use case ends in f ailure ResponseFailure.
Use Case: Authenticate
Scope: Car Crash Crisis Management System
Primary Actor: None
Secondary Actor: CMSEmployee
Intention: The intention of the System is to authenticate the v to allow access.
Main Success Scenario:
1. System prompts CMSEmployee for login id and password. reliability
2. CMSEmployee enters login id and password into System. reliability
3. System validates the login information.
Use case ends in success Authenticated.
Extensions:
(1-2)a. CMSEmployee cancels the authentication process. Use case ends in goal abandonned AuthenticationCancelled.
2a. Exception{LoginNotReceived }
2a.1 Use case ends in f ailure AuthenticationFailed.
3a. Wrong login id or password.
3a.1 Use case continues at Step 1.
258
A.3. Crisis Management System Case Study
Context-Affecting Exceptions and Handler Use Cases
Handler Use Case: SuspendHelicopterActivities
Scope: Car Crash Crisis Management System
Handler Class: Safety
Context & Exception: ManageCrisis{SevereWeatherWarning}
Primary Actor: None
Secondary Actor: WeatherInformationSystem, Pilot
Intention: Due to bad weather conditions and resulting safety risks for helicopter pilots and transported
people, the intention of the System is to abort / suspend current helicopter missions as soon as possible,
and instruct pilots that are on stand-by to stay on ground until further notice.
Level: User goal
Main Success Scenario:
Step 1 is repeated for each helicopter pilot that is available or currently executing a mission.
1. System notifiesS Pilot of bad weather conditions. reliability
System switches into degraded mode NoHelicoptersAvailable.
Use case ends in success HelicopterActivitiesSuspended.
Extensions:
1a. Exception{SendFailure}
Handler Use Case: PrepareForStrike
Scope: Car Crash Crisis Management System
Handler Class: Reliability
Context & Exception: ManageCrisis{StrikeNotification}
Primary Actor: Coordinator
Secondary Actor: ExternalResourceSystem (ERS)
Intention: The intention of the Coordinator is to inform the system of a scheduled strike, thus allowing
the system to ask for external help, if possible.
Level: User goal
Main Success Scenario:
1. System requests strike information1 from Coordinator. reliability
2. Coordinator provides strike information1 to System. reliability
3. System requests replacement workers from the appropriate ERS for the duration of the strike.
reliability
4. ERS confirms availability of external resources to System.
Use case ends in success StrikeHasNoEffects.
Extensions:
1a. Exception{SendFailure}
2a. Exception{ResponseFailure}
3a. No appropriate ERS is known. System activates strike mode. Use case ends in degraded StrikeModeActivated.
4a. ERS informs System that request can not be granted. System activates strike mode. Use case ends
in degraded StrikeModeActivated
4b. Exception{ERSUnreachable}
1 Strike
information includes which kind of workers are going on strike, the percentage of workers that are going on
strike, the scheduled date and duration of the strike, etc.
259
A.3. Crisis Management System Case Study
Use Case: ActivateStrikeMode
Primary Actor: None
Secondary Actor: SuperObserver
Intention: The intention of the System is to inform the SuperObservers of a scheduled strike that could
not be tolerated with the help of external resources.
Level: Subfunction-level
Main Success Scenario:
Step 1 is repeated for each SuperObserver.
1. System provides SuperObserver with information about forthcoming strike. reliability
System switches into degraded mode ReducedServiceProvision.
Use case ends in success StrikeModeActivated.
Extensions:
1a. Exception{SendFailure}
Handler Use Case: ManageExplosionRisk
Handler Class: Safety
Context & Exception: ManageCrisis{ExplosionRisk}
Primary Actor: Coordinator
Secondary Actor: SuperObserver, ExternalResourceSystem (ERS), NationalCrisisCenter
Intention: The intention of the Coordinator is to ensure the safety of the Workers if there is a risk of
explosion.
Level: User goal
Main Success Scenario:
1. System requestss explosion risk information1 from SuperObserver. reliability
2. SuperObserver providesR explosion risk information1 to System. reliability
Step 3 is repeated for every active mission.
3. System notifiesS Worker of explosion risk, and of mission suspension, where appropriate2 . safety
4. System processes explosion risk reduction mission.
5. ERS informs System that explosion risk is minimal. reliability
Step 6 is repeated for every suspended mission.
6. System notifiesS Worker that mission can resume. reliability
Use case ends in success ExplosionRiskManaged.
Extensions:
1a. Exception{SendFailure}
2a. Exception{ResponseFailure}
2b. Exception{SuperObserverNotResponsive}
3a. System judges that explosion risk is too high.
3a.1 System suggests to notify the NationalCrisisCenter and cancels the crisis management.
Use case ends in f ailure ExplosionRiskTooHigh.
5a. Exception{ExplosionRiskReductionMissionFailure}
6a. Exception{SendFailure}
1 Explosion
2 The
risk information includes which the affected area, the severity of the risk/potential damage, etc.
mission is suspended if the safety risk is too high, i.e. if the mission is to be carried out in the affected area.
Use Case: ContactNationalCrisisCenter
Primary Actor: None
Secondary Actor: Coordinator, NationalCrisisCenter
Intention: The intention of the System is to inform the NationalCrisisCenter of the crisis if the Coordinator
approves it.
260
A.3. Crisis Management System Case Study
Level: Subfunction-level
Main Success Scenario:
1. System notifies Coordinator that it suggests to contact the NationalCrisisCenter.
2. Coordinator instructs System to contact the NationalCrisisCenter.
3. System sends complete crisis information to NationalCrisisCenter. safety
4. NationalCrisisCenter notifies System that it received the crisis information.
Use case ends in success NationalCrisisCenterContacted.
Extensions:
4a. Exception{NationalCrisisCenterUnreachable}
Handler Use Case: VIPTreatment
Handler Class: Safety
Context & Exception: ManageCrisis{VIPInvolvement}
Primary Actor: None
Secondary Actor: SuperObserver, Worker, Coordinator
Intention: Because of the VIP nature of one of the involved victims, the System hands control of the crisis
management over to an external authority.
Level: User goal
Main Success Scenario:
Step 1 is repeated for each mission that is currently being processed.
1. System notifiesS Worker that mission is to be aborted. reliability
2. System instructs Coordinator to inform the appropriate external authorities. reliability, safety
Steps 3 and 4 can be performed in any order.
3. System informs Coordinator that all missions have terminated.
4. Coordinator informs System that external authority has taken over management of crisis. reliability
Use case ends in success CrisisMnagedByVIPAuthority.
Extensions:
1a. Exception{SendFailure}
4a. Exception{VIPAuthorityUnreachable}
Handler Use Case: ApplyCrimeNorms
Handler Class: Reliability
Context & Exception: ManageCrisis{CrimeSuspicion}
Primary Actor: None
Secondary Actor: SuperObserver, Worker, Coordinator
Intention: Because the car crash is connected to a crime, the System wants to inform all Workers that
they should adhere to the crime policies when executing their missions.
Level: User goal
Main Success Scenario:
Step 1 is repeated for each mission that is currently being processed.
1. System notifiesS Worker that mission is to be carried out following crime policy. reliability
2. System instructs Coordinator to inform the appropriate external authorities. reliability
Use case ends in success CrimePoliciesApplied.
Extensions:
1a. Exception{SendFailure}
3a. Exception{CrimeAuthorityUnreachable}
Fig. A–26 shows the use cases, exceptions and handlers related to the user goal ManageCrisis in the Car Crash Crisis Management System, by means of an extended use case
diagram.
261
Witness
262
External
Resource
System
<<include>>
Assign
IntResource
*
Observe
<<i&c>>
CreateMission
<<include>>
SendMessage
<<include>>
<<reliability handler>>
CheckFirstAid
Worker
Respond and SendMessage subfunctional use cases are included
in most of the above use cases
<<include>>
<<include>>
Exception:
{NoMessageFromSO}
Request
ExtResource
<<include>>
<<include>>
<<i&c>>
Exception:
{CrimeSuspicion}
Exception:
{StrikeNotification}
c>>
<<i&
c>>
SendSMS
<<include>>
ToleratePDA
Failure
<<reliability handler>>
Exception:
{PDAConnectionFailure}
Rescue
<<i&c>>
Transport
<<reliability handler>>
Authenticate
User
<<include>>
Respond
<<include>>
RequestLogin
Remove
Obstacle
ReportMission
Outcome
AddressMission
Failure
<<reliability handler>>
Update
ResDatabase
Activate
StrikeMode
<<include>>
PrepareForStrike
Exception:
{MissionExecFailure}
Retry
<<reliability handler>>
ExecuteMission
<<include>>
<<i&
Exception:
{EmplUnresponsive}
<<i&c>>
>
Figure A–26: Car Crash Case: Exceptional Use Case Diagram
Super
Observor
ContactNational
CrisisCenter
Select Alt Worker
<<reliability handler>>
<<include>>
Exception:
{ExtResReqDenied}
Exception:
{EmpNeverArrives,
EmpNeverLeaves}
<<reliability handler>>
ApplyCrimeNorms
ConcludeCrisis
>
i&c
<<exceptional>>
NationalCrisisCenter
1
>>
i&c
<<
ProcessMission
<<
Update
Availability
Update
Location
<<include>>
Exception:
{ContactFailure,
EmplUnresponsive
Suggest Alternate
Missions
<<reliability handler>>
<
>>
<i&c
Exception:
{EmplUnavailable}
<<include>>
c>>
<<i&
Exception:
{SevereWeatherWarning}
<<i&c>>
*
Internal
FirstAid
Worker
<<include>>
CompensateWith
ExtRes
<<reliability handler>>
CreateCrisis
<<include>>
<<include>>
<<include>>
ProcessCrisis
<<include>>
InitiateCrisis
<<include>>
<<i&c>>
>
*
Surveillance
System
*
Phone
Company
Coordinator
1
1
ManageCrisis
c>
<<i&c>>
1..*
c>>
<<i&
<<i&c>>
ManageExplosion
Risk
Exception:
{ExplosionRisk}
Exception:
{VIPInvolvement}
SuspendHelicopter
Activities
<<safety handler>>
Crisis Management System: Car Crash Case Study
i&
<<
<<i&c>>
<<reliability handler>>
VIPTreatment
<<reliability handler>>
<<exeptional>>
Weather
InformationSystem
1
PDA
GSM
System
Admin
1
1
1
A.3. Crisis Management System Case Study
A.3. Crisis Management System Case Study
A.3.2
DREP Activity Diagrams
Fig. A–27 shows an example activity diagram of the CMS.
missionDetails: MissionDescription
AssignInternalResource
missionDetails:
MissionDescription
DetermineMost
AppropriateEmpl
chosenEmpl:
CMSEmployee
<<success>>
[chosenEmpl.loggedIn]
chosenEmpl:
CMSEmployee
[else]
Request
Login
loggedEmpl:
CMSEmployee
<<failure>>
EmplNotLoggedIn
LoginRequestNotSent
<<success>>
EmplLoggedIn
loggedEmpl:
CMSEmployee
SendMission
Information
informedEmpl:
CMSEmployee
<<failure>>
SendFailure
<<success>>
Stopped
informedEmpl:
CMSEmployee
<<failure>>
MissionRefused
ResponseFailure
AwaitingMission
Acceptance
assignedEmpl:
CMSEmployee
assignedEmpl:
CMSEmployee
<<success>>
MissionAccepted
<<failure>>
EmplUnavailable
<<success>>
MissionAssigned
Figure A–27: Car Crash Case Study: Assign Internal Resource Activity Diagram
263
A.3. Crisis Management System Case Study
A.3.3
DREP Exception Table
The exceptions and handlers identified in the CMS are listed in Tables A–4, A–5, and
A–6.
Table A–4: Car Crash CMS: Context-Affecting Exceptions Summary Table
Exception
Description
Context
Handler
Detection
Severe Weather
Warning
Low visibility due to bad
weather
Manage Crisis
Weather Information System
Strike Notification
Explosion Risk
System is informed of a
scheduled strike
Risk of explosion on site
due to crash
Victim is a VIP and needs
to be treated by external
authority
Use of special policies due
to criminals involved in
crash
Manage Crisis
Suspend
Helicopter
Activities
Prepare For
Strike
Manage Explosion Risk
VIP Treatment
Apply
Crime
Norms
Worker
VIP
ment
Involve-
Crime Suspicion
A.3.4
Manage Crisis
Manage Crisis
Manage Crisis
Coordinator
SuperObserver
Worker
DREP Mode Table
Table A–7 summarizes the different modes of operations in CMS.
264
A.3. Crisis Management System Case Study
Table A–5: Car Crash CMS: Service-Related Exceptions Summary Table
Exception
Description
Context
Handler
Detection
Crisis Not Created
System unable to create crisis
record
System does not receive complete crisis information
System does not receive images
from the camera
System is denied request for external resource
Initiate Crisis
-
Create Crisis
-
Incomplete crisis information
Crisis Coordinator
Initiate Crisis
-
Process Mission
System is unable to assign an
internal worker to the mission
Process Mission
System cannot assign find any
alternate resources
System does not receive any
status updates from worker
Process Mission
Suggest
Alternate
Missions
Compensate
with External
Resource
-
Process Mission
Check
First
Aid Worker
Timeout on workers’
response or lack or resources
Lack of internal resources
Timeout on worker response
System pings worker and gets
no response
First aid worker fails to complete mission execution
System does not receive position of worker within a reasonable time period
System does not receive any final report from worker
System fails to contact worker
to request login
System is waiting for acceptance of mission message from
worker
System fails to send message to
user
Process
Mission
(2c, 4b)
Process Mission
Reassign Mission
Address Mission Failure
Check
First
Aid Worker
Timeout on worker response
Timeout on worker response
Timeout on worker response
Process Mission
-
Assign
Internal
Resource
Assign
Internal
Resource
Reassign
Worker (incl)
Reassign
worker (incl)
Timeout on worker response
Timeout on worker response
Timeout on worker response
Assign
Internal
Resource
Reassign
worker (incl)
Response Failure
System does not receive message from user
Assign
Internal
Resource
Reassign
worker (incl)
ERS Unreachable
System is unable to communicate with ERS
System does not receive crisis
information from observer
System pings worker and does
not receive any reply
System does not receive mission information from observer
System pings worker and gets
no response
System does not receive mission information from observer
System does not receive confirmation of crisis conclusion
System is unable to contact
user
System does not receive message from user
Request External
Resource
Execute Super Observer Mission
Execute Super Observer Mission
Create Mission
-
System in unable to send SMS
to user
System cannot communicate
with the user via PDA
System in unable to communicate using alternate ways
System cannot authenticate
user
System does not receive login
details from user
System cannot communicate
with the user via PDA
System attempts to send message via SMS
System does receive login info
from user
Call Disconnected
Camera Failure
External Resource
Request Denied
Internal First Aid
Worker
Unavailable
Compensated with
Alternate Missions
First Aid Worker
Never Arrives On
Site
First Aid Worker
Unresponsive
Mission Execution
Failure
First Aid Worker
Never Leaves Site
Outcome Not Reported
Login Request Not
Sent
User Not Logged
In
Send Failure
No Message from
Super Observer
First Aid Worker
Unavailable
No Message from
Super Observer
First Aid Worker
Unresponsive
No Message from
Super Observer
Crisis Not Concluded
SMS Not Sent
Response Failure
GSM Not Responsive
PDA Connection
Failure
Communication
Impossible
Authentication
Failed
Authentication
Cancelled
PDA Connection
Failure
Communication
Impossible
Login
Not
Received
Process Mission
Check
First
Aid Worker
-
Timeout on camera device
ERS notification
Exception
{Communication
Impossible}
Exception
{Communication
Impossible}
Timeout on ERS response
Timeout on observer
response
Timeout on worker response
Timeout on observer
response
Timeout on worker response
Timeout on message
from super observer
Timeout after reasonable period
GSM system cannot deliver message
Exception
{Communication
Impossible}
Timeout on GSM ack
Create Mission
Check
First
Aid Worker
-
Report
Mission
Outcome
Conclude Crisis
Check
First
Aid Worker
-
Request Login
-
Request Login
-
Send SMS
-
Send Message
Message not delivered
Send Message
Tolerate PDA
Failure
-
Respond
-
Respond
-
Respond
Respond
Tolerate PDA
Failure
-
Timeout on valid response
Timeout on user response
Message not delivered
Authenticate
-
265
SMS undelivered
SMS undelivered
Timeout on login info
A.3. Crisis Management System Case Study
Table A–6: Car Crash CMS: Service-Related Exceptions in Handlers Summary Table
Exception
Description
Context
Handler
Detection
External Resource
Request Denied
System is unable to compensate with external workers
System pings worker and receives no message from worker
Message sending via GSM fails
Suggest
Alternate
Missions
-
ERS response
First Aid Worker
Unresponsive
SMS Not Sent
Send Failure
System fails to sends message
to user
Send Failure
System fails to sends message
to user
Compensate with
External Resource
Handler
Check First Aid
Worker Handler
Tolerate PDA Failure Handler
Suspend
Helicopter
Activities
Handler
Prepare For Strike
Handler
Response Failure
System does not receive message from user
Prepare for Strike
Handler
-
ERSUnreachable
System is unable to communicate with ERS
System fails to sends message
to user
Prepare for Strike
Handler
Activate
Strike
Mode Handler
-
Send Failure
System fails to sends message
to user
Manage Explosion
Risk Handler (1,6)
-
Response Failure
System does not receive message from user
Manage Explosion
Risk Handler
-
Super
Observer
Not Responsive
Super Observer does not respond to System’s request
Manage Explosion
Risk Handler
-
Explosion
Risk
Reduction Mission
Failure
National
Crisis
Center
Unreachable
Send Failure
System does not receive any response from ERS regarding risk
reduction
System does not receive response from NCC
Manage Explosion
Risk Handler
-
-
Timeout on NCC response
System fails to sends message
to user
Contact National
Crisis Center Handler
VIP
Treatment
Handler
-
VIP Authority Unreachable
System is unable to contact external authority
VIP
Treatment
Handler
-
Send Failure
System fails to sends message
to user
Apply
Crime
Norms Handler
-
Crime Authority
Unreachable
System is unable to contact external authority
Apply
Crime
Norms Handler
-
Exception
{Communication
Impossible}
Timeout on external
authority response or
lack of resource response
Exception
{Communication
Impossible}
Timeout on external
authority response or
lack of resource response
Send Failure
-
-
-
Timeout on worker response
Exception
{GSMNotResponsive}
Exception
{Communication
Impossible}
Exception
{Communication
Impossible}
Exception
{Communication
Impossible}
Timeout on ERS response
Exception
{Communication
Impossible}
Exception
{Communication
Impossible}
Exception
{Communication
Impossible}
Exception
{Communication
Impossible}
Timeout on ERS response
Table A–7: CMS: DREP Mode Table
Mode
Normal
Type
Normal
Blackout
Emergency
ReducedServiceProvision
Degraded
NoHelicoptersAvailable
Degraded
Description
Services available and
correctly functioning
Coordinator unable to
manage crisis due to
city-wide power outage
Internal or external
workers not available
due to strike
Helicopter unsafe to be
used in severe weather
conditions
266
Services
All
normal
available
No
normal
available
services
services
Limited rescue services
available
Helicopter service unavailable
APPENDIX B
DREP Checklist
Project: _________________________________________________________
Analyst: _________________________________________________________
Iteration: _________________
Date:
_________________
Phase 1: Requirements Elicitation and Discovery
Task 1: Discovering Actors, Goals, and Modes
1.1 Brainstorm services/goals and outcomes
1.2 Brainstorm actors
1.3 Classify services/goals and actors
1.4 Decompose services into subgoals
1.5 Brainstorm modes
Task 2: Discovering Context-Affecting Exceptions
2.1 Brainstorm context-affecting exceptions
2.2 Define new exceptional detection actors
Task 3: Eliciting Handlers for Context-Affecting Exceptions
3.1 Discover and classify exceptional services
3.2 Decompose exceptional services into subgoals
3.3 Discover new exceptional secondary actors
Task 4: Eliciting Dependability Expectations and Discovering Exceptional Modes
4.1 Eliciting dependability expectations for each service
4.2 Document provided reliability and safety of mandatory secondary actors
4.3 Discover exceptional modes of operation
Phase 2: Requirements Definition and Specification
Task 5: Designing Interactions
5.1 Design goal interaction steps
5.2 Specify goal outcomes
5.3 Define new (exceptional) secondary actors
5.4 Design handler interaction steps
5.5 Specify handler outcomes
5.6 Add mode switches to handler steps
Task 6: Defining Service-Related Exceptions and Effects on Reliability and Safety
6.1 Document expected reliability and safety for actors
6.2 Annotate subgoal and handler steps with reliability and safety
6.3 Define service-related exceptions
267
Phase 3: Dependability Requirements Analysis
Task 7: Assessing Safety and Reliability
7.1 Create/revise DA-Chart
7.2 Perform reliability and safety analysis
7.3 Compare dependability analysis results with expected dependability values
Phase 4: Dependability-based Refinement
Task 8: Specifying Detection Mechanisms
8.1 Add detection actors
8.2 Add detection interaction steps and revisit goal outcomes
8.3 Add detection interaction steps for handlers
Task 9: Specifying Handler Use Cases
Task 10: Defining Degraded Modes
Phase 5: Requirements Summary and Documentation
Task 11: Use Case Summary
11.1 Create standard use case diagram
11.2 Create exceptional use case diagram
11.3 Create summary actor list
11.4 Document achievable reliability and safety for services
Task 12: Summary Tables
12.1 Exception summary table
12.2 Mode summary table
Task 13: Create Activity Diagrams
Task 14: Construct Communication Diagram
268
APPENDIX C
ANZAC ECS Use Cases
ANZAC Use Case Descriptions
Use Case: Enter Cabin
System: ElevatorControl
Level: Sub-Function
Intention in Context: The User intents to enter the elevator cabin at a certain floor.
Primary Actor: User
Main Success Scenario:
1. User makes a request to System for cabin
2. System requests Motor to move towards source floor; Motor goes in direction of source floor
Step 3 is repeated until System determines that the source floor of the User has been reached
3. Sensor informs System that cabin has reached a certain floor
4. System requests Motor to stop cabin; Motor stops cabin and informs System that it is stopped;
5. System requests Door to open, and informs User that request has been fulfilled; Door opens
6. User enters cabin at source floor
Extensions:
2a. System is serving another request:
2a.1. System schedules the request; use case continues at step 2 (when System decides to
serve this request).
2b. System determines that cabin is already at requested floor; use case continues at step 51.
(2-6)a. User walks away2; use case ends in failure
Timing Requirements:
Step 3: “It takes at least 1.5 seconds and at most 2 seconds to go from one floor to another one”.
Step 4: “the system must decide within 0.1 seconds if it is to stop the cabin”.
Notes:
1
It is possible that the door may already be open (assumption: requesting door to open while it is
already open will make it stay open for a new time period).
2
This is not detectable by the System. The only way the System could determine that the user
has left is if it times-out on waiting for a request.
ECS EnterFigure
Cabin9.2:
UseEnter
CaseCabin
(Reproduced
with
permission from
Fig. 9.2 [188])
use case for
ElevatorControl
system
The Enter Cabin use case has three extension steps. The first two extension steps are alternatives to step 2. The first extension step (2a) is taken if the system is already busy with
another request. In this case, the system schedules the request for later. This extension step
rejoins the main scenario at step 2, which indicates that the request will eventually be served
by the system. The second extension step (2b) is taken if the request made by the user is for
the same floor as the one where the cabin is stationed. In this case, the use case joins the
main scenario where the system asks the door to open. The third extension step (2-6 a) is an
269
alternative to any step between 2 and 6 inclusive.
The step is used to show the scenario
when the user simply walks away. Although this step is not directly detectable by the system, it is worth mentioning because it is a fact of the environment that may at some point be
relevant to the system. For example, this point may deter any decisions that would force the
cabin to wait for the user’s internal request (after the external request has been serviced).
Exit Cabin use case
The Exit Cabin use case captures the goal of the user to exit the cabin at his/her destination
ANZAC Specification
Use Case: Exit Cabin
System: ElevatorControl
Level: Sub-Function
Intention in Context: The User intents to leave the elevator cabin at a certain floor.
Primary Actor: User
Main Success Scenario:
Steps 1 and 2 can happen in any order
1. User makes a request to System to go to a floor
2. Door times-out on open period and closes itself, and informs System that it is closed
3. System requests Motor to move towards destination floor; Motor goes in direction of
destination floor
Step 4 is repeated until System determines that the destination floor of the User has been reached
4. Sensor informs System that cabin has reached a certain floor
5. System requests Motor to stop cabin; Motor stops cabin and informs System that it is stopped;
6. System requests Door to open, and informs User that request has been fulfilled; Door opens
7. User exits cabin at destination floor
Extensions:
2a. System determines that cabin is already at requested floor; use case continues at step 61.
(2-6)||a. User requests System to go to a different floor2:
(2-6)||a.1. System schedules the request; use case joins main scenario.
3a. System decides to serve another request:
3a.1. System schedules the request; use case continues at step 3 (when System decides to
serve this request).
3b. System is serving another request (step 2 occurred before step 1):
3b.1. System schedules the request; use case continues at step 3 (when System decides to
serve this request).
7a. User has additional requests pending3: use case continues at step 2.
Timing Requirements:
Step 4: “It takes at least 1.5 seconds and at most 2 seconds to go from one floor to another one”.
Step 5: “the system must decide within 0.1 seconds if it is to stop the cabin”.
Step 6: “The door is guaranteed to stay open for at least 5 seconds”.
Notes:
1 It is possible that the door may already be open (assumption: requesting door to open while it is
already open will make it stay open for a new time period).
2 There is no canceling of requests.
3 System cannot make a difference between a single user making many requests and many
users each making a request.
Figure Use
9.3: Exit
use case for
ElevatorControl
system
ECS Exit Cabin
CaseCabin
(Reproduced
with
permission from
Fig. 9.3 [188])
9.3
ANZAC Specification
In this section, I describe the ANZAC specification for the ElevatorControl system. In
section 9.3.1, I present the Concept Model for the ElevatorControl system. From thereon, I
describe the steps taken to derive and refine the ANZAC specification from the ANZAC use
case descriptions for the ElevatorControl system. These steps follow the ANZAC mapping
technique described in Chapter 8.
270
226
APPENDIX D
Non-functional Requirement (NFR) List
accessibility
adaptability
affordability
availability
capacity
cohesiveness
communication time
comprehensibility
confidentiality
controllability
correctness
customer evaluation time
data-space performance
dependability
distributivity
domain analysis time
enhanceability
extensibility
feasibility
generality
impact analyzability
inspection cost
inter-operability
learnability
maintenance cost
mean performance
nomadicity
operability
perfomability
planning time
precision
productivity
promptness
reconfigurability
reengineering cost
replaceability
risk analysis cost
safety
security
simplicity
space boundedness
stability
supportability
susceptibility
testing time
timeliness
trainability
usability
variability
visibility
accountability
additivity
agility
buffer space performance
clarity
commonality
compatibility
conceptuality
configurability
coordination cost
cost
customer loyalty
decomposability
development cost
diversity
efficiency
evolvability
external consistency
flexibility
guidance
independence
inspection time
internal consistency
main-memory performance
maintenance time
measurability
observability
operating cost
performance
plasticity
predictability
project stability
prototyping cost
recoverability
reliability
replicability
risk analysis time
scalability
sensitivity
software cost
space performance
standardizability
surety
sustainability
throughput
tolerance
uniform performance
user-friendliness
verifiability
wrappability
accuracy
adjustability
auditability
capability
code-space performance
communication cost
completeness
conciseness
consistency
coordination time
coupling
customizability
degradation of service
development time
domain analysis cost
elasticity
execution cost
fault-tolerance
formality
hardware cost
informativeness
integrity
intuitiveness
maintainability
maturity
mobility
off-peak period performance
peak-period performance
planning cost
portability
process management time
project tracking cost
prototyping time
recovery
repeatability
response time
robustness
secondary-storage performance
similarity
software production time
specificity
subjectivity
survivability
testability
time performance
traceability
uniformity
validity
versatility
A List of Non-functional Requirements (Reproduced from Table 5.2 [37])
271
References
[1] Jean-Raymond Abrial. The B Book - Assigning Programs to Meanings. Cambridge
University Press, August 1996.
[2] Nawal Addouche, Christian Antoine, and Jacky Montmain. Methodology for UML
modeling and formal verification of real-time systems. In CIMCA/IAWTIC, page 17.
IEEE Computer Society, 2006.
[3] Ian F. Alexander. Misuse cases: Use cases with hostile intent. IEEE Software,
20(1):58–66, 2003.
[4] Karen Allenby and Tim Kelly. Deriving safety requirements using scenarios. In
Requirements Engineering, IEEE International Conference on, volume 0, page 0228,
Los Alamitos, CA, USA, 2001. IEEE Computer Society.
[5] Jesús Manuel Almendros-Jiménez and Luis Iribarne. Describing use cases with activity charts. In Metainformatics, volume 3511 of LNCS, pages 141–159. Springer,
2004.
[6] Bruce Anderson. Formalism, technique and rigour in use case modelling. Journal of
Object Technology, 4(6):15–28, 2005.
[7] Ana I. Anton. Goal identification and refinement in the specification of softwarebased information systems. PhD thesis, Georgia Institute of Technology, Atlanta,
GA, USA, 1997.
[8] Jim Arlow and Ila Neustadt. Uml and the Unified Process: Practical Object-Oriented
Analysis and Design. Addison-Wesley Longman Publishing Co., Inc., Boston, MA,
USA, 2002.
[9] Jim Arlow and Ila Neustadt. UML 2 and the Unified Process: Practical ObjectOriented Analysis and Design (2nd Edition) (The Addison-Wesley Object Technology
Series). Addison-Wesley Professional, July 2005.
272
273
[10] Joanne M. Atlee and John Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, 19(1):24–40, January
1993. Special Issue on Software for Critical Systems.
[11] Algirdas Avizienis, Jean-Claude Laprie, and Brian Randell. Fundamental concepts of
dependability. Technical Report Research Report N01145, LAAS-CNRS, April 2001.
[12] Algirdas Avizienis, Jean-Claude Laprie, and Brian Randell. Dependability and its
threats - a taxonomy. In René Jacquart, editor, IFIP Congress Topical Sessions,
pages 91–120. Kluwer, 2004.
[13] Jakob Axelsson. Unified modeling of real-time control systems and their physical
environments using UML. Engineering of Computer-Based Systems, IEEE International Conference on the, 0:0018, 2001.
[14] William Bail. An approach to defining requirements for exceptions. In Christophe
Dony, Jørgen Lindskov Knudsen, Alexander B. Romanovsky, and Anand Tripathi,
editors, Advanced Topics in Exception Handling Techniques, volume 4119 of Lecture
Notes in Computer Science, pages 243–254. Springer, 2006.
[15] William G. Bail. Requirements management for dependable software systems. Advances in Computers, 66:80–143, 2006.
[16] Florencia Balbastro, Alfredo Capozucca, and Nicolas Guelfi. Analysis and frameworkbased design of a fault-tolerant web information system for m-health. Service Oriented Computing and Applications, 2(2-3):111–144, 2008.
[17] Victor R. Basili, Paolo Donzelli, and Sima Asgari. A unified model of dependability:
Capturing dependability in context. IEEE Software, 21(6):19–25, 2004.
[18] Benoit Baudry, Clementine Nebut, and Yves Le Traon. Model-driven engineering for
requirements analysis. In EDOC ’07, page 459, Washington, DC, USA, 2007. IEEE
Computer Society.
[19] S. Bavuso, J. B. Dugan, K. S. Trivedi, B. Rothmann, and E. Smith. Analysis of
typical fault-tolerant architectures using HARP. IEEE Transactions on Reliability,
1987.
[20] Jan A. Bergstra and J. W. Klop. ACP τ : A universal axiom system for process
specification. In M. Wirsing and J. A. Bergstra, editors, Algebraic Methods: Theory,
Tools and Applications, volume 394 of LNCS, pages 447–463. Springer-Verlag, 1987.
[21] Andrey Berlizev and Nicolas Guelfi. Correct analysis for embedded system modeling:
an outcome of east-west scientific cooperation. In SEESE ’08: Proceedings of the 2008
274
international workshop on Software Engineering in east and south europe, pages 23–
30, New York, NY, USA, 2008. ACM.
[22] Andrey Berlizev and Nicolas Guelfi. Fault tolerance requirements analysis using
deviations in the correct development process. In Michael Butler, Cliff B. Jones,
Alexander Romanovsky, and Elena Troubitsyna, editors, Methods, Models and Tools
for Fault Tolerance, volume 5454 of Lecture Notes in Computer Science, pages 275–
296. Springer, 2009.
[23] Andrea Bianco and Luca de Alfaro. Model checking of probabalistic and nondeterministic systems. In P. S. Thiagarajan, editor, FSTTCS, volume 1026 of Lecture
Notes in Computer Science, pages 499–513. Springer, 1995.
[24] Dines Bjorner and Cliff B. Jones. The Vienna Development Method: The MetaLanguage, volume 61 of Lecture Notes in Computer Science. Springer Verlag, 1978.
[25] Alvin M. Blum, Ambuj Goyal, Philip Heidelberger, Stephen S. Lavenberg, Marvin K.
Nakayama, and Perwez Shahabuddin. Modeling and analysis of system dependability
using the system availability estimator. In FTCS, pages 137–141, 1994.
[26] Andrea Bondavalli, Diego Latella, Mario Dal Cin, and Andras Pataricza. High-level
integrated design environment for dependability (hide). Object-Oriented Real-Time
Dependable Systems, IEEE International Workshop on, 0:87, 1999.
[27] Andrea Bondavalli, Ivan Mura, and Istvan Majzik. Automatic dependability analysis for supporting design decisions in UML. In HASE ’99: The 4th IEEE International Symposium on High-Assurance Systems Engineering, page 64, Washington,
DC, USA, 1999. IEEE Computer Society.
[28] Grady Booch, James Rumbaugh, and Ivar Jacobson. Unified Modeling Language User
Guide, The (2nd Edition) (The Addison-Wesley Object Technology Series). AddisonWesley Professional, 2005.
[29] Taylor L. Booth. Sequential Machines and Automata Theory. John Wiley & Sons
Inc, 1967.
[30] Oliver Botti, Vincenzo De Florio, Geert Deconinck, Flavio Cassinari, Susanna Donatelli, Andrea Bobbio, A. Klein, H. Kufner, Rudy Lauwereins, Erwin M. Thurner,
and Eric Verhulst. Tiran: Flexible and portable fault tolerance solutions for cost
effective dependable applications. In Euro-Par ’99: Proceedings of the 5th International Euro-Par Conference on Parallel Processing, pages 1166–1170, London, UK,
1999. Springer-Verlag.
[31] Ian K. Bray. An Introduction to Requirements Engineering. Addison-Wesley, 2002.
275
[32] Frederick P. Brooks, Jr. No silver bullet essence and accidents of software engineering.
Computer, 20(4):10–19, 1987.
[33] Alan W. Brown. Model driven architecture: Principles and practice. Software and
System Modeling, 3(4):314–327, 2004.
[34] CCITT. Recommendation Z.100: Specification and Description Language SDL, blue
book, volume x.1 edition, 1988.
[35] William Chan, Richard J. Anderson, Paul Beame, Steve Burns, Francesmary Modugno, David Notkin, and Jon D. Reese. Model checking large software specifications.
IEEE Trans. Softw. Eng., 24(7):498–520, 1998.
[36] Betty H. C. Cheng and Joanne M. Atlee. Research directions in requirements engineering. In Lionel C. Briand and Alexander L. Wolf, editors, FOSE, pages 285–303,
2007.
[37] Lawrence Chung, Brian A. Nixon, Eric Yu, and John Mylopoulos. Non-Functional
Requirements in Software Engineering (THE KLUWER INTERNATIONAL SERIES
IN SOFTWARE ENGINEERING Volume 5) (International Series in Software Engineering). Springer, October 1999.
[38] Lawrence Chung and Julio Cesar Prado Leite. On non-functional requirements in
software engineering. In A.T. Borgida, V.K. Chaudhri, P. Giorgini, and E.S. Yu,
editors, Conceptual Modeling: Foundations and Applications: Essays in Honor of
John Mylopoulos, pages 363–379. Springer-Verlag, Berlin, Heidelberg, 2009.
[39] M. Dal Cin. Structured language for specifications of quantitative requirements. HighAssurance Systems Engineering, IEEE International Symposium on, 0:221, 2000.
[40] M. Dal Cin. Extending uml towards a useful oo-language for modeling dependability
features. In Object-Oriented Real-Time Dependable Systems, 2003. WORDS 2003
Fall. The Ninth IEEE International Workshop on, pages 325–325, Oct. 2003.
[41] M. Dal Cin, G. Huszerl, and K. Kosmidis. Quantitative evaluation of dependability critical systems based on guarded statechart models. High-Assurance Systems
Engineering, IEEE International Symposium on, 0:37, 1999.
[42] Marcus Ciolkowski, Dirk Muthig, and Jorg Rech. Using academic courses for empirical validation of software development processes. In EUROMICRO ’04: Proceedings
of the 30th EUROMICRO Conference, pages 354–361, Washington, DC, USA, 2004.
IEEE Computer Society.
[43] Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley Longman, 2000.
276
[44] Vittorio Cortellessa and Antonio Pompei. Towards a UML profile for QoS: a contribution in the reliability domain. SIGSOFT Softw. Eng. Notes, 29(1):197–206, 2004.
[45] Luiz Marcio Cysneiros, Julio Cesar Sampaio do Prado Leite, and Jaime de Melo
Sabat Neto. A framework for integrating non-functional requirements into conceptual
models. Requir. Eng., 6(2):97–115, 2001.
[46] Luiz Marcio Cysneiros and Julio Cesar Sampaio do Prado Leite. Nonfunctional
requirements: From elicitation to conceptual models. IEEE Trans. Softw. Eng.,
30(5):328–350, 2004.
[47] Anne Dardenne, Axel van Lamsweerde, and Stephen Fickas. Goal-directed requirements acquisition. Sci. Comput. Program., 20(1-2):3–50, 1993.
[48] Robert Darimont. Process Support for Requirements Elaboration. PhD thesis, Université catholique de Louvain, 1995.
[49] Robert Darimont and Axel van Lamsweerde. Formal refinement patterns for goaldriven requirements elaboration. In SIGSOFT FSE, pages 179–190, 1996.
[50] Alan M. Davis. A taxonomy for the early stages of the software development life
cycle. J. Syst. Softw., 8(4):297–311, 1988.
[51] Alan M. Davis. Software requirements: objects, functions, and states. Prentice-Hall,
Inc., Upper Saddle River, NJ, USA, 1993.
[52] Juan de Lara and Hans Vangheluwe. AToM3 : A tool for multi-formalism and metamodelling. In ETAPS, FASE, Lecture Notes in Computer Science 2306, pages 174 –
188. Springer, April 2002. Grenoble, France.
[53] Juan de Lara and Hans Vangheluwe. Computer aided multi-paradigm modelling to
process petri-nets and statecharts. In International Conference on Graph Transformations (ICGT), volume 2505 of Lecture Notes in Computer Science, pages 239–253.
Springer, October 2002. Barcelona, Spain.
[54] Juan de Lara and Hans Vangheluwe. Defining visual notations and their manipulation
through meta-modelling and graph transformation. Journal of Visual Languages and
Computing, 15(3 - 4):309–330, June - August 2004. Special Issue on Domain-Specific
Modeling with Visual Languages.
[55] R. de Lemos and A. Romanovsky. Exception handling in the software lifecycle.
International Journal of Computer Systems Science and Engineering, 16(2):167 –
181, March 2001.
277
[56] Rogério de Lemos, Amer Saeed, and Tom Anderson. Analyzing safety requirements
for process-control systems. IEEE Software, 12(3):42–53, 1995.
[57] G. Deconinck, V. De Florio, G. Dondossola, H. Kuefner, G. Mazzini, S. Calella, and
S. Donatelli. Distributed embedded automation systems: Dynamic environments and
dependability. In Supplement of the International Conference on Dependable Systems
and Networks (DSN2001 - Special Track: European Dependability Initiative, pages
D16–D19, July 2001.
[58] D8-6: Final Report, DepAuDE Deliverable, 2003.
[59] Giovanna Dondossola and Oliver Botti. System fault tolerance specification: Proposal of a method combining semi-formal and formal approaches. In FASE ’00:
Proceedings of the Third Internationsl Conference on Fundamental Approaches to
Software Engineering, pages 82–96, London, UK, 2000. Springer-Verlag.
[60] Christophe Dony. Exception handling and object-oriented programming: Towards a
synthesis. In OOPSLA/ECOOP, pages 322–330, 1990.
[61] Paolo Donzelli and Victor R. Basili. A practical framework for eliciting and modeling
system dependability requirements: Experience from the NASA high dependability
computing project. Journal of Systems and Software, 79(1):107–119, 2006.
[62] Desmond F. D’Souza and Alan Cameron Wills. Objects, components, and frameworks
with UML: the catalysis approach. Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA, 1999.
[63] Joanne Bechta Dugan, Salvatore Bavuso, and Mark Boyd. Dynamic fault-tree models
for fault-tolerant computer systems. IEEE Transactions on Reliability, 41(3):363–77,
September 1992.
[64] Zaid Dwaikat and Francesco Parisi-Presicce. From misuse cases to collaboration diagrams in uml. In Proceedings of the 3rd International Workshop on Critical Systems
Development with UML, October 2004.
[65] Ali Ebnenasir, Betty H. C. Cheng, and Sascha Konrad. Use case-based modeling and
analysis of failsafe fault-tolerance. In RE, pages 336–337. IEEE Computer Society,
2006.
[66] Peter H. J. Van Eijk and Michel Diaz, editors. Formal Description Technique Lotos:
Results of the Esprit Sedos Project. Elsevier Science Inc., New York, NY, USA, 1989.
[67] 407 ETR. http://www.407etr.com.
278
[68] Thomas Huining Feng. DCharts, a formalism for modeling and simulation based
design of reactive software systems. M.Sc. dissertation, School of Computer Science,
McGill University, 2004.
[69] G. R. M. Ferreira, C. M. F. Rubira, and R. de Lemos. Explicit representation of
exception handling in the development of dependable component-based systems. In
Proceedings of the IEEE International High-Assurance Systems Engineering Symposium (HASE 2001), pages 182–193. IEEE Computer Society, October 2001.
[70] C. J. Fidge and A. M. Lister. Disciplined approach to real-time systems design. Inf.
Softw. Technol., 34(9):603–610, 1992.
[71] Charles Fishman. They write the right stuff. Fast Company, 6:95, December 1996.
[72] Robert France. Modeling dependability features. In Sébastien Gérard, Jean-Philippe
Babau, and Joël Champeau, editors, Model Driven Engineering for Distributed Realtime Embedded Systems. Wiley-ISTE, September 2005.
[73] Robert France and Bernhard Rumpe. Model-driven development of complex software:
A research roadmap. In FOSE ’07: 2007 Future of Software Engineering, pages 37–
54, Washington, DC, USA, 2007. IEEE Computer Society.
[74] Robert B. France, Sudipto Ghosh, Trung Dinh-Trong, and Arnor Solberg. Modeldriven development using UML 2.0: Promises and pitfalls. Computer, 39(2):59–66,
2006.
[75] Kokichi Futatsugi, Joseph A. Goguen, Jean-Pierre Jouannaud, and José Meseguer.
Principles of obj2. In POPL ’85: Proceedings of the 12th ACM SIGACT-SIGPLAN
symposium on Principles of programming languages, pages 52–66, New York, NY,
USA, 1985. ACM.
[76] Jean-Claude Geffroy and Gilles Motet. Design of Dependable Computing Systems.
Kluwer Academic Publishers, 2002.
[77] Geri Georg, Raghu Reddy, and Robert France. Specifying cross-cutting requirement concerns. In Thomas Baar, Alfred Strohmeier, Ana Moreira, and Stephen J.
Mellor, editors, UML 2004 - The Unified Modeling Language. Model Languages and
Applications. 7th International Conference, Lisbon, Portugal, October 11-15, 2004,
Proceedings, volume 3273 of LNCS, pages 113–127. Springer, 2004.
[78] Martin Glinz. On non-functional requirements. Requirements Engineering, IEEE
International Conference on, 0:21–26, 2007.
[79] Hassan Gomaa and Michael Eonsuk Shin. Modeling complex systems by separating application and security concerns. In ICECCS ’04: Proceedings of the Ninth
279
IEEE International Conference on Engineering Complex Computer Systems Navigating Complexity in the e-Engineering Age, pages 19–28, Washington, DC, USA,
2004. IEEE Computer Society.
[80] Cesar Gonzalez-Perez and Brian Henderson-Sellers. Metamodelling for Software Engineering. Wiley Publishing, 2008.
[81] John B. Goodenough. Exception handling: Issues and a proposed notation. Communications of the ACM, 18(12):683 – 696, December 1975.
[82] Object Management Group. MDA Guide Version 1.0.1, June 2003.
[83] Object Management Group. OMG Systems Modeling Language (OMG SysML), V1.0,
September 2007.
[84] Object Management Group. A UML Profile for MARTE: Modeling and Analysis of
Real-time Embedded Systems, Beta 2, June 2008.
[85] Object Management Group. UML Profile for Modeling QoS and FT Characteristics
and Mechanisms v1.1, April 2008.
[86] Javier J. Gutiérrez, Clémentine Nebut, Marı́a J. Escalona, Manuel Mejı́as, and Isabel M. Ramos. Visualization of use cases through automatically generated activity
diagrams. In MoDELS ’08, pages 83–96. Springer-Verlag, 2008.
[87] J.V. Guttag, J.J. Horning, and J.M. Wing. The larch family of specification languages. IEEE Software, 2(5):24–36, 1985.
[88] Kirsten M. Hansen, Anders P. Ravn, and Victoria Stavridou. From safety analysis to
software requirements. IEEE Transactions on Software Engineering, 24(7):573–584,
1998.
[89] D. Harel and A. Pnueli. On the development of reactive systems. Logics and models
of concurrent systems, pages 477–498, 1985.
[90] David Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231–274, June 1987.
[91] David Harel. On visual formalisms. Communications of the ACM, 31(5):514–530,
May 1988.
[92] John C. Hawkins. Extending use cases and interaction diagrams to develop distributed system architecture requirements. PhD thesis, Florida Atlantic University,
Boca Raton, FL, USA, 1997.
280
[93] Raquel L. Hill, Jun Wang, and Klara Nahrstedt. Quantifying non-functional requirements: A process oriented approach. In RE, pages 352–353. IEEE Computer Society,
2004.
[94] Andrew Hinton, Marta Z. Kwiatkowska, Gethin Norman, and David Parker. Prism:
A tool for automatic verification of probabilistic systems. In Holger Hermanns and
Jens Palsberg, editors, TACAS, volume 3920 of Lecture Notes in Computer Science,
pages 441–444. Springer, 2006.
[95] C. A. R. Hoare. An axiomatic basis for computer programming. Commun. ACM,
12(10):576–580, 1969.
[96] C. A. R. Hoare. Communicating sequential processes. Commun. ACM, 21(8):666–
677, 1978.
[97] Martin Höst, Björn Regnell, and Claes Wohlin. Using students as subjects—a comparative study of students and professionals in lead-time impact assessment. Empirical Softw. Engg., 5(3):201–214, 2000.
[98] W. S. Humphrey. The software engineering process: definition and scope. SIGSOFT
Softw. Eng. Notes, 14(4):82–83, 1989.
[99] Russell R. Hurlbut. A survey of approaches for describing and formalizing use cases.
Technical Report XPT-TR-97-03, Expertech, Ltd., 1997.
[100] Gábor Huszerl, István Majzik, András Pataricza, Konstantinos Kosmidis, and
Mario Dal Cin. Quantitative analysis of UML statechart models of dependable systems. Comput. J, 45(3):260–277, 2002.
[101] Alexei Iliasov, Fernando Dotti, and Alexander Romanovsky. Structuring specifications with modes. In Fourth Latin-American Symposium on Dependable Computing
(LADC), Brazil, September 2009.
[102] RTCA Inc. Software considerations in airborne systems and equipment certification.
Radio Technical Commission for Aeronautics (RTCA), European Organization for
Civil Aviation Electronics (EUROCAE), DO178-B, 1992.
[103] Daniel Jackson. Software Abstractions: Logic, Language, and Analysis. The MIT
Press, 2006.
[104] Michael Jackson. Software requirements & specifications: a lexicon of practice, principles and prejudices. ACM Press/Addison-Wesley Publishing Co., New York, NY,
USA, 1995.
281
[105] Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. ObjectOriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1992.
[106] Ivar Jacobson, James Rumbaugh, and Grady Booch. The Unified Software Development Process. Object Technology Series. Addison-Wesley, Reading, Massachusetts,
USA, 1999.
[107] D. N. Jansen, H. Hermanns, and J-P. Katoen. A probabilistic extension of uml
statecharts: specification and verification. In W. Damm and E-R. Olderog, editors,
Formal techniques in real-time and fault-tolerant systems: FTRTFT, volume 2469 of
Lecture Notes in Computer Science, pages 355–374, Berlin, Germany, 2002. Springer.
[108] Jan Jürjens. Umlsec: Extending uml for secure systems development. In UML ’02:
Proceedings of the 5th International Conference on The Unified Modeling Language,
pages 412–425, London, UK, 2002. Springer-Verlag.
[109] Jan Jürjens. Developing safety-critical systems with uml. In Perdita Stevens, Jon
Whittle, and Grady Booch, editors, UML, volume 2863 of Lecture Notes in Computer
Science, pages 360–372. Springer, 2003.
[110] Jan Jürjens. Secure Systems Development with UML. SpringerVerlag, 2003.
[111] Mohamed Kaâniche, Jean-Claude Laprie, and Jean-Paul Blanquart. Dependability
engineering of complex computing systems. In ICECCS, pages 36–. IEEE Computer
Society, 2000.
[112] Mohamed Kaâniche, Jean-Claude Laprie, and Jean-Paul Blanquart. A dependabilityexplicit model for the development of computing systems. In Floor Koornneef and
Meine van der Meulen, editors, SAFECOMP, volume 1943 of Lecture Notes in Computer Science, pages 107–116. Springer, 2000.
[113] Haruhiko Kaiya, Akira Osada, and Kenji Kaijiri. Identifying stakeholders and their
preferences about nfr by comparing use case diagrams of several existing systems.
IEICE Transactions, 91-D(4):897–906, 2008.
[114] Mohamed Kaniche, Jean-Claude Laprie, and Jean-Paul Blanquart. A framework for
dependability engineering of critical computing systems. Safety Science, 40(9):731 –
752, 2002.
[115] Jörg Kienzle. On exceptions and the software development life cycle. In WEH ’08:
Proceedings of the 4th international workshop on Exception handling, pages 32–38,
New York, NY, USA, 2008. ACM.
282
[116] Jörg Kienzle and Shane Sendall. Addressing concurrency in object-oriented software development. Technical Report SOCS-TR-2004.8, McGill University, Montreal,
Canada, December 2004.
[117] Barbara A. Kitchenham, Shari Lawrence Pfleeger, Lesley M. Pickard, Peter W. Jones,
David C. Hoaglin, Khaled El Emam, and Jarrett Rosenberg. Preliminary guidelines
for empirical research in software engineering. IEEE Trans. Softw. Eng., 28(8):721–
734, 2002.
[118] Anneke Kleppe, Jos Warmer, and Wim Bast. MDA Explained: The Model Driven
Architecture—Practice and Promise. Addison-Wesley, 2003.
[119] Jorgen Lindskov Knudsen. Better exception-handling in block-structured systems.
IEEE Software, 4(3):40 – 49, May 1987.
[120] Gerald Kotonya and Ian Sommerville. Integrating safety analysis and requirements
engineering. In APSEC, pages 259–271, 1997.
[121] Gerald Kotonya and Ian Sommerville. Requirements Engineering : Processes and
Techniques (Worldwide Series in Computer Science). John Wiley & Sons, September
1998.
[122] Benjamin L. Kovitz. Practical software requirements: a manual of content and style.
Manning Publications Co., Greenwich, CT, USA, 1999.
[123] Linas Laibinis and Elena Troubitsyna. Fault tolerance in use-case modeling. In
Proceedings of RHAS 2005 - the Workshop on Requirements for High Assurance
Systems, Sep 2005.
[124] J.C. C. Laprie, A. Avizienis, and H. Kopetz, editors. Dependability: Basic Concepts
and Terminology. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 1992.
[125] P. A. Lee and T. Anderson. Fault tolerance - principles and practice. In Dependable
Computing and Fault-Tolerant Systems. Springer Verlag, 2nd edition, 1990.
[126] Woo Jin Lee, Sung Deok Cha, and Yong Rae Kwon. Integration and analysis of use
cases using modular petri nets in requirements engineering. IEEE Transactions on
Software Engineering, 24(12):1115–1130, 1998.
[127] Dean Leffingwell and Don Widrig. Managing Software Requirements: A Unified
Approach (The Addison-Wesley Object Technology Series). Addison-Wesley Professional, October 1999.
[128] N. G. Leveson. Software safety. In T. Anderson, editor, Resilient Computing Systems.
Collins, 1985.
283
[129] N. G. Leveson. SAFEWARE: System Safety and Computers. Addison-Wesley Publishing Company, 1995.
[130] Nancy G. Leveson and Peter R. Harvey. Analyzing software safety. IEEE Transactions on Software Engineering, 9(5):569–579, September 1983.
[131] Liwu Li. Translating use cases to sequence diagrams. In ASE ’00: Proceedings of the
15th IEEE international conference on Automated software engineering, page 293,
Washington, DC, USA, 2000. IEEE Computer Society.
[132] Ben Lieberman. UML activity diagrams: Versatile roadmaps for understanding system behavior. Printed in The Rational Edge, 2001.
[133] Barbara Liskov and Stephen Zilles. Programming with abstract data types. SIGPLAN Not., 9(4):50–59, 1974.
[134] Andrew Lister. Design of dependable real-time systems. In ICSE ’92: Proceedings of
the 14th international conference on Software engineering, pages 35–36, New York,
NY, USA, 1992. ACM.
[135] Oscar López, Miguel A. Laguna, and Francisco J. Garcı́a. Automatic generation of use
cases from workflows: A petri net based approach. In FASE ’02: Proceedings of the
5th International Conference on Fundamental Approaches to Software Engineering,
pages 279–293, London, UK, 2002. Springer-Verlag.
[136] Robyn Lutz, Stacy Nelson, Ann Patterson-Hine, Chad R. Frost, and Doron Tal. Identifying contingency requirements using obstacle analysis. Requirements Engineering,
IEEE International Conference on, 0:263–272, 2005.
[137] Robyn Lutz and Allen Nikora. Failure assessment. In 1st Int’l Forum on Integrated
System Health Engineering and Management for Aerospace (ISHEM’05), Napa, CA,
November 2005.
[138] Robyn R. Lutz. Software engineering for safety. In Proceedings of the 22th International Conference on Software Engineering (ICSE-00), pages 213–226, NY, June
4–11 2000. ACM Press.
[139] Robyn R. Lutz and Ines Carmen Mikulski. Ongoing requirements discovery in highintegrity systems. IEEE Software, 21(2):19–25, 2004.
[140] John Lygeros, Datta N. Godbole, and Mireille E. Broucke. Design of an extended
architecture for degraded modes of operation of AHS, May 26 1995.
284
[141] Neil Maiden and Suzanne Robertson. Integrating creativity into requirements processes: Experiences with an air traffic management system. Requirements Engineering, IEEE International Conference on, 0:105–116, 2005.
[142] Neil Maiden, Suzanne Robertson, and James Robertson. Creative requirements:
invention and its role in requirements engineering. In ICSE ’06: Proceedings of the
28th international conference on Software engineering, pages 1073–1074, New York,
NY, USA, 2006. ACM.
[143] Neil A. M. Maiden, Sara Jones, and Mary Flynn. Integrating RE methods to support
use case based requirements specification. In RE, pages 369–370. IEEE Computer
Society, 2003.
[144] Neil A. M. Maiden and Suzanne Robertson. Developing use cases and scenarios in the
requirements process. In Gruia-Catalin Roman, William G. Griswold, and Bashar
Nuseibeh, editors, ICSE, pages 561–570. ACM, 2005.
[145] Ruth Malan and Dana Bredemeyer. Defining non-functional requirements. Online
at: http://www.bredemeyer.com/pdf files/NonFunctReq.PDF, August 2001.
[146] Ragavan Manian, David W. Coppit, Kevin J. Sullivan, and Joanne Bechta Dugan.
Bridging the gap between systems and dynamic fault tree models. In Annual Reliability and Maintainability Symposium 1999 Proceedings, pages 105–11, Washington,
DC, 18–21 January 1999.
[147] John McDermott and Chris Fox. Using abuse case models for security requirements
analysis. In ACSAC ’99: Proceedings of the 15th Annual Computer Security Applications Conference, page 55, Washington, DC, USA, 1999. IEEE Computer Society.
[148] Bonnie Melhart and Stephanie White. Issues in defining, analyzing, refining, and
specifying system dependability requirements. Engineering of Computer-Based Systems, IEEE International Conference on the, 0:334, 2000.
[149] Stephen J Mellor. Agile MDA. MDA Journal, June 2004.
[150] Tom Mens and Pieter Van Gorp. A taxonomy of model transformation. Electr. Notes
Theor. Comput. Sci., 152:125–142, 2006.
[151] Bertrand Meyer. On formalism in specifications. IEEE Software, 2(1):6–26, 1985.
[152] R. Milner. A Calculus of Communicating Systems. Springer-Verlag New York, Inc.,
Secaucus, NJ, USA, 1982.
[153] UK Ministry of Defence. Draft defence standard 00-56: Safety management requirements for defence systems containing programmable electronics., 1995.
285
[154] UK Ministry of Defence. Interim defence standard 00-58: HAZOP studies on systems
containing programmable electronics., 1996.
[155] Francesmary Modugno, Nancy G. Leveson, Jon D. Reese, Kurt Partridge, and
Sean D. Sandys. Integrated safety analysis of requirements specifications. Requirements Engineering, IEEE International Conference on, 0:148, 1997.
[156] Ana M. D. Moreira, João Araújo, and Isabel Sofia Brito. Crosscutting quality attributes for requirements engineering. In SEKE, pages 167–174, 2002.
[157] Jishnu Mukerji and Joaquin Miller. MDA Guide V1.0.1, 2003.
[158] John Murdoch. System safety: HAZOP and software HAZOP, felix redmill, morris
chudleigh and james catmur, wiley, 1999 (book review). Softw. Test, Verif. Reliab,
10(1):65–66, 2000.
[159] Sadaf Mustafiz and Jörg Kienzle. A survey of software development approaches
addressing dependability. In Nicolas Guelfi, Gianna Reggio, and Alexander B. Romanovsky, editors, FIDJI, volume 3409 of Lecture Notes in Computer Science, pages
78–90. Springer, 2004.
[160] J. Mylopoulos, L. Chung, and B. Nixon. Representing and using nonfunctional requirements: a process-oriented approach. Software Engineering, IEEE Transactions
on, 18(6):483–497, 1992.
[161] I. Nassi and B. Shneiderman. Flowchart techniques for structured programming.
ACM Sigplan Notices, 8(8):12–26, 1973.
[162] Bashar Nuseibeh and Steve Easterbrook. Requirements engineering: a roadmap. In
ICSE ’00: Proceedings of the Conference on The Future of Software Engineering,
pages 35–46, New York, NY, USA, 2000. ACM.
[163] Object Management Group. OCL 2.0 Specification: Version 2.0, June 2005.
[164] Object Management Group. Unified Modeling Language: Superstructure V2.1.2,
November 2007.
[165] Department of Defense (USA). Procedures for performing a failure mode, effects and
criticality analysis. Technical Report MIL-P-1629, United States Military Procedure,
November 1949.
[166] P. Pelliccione, H. Muccini, N. Guelfi, and A. Romanovsky, editors. Software Engineering of Fault Tolerant Systems, volume 19. World Scientific Publishing, 2007.
286
[167] Dewayne E. Perry, Susan Elliott Sim, and Steve Easterbrook. Case studies for software engineers. In ICSE ’06: Proceedings of the 28th international conference on
Software engineering, pages 1045–1046, New York, NY, USA, 2006. ACM.
[168] Tom Peters. The Circle of Innovation: You Can’t Shrink Your Way to Greatness.
Knopf, 1997.
[169] I. Peterson. Fatal Defect: Chasing Killer Computer Bugs. Random House, Inc., New
York, 1995.
[170] James Lyle Peterson. Petri Net Theory and the Modeling of Systems. Prentice Hall
PTR, Upper Saddle River, NJ, USA, 1981.
[171] Carl Adam Petri and Wolfgang Reisig. Petri net. Scholarpedia, 3(4):6477, 2008.
[172] Shari Lawrence Pfleeger. Design and analysis in software engineering: the language
of case studies and formal experiments. SIGSOFT Softw. Eng. Notes, 19(4):16–20,
1994.
[173] Amir Pnueli. The temporal logic of programs. In FOCS, pages 46–57. IEEE, 1977.
[174] G. Popp, J. Jürjens, G. Wimmel, and R. Breu. Security-critical system development
with extended use cases. Asia-Pacific Software Engineering Conference, 0:478, 2003.
[175] Laura L. Pullum. Software fault tolerance techniques and implementation. Artech
House, Inc., Norwood, MA, USA, 2001.
[176] Awais Rashid, Peter Sawyer, Ana M. D. Moreira, and ao Araújo, Jo˙ Early aspects:
A model for aspect-oriented requirements engineerin. In RE ’02: Proceedings of the
10th Anniversary IEEE Joint International Conference on Requirements Engineering, pages 199–202, Washington, DC, USA, 2002. IEEE Computer Society.
[177] Raghu Reddy, Robert France, and Geri Georg. An aspect oriented approach to analyzing dependability features. In Mohamed Kandé, Dominik Stein, Omar Aldawud,
Tzilla Elrad, Jeff Gray, and Jörg Kienzle, editors, 6th International Workshop on
Aspect-Oriented Modeling, March 2005.
[178] B. Regnell, K. Kimbler, and A. Wesslen. Improving the use case driven approach to
requirements engineering. Requirements Engineering, IEEE International Conference
on, 0:40, 1995.
[179] Roadtraffic-Technology.
407 Express Toll Route (ETR), Ontario, Canada.
http://www.roadtraffic-technology.com/projects/407/.
[180] James Robertson. Eureka! why analysts should invent requirements. IEEE Software,
19(4):20–22, 2002.
287
[181] Alexander Romanovsky. A looming fault tolerance software crisis? SIGSOFT Softw.
Eng. Notes, 32(2):1–4, 2007.
[182] Cecı́lia M. F. Rubira, Rogério de Lemos, Gisele Rodrigues Mesquita Ferreira, and
Fernando Castor Filho. Exception handling in the development of dependable
component-based systems. Softw., Pract. Exper., 35(3):195–236, 2005.
[183] James Rumbaugh, Ivar Jacobson, and Grady Booch. Unified Modeling Language
Reference Manual, The (2nd Edition). Pearson Higher Education, 2004.
[184] Douglas C. Schmidt. Guest editor’s introduction: Model-driven engineering. Computer, 39(2):25–31, 2006.
[185] Geri Schneider and Jason P. Winters. Applying Use Cases: A Practical Guide. Object
Technology Series. Addison-Wesley, Reading/MA, 1998.
[186] Carolyn B. Seaman. Qualitative methods in empirical studies of software engineering.
IEEE Trans. Softw. Eng., 25(4):557–572, 1999.
[187] Optimal Security. Requirements document: Version 0.8. Confidential, March 2009.
[188] Shane Sendall. Specifying Reactive System Behavior. PhD thesis, Ecole Polytechnique
Fédérale de Lausanne (EPFL), School of Computer and Communication Sciences,
Software Engineering Laboratory, 1015 Lausanne, Switzerland, 2002.
[189] Shane Sendall and Alfred Strohmeier. Uml-based fusion analysis. In UML’99, Fort
Collins, CO, USA, October 28-30, 1999, number 1723 in Lecture Notes in Computer
Science, pages 278–291. Springer Verlag, 1999.
[190] Mary Shaw. Everyday dependability for everyday needs. In Supplemental Proceedings
of the 13th International Symposium on Software Reliability Engineering, pages 7–11.
IEEE Computer Society, 2002.
[191] Mary Shaw. “Self-healing”: softening precision to avoid brittleness: position paper
for WOSS ’02: workshop on self-healing systems. In David Garlan, Jeff Kramer, and
Alexander L. Wolf, editors, WOSS, pages 111–114. ACM, 2002.
[192] Mary Shaw. Helping everday users establish confidence for everyday applications.
In Margaret M. Burnett, Gregor Engels, Brad A. Myers, and Gregg Rothermel, editors, End-User Software Engineering, volume 07081 of Dagstuhl Seminar Proceedings.
Internationales Begegnungs- und Forschungszentrum für Informatik (IBFI), Schloss
Dagstuhl, Germany, 2007.
288
[193] C. Shea and C.W. Johnson. The contribution of degraded modes of operation as a
cause of incidents and accidents in air traffic management. In Proceedings of the 25th
ISSC, pages 616–626, 2007.
[194] Mohammad Jamal Sheikh. Exception handling in software analysis. M.Sc. thesis,
School of Computer Science, McGill University, 2007.
[195] Charles P. Shelton and Philip Koopman. Improving system dependability with functional alternatives. In DSN ’04: Proceedings of the 2004 International Conference
on Dependable Systems and Networks, page 295, Washington, DC, USA, 2004. IEEE
Computer Society.
[196] Michael E. Shin and Hassan Gomaa. Software requirements and architecture modeling for evolving non-secure applications into secure applications. Science of Computer
Programming, 66(1):60 – 70, 2007. Special Issue on the 5th International Workshop
on System/Software Architectures (IWSSA’06).
[197] Guttorm Sindre and Andreas L. Opdahl. Eliciting security requirements by misuse
cases. In TOOLS (37), pages 120–131. IEEE Computer Society, 2000.
[198] Guttorm Sindre and Andreas L. Opdahl. Eliciting security requirements with misuse
cases. Requir. Eng., 10(1):34–44, 2005.
[199] Stéphane S. Somé. An approach for the synthesis of state transition graphs from use
cases. In Ban Al-Ani, Hamid R. Arabnia, and Youngsong Mun, editors, Software
Engineering Research and Practice, pages 456–464. CSREA Press, 2003.
[200] Stéphane S. Somé. An environment for use cases based requirements engineering.
Requirements Engineering, IEEE International Conference on, 0:364–365, 2004.
[201] Stephane S. Some. Use cases based requirements validation with scenarios. In RE ’05:
Proceedings of the 13th IEEE International Conference on Requirements Engineering,
pages 465–466, Washington, DC, USA, 2005. IEEE Computer Society.
[202] Ian Sommerville. Software Engineering, 8th Edition. Addison-Wesley, 2007.
[203] Ian Sommerville and Pete Sawyer. Requirements Engineering: A Good Practice
Guide. John Wiley & Sons, Inc., New York, NY, USA, 1997.
[204] J. M. Spivey. Introducing Z: A Specification Language and its Formal Semantics.
Cambridge University Press, 1988.
[205] Deepti Srivastava and Priya Narasimhan. Architectural support for mode-driven
fault tolerance in distributed applications. ACM SIGSOFT Software Engineering
Notes, 30(4):1–7, 2005.
289
[206] Alfred Strohmeier, Thomas Baar, and Shane Sendall. Applying fondue to specify a
drink vending machine. Electronic Notes in Theoretical Computer Science, 102:155 –
173, 2004. Proceedings of the Workshop, OCL 2.0 - Industry Standard or Scientific
Playground?
[207] Ximeng Sun. A model-driven approach for scenario-based requirements engineering.
M.Sc. thesis, School of Computer Science, McGill University, 2007.
[208] S. Supakkul and L. Chung. A UML profile for goal-oriented and use case-driven
representation of NFRs and FRs. In Software Engineering Research, Management
and Applications, 2005. Third ACIS International Conference on, pages 112–119,
Aug. 2005.
[209] D1-1: Requirements Specification - Version 2, TIRAN Project Deliverable, October
1999. confidential.
[210] D3-3: Guideline for Framework Users V4, TIRAN Project Deliverable, October 2000.
confidential.
[211] D7-9: Project Final Report, TIRAN Project Deliverable, October 2000. confidential.
[212] Axel van Lamsweerde. Goal-oriented requirements engineering: A guided tour. In
RE, page 249. IEEE Computer Society, 2001.
[213] Axel van Lamsweerde and Emmanuel Letier. Integrating obstacles in goal-driven
requirements engineering. In ICSE, pages 53–62, 1998.
[214] Axel van Lamsweerde and Emmanuel Letier. Handling obstacles in goal-oriented
requirements engineering. IEEE Trans. Software Eng, 26(10):978–1005, 2000.
[215] Nandamudi Lankalapalli Vijaykumar, Solon Venâncio de Carvalho, Valéria
Maria Barros de Andrade, and Vakulathil Abdurahiman. Introducing probabilities
in statecharts to specify reactive systems for performance analysis. Computers &
OR, 33:2369–2386, 2006.
[216] Robert J. Walker, Lionel C. Briand, David Notkin, Carolyn B. Seaman, and Walter F.
Tichy. Panel: Empirical validation-what, why, when, and how. Software Engineering,
International Conference on, 0:721, 2003.
[217] Jos Warmer and Anneke Kleppe. The Object Constraint Language. Object Technology Series. Addison-Wesley, Reading, MA, USA, 2nd edition, 2003.
[218] Jon Whittle and João Araújo. Scenario modelling with aspects. IEE Proceedings Software, 151(4):157–172, 2004.
290
[219] Jon Whittle and Praveen K. Jayaraman. Generating hierarchical state machines from
use case charts. Proceedings of the 14th IEEE International Requirements Engineering
Conference (RE’06), 0:16–25, 2006.
[220] Jon Whittle and Johann Schumann. Generating statechart designs from scenarios. In
ICSE ’00: Proceedings of the 22nd international conference on Software engineering,
pages 314–323, New York, NY, USA, 2000. ACM.
[221] Wikipedia. Metamodeling, 2009. [Online; accessed 15-August-2009].
[222] Wikipedia. Model-driven engineering, 2009. [Online; accessed 15-August-2009].
[223] Rebecca Wirfs-Brock. What it really takes to handle exceptional conditions. In
L. Constantine, editor, forUSE 2002 Proceedings. Ampersand Press, 2002.
[224] Robert K. Yin. Case Study Research: Design and Methods (Applied Social Research
Methods). Sage Publications, fourth edition. edition, 2008.
[225] Pamela Zave. Classification of research efforts in requirements engineering. ACM
Comput. Surv., 29(4):315–321, 1997.
[226] Marvin V. Zelkowitz and Dolores R. Wallace. Experimental models for validating
technology. Computer, 31(5):23–31, 1998.
[227] Miriam Zia, Sadaf Mustafiz, Hans Vangheluwe, and Jörg Kienzle. A modelling and
simulation based approach to dependable system design. In Lionel C. Briand and
Clay Williams, editors, MoDELS, volume 3713 of Lecture Notes in Computer Science,
pages 217–231. Springer, 2005.
[228] Miriam Zia, Sadaf Mustafiz, Hans Vangheluwe, and Jörg Kienzle. A modelling and
simulation based process for dependable systems design. Software and System Modeling, 6(4):437–451, 2007.
Документ
Категория
Без категории
Просмотров
0
Размер файла
27 058 Кб
Теги
sdewsdweddes
1/--страниц
Пожаловаться на содержимое документа