Vorlesung 6 Flashcards
The goals of design
balancing the bermuda triangle of architecturig (which consists of lifecycle, initiatives, assets)
creation of a plan or convention for the construction of a software system (decomposition of the problem, control of the complexity, prediction of effort & quality)
Risk mitigation of the impact of change on a software system (address unforeseeable changes, prepare anticipated changes, change is inevitable!)
Explain “architecture is design, but not all design is architecture”
It depends, if it is architecturally-significant. It’s architecturally significant if it is costly to change, risky and new.
When do we call things architecturally-significant?
Costly to change
risky
new
Name some challenges of architecture design (name 3)
Understand the domain and its specifics
Work on incomplete and changing requirements
Find adequate solutions
Achieve adequate confidence that solutions work
Design a solution involving many experts for specific topics
Refine and adjust architecture while implementation is already ongoing
Judge technologies for their adequacy
Select and use technologies appropriately
Become aware of drift
What are the generic decomposition steps (FRAUNHOFER)
IDENTIFY ELEMENTS (responsibilities, composes/aggregated elements, unique & self-contained roles/elements)
IDENTIFY RELATIONSHIPS (data/information exchange requirements, interfaces, dependency types, dependency graph of elements must have no cycles)
INCREASE SEMANTIC COHESION BETWEEN ELEMENTS AND REDUCE COUPLING OF ELEMENTS
(elements that change together are grouped together,
elements that are used together are grouped together,
elements that are owned by the same group are grouped together)
What are essential principles of design?
Abstraction (extraction of the essentials)
Encapsulation (information hiding, coupling & cohesion, redudancy free)
Uniformity (common design principles)
Separation of concerns (hierarchical decomposition, divide&conquer - top down, divide & conquer - multidimensional, modularization, localization of concerns)
Conceptual tools for architecture design
Creativity
Classification (element types, relation types)
Abstraction (simplifications, aggregations, processes, end-to-end usages)
Categorization (group distinct facets of a solution concepts)
Experience (since there is no guide to creativity)
Architecture Decomposition Strategies
Hierarchical Decomposition and Modularization (Divide & Conquer)
- functionality driven
- data driven
- deployment driven
Transformation (Restructure / Use Patterns)
- quality driven
Adoption and Preparation for Use/Reuse (Abstract & Retrofit)
- technology driven
What are the main purposes of the context view
definition of system boundary
identification of context (humans interacting with the system, context systems, information flow)
system seen as a black box
What are the aspects to think about in context view
what does the system do?
what is the interaction with the environment?
what data is exchanged?
Main purposes of the functional view
identification and decomposition of systems functionality
linking (functional) requirements to later design steps
understanding of function interrelationships
identify missing (functional) requirements
aspects to think about in functional view
which functions are responsible for data (creation, transportation, processing and storage)
which functions communicate?
what data is exchanged?
logical view main purposes
define the logic structure of the whole system (decompose the system into manageable components)
describe the internal logical structure of the SUD
partition the system into communicating logical components
allocate desired functions to cohesive logical units
support the reuse of already existent logical components
define the total behaviour of the system
Aspects to think about in logical view (2 nennen)
how should functionality be allocated to executable components?
how can components be refined into sub-components?
are there commonalities between components?
what data is exchanged between the components?
what are the interfaces to be used?
what behaviour does a component have?
software view main purposes
decomposition of software components into sub-components and classes
definition of software interfaces
identification of necessary software datatypes
aspects to think about in software view
how are logical components realized by software components
how should components be implemented by implementation units
what are the interfaces to be used
which component provides/requires an interface
what datatypes should be used for data exchange
hardware view main purposes (2 nennen)
identification of sensors, actuators, ECUs
identification of communication buses
deployment of software components
function realization by hardware entities
aspects to think about in hardware view
how should software components be deployed to computing nods
what bus systems are used to exchange data?
which logical components should be implemented in hardware?
when to stop working at the architecture level (2 nennen)
You should stop when…
▪ … you addressed the key requirements and quality attributes
▪ … you can explain how they are addressed
▪ … and have enough confidence that they can be achieved
▪ … and you can assign work units to developers
▪ … and you can control the parallel development and integration
When to temporarily leave the architecture level (2 nennen)
▪ … to collect information, get more confidence
▪ … if you do not exactly know what you abstract from and have to try out
▪ … in prototyping activities and technical evaluations
when to come back to the architecture level (2 nennen)
▪ … to integrate your lessons learned
▪ … to judge the results in the context
▪ … to reason about change
when to stop designing (2 nennen)
You have covered the most important things when…
▪ … you addressed the key requirements and quality attributes
▪ … you can explain how they are addressed
▪ … and have enough confidence that they can be achieved
▪ … and you can assign work units to developers
▪ … and you can control their parallel development and integration
when to continue designing (2 nennen)
You continue designing during development because …
▪ … you refine architectural decisions
▪ … you design the methods, data structures
▪ … you implement solutions (source code and test cases)
▪ … you make the system work
