Soft

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 ...

S11 – magische Viereck

S15

S16 What makes a good architect?

•Leadership skills
•Communication skills
•Negotiation skills
•Technical skills
• Project management skills
•Analytical skills
• Ability to abstraction
S18 Definition (s) software architecture
We use the following definition:
The software architecture defines the basic principles and rules for the organization of a system as well as
its structuring in building blocks and interfaces and their relationships to each other and to the
environment
S19 Definition: interface
An interface represents a well-defined access point to the system or its components. An interface
describes the properties of this access point, such as Attributes, data and functions. [...]
S20 Definition: building block
Core aspects of a building block:
- encapsulation and interchangeability
- Export and import of interfaces
- Configuration and hierarchical (de) composition
S21 (1) Export and import of interfaces
A module offers interfaces that it guarantees in terms of a contract. This guarantee applies on the
condition that the interfaces required by him are made available in the context of a corresponding
configuration.
S 22 (2) Interchangeability and encapsulation
A module encapsulates the implementation via the interfaces and can therefore be replaced by other
implementations.
S23 (3) configuration and hierarchical (de) composition
Building blocks are the unit of the hierarchical (de) composition of a software-intensive system.
S27 Typical range of tasks by an architect
• Definition of the software architecture taking into account the requirements
• Documentation of the software architecture
• Dimensioning of software components for the purpose of reuse
• Definition of the interfaces and relationships between software components
• Supporting software development and requirements management
• Assessment of the maturity of the software architecture
S28 iSAQB-International Software ArchitectureQualificationBoard (1)
• Offers 3 certification levels (CPSA - Certified Professional for Software Architecture):
Foundation
 The focus is on acquiring the following skills:
 Coordinate essential software architecture decisions with other project participants from the areas of
requirements management, project management, testing and development,
 Document and communicate software architectures based on views, architectural patterns and technical
concepts,
Understand the essential steps in the design of software architectures and carry them out independently
for small and medium-sized systems

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

S16 UML class diagram (1)

• Graphical modeling of classes and interfaces as well as their relationships to each other.
• With class diagrams you can also represent DB structures and domain models.
• Often used in
 Block view / Module View
Conceptual View
S22 UML component diagram (1)
• Graphic modeling of components and subcomponents as well as their wiring.
• Often used in
 Block view
View Module View
Contextual delimitation

S24 UML distribution diagram

• Graphical modeling of the distribution of components on computer nodes

S25/26 UML sequence diagram (1)

• Graphic modeling to describe the exchange of messages between objects.
• Usually represents a specific system flow (in contrast to activity diagrams)
• Can quickly become confusing for complex processes.
• Therefore: Always think carefully about the purpose for which a diagram is needed and whether it really
fulfills the purpose

S27 UML activity diagram

• Graphically represents the networking of actions and their connections with control and data flows.

S31 Simple template-arc42 for architectural descriptions

https://arc42.de/
Template available in the following formats: docx, asciidoc, markdown, latex, html, rst, textile,
confluence, Enterprise Architect, IBM Rhapsody, ...
And in the following languages:
EN, DE, ES, RU
Also some application examples

S32 Template Arc42 (arc42.de)

1. Introduction and goals
1.1. Task
1.2.Quality goals
1.3.Stakeholder
2.Boundary conditions
3. Contextual delimitation
3.1 Technical context
3.2.Technical or distribution context
4. Solution strategy

S37 Software architecture standards

• Standards and architectures for e-government applications (SAGA)
• The Open Group Architecture Framework (TOGAF)
• Zachman framework
• NATO C3 System Architecture Framework (NAF)
DoDAF; MODAF, ...

S43 Other common document types

• Central architecture description (arc42)
• Architectural overview
• Document overview
• Overview presentation
• Architectural wallpaper
• Documentation manual
•Technical information
• Documentation of external interfaces

S44 Practice rules for documentation (1)

• Writing from the reader's perspective
• Avoid unnecessary repetitions
• Avoid ambiguity
• Standardized organizational structure or templates and typesetting templates
• Give reasons for important decisions in writing
• Verification of usability
• Clear diagrams
• Regular updates
An architectural description should be as simple as possible, but as extensive as necessary.