Architecture Documentation and Technical/cross-cutting concepts Flashcards
1
Q
Name examples for technical/cross-cutting concerns
A
- flow control
- error handling
- security
- monitoring
- integration
- internationalization
- persistence
- deployment
2
Q
What is the base principle of cross-cutting concerns?
A
- often used in most subareas of software system
- but are themselves independent from another (except for selective interaction)
- can be mapped across different dimensions in diagrams without great overlay
3
Q
What are typical error handling tasks?
A
- Identifying error cause
- Defining appropriate reactions to dealing with errors:
- Classification into categories and severity levels
- Differentiation between technical and functional errors
- Minimizing the impact of the error
- Making diagnosis of error causes easier
- What went wrong?
- Where did it happen?
- Why did it happen?
- Using error prevention by the software system (processing tolerances, early warnings)
- Defining technology for error handling
- ensure end-to-end error handling
4
Q
What are a minimum amount of security issues to be considered?
A
- Authentication
- Authorization
- Integrity
- Availability
- Confidentiality
- Non-repudiation
5
Q
How should the relationship between Architecture plan and implementation should be specifeid?
A
- documents where the mapping between architecture plan and implementation are described are extremely useful
- should be formulated in rules/specifications
- for example, that a UML component diagram itself is always implemented as its own package
- this allows a direct correlation between diagrams and code
6
Q
What types of documents are usual for software architectures?
A
- central architecture description
- architecture overview
- documentation overview
- documentation handbook
- architecture wallpaper
- overview presentation (2 variants)
- Architecture Decision record
- Technical Information
7
Q
What is the Central architecture description?
A
- core document for software architecture
- all information with relevance to architecture
8
Q
Name examples for the information contained in the Central Architecture Description
A
- Architectures task, objectives, quality requierements and stakeholders
- Technical and organizational conditions and constraints
- Views, decisions, patterns used
- Technical concepts
- Quality evaluations
- identified risks
9
Q
What is the Architecture overview document?
A
- brief, easy-to-read summary of central architecture description
- max. 30 pages
- similiar contents like central architecture description, but focus on certain elements
- if not possible to create central architecture description, this can be created instead, pared-down alternative to a complete description
10
Q
What does the architecture overview document focus on?
A
- central views
- main requirements
- core decisions
11
Q
What is the document overview document and what purpose does it serve?
A
- either per-project or per-application
- directory that serves as index of all architecture-relevant documents and documents and their dependencies
- organizational policies on where this directory is to be found and how it should be structured should be given
- including information on which documents should be read by whom
12
Q
What is the overview presentation document?
A
- presentation slides with most important aspects of architecture for management target group
- two versions:
- max. 1 hour, with technical info, presentation of architecture
- concise, max. 10 min with central statements and business benefit
13
Q
What is the Architecture wallpaper document?
A
- used to present complete overview of a large number of architecture aspects
- usually collection of poster-sized prints detailing views with refinements, quality aspects and so on
- used for interactive discussions of specific topics
- not be-all and end-all solution, can have deterrent effect on those focused on implementation, testing, operating the system
14
Q
What is the document handbook document?
A
- explains structure and function of complete project documentation
- explains the notations used
15
Q
What is an Architecture Decision Record (ADR)
A
- fixed format for documenting architectural decisions made
- shows the decisions in isolation in its own document or section
16
Q
What does an ADR focus on beside the result of the decision?
A
- assumptions made
- motives
- influencing factors
at the time of decision
17
Q
What does an ADR consist of?
A
- Title: info about topic
- Context: what influences decision, representation of circumstances and a list of boundary conditions or previous decisions that lead to the current need for a decision
- Decision: answer to previous sections, available discussions often listed and discussed here
- Status: info whether decision is in effect, a suggestion or already outdated
- Consequences: how context changes as result of decision, including positive and negative effect of decision to ensure comprehensibility
18
Q
What is contained in the Technical information document?
A
- one or more documents containing important decisions for project developers and testers
- should store programming guidelines, development methods
- as well as info about building, starting and testing of the system
19
Q
What is important about the documentation of external interfaces?
A
- extra care and time should be spent early in the project on interface documentation
- much better than later in the project
20
Q
What information should be part of an Interface documentation template?
A
- Identification
- Resouces provided
- Error scenarios
- Variability and configuration
- Quality characteristics
- Design decisions
- Notes
21
Q
What are Best-practice rules for documentation?
A
- Write from readers perspective
- Avoid unnecessary repitition
- Avoid ambiguity
- Standardized Organizational structure or templates
- Justify important decisions in writing
- Check the documentation’s suitability for use
- Unclutterd diagrams
- Regular Updates
- Adapt the changeability of the documentation to the architecture
22
Q
Under what circumstances would it be acceptable to allow repition inside documentation? (2.)
A
Only if they do:
- simplify the use of the documentation
- Significantly simplify its maintenance and updating
23
Q
What do you have to think about when repitition occurs with only slight variations?
A
- is the variation intentional
- should importance be attached to this variation
documentation from different perspectives is not repitition but helps to deepen the understanding.
24
Q
How do you Avoid ambiguity in Architecture documentation? (3.)
A
- use formal description languages
- when symbolic notations (e.g. UML) are used, symbols should be explained or a reference to an explanatory source should be included
- in verbal and written communication the identical terms and arguments should be used
25
What is important about the justification of architectural decisions in writing? (5)
- brief justification is important
- can be done via e.g. reference to relevant company policy
- can also describe rejected solutions alternatives
- can also contain advantages and disadvantages of current solution
- saves time, especially when decisions have to be reconsidered under changed circumstances
26
What is important about checking the documentations suitablity for use? (6.)
- reviews should be carried out be suitable representatives
- review process itself should be reviewed
- improvement process for regular cheks of documentation policies should be implemented
27
What is important about Uncluttered diagrams? (7.)
- the human mind can process about 5-9 elements comprehensively
- more elements should be split into distinct diagrams, if possible
28
What is important about Regular Updates of software architectures (8.)?
- process that updates documentation after change should be established
- for regular updates during development and maintenance
- its useful to define fixed synchronization deadlines for updates
29
What is important about Adapting the changeability of the documentation to the architecture?
- level of formalization should be adapted to project circumstances
- first draft change quickly and often, later changes appear less often
several adjustment options are available:
- level of detail
- format
- accessibility
- formality of diagrams
- length of review/change/release process
