Lecture

„Engineering Informatics I“
WS 2024/2025
Software-Engineering, Part 01

2 Software Engineering

1 Introduction
2 Basics of Software Engineering
2.1 Core Processes
2.1.1 Requirements Engineering
2.1.1.1 UML
2.1.2 Software Design
2.1.3 Implementation
2.1.4 Testing
2.1.5 Maintenance

04.10.2024 | Department 13 | Institute of Numerical Methods and Informatics in Civil Engineering | Prof. Dr.-Ing. Uwe Rüppel | 1
1 Introduction
"Software misery" at the opening of Chek Lap Kok Airport in
Hong Kong

Video approach, 3:23, Audio off

https://www.youtube.com/w
atch?v=fRXHr0bnoS0

-> Damage : USD 600 million

https://www.legco.gov.hk/yr98-99/english/sec/library/989rp01.pdf

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 2
Success statistics of IT projects

2007 34 20 46 Then stable, OOP established.

- Beginn OOP

Bases on Source: CHAOS Report, Standish Group International, Inc., 2000; VDI Nachrichten 2007

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 3
"Soft indicators" for the failure of a project (in
addition to standard target-actual controls)

A great danger is that a precarious situation is not

recognized in time - either out of inexperience or out of
"intention to secure a job" (three-monkey model).
External indicators
The project team is increasingly complaining about change
requests from the customer, which can no longer be
executed "in time and on budget". It can be a planning
error or the customer has fundamentally changed their
Source: Wkipdia
requirements. Buddhist Temple in Nikko,
Japan
If the customer regularly brings change requests, the content „No hear, speak, see“

of which contradicts previous project meetings.

Change requests no longer arrive in the agreed form (if a
corresponding form has been agreed).

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 4
Indicators

• Is the invoice not paid after a previously agreed milestone has

been paid? Not even after the payment reminder? To clarify: Either
the customer is insolvent, or he is not satisfied with the service
provided.
• Bugs have been fixed and a short time later many errors are
reported again? This can mean that the programming quality is not
good or the software architecture is not robust enough: this would
https://www.heilpraxisnet.d
have to be checked. e/naturheilpraxis/gaehnen-
ist-ansteckend-die-
Internal indicators ausnahme-sind-
psychopathen-
2015082643778/
If the best project staff are withdrawn with the justification "Now an
important project is pending, we absolutely need Mr. / Mrs. xy in this
project!" This may mean that the project has already been written off
by the management.
„Signs of fatigue" among employees ("9am to 5pm mentality")

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 5
 Software Lifecycle (1)

Planning
Decision on development
Basic characteristics
Feasibility
Analysis
Question about the WHAT
Requirement Definition
Identify objects and operations of the problem area from the user's point of view and
identify their dynamic interaction
Design
Question about the HOW
Specify system components and interfaces, as well as their interaction
GUI, data and process management

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 6
Software Lifecycle (2)

Implementation phase

Implement, test and document the system model programmatically

Introductory phase

Integration of the user system into the existing process

Work organization adjustments and user training

Usage phase

Eliminate bugs

Subsequent adaptation and extension of the software functions

Update program documentation

-> Software development is an evolutionary process

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 7
2. Basics of Software-Engineering

Software engineering as a branch of

computer science deals with the
standardized "engineering" production
of software and the associated
processes.
Helmut Balzart, Textbook of Software
Technology:
" SE is the goal-oriented provision and
systematic use of principles, methods
and tools for the division of labor,
engineering development and
application of extensive software
systems."
https://www.sensirion.com/de/karriere/software-engineering-bei-sensirion/

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 8
2.1 Core processes
2.1.1 Requirements Engineering
The aim of requirements management is to achieve a common understanding of a
system to be developed between the contractor and the client. At the same time,
the resulting documents often serve as a contractual basis for further
implementation.
A common understanding can be achieved through the introduction and
implementation of requirements management methods (e.g. requirements analysis,
requirements specification, requirements modeling, requirements reviews). By using
these methods, the quality of the requirements documentation can be increased.
Quality criteria of a requirements documentation are, among other things,
comprehensibility, unambiguity, verifiability, consistency, completeness, testability.
The management of requirements means that processes are defined and
implemented by updating the requirements documentation throughout the course of
the project and using it as a basis for the creation of test cases at the end.

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 9
 2.1.1 Requirements Engineering

• Requirements assessment: Determination of the client's requirements for the system to be

developed.
• Product concept catalogue (Definition of requirements by the Client): The specifications
(sometimes also called requirements specification, catalogue of requirements, product
sketch, customer specification or requirements engineering) describe the entirety of the
customer's requirements for the deliveries and services of a contractor as precisely and
unambiguously as possible.
• Specification (Specifications refined with technical approaches by the Contractor): The
functional specification describes in concrete form how the contractor wants to solve the
requirements of the client (how and with what).

Quelle: vitolavecchia.altervista.org

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 10
Requirements Engineering

Identify and document requirement sources and content

Documentation: Are there specifications for similar products?
Users and other stakeholders
Contents
Stakeholders
Determine
Categorize (customers, users, etc.)
Determine motivation, goals, success criteria, concerns,
working environment of stakeholders
Prioritize by impact on the project
System Analysis: Structured Analysis (SA), Object-Oriented Quelle: slideshare.net

Analysis (OOA), Unified Modelling Language (UML)

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 11
 2.1.1.1 Unified Modeling Language (UML)
(1) Introduction

Why UML
for the
installation
of a swing ?

The contents of
the text or image
quotation are
discussed
scientifically within
the framework of
the context of the
lecture.
Source: Wikipedia

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 12
 UML: Why? -> Benefits

• Specifications for software development

• Helps users and developers communicate.

• Provides traceability from the first draft to the finished system (traceability).

• Central repository for knowledge and experience.

• Improvement of software quality, e.g. through transparency.

• Long-term cost reduction.

• Flexibility for rapid technical and business changes.

• Large and complex software systems require "thoughtful" design.

• ...

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 13
 UML: What?

Is a notation/language to OOM: phases OOA, OOD and OOP, is abstracted

from
- Architectural specifications,
- Design and implementation styles,
- Technologies (software, hardware, infrastructures, ...),
- Development processes

Standardized (www.omg.com)
Conceptual world (modelling concepts),
semantics (importance of modeling concepts),
Visual representation (notation of modeling concepts)

Brings together ideas of different techniques

Booch, OMT, Jacobsson, ROOM, SDL, EDOC, MSC, Component Based
Modeling, ...
Extensive literature can be found on the Internet.

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 14
History

The contents of the

text or image
quotation are
discussed scientifically
within the framework
of the context of the
lecture.

Source: Wikipedia
UML 2.3
UML 2.4.1 2011 -> 2.5.1 2017

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 15
Semantical Areas of UML

Structural Semantics defines the meaning

of UML structural model elements about
individuals in the domain being modeled,
which may be true at some specific point
in time. This category is sometimes called
“static semantics”.
Behavioral Semantics defines the meaning
of UML behavioral model elements that
make statements about how individuals in
the domain being modeled change over
time. (This is sometimes also called
“dynamic semantics.”)
Supplemental modeling defines
constructs that have both structural and
behavioral aspects. These include use
cases, deployments and information flows.

https://www.omg.org/spec/UML/2.5.1/PDF

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 16
 (2) Use case diagram (external view of the
system)

What does the system do for the user?

Simple notation:
- System (rectangle)
- Actors
- Use Cases
- Relationships (arrows)

E.g. traffic light intersection

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 17
(3) Class and object diagram

• Class diagram: classes and relationships; Static structure

• Object diagram: What does a snapshot of my system look like at
execution time?
• Used to describe the objects of an application with
Types
Attributes
Operations (Methods)
Static relationships
Assoziation:
• Relationship between objects of different classes. Objects are
associated with each other e.g. an object of one class uses / uses an
object of another class
• Load transfer in the static system: ceiling on beams, beams on
supports, etc.

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 18
(3)

• Generalization/Specialization: describes a hierarchical

relationship between classes/objects
More specific subclasses are grouped together via a
generalized "upper" / superclass

Super classes: hierarchical summary of subsets: definition of

general (universal) attributes and operations

Subclasses: Adopt all attributes and operations of their

superclass

Programmatic implementation -> inheritance

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 19
Class & Object Diagram: Selected Relationships

Directed associations are relationships that can only be

navigated in one direction. The navigation is represented
by an open arrowhead, which indicates the allowed
navigation direction.

Qualifier Association: Relationships where an object can

associate many (*) objects of the opposite side are
implemented by container objects. For example, a dictionary
is defined in which access is made by specifying a key. These
keys should be specified as qualifying attributes during 1…*
design. These are then represented in the notation as a
rectangle on the side of the class that accesses the target
object via this key. The qualifier is part of the association. In
this relationship, it is navigated exclusively via the key.

https://www.visual-
paradigm.com/guide/uml-unified-modeling-
language/uml-class-diagram-tutorial/

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 20
Class and object diagram: e.g. traffic light
intersection

Object diagram for case A:

Composition Object: Class

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 21
 (4) Sequence diagram

Who exchanges which

information with whom
and when?
-> Timing of the information
exchange of the
communicating units

https://www.uml-diagrams.org/

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 22
Sequence diagram: e.g. traffic light
intersection

C
D

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 23
 (5) State diagram (state machine)

Which states can a

system part occupy
at which events?
Input-output conditions
States
Happenings

https://drawio-app.com/uml-state-diagrams-with-draw-io/

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 24
State diagram: e.g. traffic light intersection

1 2 3 4

LightLife
switchLight RedYellow switchLight
Phase=2
Red Green
Phase=1 Phase=3
Yellow
switchLight Phase=4 switchLight

Init
[InitPhaseEqualTo(1)] [InitPhaseEqualTo(3)]

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 25
State diagram: e.g. traffic light intersection
ctd.
LightLifeNorthSouth switchLight RedYellow switchLight
Phase=2 1 2 3 4
Red Green
Phase=1 Phase=3
Yellow
switchLight Phase=4 switchLight

switchLight switchLight switchLight switchLight

ControlLife
switchControl switchControl switchControl switchControl switchControl
Red_Grn Red_Ylw RedYlw_Red Grn_Red Ylw_Red Red_RedYlw
Phase=1 Phase=2 Phase=3 Phase=4 Phase=5 Phase=6

switchControl

switchLight switchLight switchLight switchLight

3 4 1 2
LightLifeWestEast switchLight RedYellow switchLight
Phase=2
Red Green
Phase=1 Phase=3
Yellow
switchLight Phase=4 switchLight

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 26
(6) Communication diagram

Who communicates with whom about what or how?

Rough overview

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 27
Communication diagram: e.g. traffic light
intersection

1: createControl
2: createLight
3: switchLight
4: switchLight
5: switchLight
6: switchLight
7: switchLight
8: switchLight

2.1d: createLight(3)
2.1c: createLight(3)
2.1a: createLight(1) A 2.1b: createLight(1)
3.1c: switchLight
3.1d: switchLight
B 4.1c: switchLight
4.1d: switchLight
4.1a: switchLight C 4.1b: switchLight
5.1a: switchLight D 5.1b: switchLight
6.1a: switchLight E 6.1b: switchLight
7.1c: switchLight
7.1d: switchLight
7.1a: switchLight F 7.1b: switchLight
8.1c: switchLight
8.1d: switchLight
A

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 28
(7) Activity diagram (selected elements)

How does the program

sequence work?
Processes, conditions, loops,
branches, synchronization,
parallelization, etc.
Token concept (Petri Net)
Respective state of processing

https://www.educba.com/uml-activity-diagram/

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 29
Activity diagram: e.g. traffic light intersection

Swim lanes

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 30
(8) Component diagram

How are the classes grouped https://www.visual-

paradigm.com/guide/uml-unified-
into reusable components? modeling-language/what-is-component-
diagram/
Organization and dependencies of
individual system-technical
component:
Component (Encapsulated Area)
Interface
Realization, implementation and
usage relationship
Class
Artifact Document
Port (Multiple interfaces)

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 31
Component diagram: e.g. traffic light
intersection

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 32
 (9) Distribution diagram

What does the information and

communications technology (ICT)
infrastructure of the deployment look
like?
Hardware runtime environment of the
system

E.g. traffic light intersection:

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 33
(10) Package diagram

How can I break down the system into

manageable units? http://agilemodeling.com/style/packageDiagram.htm

Large units of the system

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 34
(11) Timing diagram

E.g. Pedestrian traffic lights

When are which partners in
which condition?
Elements: lifelines,
messages, time conditions,
attribute values,

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-timing-
diagram/

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 35
(12) Interaction overview diagram

In what order and under what

conditions do interactions take
place?
Picture a control flow with nodes that can
contain interaction diagrams which
show how a set of fragments might be
initiated in various scenarios. It
focuses on the overview of the flow of
control where the nodes are
interactions or interaction use.
The other notation elements for
interaction overview diagrams are the
same as for activity and sequence
diagrams. These include initial, final,
decision, merge, fork and join nodes.

https://www.visual-paradigm.com/guide/uml-
unified-modeling-language/what-is-interaction-
overview-diagram/

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 36
(12) Interaction overview diagram (ctd.)

The example above shows a student

who has been accepted into a
university. First the student must be
accepted or declined by admission.
After accepting, the student must
both register for classes and apply
for housing. After both of those are
complete, the student must pay the
registration. If payment is not
received in time the student is
excluded by the registrar.

https://www.visual-paradigm.com/guide/uml-
unified-modeling-language/what-is-interaction-
overview-diagram/

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 37
(13) Composition structure diagram

What do the internals of a class, component, or other system part look like?
Top-down modeling of the system
• Shows the internal parts of a class.
• Parts are named: partName:partType[multiplicity]
• Aggregated classes are parts of a class but parts are not necessarily classes, a part is
any element that is used to make up the containing class
• Allow the users to "Peek Inside" an object to see exactly what it is composed of.
• The internal actions of a class, including the relationships of nested classes, can be
detailed.
• Objects are shown to be defined as a composition of other classified objects

https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-composite-structure-diagram/

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 38
Overview UML 2.5

https://www.uml-diagrams.org/uml-25-diagrams.html

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 39
2.1.2 Design (software design)

• Software architecture: Basic

components and their interaction
within a Softwaresystems (also with
UML).
• Structured design (SD) with SA (see
previous)
• Engineering: Object-Oriented
Design (OOD)
• Mock-up: "Software dummy",
demonstrator
• Process Analysis / Process Model:
How best to create? onlineclassnotes.com

• UML Diagrams
•
04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 40
 Creational Patterns

Creation patterns are used to create objects. They decouple the construction of an
object from its representation. Object creation is encapsulated and outsourced to keep
the context of object creation independent of the concrete implementation.
Structural Patterns
Facilitate the design of software with ready-made templates for relationships between
classes.
Behavioral Patterns
Model complex behavior of the software and thus increase the flexibility of the software
with regard to its behavior.
Pattern for object-relational mapping
Used to deposit and access objects and their relationships in a relational database (see
module IMV)
…
https://de.wikipedia.org/wiki/Entwurfsmuster

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 41
 2.1.3 Implementation
Programming Paradigms
https://www.youtube.com/watch?v
(1) Turingmaschine (by Alan =gtRLmL70TH0
Turing)
Alan Turing, 1912 - 1954 8:13
Minimal architecture of a
computer or software system,
defined by a set of axioms (i.e. a
programming language). Makes
statements about the solvability of
a problem by means of software
(whether and not how).
Turing completeness of a
language means that it is possible
to calculate any function that a
Turing machine can calculate.
According to Church-Turing's
thesis, this is synonymous with the
ability to calculate any computable
function.
(see Cryptography, INF II)

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 42
 Programming Paradigms

https://www.youtu
be.com/watch?v=
09:23 SbqXqQ-2ixs
(2) Von Neumann's
computer
architecture

The basic principles of

a computer are a
memory and a
processor. The
program flow is
organized step by step
(process-oriented
model of
programming).

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 43
 The von Neumann Architecture

The von Neumann architecture, first

described in the 1940s, has been the
mainstay of computing up until the
2000s. Data and programs are both
stored in the same address space of
a computer’s memory).

https://semiengineering.com/von-neumann-is-struggling/

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 44
 Programming Paradigms

(3) Plan calculus

In 1945 Konrad Zuse came up with his first ideas for a chess program. Four years earlier, the Berlin inventor
had built Z3, the world's first freely programmable, program-controlled calculator. In 1945 he completed his
programming language "Pankalkül". A program written with it should also master the game of chess.

Deutsches
Museum in Munich

Subtitles in
English!
5:11

https://www.y
outube.com/w
atch?v=aUXn
hVrT4CI

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 45
Programming Paradigms

(4) Functional paradigm

The basis is the idea of functions, they act on
values or again on functions. On this
principle combined with the principle of
the list, LISP (LISt-Processing) was
developed. Today, LISP is the basis for
many OO systems.
(5) Declarative (rule-oriented) paradigm
Chains of "If Then" rules are in the foreground.
Programs are based on mathematical
logic (predicate calculus) (e.g. PROLOG
(PROgramming in LOGig)).

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 46
Programming Paradigms

(6) Object-oriented paradigm

The basic ideas were developed during the sixties.

A precursor is SIMULA (a further development of ALGOL 60.

In the seventies, the SMALLTALK system was developed at the XEROX

Palo Alto Research Center as a prototype of a completely object-
oriented system.

At the beginning of the eighties, the language C++ was developed in the
AT&T Bell laboratories of Bjarne Stroustrup.

The first compilers for the PC and workstation sector have existed since
1988. Since 1995, JAVA has become popular via SUN and
Netscape.

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 47
Object-Oriented Programming, OOP (1)

Object
Definition of a data structure and the operations
allowed for it (class)

Instance
An area of the memory existing at runtime to Objekt
Private
which the definition of the object is applied Daten / Methoden

(see: real existing object and the concept of Öffentliche Methoden

the object). Botschaften Beziehungen

Method
Description of the functionality of the object, i.e. Objekte bestehend aus
Daten und zugehörigen Methoden
the behavior in certain cases. als informationstechnische Einheiten.

Objects consisting of data and associated

Public Methods methods as information technology units
Interface to the outside world (public).

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 48
OOP (2)

Internal methods
Support functions for supplying the interface (private).

Encapsulation
Bundling of data and permitted operations within an object.

Information protection
The internal structure of the object is not accessible to the user (the programmer) (private).

Message
Call a (public) method of an object.

Inheritance
Derivation of an object O2 from an object O1, where O2 takes over the data and methods
of O1 completely or partially. Inherited data and methods can be modified and extended.
In addition, own data and methods can be defined.

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 49
OOP (3)

Multiple inheritance
Derivation of an object O3 from an object O1 and an object O2, whereby O3
takes over the data and methods of O1 and O2 completely or partially.
Inherited data and methods can be modified and extended. In addition, own
data and methods can be defined.
Object Hierarchy
Network of relationships between the objects.
Polymorphism
Different objects react differently to the same message according to their
peculiarity.
Dynamic (late) binding
Assignment of the data and methods at the late possible time (cf. early
binding: assignment at the time of compilation).

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 50
E.g. for late binding in JAVA

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 51
 2.1.4 Testing
Verification – Validation (Software Testing)
Verification in computer science is a process that ensures that a program or system is
"compliant" with a specification ("Is the system built correctly?", "Is the specification
fulfilled?", rather from a development point of view).
In contrast to this is validation, i.e. the documented plausibility check that a system meets
the requirements in practice ("Does the system work correctly?", "Are the input-output
relations correct?" "Are the results correct?", rather from the point of view of the
application).
Formal verification includes a formal specification (for example, in the form of logic, a
specification language such as Z, or the input language of Matlab/Simulink), and a formal
understanding of what "compliant" should mean..
In extreme cases, a formal verification can be a mathematical proof that a program (i.e. a
concrete implementation) complies with the given specification. Conformity then means
validity in the logical sense, i.e. the program must behave as required by the specification
for all logically possible inputs.

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 52
Free of error !?

In special cases, proof of the correctness of a program is possible (i.e.

verification (implementation) and validation (application) have been
successfully passed).
Especially in areas where the use of software is associated with high financial,
economic or human risks, such as military or medical software or in
aerospace, certain methods are used with which the correctness of a software
(to meet a specification) can be proven formally-mathematically - >
verification.
However, these methods are subject to strict limits due to the enormous effort
and are therefore very difficult to implement with complex programs.
There are now tools that, according to their own statements, can provide this
proof quickly and reliably, at least for some areas (e.g. runtime errors) (-> see
further literature).

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 53
Mathematical verification

A formal mathematical verification is not possible in every case, see e.g.:

Hold problem (Does the execution of an algorithm come to an end?)
Gödel's incompleteness theorem (logic: e.g. this theorem proves that in sufficiently
strong systems (e.g. arithmetic) there must be statements that can neither be
formally proven nor refuted (“wiederlegt”)).
There are interactive or automated theorem provers (computer-aided proofs for
logical theorems (theorem, doctrine or part of a scientific theory) for relevant
problems in practice, see further literature).
Proofs for the formal verification of a software are kept with the help of special
calculations - such as the Hoare calculus (see next page).

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 54
The Hoare Calculus

 Charles Antony Richard Hoare, British computer

scientist
 Published in 1969 in "An axiomatic basis for
computer programming"
 Purpose: To make statements on the correctness
Tony Hoare (2011)
of imperative programs. Quelle: wikipedia.org

 Basic idea:
A program is correct with regard to its pre- and post-
condition if the post-condition applies to each
execution of the program to which the pre-condition
has also applied.

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 55
Module test (low-level test)

Testing of functional components (modules); Since algorithms at the module

level usually have only a limited complexity and are activated via clearly
defined interfaces, they can be largely fully tested with relatively few test
cases. This is a prerequisite for the subsequent test stage integration test
(see next slide) in order to be able to align the test cases with the integrated
interaction of larger functional parts or the entire application.

The module-specific detail constellations can thus be limited to random

samples, which drastically reduces the number of required test cases.
For comparison: A device is only tested as a whole when the functionality of
its individual parts is considered assured.

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 56
Integration test (Higher-Level-Test)

Integration test refers to a coordinated series of individual tests that

serve to test various interdependent components (module
combinations) of a complex system in interaction with each other. The
components to be tested for the first time in a common context have
each successfully passed the module test and are functional in isolation
without errors.

For each dependency between two components of a system, a test

scenario is defined, which is able to prove that both components
function according to specification after the merger, both components
for themselves and the data exchange via the common interface(s).

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 57
System test (high-level test)

Testing the entire system.

As a rule, software testing cannot provide proof that there are no errors (anymore).
It can only usually determine that certain test cases were successful.
Edsger W. Dijkstra: „Program testing can be used to show the presence of bugs, but
never show their absence!“

The reason for this is that all program functions and also all possible values in the
input data would have to be tested in all their combination – which is practically
impossible (except for very simple test objects). For this reason, various test
strategies and concepts deal with the question of how to achieve a large test
coverage with the lowest possible number of test cases.

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 58
Acceptance test

Acceptance Test or User Acceptance Test (UAT) is the testing of the

delivered software by the customer or client. The successful completion of
this test level is usually a prerequisite for the legally effective takeover of
the software and its payment. Under certain circumstances (e.g. for new
applications) this test can already be performed on the production
environment with copies of real data.

Especially for system and acceptance tests, the black box procedure is
used, i.e. the test is not based on the code of the software, but only on the
behavior of the software in specified situations/actions (inputs of the user,
limit values for data acquisition, etc.).

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 59
Verification according to ISO 9000

In addition to mathematical verification, there is

also a practical form, which is described by the
quality management standard ISO 9000. It only
detects an error if a requirement is not met.
Conversely, a work result (and thus also
software) can be described as error-free if it
demonstrably meets all requirements.

The fulfillment of a requirement is determined by

tests. If all tests give the expected result, a
requirement is met.

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 60
 Quality management == ONLY tests ?

Pol, Koomen, Spillner: „Tests are not the only measure in the quality management of
software development, but often the last possible one. The later errors are
discovered, the more time-consuming their correction is, from which the reverse
conclusion is derived: Quality must be implemented (throughout the course of the
project) and cannot be "tested"." .... "When testing in software development, a more
or less large number of errors than normal is usually assumed or accepted.
Here there is a considerable difference to the hardware industry: In the quality control
process phase, errors are often only expected in extreme situations."

-> Quantile: Probability of failure, i.e. the proportion (in %) of samples related to the total
number of samples in series production, for which the test results have smaller values
than the required minimum values.

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 61
Software Testing Life Cycle

1. Requirements Review
Every test should come from a requirement. And every
requirement should have a test.

2. Test Planning
Preparing a test plan will help you align testing efforts with
requirements.
What you’re going to test.
How you’ll test it.
Who will do the testing.

3. Test Cases
Once you have a test plan, you’ll need to create test cases.
A test case should detail how you’re going to test a
particular requirement. It should also include a step-by-step
process for running the test. Your test case may also
indicate what type of test you’ll be running (e.g., manual vs.
automated testing).
Test cases should also be prioritized, so you test the most
important things first. And individual test cases may be part
of a test suite.
https://www.perforce.com/blog/alm/what-software-testing

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 62
Software Testing Life Cycle (2)

4. Test Environment Setup

Your test environment determines the software and hardware
conditions that will be used for your test. This may include
conditions for real user simulation testing. Depending on your
team, this task may be done by developers or by testers. You can
even set up a test environment as you create test cases.

5. Test Runs
When your test environment is ready, you can start test execution.
Tests will either pass or fail. If a test fails, bugs found in the test
should be documented (and connected to the requirement that was
tested). You should run the test again — as changes are made to
your software — to verify that the bug has been fixed.
Creating a test matrix — or a requirements traceability matrix —
will help you keep track of the status of testing.

6. Test Reporting
You may need to report on test results to your team — or to other
stakeholders within your company.
Here are some common test reporting metrics:
Test velocity, Test status, Test results, Overall test summary
https://www.perforce.com/blog/alm/what-software-testing

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 63
2.1.5 Software Maintenance

IEEE 610.12-1990: "Modifying a software product after

delivery to fix bugs, improve performance or other
attributes, or make adjustments to the changed
environment."
Fundamental improvement of the usability and increase of
the operational reliability of software.
Types of maintenance:
Corrective: Elimination of errors
Perfecting: Remediation of technical debt through
reengineering; Increased performance https://geocaching
bw.de/blog/2015/0
3/23/needs-
Adaptive: Adaptation to changed technical conditions maintenance/

04.10.2024 | Lecture „Engineering Informatics I“ Chapter 02, Part 01 | Prof. Dr.-Ing. Uwe Rüppel | 64