A Rationale-based Model for Architecture Design Reasoning

More documents

Recommendations

Info

5.3. Survey findings Table 5.11: Tendency of Forgetting the Reasons for Justifying Design Decisions Never Always 1 2 3 4 5 No of Respondents 2 15 22 22 5 Percentages 3.0 22.7 33.3 33.3 7.6 Often the architect who is responsible for maintenance is not the same person who originally designed the system. In such circumstances, we asked respondents whether they know why existing designs were created without documented design rationale. The results are shown in Table 5.12. Most respondents (80%) either agree or strongly agree with the statement that without design rationale, they may not understand why certain decisions are made in the design. Table 5.12: Do Not Understand Design without Design Rationale if Not Original Designer Strongly Strongly Disagree Agree 1 2 3 4 5 No of Respondents 1 3 9 23 29 Percentages 1.5 4.6 13.8 35.4 44.6 When respondents were asked about the usefulness of design rationale to help understand past design decisions to assess potential modification, a majority of the respondents find design rationale helpful in this regards (see Table 5.13). Hence, we concluded that there is evidence to support the claims that design rationale are an important source of effective reasoning during architectural modification. It is also stressed that if the knowledge concerning the domain analysis, patterns used, design options evaluated, and decisions made is not documented, it is quickly lost and hence unavailable to support subsequent decisions in the development lifecycle [11]. Software maintenance experts also agree that many facts may be lost to the project, either because the developers may no longer be available to the project or the limitations on a human’s ability to memorize detailed facts [75]. Table 5.13: Design Rationale Helps Evaluate Previous Design Decision Strongly Strongly Disagree Agree 1 2 3 4 5 No of Respondents 0 3 10 21 33 Percentages 0.0 4.5 14.9 31.3 49.3 Finally, when respondents were asked how often they do impact analysis during maintenance. Table 5.14 shows that a large number of respondents perform impact analysis before making any changes. Since impact analysis may consume a significant amount of resources and 80.6% of designers (levels 4 and 5) consider it to be useful in evaluating 71
5.3. Survey findings previous design decisions (Table 5.13), it can be argued that the availability of design rationale can improve this process. Design rationale is considered an important input to impact analysis because if the knowledge about the factors that may have influenced the original design decisions is available, designers do not have to spend a large amount of time to understand the existing design and the potential ramifications of any changes [128]. Table 5.14: Frequency of Performing Impact Analysis Never Always 1 2 3 4 5 No of Respondents 0 4 13 29 19 Percentages 0.0 6.2 20.0 44.6 29.2 We were also interested in determining the importance of the tasks performed in impacts analysis, some of which require design rationale support. The importance of such tasks during impact analysis can be considered as an indicator of the need or usefulness of design rationale to improve this activity and subsequently the maintenance process. To investigate this issue, there was a multiple-items question on the importance of various tasks. Table 5.15 shows what the respondents think of the importance of the factors. In carrying out impact analysis, most respondents trace requirements. They analyse the design and design rationale based on the available design specifications. In the analysis, they are concerned about the feasibility of the implementation, its costs and risk. They are also concerned that the new design is consistent with the constraints and the assumptions of the existing system. Table 5.15: Importance of Each Impact Analysis Task Not Very Important Important 1 (%) 2 (%) 3 (%) 4 (%) 5 (%) (a) Analyse and trace requirements 1.5 0.0 10.3 39.7 48.5 (b) Analyse specifications of previous design 1.5 10.3 19.1 35.3 33.8 (c) Analyse design rationale of previous design 1.5 11.9 32.8 32.8 21.0 (d) Analyse implementation feasibility 1.5 1.5 8.8 41.2 47.0 (e) Analyse violation of constraints and assumptions 1.5 8.8 25.0 41.2 23.5 (f) Analyse scenarios 1.5 7.6 16.7 36.4 37.8 (g) Analyse cost of implementation 0.0 10.3 13.2 30.9 45.6 (h) Analyse risk of implementation 0.0 4.4 5.9 32.4 57.3 Given the results, it is obvious that architects and designers often have the need to refer to design documentation for impact analysis. Some of information that they use require design rationale support such as understanding design assumptions, constraints, cost and risk. However, this information are not necessarily organised in a way that can be easily used for impact analysis. Additional factors that have been discovered in this survey can contribute to the difficulties in impact analysis: (a) architects can forget the reasons behind the design; (b) the person doing the maintenance may not be the original designers. 72
Page 1 and 2:
A Rationale-based Model for Archite
Page 3 and 4:
maintenance. These techniques can h
Page 5 and 6:
Declaration This thesis contains no
Page 7 and 8:
2.2.6 DoD Architecture Framework .
Page 9 and 10:
5.4.6 Risk assessment in architectu
Page 11 and 12:
8.2 The architecture rationalisatio
Page 13 and 14:
12.2 Contributions . . . . . . . .
Page 15 and 16:
6.10 ≪AR≫ and ≪AAR≫ Stereot
Page 17 and 18:
11.13A Process to Synchronise Chang
Page 19 and 20:
5.13 Design Rationale Helps Evaluat
Page 21 and 22:
that architecture design is highly
Page 23 and 24:
1.2. Research motivations and resea
Page 25 and 26:
1.2. Research motivations and resea
Page 27 and 28:
1.4. Structure of the thesis the ch
Page 29 and 30:
Part I Problem Analysis 10
Page 31 and 32:
2.1. Industry practice of design ra
Page 33 and 34:
2.2. Architecture frameworks and de
Page 35 and 36:
Page 37 and 38:
Page 39 and 40: 2.2. Architecture frameworks and de
Page 41 and 42: 2.2. Architecture frameworks and de
Page 43 and 44: Chapter 3 Related work in design ra
Page 45 and 46: 3.2. Why do we need design rational
Page 47 and 48: 3.2. Why do we need design rational
Page 49 and 50: 3.3. Existing methods for capturing
Page 57 and 58: 3.4. Other related studies 3.3.7 Qu
Page 59 and 60: 3.4. Other related studies evolutio
Page 61 and 62: 3.5. How well design rationale meth
Page 63 and 64: 3.5. How well design rationale meth
Page 65 and 66: Chapter 4 Research methodology and
Page 67 and 68: 4.1. Software engineering research
Page 69 and 70: 4.2. The chosen research and valida
Page 71 and 72: Part II Architecture Design Rationa
Page 73 and 74: on a regular basis. Their inputs ha
Page 75 and 76: 5.1. Architecture rationale in the
Page 77 and 78: 5.2. Survey methodology data collec
Page 79 and 80: 5.3. Survey findings experience). I
Page 81 and 82: 5.3. Survey findings Table 5.1: Fre
Page 83 and 84: 5.3. Survey findings Business Goals
Page 85 and 86: 5.3. Survey findings 5.3.5 Document
Page 87 and 88: 5.3. Survey findings Table 5.8 summ
Page 89: 5.3. Survey findings We used Spearm
Page 93 and 94: 5.4. Discussion of findings Since t
Page 95 and 96: 5.4. Discussion of findings or cons
Page 97 and 98: 5.5. Limitations and use design rat
Page 99 and 100: Part III The Representation and App
Page 101 and 102: 6.1. A conceptual model for design
Page 103 and 104: 6.2. Architecture Rationale and Ele
Page 105 and 106: 6.2. Architecture Rationale and Ele
Page 107 and 108: 6.3. Architecture elements Figure 6
Page 109 and 110: 6.4. Architecture rationale Figure
Page 111 and 112: 6.4. Architecture rationale • ris
Page 113 and 114: 6.4. Architecture rationale depicts
Page 115 and 116: 6.5. The extended AREL To prevent c
Page 117 and 118: 6.6. A UML representation of AREL a
Page 119 and 120: 6.6. A UML representation of AREL a
Page 121 and 122: 6.7. AREL usability AE by ≪AEsupe
Page 123 and 124: 6.8. Summary The AREL model is exte
Page 125 and 126: 7.1. The EFT system reasoning, a co
Page 127 and 128: 7.1. The EFT system The processing
Page 129 and 130: 7.1. The EFT system not chosen beca
Page 131 and 132: 7.1. The EFT system Figure 7.5: Int
Page 133 and 134: 7.1. The EFT system sequence checki
Page 135 and 136: 7.1. The EFT system Figure 7.7: Dec
Page 137 and 138: 7.1. The EFT system Therefore, in a
Page 139 and 140: 7.1. The EFT system Figure 7.10: De
Page 141 and 142:
7.2. An empirical study to validate
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
7.3. Summary The case study is spec
Page 153 and 154:
8.1. Background Based on these assu
Page 155 and 156:
8.2. The architecture rationalisati
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
8.3. Other applications of ARM As d
Page 165 and 166:
8.3. Other applications of ARM Figu
Page 167 and 168:
8.3. Other applications of ARM area
Page 169 and 170:
Chapter 9 Architecture rationale an
Page 171 and 172:
9.1. Background 9.1 Background In t
Page 173 and 174:
9.2. Traceability of architecture r
Page 175 and 176:
9.4. AREL and eAREL traceability ap
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Chapter 10 Architecture decision de
Page 187 and 188:
10.1. Background 10.1.2 Introductio
Page 189 and 190:
10.2. Building a BBN to represent a
Page 191 and 192:
Page 193 and 194:
Page 195 and 196:
Page 197 and 198:
10.3. Reasoning about change impact
Page 199 and 200:
Page 201 and 202:
Page 203 and 204:
Page 205 and 206:
Page 207 and 208:
Page 209 and 210:
10.5. Summary design object may cau
Page 211 and 212:
11.1. Capturing architecture design
Page 213 and 214:
11.1. Capturing architecture design
Page 215 and 216:
11.2. Checking AREL models Figure 1
Page 217 and 218:
11.3. Tracing AREL models Figure 11
Page 219 and 220:
11.4. Analysing AREL with BBN • S
Page 221 and 222:
11.5. Limitations Figure 11.13: A P
Page 223 and 224:
Chapter 12 Conclusions 12.1 Summary
Page 225 and 226:
12.2. Contributions reasoning metho
Page 227 and 228:
12.2. Contributions implementations
Page 229 and 230:
12.3. Future work architecture deci
Page 231 and 232:
12.3. Future work to examine the co
Page 233 and 234:
BIBLIOGRAPHY [10] B. W. Boehm, Soft
Page 235 and 236:
BIBLIOGRAPHY [37] A. Eden and R. Ka
Page 237 and 238:
BIBLIOGRAPHY [62] J. D. Herbsleb an
Page 239 and 240:
BIBLIOGRAPHY [89] N. Lassing, D. Ri
Page 241 and 242:
BIBLIOGRAPHY [115] D. L. Parnas,
Page 243 and 244:
BIBLIOGRAPHY [142] Z. Simsek and J.
Page 245 and 246:
BIBLIOGRAPHY [167] W. F. Tichy, N.
Page 247 and 248:
Appendix A AREL Tool User Manual 1
Page 249 and 250:
4.1 AREL Check Model When the Check
Page 251 and 252:
4.2 AREL Model Tracing AREL model t
Page 253 and 254:
Figure 9 - result of downward trace
Page 255 and 256:
To initiate the graph’s creation,
Page 257 and 258:
onto the diagram 14 Assign values t
Page 259 and 260:
Useful Definitions The following ar
Page 261 and 262:
) Some projects only c) Not at all
Page 263 and 264:
19. I revisit architecture design d
Page 265 and 266:
Complaint Procedure If you have any
Page 267 and 268:
Privacy Protection Only investigato
Page 269 and 270:
B. Exploring design reasoning. 1. W
Page 271 and 272:
3. Why does the system use asynchro
Page 273 and 274:
C. General Comments on AREL Modelli
Page 275:
IEEE Computer Society Press. A. Tan
show all

A Rationale-based Model for Architecture Design Reasoning

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?