Vorlesungsfolien

1. Later

2. Requirements & Design (= early phases)

3. Abscence

4. Changed

5. Hidden (people cannot make assumptions)

Bad code decreases productivity!

Why readability is important?

• code is much more often read than written

• you write code for the next human to read (not for the computer)

• Lehman’s law: code will be changed -> effort required for a change increases the later it occurs! (see curve)

“Code that has been taken care of”

• simple and direct

• reads like well-written prose

• straightforward logic

• minimal dependencies

WTFs/minute (caused by inconsistencies,…)

A design strategy to build a system “made up of interacting objects that maintain their own local state and provide operations on that state information.”

+ maintainability

+ understandability

Five principles of good OO design:

• Single Responsibility Principle (SRP)

• Open Closed Principle (OCP)

• Liskov Substitution Principle (LSP)

• Interface Segregation Principle (ISP)

• Dependency Inversion Principle (DIP)

1st of the 5 SOLID principles for good OO design:

Idea: A class should only have one single responsability! (“Evolution Pressure”)

(“If you have two different concerns/tasks in one class, it is better to split that up”)

There should only be one rease for a class to change

Problem Symptom: Big Class

Fix: Refactoring - Extract Classes (divide class)

Benefits:

• Code easier to understand

• modifying should affect few classes

• risk of breaking code is minimised

  
  

“Evolution Pressure”

= By following SRP, you spread the pressure across multiple smaller classes, each evolving independently and more safely.

Example: Old Fashioned Mode split up into communication and connection

“Not only classes can be split up, but also methods: famous example Command-Query-Separation.“

“Either a method changes state (command)or it returns data (query) — never both.

Not only classes can be split up (SRP), but also methods: (=Erweiterung von SRP)

Either a method changes state (command) or it returns data (query) — never both.

In real world (in Java) it is violated with the iterator pattern.

Now it has 3 steps, which reduces performance :( -> bad if called often

2nd of the 5 SOLID principles for good OO design:

Idea: Classes (Software entities) should be open for extension, but closed for modification

= Modify behaviour by adding new code, not by changing old code

3rd of the 5 SOLID principles for good OO design:

Idea: Subclasses should be usable anywhere their base class is used, without breaking the program.

(I dont want to look at the details to understand it)

“Square-class violates this principle. We overwrite width and heigth. -> If we calculate with square now (see code) it breaks the code.”

“Rectangle has now different methods than rectangle, both inherit from rectangle”

4th of the 5 SOLID principles for good OO design:

Clients should not be forced to depend upon interfaces (methods) that they do not use.

Fix: Split interface

e.g. Worker mit work(), eat() - 1. Human 2. Robot => Robot braucht kein eat()

Comparable Interface in Java: imagine this method also has encryption -> every time you want to use comparable interface you also have to implement encryption

5th of the 5 SOLID principles for good OO design:

1. High-level modules should not depend on low-level modules

1. Abstract things (copy) should only depend on abstract methods. Details should only depend on abstractions aswell. (abstract must not depend on details! (something concrete))

Fix: Introduce abstract interfaces (maybe Inversion)

e.g. cantine sells food to you (abstract) display screens are the details

Two Software Packages, A references B

If you apply principle: A references in same package, B is implementing the new package

We inject a Method into A (dependency injection)

to realize dependency inversion (reverse dependency from A to B, to B to A)

Clean Code Principle:

Dont have too many dependencies (“dont talk to strangers”)

Symptom: myCar.engine.start() -> myCar.prepareForDriving()

Rule:

method m of class C should only call the methods of

- C

- an object created by m

- an object passed as an argument to m

- an object held in an instance variable of C

Example:

Clean Code Principle:

“Leave the campground cleaner than you found it”

-> cleaning up is part of the concept of “done”, refactor the code before checking in

Clean Code Principle:

“Implement behaviour that another programmer could reasonably expect it”

-> programmer intutition can be applied (konkludentes Verhalten)

Clean Code Principles:

Use names that are

• standardised

• meaningful (clear for everyone)

• intention-revealing

How? Make meaningful distinction and avoid disinformation by giving

• hints on context (accountName instead of name)

• hints on types (accountList instead of accounts)

• prefixes

“Don’t be shy with long variable names”

Use Formatting: vertical and horizontal whitespaces

“Dont comment bad code, rewrite it”

Good comments are

• explaining (intent)

• warning (of consequences)

• informative (open issues)

Whenever possible: use well-named code instead of comments

(if they get outdated, they are even worse than no comment)

Don’t

• use redundant comments

• comment out (nobody deletes it)

Clean Code Principle:

Do not duplicate pieces of code

-> understandability (code is elss compact, passage has to be understood multiple times)

-> maintainability (lose track of copies, undocumented dependencies are horror, modify all componentes)

Clean Code Principle:

Code should be as simple as possible

-> easy to understand

-> addresses the problem adequately

-> don’t add unnecessary functionality

Clean Code Principle:

Only implement required features (= don’t add unnecessary functionality)

-> more features more cost

-> do not create platform (abstract) unless explicitly asked and payed for

-> don’t optimize every last detail (too costly, only treat the symptoms)

KISS says: if you have a solution, keep it simple,

Yagni says: do you need that? dont blow up your code base

Clean Code Principle:

Establish a well ordered hierarchy (abstraction levels) -> abstraction should decrease depth-first

Start with something that has no dependencies (least coupled) and move up from there

History

Shared working

Tagging

Reverting

Idea: write tests first = implementation driven by requirements (Test-Driven Development)

-> when you write test cases first, you also validate if you understand the requirements

Clean tests follow the FIRST rules:

• Fast - to run them frequently

• Independent - a failing test does not influence others

• Repeatable - in any environment, so there is no excuse for failing tests

• Self-Validating - tests either pass or fail automatically

• Timely - tests are written right before production code

Run code against classes of metrics which detect possible errors

Review and explain your code to others

-> detect errors

-> spread knowledge

“Disciplined technique for restructuring code, altering internal structure without changing external behavior”

Prerequisite: refactor with tests only! (otherwise you might introduce new bugs into the program)

How?

- extract cohesive parts into new methods

- move methods / rename / …

- Long method

-> Extract Methods

- feature envy (one class calls excessively other class’s methods)

-> extract or move method

- data class (only has attributes, no methods -> not desired in OO)

-> enforce information hiding principle

- duplicated code

- god class (tries to do too much)

Bad smells as indication

Generally:

- when you frequently look up details

- when you want to write a comment

negative performance

difficult code to refactor

- already published interfaces

Order of Implementation

Use Version control System

Test First

Static Code analysis

Code Reviews

Refactoring

Software architecture is the important structure(s) of the system: includes design decisions which are hard to revert (made early)

- SA links the code and the requirements

- identifies major system components and their communication

Software architecture is

• the result of a set of design decisions

• compromising the structure of the system (with components their relationships and their deployment)

-> Architectural design decisions are made in the early phases of the software development process

Architectural design is a creative process depending on the type of system being developed

• Architectural design decisions are made in the early phases of the software development process

• (analogy: “this building is built in a baroque style” -> sub decisions/characteristics follow)

= identifying major system components, their communications and mapping to hardware resources

• early stage of the system design process

• requirement engineering process and software design process are interleaved

• (analogy: “We need 3 bedrooms, 2 bathrooms, and energy-efficient materials.”)

Different people (developers, testers, managers) care about different things

-> Choose the set of views appropriate for your project

“An architecture cannot be modeled on one view type, you need several ones”.

The minimum of view types is to include a

• structural view (static properties of the system: component repository)

  example: class diagram

• behavioural view (functional and execution semantics of the system: intra and inter component behaviour)

  example: activity diagram

• deployment view (where components run and how they are deployed: allocation)

  example: component diagram

-> tool for stakeholder communication (common vision, shared language)

-> identify what requirements can be met

-> large-scale reuse (architecture may be reusable for more systems)

-> helps for project planning (cost estimation)

=> helps predicting the quality of an artefact during design!

Yes ideally record

• decisions and why chosen

• alternatives

• influential factors

Why?

• others and you can understand later

• requirements, especially constraints: “It has to be compatible with our old system/techstack”

• re-use (architectures, styles, patterns, components) “I want to have

• organisation (team size, experience, orga structure)

  -> Conways Law “A system (usually) reflects the organizational structure that built it”

Quality requirements indentify (quantify) the most important goals of the architecture (for evaluation)

SAMPSS:

• Performance

• Security

• Safety

• Availability

• Maintainability

• Scalability

-> They may often contradict with each other and thus need to be balanced!

• Separation of concerns

• Single Responsibility principle

• Information Hiding

• Principle of Least Knowledge

• Don’t repeat yourself (DRY)

• Minimize upfront design (as much as reasonable)

Architectural Pattern

solution to reocurring problem where several forces have to be balanced at the architecture level

Architectural Style

system wide solution principle that you stick to (object-oriented style, modular style), independent of application, should be used throughout the architecture

Reference Architecture

template that can be used to construct a system in a specific domain

-> defines domain concepts, components and subsystems that can be used by concrete instances

Architectural Style on how to decompose a large system into layers:

Difference:

In UP you have the stakeolders view of concpets in the domain

In layered architecture: you describe what to do in the implamantation, what are concepts of the real world domain and their interactions?

Tipp: Start with extremes: what is layer 1 and what is layer 4

layer 1: outer things, database, external providers

layer 2: oftentimes controllers, connected to layer 1 (if there is an obvious layer 1, labeles with “Subsystem” or “External”)

layer 3: more concrete use cases that deal with entities (handle stuff relate to the entity: we need user management for our web store, but this is not an entity)

layer 4: foundational application domain (my whole application does not make any sense without it)

it is allowed to skip layers, dependency rule is the only important thing

note:

names of components and remembering their level is very bad idea: only because hibernate is level 2 here, it does not mean that hibernate is level 2 in another example

Divide application into three elements:

• model (core funcitonality)

• view (displays info)

• controller (user input)

SmartUI = anti-pattern (avoid it)

-> we need model-view separation

object that carries data between processes or architectural elements

Architectural Pattern

generic reference architecture

-> acts as a standard against which systems can be built and evaluated

-> derived from a study of the application domain

Have both in mind: Use Cases = Application Business Rule

Principle: Business Logic Insie, Dependencies from outside to inside!

• Enterprise Business Rules (Entities)

• Application Business Rules (Use Cases)

• Interface

• Framework & Drivers

Why?

Inner parts are more stable (“we want to depend on things that are more stable than we are”)

Testing

=> Benefit: Inner parts dont depend on anything, you can test and change if you want! -> minimum impact of change

Entity = Core model of my software (Cantine example -> Food)

Use Case = Applying this entity to one application (Cantine example -> provide info on who provides potatos)

Controllers = Things built around my domain model, purposes, have a layer between entity and use cases and the outside (Cantine example -> layer between external service (=layer 4) where I order food)

External Interface =

Independence of Frameworks

Inner core easily Testable

Independence of UI

Independence of DB

Problem: communication

Resolve: dependency Inversion principle

Hexagonal

Onion

BCE

=> common objective: separate concerns using layers

Here: Interfaces are outer layers, model is inner layer, dependency rule: from interface to controller to model is good direction

ADG is bad

SOLID: D principle -> interface as abstraction

Here: Interfaces are outer layers, model is inner layer, dependency rule: from interface to controller to model is good direction

ADG is bad

(Distribute = Deployment, what is running on the client, what is on cloud)

Decouple layers and use cases

“Components are for composition, much beyond is unclear…”

-> building blocks for software (which can be adapted without understanding its internals)

systems are based on components

Problem: When you overwrite a method (from superclass) and another superclass method has a dependency to this method

you need to know this dependency

Components are not in the user interface

Defines what a component is, how it offers services,…

Most approaches are object oriented and rather not component based

(e.g. CORBA, EJB)

Java components?

no, we use packages, classes, …

Potential Solution to the main problem of realising components (object oriented is problematic when realising components):

OSGi offers bundles as solutions to that

Web services are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web

• self contained

• self describing

• modular

• published

• located

• invoked

=> Web services are basically deployed components

System of web services with:

• service requestor (bind to provider to invoke service)

• service provider (publishes)

• service broker (finds service from registry)

SOAP -> Messaging the Service (through passing XML encoded data)

(only SOAP really established)

WSDL -> Description of service

UDDI -> Discovery of Service

Stricter adherence to CBSE (Component-Based Software Engineering) principles and performance analysis.

1. SOFA: Protocol checking, compositionality, infrastructure.

2. ROBOCOP: Focus on consumer electronics, analyzes non-functional properties.

3. KobrA: UML-based, hierarchical modeling; supports software product lines.

4. Palladio: Predicts performance at design time, supports CBSE roles, maps to EJB.

(siehe Handy Bild)

ATM requires ->

• Card Validator, Authorization, Database (obvious chain)

• Cardreader

• Cash Dispenser

ATM provides ->

• User Interface

A domain-specific modeling language (DSL) for early performance prediction in component-based software.

Key Goals:

• Model business information systems.

• Predict performance at design time.

Components declare:

• Preconditions: What they expect (requires-interface).

• Postconditions: What they deliver (provides-interface).

Use models to predict quality attributes like:

• Performance

• Reliability

• Cost

→ Based on analytical techniques and simulations

New Palladio idea: Took into performance analysis all 4 factors:

• Usage context

• External services

• Implementation

• Runtime environment

  
  

How to handle context changes?

• Allocation context: Hardware/VM placement

• Usage context: Load, user behavior

• Assembly context: Other components used

• Hardware changes → e.g., different CPUs

• Usage changes → e.g., user load, interaction patterns

• Assembly changes → e.g., replacing connected components

Why? To enable design-time performance prediction that reflects real-world variability.

• To predict performance (e.g., delays, bottlenecks)

• To simulate changes before implementation

• To extend legacy software systems

• To analyze performance jumps and critical conditions

1. Inputs: Component behavior, usage profiles

2. Outputs: Response times, throughput, ressource utilisation

1. Component Developer: Components, interfaces, SEFFs

2. Software Architect: System architecture

3. System Deployer: Resource mapping

4. Domain Expert: User behavior

Service Effect Specification — describes a component’s externally visible behavior in an abstract way.

-> Activity diagram from Palladio

1. Abstracts a component’s internal logic

2. Describes:

   • What it provides

   • What it requires

3. Can include loops, branches, external calls

Roles, SEFF, parameterisation

1. A component made from other components

2. Enables hierarchical modeling

Assembles system from components.

System Model:

Purpose: Model the full architecture.

• Connect interfaces

• Include only relevant parts

• Prepares for performance simulation

• Defines hardware/software environment

• Maps components to resources

1. Abstract resource types (CPU, RAM, Net)

2. Allows flexibility across different hardware setups

• Knows the business domain

• Defines user scenarios and workloads

• models User behavior

  • Number of users

  • Request patterns

  • Input parameters

• Doesn’t model internal logic

• Developer → components + SEFFs

• Architect → assembly

• Deployer → resources

• Domain Expert → usage

Keeps black-box principle of components at model level for assembly, allocation, and usage

What needs to be done by who?

An architectural style for building an application as a suite of small services

-> Primarily, it is about scaling your development team (& application)

Goal: Decoupling for independent development and deployment (“Microservice: separate components into user processes to maximize decoupling and independent deployability”)

Each application:

• Runs in its own process

• Communicates via lightweight protocols (e.g., HTTP/REST)

Decoupling for independent dev/deployment (achievable in monoliths too).

1. Componentization via services – Functional units as services

2. Business capability alignment – Each service supports a business goal

3. Product-oriented – Ongoing ownership, not just project completion

4. Smart endpoints, dumb pipes – Logic in services, simple communication

5. Decentralized governance – Teams choose tools/patterns

6. Decentralized data management – Services own their own DB

7. Infrastructure automation – CI/CD & deployment automation

8. Design for failure – Handle and recover from service outages

9. Evolutionary design – Flexible and adaptable service structure

Try to split up your services by functionality: Each service implements a recognizable part of the product

-> independently deployable

=> Each service is user-facing, independently deployable, and interacts via remote mechanisms like HTTP or RPC.

Products not projects:

Focus on services enhancing business capabilities. Teams own development and operations (DevOps).

Microservice architecture splits up systems into services organized around business capabilities

-> Align services with business functions

-> Supports Conway’s Law – Structure reflects communication patterns

Services are autonomous, handling logic and responding over simple REST-like interfaces:

-> Endpoints (microservices) should do the work — they handle logic, processing, and behavior.

-> Pipes (the communication between them) should be as simple as possible — just carry data with minimal transformation or coordination.

=> Microservices are about independence, not about software reuse

Microservice teams prefer creating and sharing useful tools and standards.

Tolerant Reader: If interface provides additional data, i just ignore it.

(skipped: Consumer-Driven Contracts (CDC): Consumers define what they need; providers conform.)

Each microservice owns its own database. (Monolith: only one database)

Autonomy:

− Consistency becomes challenging, data redundancy

e.g. shipping and invoice both need address

Use CI/CD pipelines and tools to automate

Each service is a small, independent unit that:

• Has its own database

• Exposes a clear interface (e.g., HTTP API)

• Can be tested and deployed independently

If Microservice gets large: Clean Architecture

"Component" = Microservice

Reality: Services will fail — plan for it. Dont make the assumption that once it is running, it stays that way.

-> Idea: Randomly kill processes (Chaos Monkeys), how does my system react? Is it still working? It should

Practices:

• Monitor both technical (e.g., requests/sec) and business metrics (e.g., orders/min)

• Use resilience tools like Netflix’s Chaos Monkeys

• Split services gradually

• Look for low-coupling points to extract services

• Favor user functionality over tech layers when slicing

Avoid: Manual versioning and early over-engineering.

Benefits:

• Strong Module Boundaries: Supports large teams by reinforcing separation of concerns.

• Independent Deployment: Small, autonomous services are easier to deploy and debug.

• Technology Diversity: Teams can choose the best language, framework, or database per service.

Costs:

• Distribution Complexity: Remote calls are slower and prone to failure → harder to program reliably.

• Eventual Consistency: Strong consistency is hard; must design around delays and sync issues.

• Operational Complexity: Managing many services (monitoring, logging, deployments) requires mature DevOps capabilities.

-> it depends: You gain flexibility and scalability, but pay in complexity and operational overhead.

Software that supports businesses, especially business processes and business transactions & data.

Counter examples: infrastructure, nothing tied to a specific business

1. Persistent Data: Must survive app/server lifecycles

2. Large Data Volumes: Millions of records, fast access needed

3. Concurrent Access: Many users, potential for conflicts

4. Multiple UIs: For different types of users

5. System Integrations: REST, SOA, batch, etc.

6. Conceptual Dissonance: Terms mean different things to different people

7. Business "Illogic": Rules may be complex or arbitrary

1. Presentation Layer: User interface, handles input/output (lecture of Abeck)

We are talking about: “Backend”:

1. Domain Layer: Business logic (calculations, rules)

2. Data Source Layer: Communicates with databases and other systems

Pattern families: one problem, multiple patterns to solve it

• Domain Logic

• Data source architecture

• Object-relational structural patterns

-> choosing pattern depending on requirements of system at hand (advantages/disadvantages,..)

Setting: Complex business logic

Main Patterns:

1. Transaction Script – For each Use case you have your own script

2. Domain Model – OO model with behavior and data

3. Table Module – One class per DB table, procedural logic on record sets

Organizes business logic by procedures, where each procedure handles a single user request or transaction.

-> for each use case you have a script that handles a full operation

Advantages:

• ✅ Simple & fast to implement

• ✅ Easy to understand for developers

• ✅ Clear transaction boundaries

Disadvantages:

• ❌ Does not scale well with complex logic

• ❌ Tends to cause code duplication

= An object-oriented model that incorporates data and behavior

(= classic object oriented design as fix for dealing with complexity)

Designing a Domain Layer (=layer with business logic) using a domain model (artefact), low representation gap between classes and domain model

Advantages:

• ✅ Organizes complex business logic well

• ✅ Encapsulates logic with the relevant data

Disadvantages:

• ❌ Steeper learning curve, especially for non-OO teams

• ❌ More complex mapping to relational databases

A single class that handles business logic for all rows in a database table or view.

• One class handles business logic for a table

Advantages:

• ✅ Separates logic for different concepts

• ✅ Straightforward mapping to data

• ✅ Good if used technology supports it (e.g., .NET, COM)

Disadvantages:

• ❌ No object instances: Not suitable for complex, object-oriented logic

• ❌ Limited reusability and abstraction

Depends on complexity of domain logic:

simple DL: Transaction Script

data centric logic: Table Module

complex or evolving: Domain Model

(Transaction script and table module do not scale very well)

Problem: I have OO-code and i have a data source, how do i connect (Map) here? (they dont fit together well)

=> separate domain logic from database access

Common Patterns:

• Record Set (basic pattern)

• Table Data Gateway

• Active Record

• Row Data Gateway

• Data Mapper

“An in-memory representation of tabular data“