chapter 5 Flashcards

(40 cards)

1
Q

an arch documentation must _________ ?

A
  • be transparent and accessible to employees
  • be able to sever as a concrete blue print
  • contain enough info to be used in analysis
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

what do we mean when we say that an arc doc can be prescriptive and descriptive?

A
  • prescriptive : for some audiences as it describes what SHOULD BE TRUE by placing constraints on future decisions
  • descriptive : for some audiences as it describes WHAT IS ALREADY TRUE by recounting already made decisions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

which stakeholders use arch doc?

A

MM QQ IT PDE
- managers
- maintainers
- quality assurance team
- quality attr specialist
- implementers
- testers
- product line managers
- designers
- engineers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

what are the 3 uses of arch doc?

A
  • education
  • communication b/n stakeholders
  • system analysis and construction
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

what are the 3 types of notations?

A

formal, semi-formal and informal

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

what are informal notations?

A
  • are arch views created by general purpose tools deemed appropriate by the developer team
  • semantics are graphically depicted
  • characterized in natural language
  • neither semantics nor syntax can be analyzed
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

what are semi-formal notations?

A
  • are views that have a completely defined syntax and but an incomplete semantics
  • Example:
    UML diagrams : which have a standardized notation but have ambiguous semantics
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

what are formal notations?

A
  • are views that have precise semantics and syntax definition
  • semantics are usually mathematics
    Example : Arc description lang [ c, c++ … ]
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

___________ notation supports automation through association tools?

A

formal

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

what are the tradeoffs when choosing notations?

A

formal - time consuming and complex but less ambiguity and more opportunity for analysis

informal - easier but ambiguous

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

____________ allow us to divide software into manageable representations?

A

views

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

list the views found in Krutchens 4+1 view

A
  • logical
  • process
  • physical
  • dev’t
  • scenario [ + 1 ]
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

list the views found in Software Cost reduction method?

A
  • module view : shows modules as units of encapsulation
  • process view : shows comm and synchronization b/n processes
  • uses view : programs and how they depend on each other
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

an arch must consider a system in 3 ways. These are?

A
  • modules - units of encapsulation
  • components and connectors : runtime behavior
  • allocation : relation to non sw structures in the env’t
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

what are the minimum views expected in a given system?

A
  • at least 1 module view
  • at least 1 c&c view
  • if system is large, at least 1 allocation view
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

what is the method to choosing views?

A

step 1 - create R stakeholder / C view table
step 2 - combine views to reduce numbers
step 3 - prioritize and stage
- example : releasing decomposition view early is useful
- views can be developed in parallel

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

what are components of a design doc package?

A
  • views
  • doc beyond views
18
Q

what are the sections needed when documenting a view?

A

Perfectly Executed Cause Views Rough
1. primary presentation
2. element catalogue
3. context diagram
4. variability guide
5. rationale

19
Q

describe primary presentation [ documenting views ]

A
  • describes elements and their relationship with the view
  • often graphical, but might be textual, tabular or a list
20
Q

describe element catalogue [ documenting views ]

A
  • gives a detailed explanation of elements mentioned [ depicted ] in the primary presentation
21
Q

describe context diagram [ documenting views ]

A
  • shows how a system or a portion of the system depicted in this view relates to its environment
22
Q

__________ shows how to exercise the variation points shown in the chosen view?

A

variability guide

23
Q

___________ describes why the design reflected in the chosen view is, as it is?

24
Q

what is the purpose of a behavior documentation?

A
  • gives a description on how architectural elements in a given view interact with each other
25
what notations can we use to behavior documentation?
- trace oriented languages - comprehensive languages
26
describe trace oriented languages
traces - are sequence of interactions b/n architectural elements that describe a system's response to a specific system stimuli
27
what are examples of trace oriented languages?
use case, seq, activities, comm diagrams
28
describe comprehensive languages
describes the complete behavior of architectural elements by Inferring all possible paths from initial state to final state
29
where do quality attributes show up in the documentation?
rimmel, revlon, lv, Sephora, all in: - rationale - requirement mapping to quality attributes - "language" of things - stakeholders - architectural elements providing services to NFR
30
how can you tackle documenting an arch that changes faster than you can document?
By : - documenting what is true about all versions of the system - documenting in what ways the arch is allowed to change
31
give some examples of arch doc templates?
- krutchen's 4 + 1 - siemen's 4 views - IEEE standard
32
what are the 7 rules for sound doc?
CAR WARS - keep doc current but not too current - avoid ambiguities - record rationale - write from readers POV - avoid repetition - review doc - use standards / templates
33
_____________ is used to analyze properties, strengths and weaknesses of software arch?
sw arch evaluation
34
when can software arch be evaluated?
- early : while SA is being developed - after SA is compete but before SW dev't - later to ensure consistency b/n design and implementation - when acquiring new systems
35
who is involved in sa evaluation process?
- evaluation team - stakeholders
36
why do we need to evaluate an arch?
FIRE - forces review preparation [ docs, standard questions ... ] - improved arch - requirement validation [ stakeholders meet argew ] - early problem detection [ unreasonable req, performance, modification ]
37
compare and contrast b/n planned and unplanned sa evaluations.
Planned - schedules after sa completion - normal, proactive and team building Unplanned - due to serious problem - reactive and tension filled
38
list the types of sa evaluation methods
- scenario based - mathematical model based - metrics based
39
which evaluation methods belonging to scenario based methods did SEI come up with?
- arch tradeoffs analysis method ATAM - sw arch analysis method SAAM - arch review for intermediate design ARID
40
in expert opinion which evaluation method is best?
ATAM