In terms of system requirements what are constraints?
a design decision with zero degrees of freedom. AKA a design decision that has already been made for you.
how is functionality related to architecture?
functionality does not really determine architecture at all. (a given functionality can be achieved through virtually any architecture).
Bc functionality and quality are orthogonal
why use quality attribute scenarios?
provides a concrete, testable construct for characterizing quality attributes
the 6 parts of a quality attribute scenario
- stimulus
- stimulus source
- response
- response measure
- environment
- artifact
definition of “source of stimulus”
some entity (human, computer system, hardware) that generates the stimulus
definition of “stimulus”
a condition that requires a response when it arrives at a system
definition of “environment”
the set of conditions under which the stimulus occurs
definition of “artifact”
the thing (maybe a system, or part of system) that is stiumulated
definition of “response”
the activity that is undertaken as the result of the arrival of the stimulus
definition of “response measure”
a measurable characteristic of the response used to test the requirement
general vs concrete attribute scenario
general - could pertain to any system (are system independent)
concrete - are specific to a particular system
what are tactics?
architectural design primitives that can be employed to achieve some specific quality attribute response
3 reasons for using tactics?
- rarely do generic design patterns meet all the requirements as is and thus they need to be modified and adapted some
- continual application of certain tactics can lead to new design patterns
- using tactics make design more systematic and documentable
the 7 categories of design decisions that an architectural team should consider when designing an architecture
- allocation of responsibilities
- coordination model
- data model
- management of resources
- mapping among architectural elements
- binding time decisions
- choice of technology
what is “allocation of responsibilities”
we need to relate each requirement to a module and/or component-and-connector structure. Map each requirement to a structure to ensure that all requirements are accounted for
3 decision with regards to a coordination model
- identify elements that must coordinate and those that mustn’t
- determine properties of coordination (timeliness, concurrency, correctness, etc.)
- choose communication mechanism that realize those properties
2 decisions regarding the data model
- choosing the major data abstractions, their properties, and operations
- organization of the data. Where will data be kept and held
4 decisions regarding the management of resources
- ID resources that must be managed
- determine which system elements manage each resource
- determine how resources are shared and how contention is settled
- determine the impact of saturation on different resources
4 decisions regarding the mapping of architectural elements
- mapping of modules and runtime elements to each other
- assignment of runtime elements to processors
- assignment of items in the data model to data stores
- mapping of modules and runtime elements to units of delivery
What is the binding time with regards to architectural decisions
When do all of these other decisions have to be made
Examples:
- build-time script for allocation of responsibilities to modules
- run-time decision of coordination model protocols
5 decisions regarding choice of technology
- deciding which technologies are available to realize decisions made in other categories
- determining whether the tools to support this technology are adequate
- determining familiarity and available support for this technology
- determine whether new technology is consistent with existing stack
-
Chapter 1 - What is SW Architecture45
-
Chapter 2 - Why is Architecture Important22
-
Chapter 3 - Contexts of SW Architecture12
-
Chapter 4 - Understanding Quality Attributes21
-
Chapter 5 - Availability48
-
Chapter 6 - Interoperability22
-
Chapter 7 - Modifiability30
-
Chapter 8 - Performance28
-
Chapter 9 - Security39
-
Chapter 10 - Testability22
-
Chapter 11 - Usability20
-
Chapter 12- Other Quality Attributes18
-
Chapter 13 - Patterns and Tactics70
-
Chapter 14 - Quality Attribute Modeling and Analysis25
-
Chapter 15 - Architectures in Agile Projects12
