Stable Analysis Patterns For Software And

Systems 1st Edition Fayad download

https://ebookbell.com/product/stable-analysis-patterns-for-
software-and-systems-1st-edition-fayad-5892096

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Stable Isotopic Analysis Of Carbon And Nitrogen As An Indicator Of

Paleodietary Change Among Prestate Metal Age Societies In Northeast
Thailand Christopher A King

https://ebookbell.com/product/stable-isotopic-analysis-of-carbon-and-
nitrogen-as-an-indicator-of-paleodietary-change-among-prestate-metal-
age-societies-in-northeast-thailand-christopher-a-king-49986954

Metabolic Analysis Using Stable Isotopes First Edition Metallo

https://ebookbell.com/product/metabolic-analysis-using-stable-
isotopes-first-edition-metallo-5431378

Potential Analysis Of Stable Processes And Its Extensions 1st Edition

Krzysztof Bogdan

https://ebookbell.com/product/potential-analysis-of-stable-processes-
and-its-extensions-1st-edition-krzysztof-bogdan-1147076

An Introduction To Syntactic Analysis And Theory D Sportiche

https://ebookbell.com/product/an-introduction-to-syntactic-analysis-
and-theory-d-sportiche-10671806
Analyses Of Turbulence In The Neutrally And Stably Stratified
Planetary Boundary Layer 1st Edition Cedrick Ansorge Auth

https://ebookbell.com/product/analyses-of-turbulence-in-the-neutrally-
and-stably-stratified-planetary-boundary-layer-1st-edition-cedrick-
ansorge-auth-5675626

Iutam Symposium On Field Analyses For Determination Of Material

Parameters Experimental And Numerical Aspects Proceedingsof The Iutam
Symposium Held In Abisko National Park Kiruna Sweden July 31 August 4
2000 1st Edition H T Goldrein
https://ebookbell.com/product/iutam-symposium-on-field-analyses-for-
determination-of-material-parameters-experimental-and-numerical-
aspects-proceedingsof-the-iutam-symposium-held-in-abisko-national-
park-kiruna-sweden-july-31-august-4-2000-1st-edition-h-t-
goldrein-4188900

Stable Places And Changing Perceptions Cave Archaeology In Greece

Fanis Mavridis Jesper Tae Jensen

https://ebookbell.com/product/stable-places-and-changing-perceptions-
cave-archaeology-in-greece-fanis-mavridis-jesper-tae-jensen-49984300

Stable Isotopes In High Temperature Geological Processes John W Valley

Editor Hugh P Taylor Editor James R Oneil Editor

https://ebookbell.com/product/stable-isotopes-in-high-temperature-
geological-processes-john-w-valley-editor-hugh-p-taylor-editor-james-
r-oneil-editor-50924040

Stable Isotope Geochemistry John W Valley Editor David R Cole Editor

https://ebookbell.com/product/stable-isotope-geochemistry-john-w-
valley-editor-david-r-cole-editor-50924130
 Stable Analysis Patterns
for Software and Systems
 Stable Analysis Patterns
for Software and Systems

M. E. Fayad
CRC Press
Taylor & Francis Group
6000 Broken Sound Parkway NW, Suite 300
Boca Raton, FL 33487-2742

© 2017 by Taylor & Francis Group, LLC

CRC Press is an imprint of Taylor & Francis Group, an Informa business

No claim to original U.S. Government works

Printed on acid-free paper

International Standard Book Number-13: 978-1-4987-0274-4 (Hardback)

This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have
been made to publish reliable data and information, but the author and publisher cannot assume responsibility for
the v­ alidity of all materials or the consequences of their use. The authors and publishers have attempted to trace
the ­copyright holders of all material reproduced in this publication and apologize to copyright holders if permission
to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and
let us know so we may rectify in any future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted,
or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, includ-
ing ­photocopying, microfilming, and recording, or in any information storage or retrieval system, without written
­permission from the publishers.

For permission to photocopy or use material electronically from this work, please access www.copyright.com (http://
www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA
01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users.
For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been
arranged.

Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for
identification and explanation without intent to infringe.
Visit the Taylor & Francis Web site at
http://www.taylorandfrancis.com
and the CRC Press Web site at
http://www.crcpress.com
To all Software Professionals and Developers,
especially the ones who apply my work.
Contents
Preface............................................................................................................................................xvii
Acknowledgments............................................................................................................................xxi
Author........................................................................................................................................... xxiii

Part I Introduction

Chapter 1 Stable Analysis Patterns Overview............................................................................... 5

1.1 Introduction........................................................................................................5
1.2 Related Work......................................................................................................6
1.3 Challenges That Analysis Patterns Face............................................................ 6
1.4 Stable Analysis Patterns..................................................................................... 8
1.5 Development of Stable Analysis Patterns...........................................................9
1.6 Example of Stable Analysis Patterns................................................................ 14
1.6.1 The Negotiation Analysis Pattern....................................................... 14
1.6.2 The Trust Analysis Pattern.................................................................. 14
1.7 Summary.......................................................................................................... 18
1.8 Open and Research Issues................................................................................ 18
Overview Questions.................................................................................................... 18
Exercises...................................................................................................................... 19
Projects........................................................................................................................ 19
Sidebars.......................................................................................................................20
References...................................................................................................................28

Chapter 2 Applying Analysis Patterns through Analogy: Problems and Solutions.................... 29

2.1 Introduction...................................................................................................... 29
2.2 Analysis Patterns as Templates........................................................................ 30
2.3 Problems with Using Analysis Patterns through Analogy............................... 31
2.4 Stable Analysis Patterns................................................................................... 32
2.4.1 Stability Model.................................................................................... 32
2.4.2 Stable Analysis Pattern Example........................................................ 33
2.5 Applying Stable Analysis Patterns................................................................... 33
2.6 Summary..........................................................................................................34
Review Questions........................................................................................................ 35
Exercises...................................................................................................................... 35
Projects........................................................................................................................ 35
References................................................................................................................... 36

Chapter 3 A Pattern Language for Building Stable Analysis Patterns........................................ 37

3.1 Introduction...................................................................................................... 37
3.2 Pattern Language Overview............................................................................. 38
3.3 Building Stable Analysis Pattern Language Description................................. 39
3.3.1 Pattern 1.1: Efficient Usable Analysis Models.................................... 39
3.3.1.1 Intent................................................................................... 39

vii
viii Contents

3.3.1.2 Context................................................................................ 39
3.3.1.3 Problem............................................................................... 39
3.3.1.4 Forces.................................................................................. 39
3.3.1.5 Solution...............................................................................40
3.3.2 Pattern 1.2: Stability Model................................................................. 42
3.3.2.1 Intent................................................................................... 42
3.3.2.2 Context................................................................................ 42
3.3.2.3 Problem............................................................................... 42
3.3.2.4 Forces.................................................................................. 42
3.3.2.5 Solution............................................................................... 42
3.3.3 Pattern 2.3: Identify the Problem........................................................ 45
3.3.3.1 Intent................................................................................... 45
3.3.3.2 Context................................................................................ 45
3.3.3.3 Problem............................................................................... 45
3.3.3.4 Forces.................................................................................. 45
3.3.3.5 Solution............................................................................... 45
3.3.4 Pattern 2.4: Identify EBTs...................................................................46
3.3.4.1 Intent...................................................................................46
3.3.4.2 Context................................................................................46
3.3.4.3 Problem...............................................................................46
3.3.4.4 Forces.................................................................................. 47
3.3.4.5 Solution............................................................................... 47
3.3.4.6 Discussion........................................................................... 48
3.3.5 Pattern 2.5: Identify BOs..................................................................... 49
3.3.5.1 Intent................................................................................... 49
3.3.5.2 Context................................................................................ 49
3.3.5.3 Problem............................................................................... 49
3.3.5.4 Forces.................................................................................. 49
3.3.5.5 Solution............................................................................... 49
3.3.5.6 Discussion........................................................................... 51
3.3.6 Pattern 2.6: Proper Abstraction Level................................................. 52
3.3.6.1 Intent................................................................................... 52
3.3.6.2 Context................................................................................ 52
3.3.6.3 Problem............................................................................... 52
3.3.6.4 Forces.................................................................................. 52
3.3.6.5 Solution............................................................................... 52
3.3.6.6 Discussion........................................................................... 53
3.3.7 Pattern 3.7: Build Stable Analysis Patterns......................................... 54
3.3.7.1 Intent................................................................................... 54
3.3.7.2 Context................................................................................ 54
3.3.7.3 Problem............................................................................... 56
3.3.7.4 Forces.................................................................................. 56
3.3.7.5 Solution............................................................................... 56
3.3.7.6 Examples............................................................................. 56
3.3.8 Pattern 3.8: Use Stable Analysis Patterns........................................... 58
3.3.8.1 Intent................................................................................... 58
3.3.8.2 Context................................................................................ 58
3.3.8.3 Problem............................................................................... 58
3.3.8.4 Forces.................................................................................. 58
3.3.8.5 Solution............................................................................... 58
3.3.8.6 Comment............................................................................. 59
Contents ix

3.3.8.7 Example.............................................................................. 59
3.4 Summary..........................................................................................................60
3.5 Open and Research Issue.................................................................................. 61
Review Questions........................................................................................................ 61
Exercises...................................................................................................................... 62
Projects........................................................................................................................ 62
References................................................................................................................... 62

Chapter 4 Model-Based Software Reuse Using Stable Analysis Patterns................................... 63

4.1 Introduction...................................................................................................... 63
4.2 Essential Properties of Analysis Patterns.........................................................64
4.3 Classification of Analysis Pattern Methodologies............................................ 65
4.4 Evaluation of Analysis Patterns Groups........................................................... 65
4.4.1 Group I: Direct Approach................................................................... 65
4.4.2 Group II: Analogy Approach..............................................................66
4.4.3 Group III: Stability Approach............................................................. 67
4.5 Comparison of Analysis Patterns Groups........................................................ 68
4.6 Summary.......................................................................................................... 68
4.7 Open and Research Issues................................................................................ 70
Review Questions........................................................................................................ 70
Exercises...................................................................................................................... 71
Projects........................................................................................................................ 72
References................................................................................................................... 72

Chapter 5 Stable Patterns’ Documentation: Templates, UML Forms, Rules, and Heuristics...... 75
5.1 Introduction...................................................................................................... 75
5.2 Patterns’ Documentation Templates................................................................. 77
5.2.1 Current Stable Models’ Templates and Their Problems..................... 77
5.2.2 Full Stable Patterns’ Template Description with Rules and
Heuristics............................................................................................. 78
5.2.2.1 Pattern Name...................................................................... 78
5.2.2.2 Known As........................................................................... 78
5.2.2.3 Context................................................................................ 79
5.2.2.4 Problem...............................................................................80
5.2.2.5 Challenges and Constraints................................................80
5.2.2.6 Solution............................................................................... 81
5.2.2.7 Consequences...................................................................... 83
5.2.2.8 Applicability.......................................................................84
5.2.2.9 Applicability with Illustrated Examples.............................84
5.2.2.10 Related Patterns and Measurability....................................84
5.2.2.11 Modeling Issues, Criteria, and Constraints........................ 86
5.2.2.12 Design and Implementation Issues..................................... 86
5.2.2.13 Testability............................................................................ 86
5.2.2.14 Formalization using Z++, Object Z, or Object-
Constraints Language (OCL) (Optional)��������������������������� 87
5.2.2.15 Business Issues.................................................................... 87
5.2.2.16 Known Usage......................................................................92
5.2.2.17 Tips and Heuristics.............................................................92
5.3 Summary..........................................................................................................92
x Contents

Review Questions........................................................................................................ 93
Exercises...................................................................................................................... 93
Project.......................................................................................................................... 93
Sidebars.......................................................................................................................94
References................................................................................................................. 101

Part II SAPs: Detailed Documentation Templates

Chapter 6 Competition Stable Analysis Pattern......................................................................... 105
6.1 Introduction.................................................................................................... 105
6.2 Competition Analysis Pattern Document....................................................... 106
6.2.1 Pattern Name: Competition Stable Analysis Pattern........................ 106
6.2.1.1 Known As......................................................................... 106
6.2.1.2 Context.............................................................................. 106
6.2.1.3 Problem............................................................................. 107
6.2.1.4 Challenges and Constraints.............................................. 109
6.2.1.5 Solution............................................................................. 110
6.2.1.6 Consequences.................................................................... 111
6.2.1.7 Applicability..................................................................... 111
6.2.1.8 Related Pattern and Measurability.................................... 120
6.3 Summary........................................................................................................ 123
6.4 Open and Research Issues.............................................................................. 123
Review Questions...................................................................................................... 124
Exercises.................................................................................................................... 125
Projects...................................................................................................................... 126
References................................................................................................................. 127

Chapter 7 Corruption Stable Analysis Pattern........................................................................... 129

7.1 Introduction.................................................................................................... 129
7.2 Corruption Stable Analysis Pattern................................................................ 129
7.2.1 Context.............................................................................................. 130
7.2.1.1 Executive Branch Political Corruption............................. 130
7.2.1.2 Public Corruption............................................................. 130
7.2.2 Problem............................................................................................. 130
7.2.2.1 Functional Requirements.................................................. 131
7.2.2.2 Nonfunctional Requirements............................................ 132
7.2.3 Challenges and Constraints............................................................... 133
7.2.3.1 Constraints........................................................................ 133
7.2.4 Solution.............................................................................................. 133
7.2.5 Applicability with Illustrated Examples........................................... 133
7.2.6 Business Rules................................................................................... 137
7.2.7 Known Usage.................................................................................... 141
7.3 Summary........................................................................................................ 141
7.4 Open and Research Issues.............................................................................. 141
Review Questions...................................................................................................... 142
Exercises.................................................................................................................... 143
Project........................................................................................................................ 143
References................................................................................................................. 143
Bibilography.............................................................................................................. 143
Contents xi

Chapter 8 Dignity Stable Analysis Pattern................................................................................ 145

8.1 Introduction.................................................................................................... 145
8.2 Pattern Documentation................................................................................... 146
8.2.1 Known As.......................................................................................... 146
8.2.2 Context.............................................................................................. 146
8.2.3 Problem............................................................................................. 147
8.2.4 Challenges and Constraints............................................................... 152
8.2.4.1 Challenges......................................................................... 152
8.2.4.2 Constraints........................................................................ 152
8.2.5 Solutions............................................................................................ 153
8.2.5.1 Class Diagram Description............................................... 154
8.2.5.2 Participants....................................................................... 154
8.2.6 Consequences.................................................................................... 155
8.2.7 Applicability with Illustrated Examples........................................... 155
8.2.7.1 Application 1: Dignity at Work......................................... 155
8.2.7.2 Application 2: Dignity of Human Rights.......................... 161
8.2.8 Related Patterns and Measurability.................................................. 164
8.2.8.1 Related Pattern.................................................................. 164
8.2.8.2 Measurability.................................................................... 168
8.2.9 Modeling Issues, Criteria, and Constraints....................................... 169
8.2.9.1 Abstraction........................................................................ 169
8.2.10 Modeling Heuristics.......................................................................... 170
8.2.10.1 General Enough to Be Reused in Different Application.. 170
8.2.11 Design and Implementation Issues.................................................... 170
8.2.11.1 Delegation versus Inheritance........................................... 170
8.2.11.2 Testability.......................................................................... 172
8.2.12 Formalization Using OCL, Z++, Object Z, and/or EBNF................ 173
8.2.13 Business Issues.................................................................................. 175
8.2.13.1 Business Rules.................................................................. 175
8.2.13.2 Business Integration.......................................................... 177
8.2.13.3 Business Enduring Themes............................................... 177
8.2.14 Known Usage.................................................................................... 177
8.3 Tips and Heuristics......................................................................................... 178
8.4 Summary........................................................................................................ 178
8.5 Open Research Issues..................................................................................... 179
Review Questions...................................................................................................... 179
Exercises.................................................................................................................... 181
Projects...................................................................................................................... 183
References................................................................................................................. 184

Chapter 9 Trust Stable Analysis Pattern.................................................................................... 185

9.1 Introduction.................................................................................................... 185
9.2 Trust Analysis Pattern Document................................................................... 186
9.2.1 Pattern Name: Trust Stable Analysis Pattern.................................... 186
9.2.1.1 Known As......................................................................... 186
9.2.1.2 Context.............................................................................. 187
9.2.1.3 Problem............................................................................. 188
9.2.1.4 Challenges and Constraints.............................................. 189
9.2.1.5 Solution............................................................................. 189
9.2.1.6 CRC Cards........................................................................ 192
xii Contents

9.2.1.7 Applicability with Illustrated Examples........................... 192

9.3 Tips and Heuristics......................................................................................... 197
9.3.1 Design Heuristics.............................................................................. 197
9.4 Summary........................................................................................................ 199
9.5 Open and Research Issues.............................................................................. 199
Review Questions...................................................................................................... 201
Exercises....................................................................................................................202
Projects......................................................................................................................202
References................................................................................................................. 203

Chapter 10 Accessibility Stable Analysis Pattern........................................................................205

10.1 Introduction....................................................................................................205
10.2 The Accessibility Analysis Pattern................................................................206
10.2.1 Pattern Name: Accessibility Stable Analysis Pattern........................206
10.2.1.1 Known As.........................................................................206
10.2.1.2 Context..............................................................................207
10.2.1.3 Problem.............................................................................207
10.2.1.4 Challenges and Constraints..............................................209
10.2.1.5 Pattern Structure and Participants.................................... 210
10.2.1.6 Consequences.................................................................... 212
10.2.1.7 Applicability..................................................................... 213
10.2.1.8 Related Patterns and Measurability.................................. 220
10.2.1.9 Modeling Issues, Criteria, and Constraints...................... 222
10.2.1.10 Design and Implementation Issues...................................224
10.2.1.11 Testability..........................................................................224
10.2.1.12 Business Issues..................................................................224
10.2.1.13 Known Usage.................................................................... 226
10.2.1.14 Tips and Heuristics........................................................... 227
10.3 Summary........................................................................................................ 227
10.4 Open and Research Issues.............................................................................. 227
Review Questions...................................................................................................... 228
Exercises.................................................................................................................... 229
Projects...................................................................................................................... 230
References................................................................................................................. 230

Part III SAPs: Mid-Size Documentation Templates

Chapter 11 Reputation Stable Analysis Patterns......................................................................... 235

11.1 Introduction.................................................................................................... 235
11.2 Reputation Analysis Pattern Document......................................................... 236
11.2.1 Pattern Name: Reputation Stable Analysis Pattern........................... 236
11.2.1.1 Context.............................................................................. 236
11.2.1.2 Problem............................................................................. 237
11.2.1.3 Solution............................................................................. 237
11.2.1.4 Applicability with Illustrated Example............................. 238
11.3 Summary........................................................................................................ 243
11.4 Open and Research Issues.............................................................................. 243
Review Questions...................................................................................................... 243
Contents xiii

Exercises....................................................................................................................244
Projects......................................................................................................................244
References.................................................................................................................244

Chapter 12 Temptation Stable Analysis Pattern.......................................................................... 245

12.1 Introduction.................................................................................................... 245
12.2 Reputation Analysis Pattern Document......................................................... 245
12.2.1 Pattern Name: Temptation Stable Analysis Pattern.......................... 245
12.2.1.1 Context.............................................................................. 245
12.2.1.2 Problem.............................................................................246
12.2.1.3 Challenges.........................................................................248
12.2.1.4 Constraints........................................................................248
12.2.1.5 Solution.............................................................................248
12.2.1.6 Applicability with Illustrated Example............................. 251
12.3 Summary........................................................................................................ 255
Review Questions...................................................................................................... 255
Exercises.................................................................................................................... 256
Projects...................................................................................................................... 257
References................................................................................................................. 257

Part IV SAPs: Short Documentation

Templates and Future Work and Conclusions

Chapter 13 Analysis Stable Analysis Pattern............................................................................... 261

13.1 Introduction.................................................................................................... 261
13.2 Pattern Name: Analysis Stable Analysis Pattern............................................ 262
13.2.1 Context.............................................................................................. 262
13.2.2 Scenarios........................................................................................... 262
13.2.3 Problem............................................................................................. 263
13.2.3.1 Functional Requirements.................................................. 263
13.2.3.2 Nonfunctional Requirements............................................264
13.2.4 Solution..............................................................................................264
13.2.4.1 Class Diagram Description...............................................264
13.3 Summary........................................................................................................264
13.4 Open and Research Issues.............................................................................. 265
Review Questions......................................................................................................266
Exercises....................................................................................................................266
Projects...................................................................................................................... 267
References................................................................................................................. 267

Chapter 14 Deployment Stable Analysis Pattern......................................................................... 269

14.1 Introduction.................................................................................................... 269
14.2 Pattern Name: Deployment Stable Analysis Pattern...................................... 269
14.2.1 Context.............................................................................................. 270
14.2.1.1 Scenario 1: Deployment of Military Personnel................ 270
14.2.1.2 Scenario 2: Resource Deployment.................................... 270
14.2.1.3 Scenario 3: Deployment of Parachute............................... 270
xiv Contents

14.2.2 Problem............................................................................................. 270

14.2.2.1 Functional Requirements.................................................. 270
14.2.2.2 Nonfunctional Requirements............................................ 271
14.2.3 Solution.............................................................................................. 271
14.2.3.1 Class Diagram Description............................................... 271
14.2.4 Five Scenarios................................................................................... 272
14.3 Summary........................................................................................................ 272
14.4 Open and Research Issues.............................................................................. 272
Review Questions...................................................................................................... 274
Exercises.................................................................................................................... 274
Projects...................................................................................................................... 275
References................................................................................................................. 275

Chapter 15 Change Stable Analysis Pattern................................................................................ 277

15.1 Introduction.................................................................................................... 277
15.2 Name: Change Stable Analysis Pattern.......................................................... 278
15.2.1 Context.............................................................................................. 278
15.2.1.1 Change of Workplace Location........................................ 278
15.2.1.2 Change of Password.......................................................... 278
15.2.1.3 Change Review Meeting................................................... 278
15.2.2 Problem............................................................................................. 279
15.2.2.1 Functional Requirement.................................................... 279
15.2.2.2 Nonfunctional Requirement.............................................280
15.2.3 Solution.............................................................................................. 281
15.2.3.1 Class Diagram................................................................... 281
15.2.3.2 Class Diagram Description............................................... 281
15.2.3.3 Applicability..................................................................... 282
15.3 Summary........................................................................................................ 282
15.4 Open Research Issues..................................................................................... 282
Review Questions...................................................................................................... 282
Exercises.................................................................................................................... 283
Projects...................................................................................................................... 283
References.................................................................................................................284

Chapter 16 Propaganda Stable Analysis Pattern......................................................................... 285

16.1 Introduction.................................................................................................... 285
16.2 Pattern Name: Propaganda Stable Analysis Pattern....................................... 286
16.2.1 Context.............................................................................................. 286
16.2.1.1 Political Propaganda......................................................... 286
16.2.1.2 Business Manipulation...................................................... 286
16.2.2 Problem............................................................................................. 287
16.2.2.1 Functional Requirements.................................................. 287
16.2.2.2 Nonfunctional Requirements............................................ 288
16.2.3 Solution.............................................................................................. 289
16.2.3.1 Class Diagram Description............................................... 289
16.3 Summary........................................................................................................ 289
16.4 Open Research Issues..................................................................................... 289
Review Questions...................................................................................................... 289
Exercises.................................................................................................................... 290
Contents xv

Projects...................................................................................................................... 290
References................................................................................................................. 291

Chapter 17 Fairness Stable Analysis Pattern............................................................................... 293

17.1 Introduction.................................................................................................... 293
17.2 Pattern Name: Fairness Stable Analysis Pattern............................................ 293
17.2.1 Context.............................................................................................. 294
17.2.1.1 Sportsmanship.................................................................. 294
17.2.1.2 Legal Judgment................................................................. 294
17.2.2 Problem............................................................................................. 294
17.2.2.1 Functional Requirements.................................................. 295
17.2.2.2 Nonfunctional Requirements............................................ 295
17.2.3 Solution.............................................................................................. 296
17.2.3.1 Class Diagram................................................................... 296
17.2.3.2 Class Diagram Description............................................... 296
17.3 Summary........................................................................................................ 296
17.4 Open Research Issues..................................................................................... 297
Review Questions...................................................................................................... 297
Exercise..................................................................................................................... 297
Projects...................................................................................................................... 297
References................................................................................................................. 298

Chapter 18 Anxiety Stable Analysis Pattern............................................................................... 299

18.1 Introduction.................................................................................................... 299
18.2 Name: Anxiety Stable Analysis Pattern.........................................................300
18.2.1 Context..............................................................................................300
18.2.1.1 Scenario 1: Work Place Anxiety.......................................300
18.2.1.2 Scenario 2: Anxious Wait for Test Results.......................300
18.2.2 Problem.............................................................................................300
18.2.2.1 Functional Requirements..................................................300
18.2.2.2 Nonfunctional Requirements............................................ 301
18.2.3 Solution..............................................................................................302
18.2.3.1 Class Diagram Description...............................................302
18.3 Summary........................................................................................................302
18.4 Open Research Issues..................................................................................... 303
Review Questions...................................................................................................... 303
Exercises.................................................................................................................... 303
Projects......................................................................................................................304
References.................................................................................................................304

Chapter 19 Future Work and Conclusions................................................................................... 305

19.1 Future Work.................................................................................................... 305
19.2 Summary........................................................................................................306
Review Questions......................................................................................................307
Exercises....................................................................................................................307
References.................................................................................................................307

Index...............................................................................................................................................309
Preface
Software analysis patterns play an important role in reducing the overall cost, and in abridging and
compressing the time of software project lifecycles. However, building reusable and stable analysis
patterns (SAPs) is still considered a major and sensitive challenge. This book proposes the novel
concept of SAPs based on software stability as a modern approach for building stable and highly
reusable and widely applicable analysis patterns. This book also intends to provide a true and defi-
nite understanding of the problem space and focus users’ requirements analysis accurately. It shows
that this new formation approach of discovering/creating SAPs accords with Alexander’s current
understanding of architectural patterns. This agreement is not accidental, but truly fundamental.
The SAPs are a kind of knowledge patterns that underline human problem-solving methods, and
appeal to the pattern community to look for patterns from building a foundation of architectures on
demand from a broader system perspective.
This book presents a new and pragmatic approach for understanding the problem domain and
in utilizing SAPs for any field of knowledge and modeling the right and stable software systems,
components, and frameworks. Along with the core value of reusing the presented patterns, this book
also helps readers attain the basic knowledge that is needed to analyze and extract analysis patterns
for their own domains of interests. Moreover, readers will also learn and master ways to document
their own patterns in an effective, easy, and comprehensible manner.
The work reported in this book brings truly significant contributions to the computing field for
several important reasons. It is the first and the only complete reference manual on the topic of
SAPs. It is also the first book on handling the true understanding of the problem space, and it will
teach a reader the methods and processes to analyze user’s requirements accurately, and ways to
build a myriad of cost-effective and highly maintainable systems by using SAPs.

THE SCOPE OF THIS BOOK

Software analysis patterns play a major and decisive role in reducing the overall cost and in con-
densing the time duration of software project lifecycles. However, building reusable and SAPs is
still a major challenge. SAPs are new and fresh tools for building stable and reusable analysis pat-
terns based on the concept of software stability.
Although SAPs are known to lend the much needed solidity and stability to a software system,
nagging doubts still persist in today’s domains of contemporary design and analysis patterns and
their applications in software programming industry. For example, one of the pertinent questions
raised by pattern developers is the perceived concerns on the stability factors of a software system
and its ability to adapt to the issue of reuse over time. Similarly, another question that might be
posed elates to a SAP’s capability to capture and model the core knowledge of a given problem.
Furthermore, it is also pertinent to seek answers to the question of achieving necessary levels of
abstraction that usually makes software systems robust and reusable over a period. Often, pattern
designers link the aspect of smooth transition from the analysis phase to design phase as a key factor
to build effective software systems. In this regard, analysis patterns will need to provide necessary
details that reveal the overall structure of an analysis pattern. Additionally, another key question
that arises is the practicality of methods and processes that are used to describe and narrate analysis
patterns from the initial phase of conception to designing aspects to creation.
One of the major pitfalls or weaknesses in developing meaningful and convenient analysis and
design patterns is the perceived factor of immaturity; thus, most of the patterns developed are yet
to fulfill the expectations for their use in facilitating the development of software systems. As a
result, it becomes a major concern to investigate, why software patterns have not yet developed the
level of maturity that is so much needed for establishing the stability of a given software system.

xvii
xviii Preface

Even with the best of software architecture knowledge, a piece of software system is bound to face
some problems in its lifetime. This book attempts to highlight and deliberate a number of common
problems found in today’s traditional software patterns, like the Gang of Four, Siemens Group,
and others.
While Christopher Alexander’s earlier work on patterns (e.g., “Timeless Way of Building” and
“A Pattern Language”) influenced the development of software (analysis, design, and architectural)
patterns, his latest work on fundamental properties of patterns (presented in the four book series
called “The Nature of Order”) seems to be less influential to software patterns, in general, and
analysis patterns in particular. Thus, the most obvious solution would be to focus more on develop-
ing effective patterns that contributes positively to the future development of software systems. This
book is expected to overcome all the pitfalls of traditional or existing analysis patterns.
The main purpose of this book proposal is therefore to fill in the important gap in the current
analysis pattern book, by adding new sets of analysis knowledge, and by providing a very well-
defined paradigm of discovering/creating analysis patterns, based on software stability. This book
also proposes the novel concept of SAPs based on software stability as a modern approach for build-
ing stable and highly reusable and widely applicable analysis patterns. This book overcomes the
factor of immaturity in existing software patterns, in general, and analysis patterns, in particular,
presented in many different existing software patterns pitfalls.
Throughout this book, we have furnished a number of answers to questions raised before, and
practical approaches to follow clear-cut processes that arise from these answers. The Software
Stability Concepts acted as the major backbone to all these questions. By applying concepts of
stability model to the assumptions of analysis patterns, we suggest the concept of SAPs. The main
idea behind using SAPs is to analyze the overall problem under question, in terms of its EBTs and
the BOs, mainly with the goal of increased stability and broader reuse. By examining ensuing prob-
lem in terms of their EBTs and the BOs, the resulting pattern will form the core knowledge of the
problem. The ultimate goal of this new concept is achieving ample stability. Accordingly, anyone
could easily comprehend, understand, and build reusable models that tackle solving similar prob-
lems occurring under different contexts and domains. The real essence of SAPs is twofold: A clear
paradigm and a precise visual representation. For the paradigm approach, we have presented a set
of guidelines, heuristics, and quality factors that will ease the process of creating SAPs, along with
a well-defined and reusable documentation. On the other hand, for visual representation, we have
offered visual gadgets or symbols that convey what the SAPs are and how to apply them.
In addition to an introduction of twin and narrative essences of SAPs, this book also attempts
to analyze reasons and factors that might affect designing, sustained life cycle, durability, general-
ity, traceability, and quality of composition. In order to overcome all these perceived lacunae, this
book provides a standard way of creating SAPs by using the principle of software stability that has
been covered in depth in our earlier book titled Software Patterns, Knowledge Maps and Domain
Analysis. The scope of this book extends beyond just designing an SAP. Being the only complete
reference manual on SAPs, this book documents and highlights several aspects, techniques, and
processes that are linked to the problem of understanding software systems that exist today. In addi-
tion, this book also presents a diversity of domain-less SAPs that one can easily comprehend and
reuse to model similar problems in any given context.
Furthermore, tips from this book show the reader how to link the analysis pattern to the design
phase; the main design issues necessary for a smooth transition between analysis and design phases
are some of the useful contributions provided by this book. This book also offers a brand new
template for improving the communication of analysis patterns among all developers; incidentally,
this template aims to capture the static and dynamic behavior of the pattern, while maintaining the
simplicity of reading and understanding the pattern. The main goal of this book is to ensure reus-
ability of the pattern and its stability. Eventually, the overall scope of this book extends beyond the
usual paraphernalia that is attached to pattern designing and making without taking into account
the factors of traceability, robustness, stability, enhanceability, and reusability.
Preface xix

WHOM THIS BOOK IS FOR

We always write for the mass and public—This book could be of great help (frankly speaking is
necessary). This book is specially written for a large community of computing and modeling aca-
demics, students, software technologists and methodologists, software patterns’ communities, com-
ponent developers, and software reuse communities and software professionals (analysts, designers,
architects, programmers, testers, maintainers, developer), who are involved in the management,
research, and development of methodologies and software patterns. Industry agents, who work on
any technology project and want to improve the project’s reliability and cost-effectiveness, will also
benefit hugely by reading this book.
This book is also specially designed for a big community of computer and software profession-
als, who are involved in the management, research, and development of software systems, compo-
nents, and enterprise and application frameworks. Software researchers, system architects, software
designers, and software engineers (both systems level and application level) will also greatly benefit
from this book. We anticipate that the new concepts presented in this book will definitely impact
the development of new software systems, components, enterprise frameworks, and application
frameworks for the next one or two decades.
Potential buyers for this book will be from established software firms and those people who are
currently analyzing, designing, and developing different types of software for different domains.
In addition, the UML and communities, who are active in designing software architecture, com-
ponents, software engineering, enterprise frameworks, application frameworks, and the analysis
pattern and design pattern, may also evince a keen interest in this book.
In a bookshop and library, the librarian would index and store this book in the Computer
Science/Software Engineering/Object-Orientation/Component Software/Enterprise Frameworks/
Application Frameworks category. This book is very suitable for anyone dealing with knowledge
in their domain, software engineering academic and software development, sciences, engineering,
business, and other communities.
All large software firms, people who are studying, researching, analyzing, designing, and devel-
oping any systems, and educators, academicians, and students in many other fields are also the
potential customers for this book. In addition, a number of communities related to UML, require-
ments engineering software architecture, components, software engineering, enterprise frame-
works, application frameworks, knowledge modeling and management, ontology, domain analysis,
software reuse, architectural patterns, and the analysis pattern and design pattern would benefit by
reading this book as well.
Further, people and experts, who attend workshops on object-oriented technology, software
engineering, requirements engineering, robotics systems, and domain-specific conferences,
will also be potentially interested in reading this book. These conferences and workshops may
include OOPSLA, ECOOP, TOOLS, UML, ICSE, ICSR, PLOP, COTS, ICRA, Robotics, IROS,
ICAR, ASRO, CORR, AIM, RO-MAN, ARAS, ISR, and many others. In a bookstore or a library
shelf, this book would be, indexed and shelved in the Computer Science/Software Engineering
categories.
We believe that concepts presented in this book will act as a catalyst to urge academicians,
software students, software technologists, methodologists, pattern designers, software reuse
proponents, analysts, designers, testers, and developers, to pursue rigorous research in the areas
of SAPs. Industry agents, developers, and enthusiasts, who want to improve project life cycles,
cost-effectiveness, and project reliability, will also benefit after reading this book. We also per-
ceive that concepts presented in this book may positively affect the development of new soft-
ware systems and application framework systems for the next decade or two. This book is also
expected to be a knowledge source for creating future graduate course on software engineering,
pattern modeling, domain analysis, knowledge modeling, advanced software architecture, and
designing.
xx Preface

HOW TO USE THIS BOOK

The main goal of writing this book is to allow readers to understand and master the basics of
SAPs from their theoretical underpinning to practical applications of principles to create robust and
stable patterns. To enable easy understanding and comprehension of the subject matter, this book is
divided into numerous sections, each of which deals with separate aspects of SAPs.

Book Supplement
The author provides a book supplement of 400+ pages containing solutions to the exercises and
projects in each chapter. In addition to problem statements for team projects, exams, quizzes, and
a modeling tips and heuristics are also given. The supplement also provides over 20–30 numbers
of special SAPs. Static, dynamic, and behavior models for each of the patterns are also given.
Similarly, the author also provides a number of scenarios to illustrate how to do them in the supple-
ment section. The book supplement also has several private links for power point presentation of all
the sections of the book.
Acknowledgments
This book would not have been completed without the help of many great people; I thank them
all. Special thanks to my friend and one of my best student Dr. Haitham Hamza, Cairo University,
Egypt for his excellent thesis work on Stable Analysis Patterns. Special thanks to my friend Srikanth
G. K. Hegde. I also would like to thank all of my student assistants, Vishnu Sai Reddy Gangireddy,
Mansi Joshi, Siddharth Jindal, Hema Veeraragavathatham, and Pavan Pavuluri for their work on the
figures and diagrams and long discussions on some of the topics of this book.
This was a great and fun project because of your tremendous help and extensive patience. Special
thanks to my San Jose State University students for forming teams and work on some of the exer-
cises and projects in this book. Special thanks to my wife Raefa, my lovely daughters Rodina and
Rawan, and my son Ahmad for their great patience and understanding. Special thanks to Srikanth’s
wife, Kumuda Srikanth, for help with reviewing some of the chapters. Special thanks to all my
friends all over the world for their encouragement and long discussions about the topics and the
issues in this book. Thanks to all my students and coauthors of many articles related to this topic
with me, in particular Ahmed Mahdy (Texas A&M University at Corpus Christi, Corpus Christi,
TX), Shasha Wu (Spring Arbor University, Michigan), and Shivanshu Singh, to my friends Davide
Brugali and Ahmed Yousif for their encouragement during this project, to the Communications of
the ACM staff—my friends Diana Crawford, the executive editor, Thomas E. Lambert, the manging
editor, and Andrew Rosenbloom, the senior editor.
I would like to acknowledge and thank all of those who have had a part in the production of this
book. First, and foremost, we owe our families a huge debt of gratitude for being so patient while
we put their world in a whirl by injecting this writing activity into their already busy lives. We also
thank the various reviewers and editors who have helped in so many ways to get the book together.
We thank our associates who offered their advice and wisdom in defining the content of the book.
We also owe special thanks to those who have worked on the various projects covered in the case
studies and examples.
Finally we would like to acknowledge and thank the work of some of the people and who helped
us in this effort. John Wyzalek, acquisition editor, Stephanie Place, editorial assistant, Glenon
Butler, project editor, and Michelle Rivera-Spann the marketing manager at CRC Press, Taylor &
Francis Group for their excellent and quality support and work done to produce this book and a spe-
cial acknowledgment and thanks to Karthick Parthasarathy, assistant manager at Nova Techset, who
did a tremendous job for proofreading and copyediting of all the chapters in detail and the elegant
and focused ways of taking care of day-to-day handling of this book, and special thanks to all the
people in marketing, design, and support staff at CRC Press, Taylor & Francis Group.

xxi
Author
Dr. M. E. Fayad is a full professor of computer engineering at San
Jose State University from 2002 to present. He was a J. D. Edwards
professor of computer science and engineering at the University of
Nebraska, Lincoln, from 1999 to 2002, and an associate professor
of the computer science and computer engineering faculty at the
University of Nevada, from 1995 to 1999. He has over 15 years of
industrial experience. Dr. Fayad is an IEEE distinguished speaker,
an associate editor, editorial advisor, and a columnist for The
Communications of the ACM where his column name is Thinking
Objectively. He is also a columnist for Al-Ahram Egyptians
Newspaper, and an editor-in-chief for IEEE Computer Society
Press—Computer Science and Engineering Practice Press (1995–
1997). He also served as General Chair of IEEE/Arab Computer Society International Conference
on Computer Systems and Applications (AICCSA 2001), Beirut, Lebanon, June 26–29, 2001, and
he is the Founder and President of Arab Computer Society (ACS) from April 2004 to April 2007.
Dr. Fayad is a known and well-recognized authority in the domain of theory and the applications
of software engineering. Fayad’s publications are in the very core, archival journals and conferences
in the software engineering field. Dr. Fayad was a guest editor on 11 theme issues: CACM’s OO
Experiences, Oct. 1995, IEEE Computer’s Managing OO Software Development Projects, Sept.
1996, CACM’s Software Patterns, Oct. 1996, CACM’s OO Application Frameworks, Oct. 1997,
ACM Computing Surveys—OO Application Frameworks, March 2000, IEEE Software—Software
Engineering in-the-small, Sept./Oct. 2000, and International Journal on Software Practice
and Experiences, July 2001, IEEE Transaction on Robotics and Automation—Object-Oriented
Methods for Distributed Control Architecture, October 2002, Annals of Software Engineering
Journal—OO Web-Based Software Engineering, October 2002, Journal of Systems and Software,
Elsevier, Software Architectures and Mobility, July 2010, and Pattern Languages: Addressing the
Challenges, the Journal of Software, Practice and Experience, March–April 2012.
Dr. Fayad has published more than 300 high-quality articles, which include profound and well-
cited reports (more than 50 in number) in reputed journals, and over 100 advanced articles in ref-
ereed conferences, more than 25 well-received and cited journal columns, 16 blogged columns,
11 well-cited theme issues in prestigious journals and flagship magazines, 24 different workshops
in very respected conferences, over 125 tutorials, seminars, and short presentations in more than
30 different countries, such as Hong Kong (April 96), Canada (12 times), Bahrain (2 times), Saudi
Arabia (3 times), Egypt (25 times), Lebanon (04 & 05), UAE (2 times), Qatar (2 times), Portugal (Oct.
96, July 99), Finland (2 times), UK (3 times), Holland (3 times), Germany (4 times), Mexico (Oct.
98), Argentina (3 times), Chile (00), Peru (02), and Spain (02), Brazil (04), a founder of 7 new online
journals, NASA Red Team Review of QRAS and NSF-USA Research Delegations’ Workshops to
Argentina and Chili and four authoritative books, of which three of them are translated into dif-
ferent languages such as Chinese and over 5 books currently in progress. Dr. Fayad is also filling
for eight new, valuable, and innovative patents and has developed over 800 stable software pat-
terns. Dr. Fayad earned an MS and a PhD in computer science from the University of Minnesota
at Minneapolis. His research topic was OO Software Engineering: Problems and Perspectives. He
is the lead author of several classic Wiley books: Transition to OO Software Development, August
1998, Building Application Frameworks, September, 1999, Implementing Application Frameworks,
September, 1999, Domain-Specific Application Frameworks, October, 1999, and several classic
books by CRC Press, Taylor & Francis Group: Software Patterns, Knowledge Maps, and Domain

xxiii
xxiv Author

Analysis, December 2014 and several new books in Progress with Taylor & Francis Group—Stable
Analysis Pattern for Software and Systems (May 2017), Stable Design Pattern for Software and
Systems (July 2017), Unified Business Rules Standard (UBRS), Software Architecture On Demand,
Unified Software Engineering Reuse (USER) and Unified Software engineering (USE) in Progress.
Part I
Introduction

Stable analysis patterns (SAPs) are conceptual models that model the core knowledge of the
problem. Therefore, it is expected that the pattern that model the specific problem should be
easily and successfully used to model the same problem, regardless of the context in which the
problem appears. SAPs are generated using the stability model [1–4]. In this subsection, we will
provide its structure, mantra, and the rationale-driven language used to discover and visualize
elemental pieces of knowledge (patterns), how to organize them, and how to relate them to for-
mulate an accurate solution in contexts, that shares the same core knowledge (rationale or goals,
and capabilities).
Building SAPs using software stability [1–4] for a specific problem involves myriad skills,
knowledge and steps beyond the identification of the tangible artifacts that are bound to a specific
context of applicability. It also requires a systematic capture and full understanding of the domain,
where our solution would be laid down and expanded. That includes, describing the problem not
from its tangible side, but focusing more on its conceptual side, describing underlying affairs with
respect to the problem, and the elements required to fulfill them. Part I comprises 5 chapters and
20 sidebars.

Chapter 1 titled “Stable Analysis Patterns Overview” introduces the key concepts, and tech-
nologies of the development of SAPs, such as stability model and knowledge maps [5],
where the enduring business themes (EBTs) or goals are the SAPs, and its business objects
(BOs) are their own capabilities. It also discusses related work and different analysis pat-
terns’ development approaches, the challenges that analysis patterns face with examples,
the overview of SAPs, the development processes of SAPs, and examples of SAPs.
Chapter 2 titled “Applying Analysis Patterns through Analogy: Problems and Solutions”
focuses on two of the qualities: traceability and generality. Generality means that the pat-
tern that analyzes a specific problem can be successfully reused to analyze the same prob-
lem whenever it appears, even within different applications or across different domains.
It discusses analysis patterns as templates: (1) The problems with using analysis patterns
through analogy and (2) SAPs with examples are discussed. It also shows how to apply
SAPs in different application.
2 Introduction

Chapter 3 titled “Pattern Language for Building Stable Analysis Patterns” provides an over-
view of the proposed pattern language, shows how a list of patterns build SAPs, and dis-
plays the relations between the different patterns. It also provides a detailed description of
each pattern that is part of the proposed pattern language.
Chapter 4 titled “Model-based Software Reuse Using Stable Analysis Patterns” treats SAPs as
model-based architectures and proposes nine essential properties (or metrics) to measure
pattern reusability that are used to compare the three different analysis patterns’ develop-
ment approaches.
Chapter 5 titled “Stable Patterns Documentation: Templates, UML Forms, Rules, and
Heuristics” addresses key questions and issues about each stable pattern. The template
is suitable for documenting stable atomic patterns and stable architectural patterns where
stable atomic patterns are SAPs (also called Enduring Business Themes [EBTs], goals,
rationales, aims, purposes, and objectives) and stable design patterns (also called Business
Objects [BOs] or capabilities used to achieve each of the goals). This chapter provides
three different templates with rules, UML forms, and heuristics to document any pattern:
(1) detailed, (2) mid-size, and (3) short templates.

Each of the chapters concludes with a summary and an open research issue. This chapter also
provides a number of review questions, exercises, and projects.
Chapter 1 has four sidebars (1–4):

Sidebar 1.1: titled “The Roots of Patterns—Historical Perspectives” explores the patterns
from ancient civilizations [6,7], such as Egyptians, Chinese, Indian, etc. and concludes
with ALEXANDRINE Patterns as Inherited Architectural Solutions [8].
Sidebar 1.2: titled “Common Stable Design Patterns” lists the most common design patterns
that will be utilized in developing SAPs as part of their capabilities to achieve them [9].
Sidebar 1.3: titled “Analysis Patterns’ References” presents a brief overview of the existing
journal and book literature on analysis patterns.
Sidebar 1.4: titled “Martin Fowler’s Analysis Patterns” discusses briefly Martin Fowler’s anal-
ysis patterns [10] and highlights their pitfalls with an example.

Chapter 5 has 8 sidebars (5–12):

Sidebar 5.1: titled “Context/Scenario Template.”

Sidebar 5.2: titled “NonFunctional Requirements.”
Sidebar 5.3: titled “Challenges Template.”
Sidebar 5.4: titled “Fayad’s Stability Model Templates.”
Sidebar 5.5: titled “Fayad’s Class Responsibility and Collaborations (CRC) Card.”
Sidebar 5.6: titled “Fayad’s Use Case Template.”
Sidebar 5.7: titled “Model Essential Properties.”
Sidebar 5.8: titled “Model Adequacies.”

A reference to sidebar on Functional Requirements in the Knowledge Maps Book [5].

REFERENCES
1. M.E. Fayad, and A. Altman, Introduction to software stability, Communications of the ACM, 44(9),
2001, 95–98.
2. M.E. Fayad, Accomplishing software stability, Communications of the ACM, 45(1), 2002a, 111–115.
3. M.E. Fayad, How to deal with software stability, Communications of the ACM, 45(4), 2002b, 109–1112.
4. M.E. Fayad, and S. Wu, Merging multiple conventional models into one stable model, Communications
of the ACM, 45(9), 2002c.
Introduction 3

5. M.E. Fayad, H.A. Sanchez, S.G.K. Hegde, A. Basia, and A. Vakil, Software Patterns, Knowledge Maps,
and Domain Analysis, Boca Raton, FL: Auerbach Publications, 2014.
6. C. Somers, and R. Engelbach, Ancient Egyptian Construction and Architecture, New York: Dover
Publications, 1990.
7. C. Eric, and H. O’Connor, David Kevin Amenhotep III: Perspectives on His Reign, Ann Arbor, Michigan:
University of Michigan Press, 2001, 273.
8. C. Alexander et al., A Pattern Language, New York: Oxford University Press, 1977.
9. M.E. Fayad, Stable Design Patterns for Software and Systems: Ultimate Solutions, Auerbach Publications,
2017.
10. M. Fowler, Analysis Patterns—Reusable Object Models, Reading, MA: Addison-Wesley Publishing,
1997.
 1 Stable Analysis
Patterns Overview
You look at where you’re going and where you are and it never makes sense, but then you look
back at where you’ve been and a pattern seems to emerge.
Robert M. Pirsig
Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values

Domain models are conceptual models that capture the main concepts within the domain and their
embedded relationships. These models play an important role in software development to facilitate
understanding and communicating the problem to be solved among developers and stakeholders.
However, developing conceptual models requires both domain knowledge and modeling skills,
which can be challenging for novice as well as experienced practitioners. Analysis patterns are
conceptual models that can be used to model and share domain k­ nowledge, and hence, they can
aid in developing domain models. However, most existing analysis patterns do not separate the core
concepts of the domain from business-­specific concepts, limiting the scope of the pattern usabil-
ity. In this chapter, the main c­ hallenges in analysis patterns reuse are identified and elucidated. To
overcome some of these challenges, the concept of Stable Analysis Pattern is proposed as a new
approach for developing patterns that separate domain concepts from business-specific concepts.
The proposed approach is illustrated through several examples.

1.1 INTRODUCTION
Developing software systems involves several activities, starting from domain and requirement
analysis to system implementation and deployment [1–7]. Numerous requirements, techniques, and
object-oriented design methods that are widely used in industry, start invariably with the develop-
ment of a domain model that captures the core concepts in the domain [8]. Developing domain
models, however, requires domain knowledge and modeling skills. But domain experts and analysts
may have limited access to skill and knowledge, faced with under-tied “time-to-market” constraints
and restricted by condensed budgets.
It has been long realized that software systems do share many requirements. For example, in a
health-care system and an e-commerce infrastructure, there is a common need for techniques to
attain “Information Privacy” in order to protect user information. At a conceptual level, the concept
of “Privacy” does not change in both systems, although, realizing privacy at the implementation
level is likely to be different in both systems. Nonetheless, conceptual modeling can greatly benefit
from capturing commonly recurring problems at a reusable, yet meaningful abstraction level.
Software community has long realized the advantage of reuse [1,2], which is evident by the
emergence of several reuse communities over the last few decades. Among these communities is
the patterns community that advocates reuse by extracting and documenting solutions of recurring
problems throughout the different phases of software development, for example, design (design
­patterns) and analysis (analysis patterns). In this book, we will focus on the important topic of
analysis patterns. Analysis patterns are known to shape the knowledge of the problem domain. They
support developers in understanding the underlying problem, rather than showing how to design a
solution. (Please refer to Sidebar 1.2 on Common Stable Design Patterns for creating stable analysis
patterns.)

5
6 Stable Analysis Patterns for Software and Systems

Despite the fact that analysis patterns have been around for almost a decade now, their reuse is
still limited when compared to design patterns and other reuse techniques. Here, we will argue that
this limited reuse is due to several shortcomings in existing analysis patterns structures including the
lack of stability, the lack of proper abstraction levels, and inadequate documentation. In this ­chapter,
we will first identify the main challenges that adversely impact analysis patterns’ reuse. Then, we
will propose the concept of Stable Analysis Pattern as a new approach for s­eparating ­problem
­concepts from business-specific concepts, in order to overcome some of the main ­shortcomings
in existing analysis patterns. We will also demonstrate the proposed approach through several
examples.
The remainder of this chapter is organized as follows: related work is discussed in Section 1.2;
challenges that face analysis patterns are discussed in Section 1.3. The concept of stable analysis
patterns is introduced in Section 1.4. In Section 1.5, an approach for developing stable analysis
patterns is described. Examples of stable analysis patterns are discussed in Section 1.6; conclusion
in Section 1.7. Please refer to Sidebar 1.3 (Analysis Patterns References), which is useful for more
knowledge about analysis patterns.

1.2 RELATED WORK

The increasing interest in analysis patterns over the last few years have led to several analysis
­patterns that span a wide spectrum of domains, such as healthcare, finance, business enterprise, and
system security [9–13]. Several types of analysis patterns have been proposed over the last decade
(Refer to Sidebar 1.4: Quick Survey of Analysis Patterns). We will briefly review these techniques
by classifying them based on their development approaches. In addition, we will also distinguish
between three different development approaches: Direct Approach, Specialization Approach, and
Analogy Approach.
In the Direct Approach, analysts identify analysis patterns they encounter in similar and related
projects. Identified patterns are not further generalized or abstracted; instead, they are presented the
way they were found. All developers, who follow this approach, believe that it is unsafe to further
abstract patterns generated within certain projects in order to make them reusable in other contexts,
as there is no guarantee that these abstracted patterns will successfully apply in other contexts.
Examples of pattern in this category are the analysis patterns given in Reference [13].
In the Specialization approach, analysts usually document patterns they come across; however,
in this approach, identified patterns are further abstracted, so that they can be applied to similar
and related applications through the process of specialization (i.e., by instantiating the abstracted
pattern).
In the Analogy approach, analysts document patterns, by following previously stated two
approaches; however, here patterns are abstracted to create templates that are applied to other appli-
cations through the process of analogy. Incidentally, this approach is widely used in the domain of
analysis patterns. In fact, in Reference [14], a pattern is defined as follows: A pattern is a template of
interacting objects, one that may be used again and again by analogy. However, applying analysis
patterns through analogy usually suffers from several significant limitations [15].

1.3 CHALLENGES THAT ANALYSIS PATTERNS FACE

In this section, we will identify and discuss the main challenges that analysis patterns face in
­general. We will also summarize the main challenges of analysis patterns as follows:

1. Pattern instability: Here, we will define stability, informally, as the degree by which the sys-
tem can accommodate future changes and evolving requirements while preserving most
of its original design. Software systems, by nature, evolve or change over time as new
Stable Analysis Patterns Overview 7

requirements emerge; yet, it is always desired that such changes do not result in higher cost
or force the system to be redesigned from scratch. If analysis patterns used in the system are
unstable themselves, then this instability will ripple or cascade through other development
phases, eventually leading to the development of unstable systems. Current analysis patterns
approaches do not consider the stability as a goal when designing and developing analysis
patterns.
2. Pattern redundancy: The increasing growth of the pattern community has also increased
the likelihood of finding several patterns that address similar problems. Analyzing any
problem with specific applications in mind might result in analysis models that are bound
to specific applications and that are hard to apply, when similar problems appear in other
applications. Consequently, several patterns that address similar problems, which are
­positioned within different applications will be derived and developed. For instance, dif-
ferent patterns have been proposed to model accounts.
3. Analysis patterns documentations: Describing pattern is perhaps as crucial as the p­ attern
itself. A fine thin line should be drawn between the pattern’s details and their depths.
Regarding a pattern’s details, it is understood that the quantum of information presented
to describe or highlight the pattern in hand, while a pattern’s depth is closely linked to
the technical complexity of the solution the pattern usually presents. Too great a ratio of
details to depth, or too small a ratio, might leave the user lose the intended track eventu-
ally ­making the pattern very hard to understand and reuse [1,2]. Efforts on exploring how
analysis patterns are documented are rather rare, while design pattern templates are the
most commonly used ways to document analysis patterns.
4. Identification of the problem boundary: One of the major challenges that developers
face while developing analysis patterns are to precisely identify the boundary of the
problems that these patterns try to analyze and evaluate. Without clear identification
of problem boundary, it is more likely that the pattern will embody many other prob-
lems that are invariably out of the scope of the main problem. For example, the word
“account” alone becomes a vague concept, if it is not allied with a word that is related
to a certain context. Besides all of the traditionally well-known business and banking
accounts, we also have e-mail accounts, online shopping accounts, etc. The account
pattern models has two ­significantly different problems: the “account” problem and the
“entry” problem. These are closely related, although they are independent problems. It
is quite possible that we come across numerous entries that do not have any accounts or
they are accounts without any entries. Tables 1.1 and 1.2 show some examples of such
situations.
5. Pattern traceability: This type of problem is very common in analysis patterns that
belong to the analogy approach (Section 1.3). When patterns are used as thorough analogy
approach, the original patterns are no longer extractable. This un-traceability factor may
complicate the maintainability aspect of the developed software.

TABLE 1.1
Accounts without Entries
1. Free online services account: Many online sites provide free goods or services. For example, some companies
provide learning software packages or instructional documents. In order to access these materials, you will need to
create an account. This account is merely a passport provided to the users to access their services; in fact, there is
nothing in this account that can be considered as your property.
2. Access account to the copy machine: Suppose, you have an account to access the copy machine in your school or
work. This account is no more than a passport for you to use the copier. There are no entries in this case.
8 Stable Analysis Patterns for Software and Systems

TABLE 1.2
Entries without Accounts
The following table contains information about class schedules, at the University of
Nebraska-Lincoln. In this table, each piece of information forms an entry to the
table. Here, we do not need any accounts where user entries could be maintained.
Call # Course Title Cr Hrs Time Day Room
2850 Computer Architecture 003 0230–0320p MWF Freg 112
2855 Software Engineering 003 0930–1045p TR Freg 111

1.4 STABLE ANALYSIS PATTERNS

In order to confront some of the problems that were discussed in Section 1.3, we will propose
the concept of Stable analysis pattern as a new approach for developing analysis patterns. Stable
­analysis patterns are broadly based on the generic concept of stability model [3–6] and Knowledge
Maps [7,14]. Before we proceed to discuss the details of stable analysis patterns, we will initially
review the main concepts of stability model.
Stability model is a layered approach for designing and developing robust software systems. In
this approach, the classes of the system are classified into three layers: the enduring business themes
(EBTs) layer [3,16], the business objects (BOs) layer [4], and the industrial objects (IOs) layer [4].
Based on its innate nature, each class in the system is classified into one of these three layers. EBTs
are the classes that present the enduring and core knowledge of the underlying industry or business.
Therefore, they are extremely stable and form the nucleus of the stability model. BOs are the classes
that map the EBTs of the system into more concrete and precise objects. BOs are semi-conceptual
and externally stable, but they are internally adaptable. IOs are the classes that map the BOs of
the system into physical objects. The detailed properties of EBTs, BOs, and IOs are discussed in
References [15,17].
Figure 1.1 illustrates the basic concepts of stable models and their uses. The EBTs and BOs
in the left-hand side of the figure form and create a stable core. By externally adapting the BOs
through hooks and by adding the necessary IOs, two new systems were constructed, that is, system

EBTs

Add IOs of system 1

IOs
Adapt BOs

BOs
Adapt BOs System 1
EBTs + BOs = Stable core

Add IOs of system 2

IOs

System 2

FIGURE 1.1 Software stability concepts. The stable core (in the left) has been adapted to construct two
systems (in the right).
Stable Analysis Patterns Overview 9

Problem A Use
Identify IOs for Problem B
problem B

Use stability
concepts Extend
Extend

Develop Adapt
Identify EBTs, Stable Adapt BOs for
and BOs pattern problem B

FIGURE 1.2 Stable analysis patterns approach.

1 and system 2, which are shown in the right-hand side of the figure. It is important to point out the
assumption that these two systems are closely related (e.g., share the same domain) so that we can
identify common EBTs and BOs.
The main goal of stable analysis patterns is to develop models that capture the core knowledge
of the problem and present it in terms of the EBTs and the BOs of that problem. Consequently, the
resultant pattern will inherit stability features and hence it can be reused to analyze the same prob-
lem whenever it appears. Figure 1.2 shows the generic approach of developing and reusing stable
analysis patterns.
Since the EBTs and BOs are stable by their nature, it is guaranteed that they will compose a
stable pattern, and hence, one can overcome the instability problem that was discussed in Section
1.3. Stable pattern can be used by directly extending it by attaching most appropriate IOs for the
problem B (Figure 1.2). Stable patterns may also be used by first adapting the hooks configurations
of its BOs and then attaching all appropriate IOs for problem B (Figure 1.2).

1.5 DEVELOPMENT OF STABLE ANALYSIS PATTERNS

In this section, we will describe a high-level iterative approach for developing stable analysis
­patterns. Figure 1.3 illustrates the main activities in the course of the development approach and
essential relations between them.

Problem Identify problem

domain boundary

Refine
EBTs Identify
EBTs Identify EBTs Express relationships between
identification objects EBTs abstraction EBTs and BOs
heuristics list level

Refine BOs
BOs EBTs Identify BOs list
identification objects Refine
heuristics BOs
Key:
Normal Iterative Second abstraction
flow flow level flow

FIGURE 1.3 The high-level approach for developing stable analysis patterns.
10 Stable Analysis Patterns for Software and Systems

In the following section, we will also explain different phases of the integration approach:
Identify problem boundary: The reusability of a pattern is related to the number of problems it
addresses and tackles. If a pattern is used to model an overly broad portion of a system, the gener-
ality of resulting patterns is sacrificed—the maxim holds here: “the probability of occurrence of
all the problems together is far lesser than the probability of the occurrence of each problem when
considered individually.”
Identifying problem boundaries is not a trivial activity for many important reasons. First, certain
groups of problems often appear together, and as a result, they will be naturally considered as one,
solitary problem. Here, the resultant model may or may not be correctly modified to sculpt these
problems whenever they appear separately. Additionally, in practice, not all of the small problems
that are separable are qualified to form practically capable and stand-alone problems. There is a
subtle tradeoff between dividing the problem and the complexity of integrating smaller problems to
model a larger problem.
This phase can be accomplished by checking whether the problem could be further divided into
smaller and practical problems. Answering the following questions help us to achieve the above-
mentioned task: “What is the exact problem that we want to solve?” “Can we split this problem
further into a list of smaller problems?” “Are there any known and identified possible scenarios,
where these smaller problems might appear?” If one is able to find practical scenarios for each of
the smaller problems that are separated, then there is an urgent need to model each of them sepa-
rately. If smaller problems have no practical use, they should be grouped together and considered
as combined entities.
Identifying objects of EBT: We will need to identify core elements of the problem while we
are developing a stable pattern. Certain issues are known to complicate the identification of
EBTs in a given problem. For instance, domain experts may not always be able to identify accu-
rate, precise, and relevant EBTs [14]. Thus, experience is absolutely essential, but not sufficient
enough for extracting the right EBTs of the problem. The 3-step heuristic shown in Table 1.1 will
help us in identifying the most appropriate EBTs of the problem:
As an example for applying the 3-step heuristic that is shown in Table 1.3, it is important to
­consider the identification of the EBTs in a modeling account:

Step 1 Create initial EBTs list. We will need to answer the question: “What is the ‘Account’
made for?” The initial EBTs list might include the following EBTs: Storage, Ownership,
Tractability, and Recording.
Step 2 Filter EBTs list. In this step, we may need to dig out the most appropriate EBTs for
the “account” problem. To do so, we will require examining each EBT given in the list
and see whether or not it reflects the enduring concepts of the problem modeled. Since
our main focus is centered on modeling the “account” problem alone, we will realize that
most of the EBTs that we have defined are mainly related to accounts that have entries. For
instance, “Storage,” “Tractability,” and “Recording” are all important concepts that are
dependent upon the existence of entries within the account. Suppose the account has no
entries, “Storage,” “Tractability” and “Recording” is unneeded. Therefore, we may need to
eliminate the EBTs like “Storage,” “Tractability,” and “Recording” from the list. Now, we
have only one EBT in the arrangement that is, “Ownership,” instead of four.
Step 3 Check the Main EBTs Properties. We will also answer the following questions: “Can
we replace the ‘Ownership’ with other EBT?”—No. “Is ‘Ownership’ stable internally and
externally?”—Yes. “Does ‘Ownership’ belong to a specific application or domain?”—No.
“Can we have direct physical representation for ‘Ownership’?”—No.

Identifying business objects: During the development of a stable analysis pattern, and after iden-
tifying the EBTs of the problem, we will want to identify the BOs of the problem. In some cases,
it is not readily obvious whether the object is an EBT or BO. After the EBTs of the problem have
Stable Analysis Patterns Overview 11

TABLE 1.3
A 3-Step Heuristic for Identifying EBTs
Step Step Name Details
1 Create Initial EBTs List To create the initial list of the EBTs of the problem, answer the question:
“What is the ‘problem’ designed for?” In other words: “What are the reasons
for the existence of the ‘problem?’” The output of this step is the list of the
initial EBTs of the problem. These EBTs are still tentative and some of them
are not as strongly related to the problem as they might appear.
2 Filter the EBTs List Eliminate the redundant and irrelevant EBTs from the initial list. People
unintentionally construct the initial EBTs list with a specific application in
mind. The output of this step is a modified EBTs list, which should contain
less EBTs than the initial list.
3 Check the Main EBTs Properties Examine the EBTs obtained in previous steps against the main essential
properties of the EBTs. The typical procedure is to answer the following
questions for each EBT in the list. The desired answer is written in bold for
each question: Can we replace this EBT with another one? No. Is this EBT
stable internally and externally? In other words, does this EBT reflect the
core aspects of the problem we are trying to model? Yes. Can we directly
represent this EBT physically? No. It is important to note that the EBTs
should not have direct physical representations (IO); otherwise they should
be considered BOs instead. For example: “Agreement” is a concept and one
can see it as an EBT. However, “Agreement” also has a direct physical
representation (for instance “Contract”). Therefore, “Agreement” is not an
EBT, it is a BO.

been identified, the conceptualization becomes comprehensible, since the BOs of the problem must
be based on the defined EBTs.
In addition to the main BOs identified for the problem, it is also possible to obtain some hidden
BOs that have no direct relationship with the defined EBTs. Instead, they are related to the main
BOs and to the other hidden BOs in the problem. The 4-step, heuristic shown in Table 1.4 can help
us in identifying the most appropriate BOs of the problem:
As an example of applying the 4-step heuristic shown in Table 1.4, suppose we want to identify
the possible BOs for the given “account” problem. In order to identify these BOs, we will apply all
the four steps that we have proposed earlier. The input of the first step is the EBTs list that contains
one essential EBT, “Ownership.”

Step 1 Identify the main BO of the problem: We will also answer the following questions:
How can we approach the goal of “Ownership”? In the account problem given here, to
achieve “Ownership,” we need to have something to own. The “Account” itself is what
makes the meaning of “Ownership.”
What are the results of doing/using “Ownership”? By having “Ownership,” we also
have “Privacy,” but this is not a BO. Rather, it is a redundant EBT, and hence we would
exclude it. “Agreement” is a possible BO for the problem, but, when you own an account,
you will have to agree with its policy. Who should do/use “Ownership”? For the “Owner”
to be able to use the “Account,” he or she should follow the responsibilities that are
defined by the “Ownership” policy. Hence, the BOs main list is “Owner,” “Account,” and
“Agreement.”
Step 2 Filter the main BOs List. Now, the following BOs still remain: “Owner,” “Account,”
and “Agreement.” While modeling this unique problem, we have debated the accuracy of
using the BO “Agreement” in our model. “Agreement” is a more general term that appears
12 Stable Analysis Patterns for Software and Systems

TABLE 1.4
A 4-Step Heuristic for Identifying BOs
Step Step Name Details
1 Identify the main BOs of the problem We will identify the main set of BOs that are directly related to each of
the EBTs that we have in the problem. There could be one or more BOs
corresponding to each EBT in the problem. However, some of the EBTs
may have no corresponding BOs. The main set of BOs of the problem
could be identified by answering one or more of the following questions
for each EBT: How can we approach the goal that this EBT presents?
(e.g., To achieve the goal of the EBT Organization, we can use, the BO
Schedule. Another example: for the EBT Negotiation, we need the BOs
AnyContext, and AnyMedia to perform the negotiation). What are the
results of doing/using this EBT? (e.g., for the EBT Negotiation, the
eventual result is to reach an Agreement, so this is one possible BO that
maps this EBT). Who should do/use this EBT? (e.g., The BO Party
does/ uses Negotiation. This Party can be a person, a company, or an
organization. Therefore, Party is one possible BO that maps the EBT
Negotiation).
2 Filter the main BOs List Purify the main BOs identified in the previous step. The objective of this
step is to eliminate the redundant and irrelevant BOs from the initial list.
One way to achieve this goal is to debate the listed BOs with a group.
(Please refer to Sidebar 1.2)
3 Identify the hidden BOs of the Identify the hidden BOs of the problem. These BOs are named “hidden,”
problem because they have no direct relationships with any of the EBTs of the
problem. Thus, we cannot extract them in the first two steps we have
performed. For example, let us assume that we need to model a simple
transportation system that offers transportation services for different
types of materials (e.g., gas, water, etc.). One possible EBT is
Transportation. One possible BO that maps this EBT is Transport.
A possible IO that can physically represent this BO is Trucks. In this
problem, one possible hidden BO is Materials. We do not have a direct
EBT that the BO Materials can be mapped to; however, there is a clear
relationship between the two BOs: Transport and Materials.
Before thinking about the hidden BOs in the problem, just visualize a
provisional scenario for each EBT and its corresponding BOs. Then,
answer the question, “What is still missing in the problem?” Usually,
the answer to this question is the list of the hidden BOs of the problem.
Some problems do not have any hidden BOs, especially in the case of
the small-scale problems.
4 Check the characteristics of the BOs This step is to ensure that the identified BOs satisfy the main BOs
characteristics. BOs are partially tangible, internally stable and should
remain stable throughout the life of the problem, externally adaptable
through hooks, and can be physically represented by IOs.

in many contexts and under different scenarios. For instance, in the “­negotiation” problem,
we will need the BO “Agreement.” Therefore, possessing the BO “Agreement” as part
of the “Account” pattern will offset the simplicity property of the pattern. “Agreement”
is a stand-alone problem that occurs in many contexts, and hence it is more appropriate
to model the “Agreement” problem wholly independent of the context of this problem.
Consequently, we have excluded the BO “Agreement” from the main list. The filtered BOs
list thus contains “Account” and “Owner.”
Stable Analysis Patterns Overview 13

Step 3 Identify the hidden BOs of the problem. After identifying and filtering the main BOs
list, now answer this question, “Does the account problem need anything else so as to
be complete in every sense?” We have an “Account,” its “Owner,” and the concept of
“Ownership” that regulates the responsibilities and benefits of the “Owner.” This is all that
is needed to model any basic account.
Step 4 Check the characteristics of the BOs. BO should be partially tangible. “Owner” and
“Account” are partially tangible. BOs are internally stable, and they should be so through-
out the life span of the problem. “Owner” and “Account” are always stable. In other words,
we cannot have any account without having these two objects in its model. Here, BOs are
adaptable; thus, they might change externally.

Express abstraction level: Stable patterns can be generally classified into two main categories:
simple and composite patterns. A simple analysis pattern is a pattern that consists of classes and
no sub-patterns exist. On the other hand, composite stable analysis pattern ­consists of both classes
and subpatterns. Simple patterns are said to have one level of abstraction (such as the conventional
class diagram), while composite analysis patterns may have several levels of abstraction depending
on the structure of its subpatterns. Figure 1.4 shows the negotiation stable analysis pattern, which
is actually a composite pattern. Notice that the AnyMedia box in the displayed pattern is a pat-
tern in itself. Two different ­applications of the negotiation stable analysis pattern are illustrated in
Figures 1.7 and 1.8.
In stable ­patterns, we usually differentiate between two main participants in the pattern model:
classes, and patterns. Classes are defined as in the case of any traditional object-oriented class
diagram. On the other hand, patterns also present a second level of abstraction in the model,
where each pattern is by itself another model that contains classes and in some cases, other
patterns.
A class within a stable pattern could be one of the five following kinds: an EBT, a BO, an IO,
a sub-pattern and EBT, or a sub-pattern and BO. Therefore, each class in the stable pattern should
have one of the following tags: EBTs, BOs, IOs, Pattern-EBT, or Pattern-BO.
Note that the second abstraction level flow shown in Figure 1.4 will restart the modeling process
again from the first step. The negotiation pattern has resulted from the first execution of the develop-
ment process in Figure 1.4, the second abstraction level is the result of repeating the development
process for all the patterns that are tagged with <P-Bo>, but for different components (classes) in

EBT BO

Defines or
Handles 1..* <P-BO> follows 0..* <P-BO> {OR} <P-BO>
Party Criteria Rule
0..*
es
nc
lue
Inf

<EBT> Through 0..* <P-BO> Resolves 1..* <P-BO> Leads to <P-BO>

Negotiation Mechanism Option 1..* Agreement

Using

1..*
For a specific <P-BO> defines <P-BO> names <P-BO> <P-BO>
1..* Context 1..* Type 1..* Entity 1..* Media
Event

FIGURE 1.4 Negotiation pattern stable object model.

14 Stable Analysis Patterns for Software and Systems

the ­negotiation pattern (in Figure 1.4), the result of repeating the development process over the
AnyMedia, the AnyParty has resulted in the second abstraction level all of the patterns which are
tagged with <P-Bo>.

1.6 EXAMPLE OF STABLE ANALYSIS PATTERNS

We would illustrate the concept of stable analysis patterns by presenting two stable analysis
­patterns: negotiation analysis patterns (Figure 1.4), and trust analysis patterns (Figure 1.7) [11].

1.6.1 The Negotiation Analysis Pattern

Negotiation may take place in different situations and under different context. For instance, buy-
ing or selling activity usually involves some sort of negotiation (e.g., buying or selling a home or
a car). Similarly, in the domain of software systems, negotiation appears frequently in the process
of d­ evelopment of different applications. For example, developing a piece of software for online
­auctions and e-shopping might involve the negotiation for the price and/or the negotiation for dif-
ferent product aspects and issues. More technically, negotiation is an essential part in the develop-
ment of next generation web-based devices and appliances. Today, numerous devices that need
to access the web usually diverge greatly in their capabilities, making them highly desirable for
similar resources to be made available in several different representations (e.g., different languages).
Negotiation algorithms also play a fundamental role in assisting servers to decide the mode of
­representation of a device or gadget should be provided. In this case, the browser (client agent) will
indicate its preferences and options.
The important fact that negotiation concept embed a wide range of spectrum of heterogeneous
applications, along with the reality that the negotiation concept itself does not change whenever it
appears, make the development of a model that captures the core knowledge of the negotiation very
dicey and truly challenging.
We may also apply the negotiation pattern in two different applications: negotiation of buying a
car, and content negotiation using composite capability/preference profile (CC/PP) (for simplicity,
these examples do not present the complete model for the problem. The details of these examples
can be found in Reference [18]). Figure 1.5 shows the model of the negotiation used in buying a car,
and Figure 1.6 shows another instance of the negotiation pattern [15].

1.6.2 The Trust Analysis Pattern

The emerging boom of extremely useful web-based applications, like e-commerce, e-business, and
e-negotiation, makes the development of an accurate model, which captures that the core aspect
of trust is of great importance and immense interest. The issue of trust has been studied inten-
sively in the literature from different perspectives [16,19,20]. In addition, several studies have also
focused on the deployment issues of trust in e-commerce and web-based applications. For instance,
in Reference [21], a summary of the three trust-building measures for e-commerce applications is
given.
Even though different applications impose different requirements for establishing, different
applications may still share a vital part of trust requirements, although they differ in some aspects.
We will develop an analysis pattern that captures the core knowledge of the trust concept that is
independent of any specific application. This eventually leads to the trust analysis pattern, which is
shown in Figure 1.7.
Here, we will use the patterns presented in Reference [21] as an example of trust pattern applica-
bility. Three sample patterns to illustrate the idea of building a pattern language for online consumer
trust have also been proposed in Reference [21], namely, “Contact Us,” “Consumer Testimonials,”
Stable Analysis Patterns Overview 15

IO
EBT BO

1..*
<IO>
Customer
Defines or
Handles 1..* follows 0..* {OR}
<P-BO> <P-BO> <P-BO> 1..*
Party Criteria Rule
0..*

s
<IO>

ce
en
Car dealer
f lu
In

Makes
1..*

Resolves Leads to <IO>

<EBT> Through 0..* <P-BO> 1..* <P-BO> <P-BO> Finance
Negotiation Mechanism Option 1..* Agreement contract

Received by
Speaks on

Agreed by
Usi
ng 1..*

<IO>
Phone

1..*
For a <P-BO> <IO>
specific Defines Names Media Mail
<P-BO> <P-BO> <P-BO>
Context 1..* Type 1..* Entity 1..*
1..*

Event

Sent through
<IO>
Warranty

<IO>
Price

FIGURE 1.5 Examples of the negotiation pattern: buying a car example.

and “Return Policy.” Each of these three patterns represents, in the given order, an example of one
of the following trust-building recommendations presented in Reference [22] and summarized in
Reference [21]: information policy, reputation policy, and warranty policy.
Based solely on the stability concepts (Section 1.3), it is easy to see the three main trust-
building recommendations: information policy, reputation policy, and warranty policy, could
be viewed as BOs, while the example pattern for each category “Contact Us,” “Consumer
Testimonials,” and “Return Policy,” respectively, can be regarded as IOs. This simple, yet effec-
tive mapping allows us to better understand the structure of the given patterns and to develop a
relationship between them and the trust stable analysis pattern. It is also possible to plot the three
categorizes and their corresponding patterns that are proposed in Reference [21]. Notice that the
AnyLog <P-Bo> shown in the Figure 1.7 represents the AnyLog in the trust analysis patterns in
the second level.
We can also use trust analysis pattern to gain more insight into how comprehensive the patterns
in Figure 1.2 are. It really turns out that all the proposed patterns are related to the AnyLog pattern,
which is part of the trust analysis pattern. For example, we can argue that a consumer would use the
three proposed policies together in order to perform the rating process for trusting the correspond-
ing e-commerce web site (which in this case could be just a matter of deciding, whether to shop in
 16

IO
EBT BO

<IO>
Client
Defines or
Handles 1..* follows {OR}
<P-BO> 0..* <P-BO> <P-BO>
Party Criteria Rule
0..* <IO>
CC/PPRepository

s
ce
en
<IO>

lu
nf
Service provider

I
1..*
<IO>
Original server

<EBT> Through 0..* <P-BO> Resolves 1..* <P-BO> Leads to <P-BO> <IO>
Negotiation Mechanism Option 1..* Agreement Adapted content
Sends
Return

Usi
ng <IO>
Request

1..*

1..*
<IO> Through
<P-BO> Internet
For a specific defines Media
<P-BO> <P-BO> names <P-BO>
1..* Context 1..* Type Entity 1..*
1..*
Event
Stable Analysis Patterns for Software and Systems

FIGURE 1.6 Examples of the negotiation pattern: negotiation example.

Stable Analysis Patterns Overview 17

EBT BO

-Countries -People
-Organizations -Companies
-Political parties -Family
-Any mixture of the above

Asks 1..* <P-BO>

Party
Specifies
And/Or <P-BO>> 0…* <P-BO>
1..* Actor And/Or
Criteria
Specifies
Be trusted
0..*
Basedon 0..*

<EBT> <P-BO> <P-BO>

Trust Done by Mechanism Rating
Results 0..*
0..*
0…*
Operates on

Based on
1..*

<P-BO> 0…*
Party Related to
<P-BO> Recorded on <P-BO>
And/Or Log Log
<P-BO>> 1…*
Actor 1…*
-Collection of records -Situation
-Past experience -Video
-Creditre ports -Movies
-Historical records -Books
-etc.

FIGURE 1.7 The Trust analysis pattern. (From R.T. Vaccare Braga et al., A confederation of patterns for
business resource management, Pattern Language of Programs Conference, Monticello, IL, 1998.)

this site or not). In that sense, all the three proposed patterns can fit in our analysis patterns as an
instance of AnyLog.
As shown in Figure 1.8, even though the three sample patterns proposed in Reference [21] are not
claimed to be complete or sufficient, analysis pattern can be used to show that the three categories of
the trust-measures (information policy, reputation policy, warranty policy) that were used as drivers
to the three sample patterns (Contact Us, Customer Testimonials, Return Policy) are not perfect and
does not fully cover the core knowledge of trust concept. In the meantime, we can argue that none
of the three categorizes covers the rating issues, which is presented as AnyRating in our analysis
pattern. This rating process is a fundamental step for any trust process, but the way that the rating
process is conducted may greatly differ though.
Another important aspect in the analysis pattern is that it covers future applications that are
likely to emerge in the near future, which is why we claim that this trust pattern is robust and
stable. One can argue that in the case of e-commerce consumer trust, the rating process is subjec-
tive and will not be implemented as part of the system. The user, a human being, will take the
­decision of whether to trust an e-commerce application or not. However, recent a­ pplications, such as
e-­negotiation, may involve a trust agent that will be responsible for automatically u­ nderstanding the
AnyLog records and performing the rating process, and based on that it will take the trust decision.
Such visible application is beyond the capabilities of the patterns c­ ategorizes given in Reference
[21]; however, our analysis pattern can still capture the aspects of the trust in these systems, and
hence, can be still applied in a wide spectrum of domains.
18 Stable Analysis Patterns for Software and Systems

AnyLog

Policy

Information policy Reputation policy Warranty policy

Contact Us Customer Testimonials Return Policy

FIGURE 1.8 A diagram o represent patterns and categories given in Reference [20].

1.7 SUMMARY
In this chapter, we have successfully identified the main challenges that limit the use of analysis
patterns. To overcome some of these problems, we have proposed the concept of stable analysis
­patterns. Stable analysis patterns separate the core concepts of the problem from the business-
specific concepts, thereby leading to conceptual models that are more reusable compared to ­existing
analysis patterns. We have illustrated the approach with a number of examples and showed how
stable ­analysis patterns can help not only to model the problem, but also to develop a deeper
­understanding of the essence of the problem.

1.8 OPEN AND RESEARCH ISSUES

Generate a catalog of stable analysis patterns fully documented and implemented to be used as
part of new stable programming environments, and show how we can easily generate sophisticated
applications very quickly and perform dynamic analysis of each of the generated applications on top
of the stable analysis patterns. This will ultimately lead to comparative studies and real-time data
about the dynamic analysis, and allow the developers and users of the applications to give concrete
results based on real running systems or applications.

OVERVIEW QUESTIONS
1. What is a domain model?
2. What are the properties of domain models?
3. T/F: Developing conceptual models require both domain knowledge and modeling
skills.
4. T/F: Analysis patterns are conceptual models that can be used to model and share domain
knowledge.
5. T/F: Stable analysis patterns (SAPs) separate the core concepts of the domain from
­business-specific concepts.
6. T/F: Traditional analysis patterns do not separate the core concepts of the domain from
business-specific concepts.
Stable Analysis Patterns Overview 19

7. T/F: A traditional analysis pattern has a very limited reuse.

8. T/F: SAPs model the knowledge of the problem domain.
9. T/F: SAPs aid the understanding of the problem, rather than showing how to design a
solution.
10. Traditional analysis patterns have limited reuse. Why?
11. Identify and discuss the traditional analysis patterns development approaches.
12. Name three samples of traditional analysis patterns developed using direct approach.
13. Name three samples of traditional analysis patterns developed using specialization approach.
14. Name three samples of traditional analysis patterns developed by using analogy approach.
15. T/F: SAPs are based on stability model.
16. Stability model is a layered approach for developing software systems.
17. Stability models have three layers. Name them?
18. T/F: EBT layer is the nucleus layer of stability model.
19. EBTs are enduring concepts and extremely stable.
20. T/F: EBTs are classes and they could be considered as goals, aims, rationales, and
objectives.
21. T/F: BOs is the middle layer of stability model.
22. T/F: BOs are internally stable and externally adaptable.
23. T/F: BOs are semi-tangible and mostly conceptual.
24. T/F: BOs are the capabilities of achieving the goals (EBTs).
25. T/F: BOs are classes that map the EBTs of the system into more concrete objects.
26. T/F: IOs are classes that map the BOs of the system into physical objects.
27. T/F: BOs are externally adaptable through hooks or extension points by adding the
­necessary IOs.
28. EBTs + BOs = Knowledge Map of any domain or any system or any pattern.
29. T/F: IOs can be connected directly to the EBTs
30. Identifying the problem boundaries is not trivial for many means. Discuss.
31. Describe the process of identifying the EBTs.
32. Describe the process of identifying the BOs.
33. What are the differences between EBTs and BOs?
34. T/F: The product of the first-level abstraction is design.
35. T/F: The product of the second-level abstraction is architecture.
36. What are the differences between SAPs and traditional analysis patterns?

EXERCISES
1. Take the negotiation pattern and add a second abstraction level for AnyAgreement.
2. Take the trust pattern and add a second abstraction level for AnyRating.
3. Apply the Negotiation pattern to purchasing an item online.
• Draw a class diagram of using negotiation patterns to purchase an item online.
• Generate a significant use case for this context.
• Map the use case to a sequence diagram.

PROJECTS
1. List the properties of EBTs and each of the properties as Stable Analysis Patters.
2. For negotiation stable analysis pattern.
a. Name a few context of negotiation.
b. Use one of the context and draw a class diagram.
c. Document a detailed and significant use case selected context in b.
d. Create a sequence diagram of the created use case of c.
20 Stable Analysis Patterns for Software and Systems

3. For trust stable analysis pattern.

a. Name a few context of Trust.
b. Use one of the context and draw a class diagram.
c. Document a detailed and significant use case selected context in b.
d. Create a sequence diagram of the created use case of c.

SIDEBARS
SIDEBAR 1.1 THE ROOTS OF PATTERNS: HISTORICAL PROSPECTIVE
The roots of patterns in general include ancient Egyptians, the ancient Chinese and Indian
civilization, Muslim civilization and architectures, and western civilization, and the influence
of mathematics and architecture from many other civilizations. This sidebar will conclude
with ALEXANDRINE Patterns as Inherited Architectural Solutions.

Ancient Egyptians and Imhotep: The Architect

The original intention of patterns was introduced by Ancient Egyptians, as shown in
Figure SB1.1.1. The ancient Egyptians built their pyramids, tombs, temples, and palaces out
of stone, the most durable of all building materials. Although earthquakes, wars, and the
forces of nature ravaged these memorable structures, the remnants of Egypt’s monumental
­architectural achievements are clearly visible across the ancient land, a tribute to the great-
ness of this wonderful civilization. These building projects took a high degree of architectural
and engineering skills and techniques, and the accumulation of a large labor force consisting
of highly trained craftsmen and laborers [1,2].
Apart from the great pyramids, Egyptian buildings were decorated with beautiful p ­ aintings,
carved stone images, hieroglyphs, and other three-dimensional statues. The superb art of
yesteryears tells the undying story of the pharaohs, the gods, the common people, and the
natural world of plants, birds, and animals. The eternal beauty and grandeur of these sites are
beyond any comparison. How the ancient Egyptians were so successful in constructing these
massive structures using primitive tools is still a big mystery.
Pattern Mystery: How to build massive structures using primitive tools?
Imhotep, the world’s first well-known architect who built Egypt’s first pyramids, is often
recognized as the first of many skills and techniques: a doctor, a priest, a scribe, and a
vizier, among others [1,2]. He is known to have worked for Djoser, the second great king of
Egypt’s third dynasty. A historical inscription calls him “the chancellor of the king of lower
Egypt,” the “first one under the king,” the “administrator of the great mansion,” and the “chief
carpenter.”

FIGURE SB1.1.1 Ancient Egyptians architectures.

Stable Analysis Patterns Overview 21

Mathematics and Architecture in Several Civilizations

Historically, architecture was actually an integral part of mathematics, and in many periods
of the past, the two disciplines were indistinguishable from each other [3]. In the ancient
world, mathematicians were architects, whose great constructions—the pyramids, ziggurats,
­temples, stadia, and irrigation projects—we still gape and marvel at today. In the classical
period of Greece and ancient Rome, architects were also accomplished mathematicians.
When the Byzantine emperor Justinian wanted an architect to build the Hagia Sophia as a
building that surpassed everything ever built before, he sought the help of two professors
of mathematics (geometers), Isidoros and Anthemios, to perform the task [4]. This practice
continued throughout the great Islamic civilizations. Well-known Islamic architects created
a wealth of two-dimensional tiling patterns many centuries before western mathematicians
started giving a comprehensive and complete classification [5].

Check the Architectural History

In the past, architecture was considered an amalgamation of several significant influences
such as artistic, cultural, political, technological, and social. There was also a direct relation-
ship between the build environment and the overall meaning of the construction. Themes like
functions, purposes, objectives, goals, and other intangible functions were directly related to
the concept of architecture. Being a prisoner of limitations, potentialities, and restrictions of
history, architecture offered a wider perspective of understanding things. One such example
of this perception is the wide belief that architecture is very formal with wider association
with many morphological characteristics like form, technique, and materials.
Pattern Mystery: Patterns exist in all walks of life.

Check the Type of Architectures

Our world has witnessed a rapid advancement in the development of architecture, right from
the Neolithic era to present-day modern architecture. Neolithic or “stone age” architecture
includes many old structures that are considered the oldest in the history of humankind.
Every well-known civilizations and cultures around the world has contributed immensely
to the growth and progress of architecture. Each of the succeeding periods in the timeline
of history had its own type of architectural concepts and principles that were based on the
finer aspects of form, shape, concepts, vision, goal, materials, techniques, purposes, and
objectives. As time progressed, man’s thinking process underwent a radical evolution too!
Currently the concept of architecture goes beyond the abovementioned principles to a wider
scheme of things such as geometry, symmetry, usability, stability, life-span, tangibility, user
comfort, styles, and a concept of integrating several things that are nonarchitecture in nature.
Pattern Mystery: Patterns can be categorized or classified in different category level and
different classes.
• Assyrian architecture
• Babylonian architecture
• Etruscan architecture
• Minoan architecture
• Maya architecture
• Mycenaean architecture
• Persian architecture
• Sumerian architecture
• African architecture
• Chinese architecture
• Indian architecture
22 Stable Analysis Patterns for Software and Systems

• Islamic architecture
• Japanese architecture
• Mesoamerican architecture
• Incan architecture
• Classical architecture
• Architecture of ancient Greece
• Roman architecture
• Medieval architecture
• Byzantine architecture
• Sassanid architecture
• Romanesque architecture
• Gothic architecture
• Tudor and Jacobean architecture
• Renaissance architecture
• Baroque architecture
• Regency architecture
• Neo-Classical architecture
• Neo-Gothic architecture
• Neo-Byzantine architecture
• Neo-Romanesque architecture
• Jacobethan architecture
• Tudorbethan architecture
• Beaux-Arts architecture
• Modern architecture
• Expressionist architecture
• Futurist architecture
• Functionalism (architecture)
• De Stijl
• Bauhaus
• Art Nouveau
• Art Deco
• International style
• Postmodern architecture
• Googie architecture
• Deconstructivist architecture
• Australian architectural styles
• Canadian architecture
• Indonesian architecture
• Origamic architecture (OA)
• Spanish architecture
• Temple architecture (Latter-day Saints)

Alexandrine Patterns as Inherited Architectural Solutions

Christopher Alexander and his associates first attempted to define patterns in solution space
by collecting architectural and urban solutions into a Pattern Language [6]. These distill time-
less archetypes such as the need for light from two sides of a room; a well-defined entrance;
interaction of footpaths and roads; a hierarchy of privacy in different rooms of a house; etc.
The value of Alexander’s Pattern Language is that it is not about specific building types, but
about building blocks that can be combined in an infinite number of ways. This implies a
more mathematical, combining approach to design in g­ eneral. Unfortunately, this book is not
yet used for a required course in architecture schools [3].
Stable Analysis Patterns Overview 23

Alexandrine patterns represent solutions repeated in time and space, and are thus akin
to visual patterns transposed into other dimensions [7]. Fortunately, the structural solutions
that architects depend upon remain part of engineering, which preserves its accumulated
­knowledge for reuse [3].
Pattern Mystery: Patterns capture the essence of successful solutions to recurring design prob-
lems in urban architecture.
References
1. S. Clarke, and R. Engelbach, Ancient Egyptian Construction and Architecture, New York, NY:
Dover, 2014.
2. E.H. Cline, and D.K. O’Connor, Amenhotep III: Perspectives on His Reign, Ann Arbor, Michigan:
University of Michigan Press, 2001, p. 273.
3. N.A. Salingaros, Architecture, patterns, and mathematics, originally published in the NNJ 1(2),
1999, has become widely read and referred to on the Internet, we have decided to republish an
updated version of it, included new Internet links. It is also now available in print in the Nexus
Network Journal vol. 1 (1999).
4. N.A. Salingaros, The laws of architecture from a physicist’s perspective, Physics Essays, 8, 1995,
638–643.
5. R.J. Mainstone, Hagia Sophia, New York, NY: Thames and Hudson, 1988.
6. B. Grünbaum, and G.C. Shephard, Tilings and Patterns, New York, NY: Freeman, 1987.
7. C. Alexander et al., A Pattern Language, New York, NY: Oxford University Press, 1977.

SIDEBAR 1.2 COMMON STABLE DESIGN PATTERNS

1. AnyActor: The AnyActor design pattern models the concept of actor by using
Software Stability Model [1–5] and knowledge maps [6]. Since AnyActor design pat-
tern captures the core knowledge, it is easy to model AnyActor in any a­ pplication,
by just hooking in the dynamic components of the application. AnyActor can
represent a human, smart hardware device, external software package, or crea-
tures depending on the context, where the term AnyActor is being used. The
AnyActor design pattern can be applied to numerous applications and within diverse
­disciplines such as Software systems, Entertainment Business, and other fields like
renting, lending, engineering, and science applications, etc. This pattern can be
applied to different applications where AnyActor performs diverse roles.
2. AnyParty: AnyParty is the most commonly used entity in the entire system.
Generally, AnyParty refers to an external legal user of the system. However,
AnyParty can also be an internal entity, when it is part of the system or the system
itself. AnyParty is used in numerous applications and with in diverse disciplines such
as Software systems, Entertainment Business, etc., each having its own context and
rationale for using the term Party. AnyParty can represent a human, any organiza-
tion, any country, or even any political party depending on the context, where the
term AnyParty is being used. For example, in context of politics, AnyParty refers to a
group of persons with common political opinions, beliefs, and purposes, whose goal
is to gain political influence, seize initiative, and governmental control for directing
future government policy. Examples of political parties include the Republican Party,
the Democratic Party, etc. In other scenarios like peace treaty signing, AnyParty
may represent a country. Example of such scenario includes Camp David Accord.
However, a party may represent a social gathering of humans to celebrate some
events or occasion like birthday, promotion, etc. Again, party might also mean a
person or group of persons who are working as an organization having specific goals
like United Nations, NGO’s, etc. The AnyParty design pattern tries to capture the
24 Stable Analysis Patterns for Software and Systems

core knowledge of AnyParty that is common to all these application scenarios to

create stable, extendable, adaptable, and reusable pattern.
3. AnyCriteria: The Stable design pattern for AnyCriteria describes the term Criteria.
AnyParty or AnyActor, who wants evaluate AnyEntity, uses this term. EBT [2,3,6] that
describes the ultimate goal of “AnyCriteria” is Evaluation. AnyCriteria stable sesign
pattern can be applied to any context where an AnyEntity needs to be evaluated
under AnyCriteria for AnyReasons. Criteria serve as a principle or a standard by
which something can be judged or evaluated.
4. AnyConstraint: Constraint stable design pattern can be applied to any domain,
where limitation is applied or forced. Constraint limits an entity to produce a certain
output that can be positive or negative depending on the situation. It restricts certain
activity, by imposing noticeable limitations. Constraints are usually negative forces
that can stop someone to take some actions. Constraints also impose severe restric-
tions by way of unforeseen circumstances and scenarios.
5. AnyRule: A rule is a set of regulations or laws that informs what needs to be done or
allowed and eventually the best way of doing something. It is generally defined by a
legislative body, an authority or a head and abides to the masses under them. A rule
is defined, either to make an orderly system or to obtain uniformity for reaching the
target.
6. AnyMechanism: AnyMechanism or AnyService design pattern deals with the
concept of service, mechanism, assistance, and the interactions between various
parties involved with services. The concept of assistance and using a mechanism or
a service to fulfill a functionality is used in multiple contexts, though each of these
contexts use different services and the parties dealing with services are unique to the
domain or the context. The AnyMechanism or AnyService design pattern makes it
easier to capture underlying concept of service and related interactions in different
application domains in a generic way using the Stability Model. The pattern presents
a generic model for services that can be extended for different domains and con-
texts, by capturing the core knowledge of services and assistance.
7. AnyConsequence: A consequence is a result of a course of action (or of a decision)
taken by the decision maker. In an analysis, the consequences of a course of action
are determined (predicted) by the use of models. The AnyConsequence pattern
deals with the core of problem in depth to find a solution for the aftermath of conse-
quence which is incidentally, the impact of consequence. The pattern designed after
the term consequence is reusable, extendable, and robust under any context and
usage scenario. Once this pattern is created, a developer need not work again and
repeatedly to recreate and rebuild it from the scratch.
8. AnyOutcome: The Outcome Design Pattern represents the return result of some of
the AnyMechanism or AnyService.
9. AnyImpact: The concept impact suggests that any change in a given situation, when
an impact is applied. Impact can be positive or negative. The AnyImpact design pat-
tern is used in many ways, for different situations and is applied to different scenar-
ios. Impact can also be stated as the striking of one thing to other, a forceful action
or collision. For example, social media helps the youths update with what is happen-
ing around the world, help them stay connected with friends and interact with their
family members even if they are distance apart. This will strengthen relationship
among them, even if they work and live in different locations and this is considered
to be a positive impact.
10. AnyReason: The stable design pattern for Reason describes the term “Reason” that
is used by AnyParty or AnyActor to get motivated. We give reasons to get motivated
and hence EBT for “Reason” is said to be “Motivation”.
Stable Analysis Patterns Overview 25

11. AnyCause: A cause is the motive for some human action. The word cause is also
used to mean explanation or answer to a why question. The key idea is that a
cause helps to identify the reason for behaving in a particular way or for feeling a
particular emotion. This will lead to a stable design pattern for Cause by using it as
one of BO and Justification as its EBT. If implemented in such a fashion, this pat-
tern can be used in all the areas where the concept of justification and cause are
present.
12. AnyType: AnyType design pattern signifies the classification of entities in a problem
domain. It could be the classification of entities into various data types in a class
diagram or various data items in a database. The AnyType design pattern g­ eneralizes
the concept of classifying entities into types in different domains and numerous
contexts.
13. AnyEntity: The AnyEntity design pattern abstracts the existence of an entity based
on certain properties inherent to the context in which entity is used and thereby
achieves a general pattern that can be used across any application. This pattern is
required to model the core knowledge of AnyEntity without tying the pattern to
a specific application or domain; hence, the name AnyEntity is chosen. AnyEntity
design pattern is one of the most common pattern and it is used by the majority of
stable analysis and design patterns.
14. AnyEvent: Event is an occurrence; something that happens. The wide range of con-
text of AnyEvent in many applications makes it necessary to have a stable pattern
that can be reused and extended further depending on the application. An event
exists in all walks of life. An event may refer to: (1) Events in gathering of people or
social activities, such as ceremony, convention, festival, sport, and social event, etc.
(2) Events in science, technology, mathematics, such as software events, synchro-
nization, impact events, etc. (3) Events in art and entertainment. (4) Other events,
such as competition, news, phenomenon, etc.
AnyEvent design pattern is one of the most common patterns and it is used by the
majority of stable analysis and design patterns.
15. AnyMedia: AnyMedia is a very general concept with wide range of application in
many different contexts. The AnyMedia Stable Design Pattern aims at analyzing the
general and important concept of AnyMedia. Since AnyMedia pattern is introduced
based on the stable design pattern, it makes it easier to employ this pattern in many
different applications. This is possible by just hooking [6] the unstable IOs to the
stable business objects according to the application under study. Here we introduce
the general AnyMedia design pattern based on stability model and introduce few
scenarios where this pattern can be used.
16. AnyLog: The AnyLog design pattern models the core knowledge of any Log, as a
written record. The Log finds extensive use in the computing industry. The pattern
makes it easy to model different kinds of logs rather than thinking of the problem
each time from scratch. This pattern can be utilized to model any kind of log in any
application and it can be reused as part of a new model [7].

References
1. M.E. Fayad, Stable Design Pattern for Software and Systems, Boca Raton, FL:
Auerbach Publications, 2016.
2. M.E. Fayad, and A. Altman, Introduction to software stability, Communications of the ACM,
44(9), 2001, 95–98.
3. M.E. Fayad, Accomplishing software stability, Communications of the ACM, 45(1), 2002,
111–115.
4. M.E. Fayad, How to deal with software stability, Communications of ACM, 45(4), 2002,
109–112.
Exploring the Variety of Random
Documents with Different Content
damaged disk or other medium, a computer virus, or computer
codes that damage or cannot be read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for

the “Right of Replacement or Refund” described in paragraph 1.F.3,
the Project Gutenberg Literary Archive Foundation, the owner of the
Project Gutenberg™ trademark, and any other party distributing a
Project Gutenberg™ electronic work under this agreement, disclaim
all liability to you for damages, costs and expenses, including legal
fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR
NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR
BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH
1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK
OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL
NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF
YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of receiving
it, you can receive a refund of the money (if any) you paid for it by
sending a written explanation to the person you received the work
from. If you received the work on a physical medium, you must
return the medium with your written explanation. The person or
entity that provided you with the defective work may elect to provide
a replacement copy in lieu of a refund. If you received the work
electronically, the person or entity providing it to you may choose to
give you a second opportunity to receive the work electronically in
lieu of a refund. If the second copy is also defective, you may
demand a refund in writing without further opportunities to fix the
problem.

1.F.4. Except for the limited right of replacement or refund set forth
in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO
OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of damages.
If any disclaimer or limitation set forth in this agreement violates the
law of the state applicable to this agreement, the agreement shall be
interpreted to make the maximum disclaimer or limitation permitted
by the applicable state law. The invalidity or unenforceability of any
provision of this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation,

the trademark owner, any agent or employee of the Foundation,
anyone providing copies of Project Gutenberg™ electronic works in
accordance with this agreement, and any volunteers associated with
the production, promotion and distribution of Project Gutenberg™
electronic works, harmless from all liability, costs and expenses,
including legal fees, that arise directly or indirectly from any of the
following which you do or cause to occur: (a) distribution of this or
any Project Gutenberg™ work, (b) alteration, modification, or
additions or deletions to any Project Gutenberg™ work, and (c) any
Defect you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new computers.
It exists because of the efforts of hundreds of volunteers and
donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project Gutenberg™’s
goals and ensuring that the Project Gutenberg™ collection will
remain freely available for generations to come. In 2001, the Project
Gutenberg Literary Archive Foundation was created to provide a
secure and permanent future for Project Gutenberg™ and future
generations. To learn more about the Project Gutenberg Literary
Archive Foundation and how your efforts and donations can help,
see Sections 3 and 4 and the Foundation information page at
www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-profit
501(c)(3) educational corporation organized under the laws of the
state of Mississippi and granted tax exempt status by the Internal
Revenue Service. The Foundation’s EIN or federal tax identification
number is 64-6221541. Contributions to the Project Gutenberg
Literary Archive Foundation are tax deductible to the full extent
permitted by U.S. federal laws and your state’s laws.

The Foundation’s business office is located at 809 North 1500 West,

Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up
to date contact information can be found at the Foundation’s website
and official page at www.gutenberg.org/contact

Section 4. Information about Donations to

the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission of
increasing the number of public domain and licensed works that can
be freely distributed in machine-readable form accessible by the
widest array of equipment including outdated equipment. Many
small donations ($1 to $5,000) are particularly important to
maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws regulating

charities and charitable donations in all 50 states of the United
States. Compliance requirements are not uniform and it takes a
considerable effort, much paperwork and many fees to meet and
keep up with these requirements. We do not solicit donations in
locations where we have not received written confirmation of
compliance. To SEND DONATIONS or determine the status of
compliance for any particular state visit www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states where

we have not met the solicitation requirements, we know of no
prohibition against accepting unsolicited donations from donors in
such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot make

any statements concerning tax treatment of donations received from
outside the United States. U.S. laws alone swamp our small staff.

Please check the Project Gutenberg web pages for current donation
methods and addresses. Donations are accepted in a number of
other ways including checks, online payments and credit card
donations. To donate, please visit: www.gutenberg.org/donate.

Section 5. General Information About

Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could be
freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose network of
volunteer support.
Project Gutenberg™ eBooks are often created from several printed
editions, all of which are confirmed as not protected by copyright in
the U.S. unless a copyright notice is included. Thus, we do not
necessarily keep eBooks in compliance with any particular paper
edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg Literary
Archive Foundation, how to help produce our new eBooks, and how
to subscribe to our email newsletter to hear about new eBooks.
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com