Professional Documents
Culture Documents
2019-2020
C1
S1.Observations…
• Everyday life is increasingly permeated by software
• Software increasingly determines the success of products and services
• The size of systems is growing continuously
• Our ability to develop software systems grows more slowly than demand (so-called "software crisis")
• Only about 1/3 of all development projects were successful (in terms of time, quality, costs)
• Up to approx. 80% of the total costs of a software system are incurred after completion
S2 Framework conditions of today's software development
• Changing requirements
• Changing teams
• Increasing complexity
• Large amount of technologies and frameworks available
•Time pressure
S9 Why is well structured and legible software important?
• Increasing complexity and maintenance requirements for software systems
• Evolution share in software development is growing
• Software developers in the project change over time
The environment as a whole is becoming more dynamic!
S10 Every software has an architecture
• Every software has an architecture!
• There isn't the perfect architecture for a problem.
• Every architecture is a compromise and has advantages and disadvantages
• And: An explicit architectural design is not always required ...
C2
S1 How can you describe an architecture?
• Architectures are described using (UML) models
• Models are simplified representations of reality that allow statements to be presented in the model in
such a way that they can be interpreted equally by all those involved.
• A meta model defines a language to describe models. With the help of the metamodels, generally valid
consistency and transformation rules can be established
• to ensure the consistency of the views of models
• determine the transformation and consistency between models
Architectural models are structured using so-called views. A view is a description of the object to be
viewed from a certain point of view.
For each view there are special description techniques (e.g. in the UML, see further slides)
DiagrammA diagram is a graphic representation of data, facts or information (graphic representation of
model components). A diagram has a well-defined, formally defined language (syntax).
S4/S5 IEEE Standard 1471-2000 (1)
• Is a standard for descriptions / plans, not for concrete "buildings"
• Developed by the IEEE Computer Society
• Architectural descriptions can be standard-compliant while systems, projects, processes or organizations
not!
Aims:
"Establish a conceptual framework and vocabulary for talking about architectural issues of systems"
Identify and disseminate solid architectural practices
Allows practices to evolve when new technological opportunities become available
• Can be used in the
Architectural description of individual systems
Iterative architecture work of evolutionary systems
Analysis and description of existing systems
S8
Views - Why?
• Why are different views of a system required?
Complexity management
Communication with stakeholders
• Examples of views
Deployment / distribution view
Static view
Dynamic / behavioral view
Execution view
...
• Challenges with multiple views of the same system
How do I keep the different views consistent with each other?
Example: If a component has been renamed within the static view, how do I ensure that it is
also renamed in all other views?
UML modeling tools help here
S9
A viewpoint is defined by
•Surname
• Addressed stakeholders
• Concerns that are addressed
• "ViewpointLanguage": components, connectors, ports, ...
• References
• Consistency and completeness checks
S10
S11
The 4 views of Hofmeister
• Conceptual View: concepts of the application domain and their relationships (including the domain
model). Not to be confused with the "Module View"!
• Module View: Breakdown of the system into modules and submodules
• Execution View: display of the communication paths between the modules, distribution to the hardware,
...
• Code View: package structure, versioning, DB structure, ...
S12
Views according to arc42.de
• Contextual delimitation:
Embedding the system in its environment
System as a black box
• Block view:
Disassembly into subsystems, components, frameworks, ...
• Runtime view:
Interaction of runtime instances
General processes within the software
• Distribution view:
Technical environment and infrastructure
Hardware components and their interaction / network topology
Deployment artifacts
S13
S15
Every view needs appropriate description techniques
Not all aspects of all views can be represented equally with a diagram type.
The “Unified Modeling Language (UML)” is a graphical modeling language that can be used for the
specification, construction, documentation and visualization of software systems.
Diagrams in UML can be divided into two main groups:
• Structure diagrams, class diagram, component diagram, distribution diagram, composition structure
diagram, package diagram, object diagram, profile diagram
• Behavior diagrams, activity diagram, use case diagram, interaction overview diagram, communication
diagram, sequence diagram, timing diagram, state diagram