Slides Ilearn

ADVANCED PROGRAMMING TECHNIQUES
Prof. Dr. Andreas Wölfl
Department of Applied Computer Science,

Deggendorf Institute of Technology
andreas.woelfl@th-deg.de
UNIFIED MODELING LANGUAGE
1. MOTIVATION
MOTIVATION
Essentially, all models are wrong, but some are useful.

(George Box, 1976)
Prof. Dr. Andreas Wölfl Advanced Programming Techniques 1

MOTIVATION
Model
A representation of a system using rules and concepts.
→ It provides an abstract view on what is important, devoid of unnecessary

detail, and help engineers to deal with the complexity of the problem.
Example Housing Prices:
price(size) = wo + w1 · size
• Linear relationship between price and size.

• Other variables such as area or year of construction are not considered.

MOTIVATION
Why do we model in software engineering?
• Understand requirements, actors, entities, relationships, dependencies, etc.

• View the same concepts from different perspectives.
• Simplify and isolate problems to develop a proper solution.
design
Start Architecture Program
→ Design the architecture first, implement the program second.

MOTIVATION
Unified Modeling Language (UML)

A modeling language that consists of an integrated set of diagrams to help
programmers to specify, visualize, and document artifacts of software systems.
Benefits:
• De-facto standard with a huge ecosystem.

• Supported by software tools to quickly draw diagrams.
• Code generation possible.

MOTIVATION
Diagram
Behaviour Structure
Diagram Diagram
Activity State Class Component Object

Diagram Machine Diagram Diagram Diagram
Diagram
Interaction Use Case Composite Deployment Package Profile

Diagram Diagram Structure Diagram Diagram Diagram
Diagram
Communication Interaction Sequence Timing

Diagram Overview Diagram Diagram Notation: UML
Diagram

2. USE CASE DIAGRAM

USE CASE DIAGRAM
UML Use Case Diagram

A visualization of possible interactions of a user with a system.
Example system Campus Management:
Campus Management
Query student data
Grant ETCS
Professor
Announce exam

USE CASE DIAGRAM
Actor
A basic UML element that represents a user that is interacting with a system.
Professor
• Actors interact with the system by using (or being used by) the use case.
• Represent roles that humans or non-humans (systems) adopt.
• Named by a noun.

USE CASE DIAGRAM
Use Case
A basic UML element that describes a unit of useful functionality performed by
the system.
Grant ETCS
• Derived from collected customer wishes

• Provides tangible benefit for one or more actors
• Named by a verb followed by a noun.

USE CASE DIAGRAM
System boundary
A rectangle to separate use cases that are internal to a system from the actors
that are external to the system.
Campus Management
Announce exam
• Optional visual aid in the diagram.

• Does not add semantic value to the model
• Bears the system name

USE CASE DIAGRAM
Association relationship
A solid line to visualize a connection between an actor and a use case.
Announce exam
Professor
• Every actor must communicate with at least one use case.

• An association is always binary.

USE CASE DIAGRAM
Include relationship
A dashed arrow described with <<includes>> indicating that the behavior of
one use case is integrated in the behavior of another use case.
Campus Management
Assign lecturer
«include»
Announce lecture
Professor
• Requires the behavior of the included class to offer its functionality.

USE CASE DIAGRAM
Extends relationship
A dashed arrow described with <<extends>> indicating that the behavior of one
use case is integrated in the behavior of another use case, but does not have to.
• Both use cases may also be executed independently.

• Extension points define at witch point the behavior is integrated
(represented in the form of notes).
• Conditions define under which circumstances the behavior is integrated
(represented in the form of notes).

USE CASE DIAGRAM
Campus Management
Extends relationship syntax: Announce exam
• Extension points and conditions are

Condition:
added in the form of notes. «extends»
{Data entered}
Extension point:
{Enter exam}
• In addition, extension points are
written directly within the use case. Announce lecture
extension points
• Specification of multiple extension Enter exam
Select lecture hall
Professor
points is possible.
Condition:
{Lecture hall free}
«extends»
Extension point:
{Select lecture hall}
Reserve lecture hall

USE CASE DIAGRAM
Inheritance relationship
A solid line with a triangle arrow head representing a parent-child relationship
between use cases or actors.
• The parent element generalizes the child element.

• The child element inherits the behavior of the parent element and may
either extend or overwrite it.
• The child element adopts the basic functionality of the parent element but
decides itself what part of the parent element is executed or changed.

USE CASE DIAGRAM
Example:
Campus Management
Announce event
Professor
«extends»
Announce exam Announce lecture

USE CASE DIAGRAM
Multiple actors may interact with the same use case:

→ Actors A and B execute the use case X together (i.e., both actors are required to
execute the use case).
A
X

USE CASE DIAGRAM
Multiple actors may interact with the same use case:

→ Actors A and B execute the use case X independently of each other.
{abstract} C
A B
Note: Elements declared as abstract cannot be instantiated.

USE CASE DIAGRAM
Exercise: Create a use case diagram for an ATM machine including at least:
• 3 Actors
• 5 Use cases
• 1 Generalization

USE CASE DIAGRAM
One possible solution:
ATM
Deposit money
Bank
Withdraw
Customer
Check balance
Register ATM at Bank
Administrator
Read log

3. CLASS DIAGRAM
CLASS DIAGRAM
UML Class Diagram

Visual representation of the structure of a system by showing the system’s
classes, attributes, operations, and the relationships among objects.
Example:
attends takes place

Student Lecture Auditorium
contains
Course

CLASS DIAGRAM
Class
A rectangle that describes an entity of a system, i.e. represents a set of objects
that share a common structure or behavior.
Course
name: string
semester: SemesterType
hours: float
getCredits(): integer
getLecturer(): Lecturer
getGPA(): float
setHours(hours: float) : void
• Consists of three parts: Name, attributes, methods.

• Attributes and methods are prefixed with access modifiers.

CLASS DIAGRAM
Access modifiers specify the visibility of attributes or methods:
Access Right public (⃝) private (□) protected (♢) package (△)
Member of the same class yes yes yes yes
Member of a derived class yes no yes yes
Member of any other class yes no no if in package

CLASS DIAGRAM
Granularity: It is legitimate to draw diagrams with lower levels of detail. It is up to

the software architect to choose the appropriate level of abstraction.
Course Course Course
name: string name

semester: SemesterType semester
hours: float hours
getCredits(): integer getCredits()

getLecturer(): Lecturer getLecturer()
getGPA(): float getGPA()
setHours(hours: float) : void

CLASS DIAGRAM
Association relationship
A solid line that depicts a semantic connection between two classes.
givesLecturesFor
Professor Student
• Represents a structural link between two classes.

• May have an association name (text in camel case).
• May have a reading direction (represented as arrow head).

CLASS DIAGRAM
Multiplicity
An indicator of how many objects may be associated with exactly one object of
the opposing side.
Professor Course
1..2 *
• Many: *
• n or more: 0..*, 1..*, 5..*
• Exact number: 0, 1, 5
• Exact range: 0..1, 0..5

CLASS DIAGRAM
Navigability
An indicator that specifies whether an object can access the visible attributes
and methods of objects on the opposing side.
Professor Student
• Navigability indicated by an open arrow head.

• Non-navigability indicated by a cross.
• If navigability is undefined, bidirectional navigability is assumed.
• If navigability is defined, declaring non-navigability is omitted.

CLASS DIAGRAM
Role
A label that describes the way in which an object is involved in an association
relationship.
Professor Student
+ lecturer
• Useful when the role of an object is not clear.

• If the role is undefined, a default role name equal to the related class name
is asumed.

CLASS DIAGRAM
xor constraint
A dashed line representing that An object of class A is to be associated with an
object of class B or an object of class C, but not with both.
Office LectureHall
1 1
{xor}
* *
Exam

CLASS DIAGRAM
Unary Association
An unary association relationship is when two partner objects from the same
class are involved in the relationship.
+examiner
examines
Person
+examinee
• Add roles and an assotiation name for better readability

CLASS DIAGRAM
n-ary Association
An n-ary association relationship is when more than two partner objects from
different classes are involved in the relationship.
Student Lecturer
0..* 0..1
+examiner
0..*
Exam
• One student takes one exam with one or no lecturer

• One exam with one lecturer is taken by many students
• One student is graded by one lecturer for many exams
CLASS DIAGRAM
Association Class
A class attached to an association to assign attributes and operations to the
relationship.
StudyProgram Student
* 1..*
Enrollment
startDate: Date
enroll()
drop()
• No duplicates allowed, i.e., one student can enroll in one particular study
program exactly once.

CLASS DIAGRAM
Aggregation
A form of association that expresses that a class is part of another class.
StudyProgram Course
1..* *
• Illustrated with an empty diamond-shaped arrow head.

• Constitutes a weak belonging of the parts to a whole.
• The parts may exist independently of the whole.
• One object can be part of multiple other objects simultaneously.

CLASS DIAGRAM
Composition
A form of association that expresses that a class is part of another class.
Building LectureHall
1 *
• Illustrated with a filled diamond-shaped arrow head.

• Represents a strong belonging of the parts to a whole.
• The parts are deleted when the whole is deleted.
• One object can be part of exactly one other object.

CLASS DIAGRAM
Generalization
A form of association that represents an is a relationship.
• The parent class is called superclass.

Person
• The child class are called subclass.
• The subclass inherits all attributes, methods, and
aggregations of the superclass (except privates).
Student Employee
• A subclass may have further characteristics.
• Generalizations are transitive.
Professor

CLASS DIAGRAM
Realization
A form of association that represents a relationship between an interface and a
class, where the class provides the implementation.
• Denoted as dashed generalization arrow.

Person
• An interface is a contract or specification for a set
of related methods that other classes implement.
Student Employee
Professor

CLASS DIAGRAM
Exercise: Create a UML class diagram representing the following scenario:
• A university consists of multiple faculties which are composed of various institutes. Each
faculty and each institute has a name. An address is known for each institute.
• Each faculty is led by a dean, who is an employee of the university.
• The total number of employees is known. Employees have a social security number, a name,
and an email address. There is a distinction between research and administrative personnel.
• Research associates are assigned to at least one institute. The field of study of each research
associate is known. Furthermore, research associates can be involved in projects for a certain
number of hours, and the name, starting date, and end date of the projects are known. Some
research associates hold courses. Then they are called lecturers.
• Courses have a unique number (ID), a name, and a weekly duration in hours.

CLASS DIAGRAM
Employee
le a d s Faculty
sosec_nr: integer
1 +dean 0..1
name: string name: string
email: string
Research Institute
Administrative Associate
Employee 1..* 1..* name: string
field_of_study: string address: string
1..*
Participation
Lecturer
hours: integer
1..*
teaches
1..* 0..*
Course Project
id: integer name: string

name: string start: date
hours: float end: date

4. SEQUENCE DIAGRAM
SEQUENCE DIAGRAM
Sequence Diagram
Visual representation of the interactions and message exchanges among
objects or components in a system or process.
Example:
:Application :Database
execute_query()
result_set
• Horizontal axis: Involved interaction partners

• Vertical axis: Chronological order of the interactions

SEQUENCE DIAGRAM
Lifeline
Representation of the existence of an object over a period of time.
• Head of the lifeline: Name of the object in the format roleName:Class.

• Body of the lifeline: Lifetime of the object.
lecturer :Professor lecturer:Professor

SEQUENCE DIAGRAM
Interaction
An arrow representing the exchange of a message between objects.
:Application :Database
query(statement)
result_set
process(result_set)
An activation box represents the period of time during which an object is active.

SEQUENCE DIAGRAM
Types of messages:
• Syncronous message
:A :B
• Sender waits until response received
• Syntax: msg(p1,p2,...) << synchronous >>
• Asyncronous message
:A :B
• Sender continues without waiting
• Syntax: msg(p1,p2,...) << asynchronous >>
• Response message
:A :B
• May be omitted if content and location are obvious
• Syntax: variable: "value" < < re s p o n s e > >

SEQUENCE DIAGRAM
Order of messages:1
:A :A :B :A :B
a a a
c b
c
c
On a single lifeline: On different lifelines: With interactions:

• T01: a → c • T01: a → c • T01: a → b → c
• T02: c → a
1
The operator ”→” stands for ”happens before”
SEQUENCE DIAGRAM
Combined Fragments
Logical groupings, represented by a rectangle, which contain structures
affecting the flow of messages.
• Used to model various control structures (if-then-else, loops, etc.).

• 12 predefined types of operators2 .
• Examples: alt, opt, loop, break
2
https://www.omg.org/spec/UML/2.5/PDF
SEQUENCE DIAGRAM
Alt Fragment
Combined fragment that represents a conditional branch.
:Person :ATM
withdraw(amount)
alt [balance >= amount]

handout cash
[else]
reject
• Equivalent to a switch or if-then-else statement in Java/C++.

• Guards (brackets) specify the conditions.

SEQUENCE DIAGRAM
Opt Fragment
Combined fragment that represents an optional branch.
• Equivalent to an if statement without the else branch.

• The guard specifies the condition.

SEQUENCE DIAGRAM
:Student :CampusManagement :Database
register(matrNr, exam)
enter(matrNr, exam)
status
alt [status == ok]

register: "ok"
[status == waiting list free]
register: "wl"
opt [register on WL == true]

enterWL(matrNr, exam)
enterWL: "ok"
register: "ok"
[else]
register: "error"

SEQUENCE DIAGRAM
Loop Fragment
Combined fragment that represents a repetitive loop or iteration.
• Equivalent to a for loop.

• The guard specifies how many times the loop is executed.
• The guard is defined the form (min,max) and/or a loop condition.
Note: The loop condition is only executed after the minimum number of loops.

SEQUENCE DIAGRAM
Break Fragment
Combined fragment that represents the premature termination of a loop or
iteration.
• Equivalent to a break statement.

• The guard specifies a condition. If it evaluates to true:
• Interactions within this combined fragment are executed.
• Remaining operations of the surrounding combined fragment are omitted.
• Interaction continues in the next higher level combined fragment.

SEQUENCE DIAGRAM
Example:
:Student :CampusManagement :Database
loop [(1,3) times,

invalid password]
login(user, pass)
check(user, pass)
break [invalid password]

error message
enter(matrNr, exam)

SEQUENCE DIAGRAM
Exercise: Create a UML sequence diagram representing a telephone call.
• A caller picks up the phone.

• A dial tone sounds.
• The caller enters the recipients phone number one by one.
• The phone rings the recipient.
• A ring notification sounds at the caller.
• After picking up the phone, the recipient answers with ”Hello”.

SEQUENCE DIAGRAM
caller:Person :Phone recipient:Person
picks up
dial tone
loop [number not fully dialed]

enter number
ring
ring notification
picks up
"Hello"
"Hello"

5. ACTIVITY DIAGRAM
ACTIVITY DIAGRAM
Activity Diagram
Visual representation of a workflow of stepwise activities and actions
supporting choices, iteration, and concurrency.
Enter login credentials
Show incorrect login screen
no
credentials correct?
yes
Show homescreen

ACTIVITY DIAGRAM
Action
A basic UML element to specify user-defined behavior.
Attend lecture
• Definition in natural language or in a programming language.

• Processes input values to produce output values.
• Actions are considered atomic (all or nothing), but can be aborted.

ACTIVITY DIAGRAM
Edges
A basic UML element to connect actions to one another.
Attend lecture
Write exam
• Edges are directed and express the execution order.

ACTIVITY DIAGRAM
Beginning and termination of activities:

• Initial node: Starts the execution of an activity.
• Activity final node: Ends all flows of an activity.
• Flow final node: Ends one execution path of an activity.
→ Multiple initial nodes can be used to model concurrency.

ACTIVITY DIAGRAM
Decision Node
Control node that represents a test condition to ensure that the flow only goes
down one path.
• Evaluates boolean expression.

• Similar to an if statement. Write exam Write exam
• Guards must be mutually exclusive.

[grade == 5] no
• Alternative verb syntax possible. [grade < 5]
passed?
yes
Get ETCS Get ETCS

ACTIVITY DIAGRAM
Merge Node
Control node that brings back together different decision paths that were
created by a decision node.
5
counter?
print 5 print not 5

ACTIVITY DIAGRAM
Fork Node
Control node that has one incoming edge
and multiple outgoing edges to split the Register
incoming flow into multiple concurrent

flows.
Attend lecture Complete assignment
Join Node
Control node that brings back together
Write exam
(and synchronizes) a set of concurrent
flows.

ACTIVITY DIAGRAM
Swimlane Professor Assistant Student

A structural element to delineate who does
what in an activity. Create exam
• Represents actors or organizational units. Print instructions
• Clarifies and organizes the

responsibilities of different actors.
Write exam
• Shows the interactions and Correct exam
communication between them.

Publish results

ACTIVITY DIAGRAM
Exercise: Create a UML activity diagram in context of an ATM machine:
• A person wants to always check the account first.

• Afterwards, a person decides to either perform a withdrawal or a deposit.
• A deposit updates the account balance.
• A withdrawal is first evaluated whether or not the person has sufficent funds.
• If a person does not have sufficient funds, the withdrawal is rejected.
• If a person does have sufficient funds, the cash is handed out and the balance is updated
afterwards.

ACTIVITY DIAGRAM
CheckAccount
Withdrawal Deposit
no yes
sufficientFunds
Reject HandoutCash
UpdateBalance

6. SUMMARY
SUMMARY
UML modeling tools:
• DrawIO3
• Eclipse Papyrus4
• PlantUML5
3
https://app.diagrams.net
4
https://www.eclipse.org/papyrus/
5
https://plantuml.com/
SUMMARY
Best practices:
• Use modeling as a tool to solve real problems.

• Do not use a model as an end in itself.
• Problems are often described best from an abstract view.
• Aim for simple solutions (KISS6 principle)
• Programmers tend to amend the notation for their own purpose.
• In practice, that is common practice.
• In the exam, stick to the notation as defined in the lecture.
6
Keep it simple, stupid!
SUMMARY
Summary
You should have accquired the following competencies:
• Understand why modeling in software engineering is important

• Use modeling as a tool to solve real problems
• Perform requirements engineering using UML use case diagrams
• Design and describe software architectures using UML class diagrams
• Describe the procedure of algorithms using UML activity diagrams.
• Specify time sensitive interactions between users and/or system
components using UML sequence diagrams.

Slides Ilearn

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Slides Ilearn

Uploaded by

Copyright:

Available Formats

ADVANCED PROGRAMMING TECHNIQUES

Prof. Dr. Andreas Wölfl

Department of Applied Computer Science,

Essentially, all models are wrong, but some are useful.

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 1

→ It provides an abstract view on what is important, devoid of unnecessary

Example Housing Prices:

• Linear relationship between price and size.

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 2

Why do we model in software engineering?

• Understand requirements, actors, entities, relationships, dependencies, etc.

Start Architecture Program

→ Design the architecture first, implement the program second.

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 3

Unified Modeling Language (UML)

• De-facto standard with a huge ecosystem.

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 4

Activity State Class Component Object

Interaction Use Case Composite Deployment Package Profile

Communication Interaction Sequence Timing

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 5

2. USE CASE DIAGRAM

UML Use Case Diagram

Example system Campus Management:

Query student data

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 6

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 7

• Derived from collected customer wishes

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 8

• Optional visual aid in the diagram.

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 9

• Every actor must communicate with at least one use case.

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 10

• Requires the behavior of the included class to offer its functionality.

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 11

• Both use cases may also be executed independently.

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 12

Extends relationship syntax: Announce exam

• Extension points and conditions are

Reserve lecture hall

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 13

• The parent element generalizes the child element.

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 14

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 15

Multiple actors may interact with the same use case:

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 16

Multiple actors may interact with the same use case:

Note: Elements declared as abstract cannot be instantiated.

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 18

One possible solution:

Register ATM at Bank

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 19

UML Class Diagram

attends takes place

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 20

• Consists of three parts: Name, attributes, methods.

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 21

Access modifiers specify the visibility of attributes or methods:

Prof. Dr. Andreas Wölfl Advanced Programming Techniques 22

Granularity: It is legitimate to draw diagrams with lower levels of detail. It is up to

Course Course Course

name: string name

getCredits(): integer getCredits()