Soft 4

C4.1
S2 Design pattern goals
• The aim of design samples is:
Documentation and reuse of solutions that were previously used successfully.
• In many object-oriented systems, recurring patterns of classes and communicating objects can be found.
• These patterns solve specific design problems and make object-oriented designs
 More flexible
Elegant
Reusable
Definition pattern:
A pattern is a schematic solution to a class of problems that has proven itself in a certain context.
S3 Patterns are descriptions of solutions
• A design problem is based on the fact that in certain situations (context) there are opposing forces
(problem).
• The solution is to use the tools available in the respective design discipline to design the situation so that
these forces are optimally balanced.
• A pattern describes a solution to a design problem
Patterns are constructive, i.e. they provide instructions for solving a problem situation
Patterns are abstract, i.e. they offer a wide range of applications with many different applications
Patterns are stable, i.e. they capture the stable core of the solution
• Patterns are valid over time and largely invariant to new possibilities
S5-9 Layer Architecture (1)
• The software system is structured in layers. Individual aspects (e.g. classes or components) of a software
system are assigned to a layer.
• Aspects of a higher layer may
only use aspects of the same or a
lower layer.

Advantages and disadvantages:

+ Reuse of layers
+ Possibility of standardization
+ Minimize code dependencies
+ Interchangeability of the implementation of layers
- Changes may have to be made through all / many layers
–Lower efficiency due to many layer transitions
- Unnecessary and duplicate work (e.g. error correction on all layers)
- Difficulty finding the "correct" number of layers
–Shifts are more of a technical, rather than a technical, structure
–Team members focus on completing “their” shift. The overall functionality takes a back seat.
Note: The architecture within a layer must also be defined. Otherwise there is a risk of technical debt
within each shift.
• Poor maintainability
•Bad performance
• ...

S11-12 Pipes and Filters (1)

• A pipes and filters architecture helps to structure systems that process a data stream.
• The architecture consists of
 filter:
-A processing step in which incoming data is converted and passed on to a next filter via a pipe.
-Parts of the data can be removed, added or completely replaced.
 pipes:
-Represents the connection between the individual processing steps
Properties of architecture
The individual filters can be combined, exchanged and the processing order changed.
-Condition: The output of one filter can be interpreted and processed by all other filters.
Smaller filters facilitate reusability. They are more manageable and can be used in different contexts
No information sharing
-Consistent filters do not share global information.
 Various data sources and data sinks can be supported
-Files, network connections, storage systems
No need to save intermediate results
 Parallel processing can also be implemented via one filter passing its results to two other filters (T-
Filter / T-Pipes).
S13-16 Broker Architecture (1)
• The broker pattern helps structure distributed software systems with decoupled components that interact
by calling remote services. An intermediary (the broker) coordinates the communication.
• The servers register themselves with the broker and make their services available to the clients. Clients
access the functionality of the server by sending service requests through the intermediary.
• The broker:
-Finds the suitable server
- forwards the service requests
-Submits results and error messages
• Components can be exchanged, added or removed at runtime.

Example: MQTT -Message Queuing Telemetry Transport

• An open network protocol for machine-to-machine communication (M2M)
• After the connection has been established, clients send the server (“broker”) messages with a topic that
classifies the message hierarchically
• Example: kitchen / refrigerator / temperature
• Clients can subscribe to these topics, whereby the server forwards the received messages to the
corresponding subscribers
Example: CORBA - Common Object Request Broker Architecture
 The core is a so-called "ObjectRequest Broker (ORB)"
 Simplifies the implementation of distributed applications in heterogeneous environments
Component interfaces are specified using an IDL (Interface Definition Language).
-This is independent of programming languages
-This is used to generate programming language-specific stubs and skeletons. (see mediator
patter, not part of this lecture)
-These make the method call appear local to the caller.
-Allows communication between components that have been developed in different programming
languages.
 Some CORBA services are
Trading service
- Event service
- And many more
S17 DTO Data Transfer Object
• Bundles several data in one object, the DTO
• Goal: Minimize the number of cross-process method calls
• Are used in distributed systems to replace multiple time-consuming remote accesses with a single or a
few.
• The structure of DTOs is mostly based on the needs of the clients and less on the data structures of the
server.
• Attributes of a DTO are primitive, serializable data types, or reference further DTOs.
S18 Model View Controller (1)
• Goal: Flexible program design to facilitate later changes or extensions and to reuse the three
components.
• MVC consists of three components
Model
Presentation (View)
Control (controller)
The same information is displayed in different ways in different windows, e.g. in a bar or pie graphic.
• The display and behavior of the application must immediately reflect changes to the data.
• The support of various "Look & Feel" standards or the porting of the user interface to another platform
should not affect the core functionality of the application.
 S20 Variant of the model view controller pattern
• Separation of representation and logic of the
user interface
• Used in UI platforms like
Cocoa, Windows Presentation Framework
(WPF), JavaFX, ...
• Allows a separation of roles between UI
designers and developers
S21 CQRS (1)
• CQRS: Command Query Responsibility Segregation
• Based on the CQS principle (Command Query Separation)
 Each method should either
 be a command that performs actions, or
 a query, which data returns to the caller,
 But never both!
Ask "Asking a question should not change the answer."
• Requires the division of the software architecture into two parts with clearly separated responsibilities
 Execution of commands
 Side effect-free operation of queries
• Often combined with the event sourcing approach
A process in which all changes in the state of a system are mapped and recorded as a sequence of events.
Areas of application
 Components in which data is read much more frequently than is changed
 Systems with high collaboration and frequent competing access by multiple users
 CQRS with Event Sourcing fulfills the requirement of traceability of all processes in the system
•Disadvantage
 With simple systems leads to greater effort in analysis and design than the pure implementation of data
structures
 Lack of tool support, few standard frameworks or libraries available

S25 Blackboard (1)

• The blackboard pattern is helpful for problems for which no deterministic solution strategy is
known.
• Several specialized subsystems collect their knowledge in the Blackboard to create a possible
partial or approximate solution.