Soft2

C3.1
S2 Aim of the architectural design
• The aim of the architectural design is:
Design and coordinate the system's blueprint,
 which guarantees the required functional and non-functional requirements,
 and document this in a complete and concise architectural description, on the basis of which creation,
maintenance, care and further development can be aligned.
• The architecture description serves as
Communication and discussion platform
Design and implementation plan
S3

S4 Definition: software-intensive system

A software-intensive system consists of a number of components that are put together in such a way that
they together fulfill the purpose of the system. Components that consist entirely or in large part of
software take on essential tasks to fulfill the system purpose. The software part of the system consists of a
number of programs and other procedures and data as well as the associated documentation.
S5Categorization of software-intensive systems
Different categorizations possible and partly dependent on perspective:
• Web browser from the end user's perspective is application software
• From the point of view of the programmer who develops browser plugins: system software
S7
S8 Different systems - different (architecture?) Questions
• For systems of every category ...
 ... there are different requirements
Transaction control in information systems to support x thousand users
Energy saving requirements in embedded systems (or mobile applications) due to limited resources
… there are proven systematics / architectural styles
Information systems often layer architectures
 Embedded system communication via buses
• The basic category of the system also determines which “architectural style” comes into question and
which further questions are relevant!

S11
S12

S15Coupling (1)
• What is coupling?
–Developed by the interdependency of two or more components
–Defines the degree of dependency
–Indicates how much changes to components affect others
The goal is a low coupling between components
S17Cohesion
Cohesion describes the content-relatedness of components with regard to their area of responsibility.
The goal is high cohesion within a component.
• Do the contents really belong together within a component?
S18Cohesion & coupling
Low cohesion and high coupling
“High communicative scenario” - Bad
High cohesion and low coupling
“Low communicative scenario” - Good
Coupling and cohesion can be measured using metrics!
S19 Measuring cohesion
LCOM - Lack of Cohesion Metric (1)

The higher the LCOM value, the lower the cohesion

• A: attribute of the class
• a: number of attributes in a class
• m: number of methods in a class
• n (Aj): Number of methods of a class that use attribute Aj

S22 How do you get a "good" = "modular" architecture? (1)

Compositional interplay of high cohesion, appropriate abstraction and information hiding as well as a low
coupling
A common way to determine the components of an architecture is to look at the dependencies.
• "Group" elements with strong dependency
• Dependencies between components become interfaces
• Once the architecture is defined, it provides guidelines for the introduction of new dependencies
S25 YAGNI –You Ain’t Gonna Need It
• observations
 Inaccurate requirements are often compensated for by products that try to compensate for the
inaccuracy.
 Constantly changing requirements are updated in the product as quickly as possible, because this is
possible thanks to the immateriality of software.
Precedented obedience
• Problems that arise from this
Unnecessarily complex software
Each line of code written, even if it is never used, costs time and money. Especially after it was written!
•That's why
 “Things that nobody needs have no value. So don't waste time on them. "
 Question what is really required and needed.
S26-28 Design byContract (1)
• Design byContract contains a number of principles for component-based software development
• Analogy with contracts in business
The components conclude contracts with each other
A contract includes the promise of a program component to provide a certain service if certain conditions
are met.
 Put the program together in such a way that it works properly if only all of your contracts are met.
Contracts between classes have e.g. following form:
If a certain requirement is met before calling a method in a class, the class is put into a certain state by
executing the method.
A contract for a method consists of:
Precondition
What assumptions are made about the arguments of the method and the state of the class.
Condition
What performance does the method provide, i.e. which property applies after its execution.
In Class invariant
At any point in time, the state of the class fulfills a certain property (the invariant).
S29 Law of Demeter (1)
• "Objects should only communicate with objects in their immediate vicinity."
• Also called the "principle of secrecy".
• Reduces the coupling
• A method should only use the following methods:
-Methods of your own class
-Methods of the passed parameters
-Methods of the classes associated with your own class
-Methods of objects that the method itself created

S31 Single responsibility principle

• "A module should be responsible to one, and only one, actor."
• Each class should only fulfill a precisely defined task
• General: “If you can't say in a simple sentence what the class / component is doing, this principle is
violated.”
• Focus makes understanding easier. A class / component with exactly one task is easier to understand
than a general store.
• Injuries lead to increased coupling.
• A class / component violates the principle if
A responsibility is spread over several classes / components.
Various responsibilities are united in one class.
S32 Separation of Concerns
• Separation of concerns is an old principle of software engineering and states that every function that
corresponds to a separate task should be implemented in a separate component (Dijkstra, 1982)
• Distribution of complex systems according to responsibilities (example: shifts)
•Advantages:
 Easier exchange and reuse of program parts
Quality increase through easier traceability of changes (easier testability)
If a code unit does not have a clear task, it is difficult to understand it, to apply it and, if necessary, to
correct or expand it.
S33 Interface segregation principle (1)
• Clients should not be forced to depend on interfaces (and their methods) that they do not need.
• Changes to unnecessary interfaces (and their methods) would unnecessarily affect users.

Note: Interfaces should be structured by subject. Therefore, do not align them exclusively to the
needs of all clients.