chapter 5 Flashcards

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?

A

rationale

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
Q

what notations can we use to behavior documentation?

A
  • trace oriented languages
  • comprehensive languages
26
Q

describe trace oriented languages

A

traces - are sequence of interactions b/n architectural elements that describe a system’s response to a specific system stimuli

27
Q

what are examples of trace oriented languages?

A

use case, seq, activities, comm diagrams

28
Q

describe comprehensive languages

A

describes the complete behavior of architectural elements by Inferring all possible paths from initial state to final state

29
Q

where do quality attributes show up in the documentation?

A

rimmel, revlon, lv, Sephora, all
in:
- rationale
- requirement mapping to quality attributes
- “language” of things
- stakeholders
- architectural elements providing services to NFR

30
Q

how can you tackle documenting an arch that changes faster than you can document?

A

By :
- documenting what is true about all versions of the system
- documenting in what ways the arch is allowed to change

31
Q

give some examples of arch doc templates?

A
  • krutchen’s 4 + 1
  • siemen’s 4 views
  • IEEE standard
32
Q

what are the 7 rules for sound doc?

A

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
Q

_____________ is used to analyze properties, strengths and weaknesses of software arch?

A

sw arch evaluation

34
Q

when can software arch be evaluated?

A
  • 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
Q

who is involved in sa evaluation process?

A
  • evaluation team
  • stakeholders
36
Q

why do we need to evaluate an arch?

A

FIRE
- forces review preparation [ docs, standard questions … ]
- improved arch
- requirement validation [ stakeholders meet argew ]
- early problem detection [ unreasonable req, performance, modification ]

37
Q

compare and contrast b/n planned and unplanned sa evaluations.

A

Planned
- schedules after sa completion
- normal, proactive and team building

Unplanned
- due to serious problem
- reactive and tension filled

38
Q

list the types of sa evaluation methods

A
  • scenario based
  • mathematical model based
  • metrics based
39
Q

which evaluation methods belonging to scenario based methods did SEI come up with?

A
  • arch tradeoffs analysis method ATAM
  • sw arch analysis method SAAM
  • arch review for intermediate design ARID
40
Q

in expert opinion which evaluation method is best?

A

ATAM