SE Winter1415 All Merged

Systems Engineering
Prof.Dr. Thomas Baar

thomas.baar@htw-berlin.de
Winter 2014/15
Lect. 01: 2014-10-09 T.Baar: Systems Engineering Winter 2014/15, HTW Berlin 1
Organisational Remarks
Short CV of Thomas Baar
1990 – 97 Study of Computer Science at Humboldt-University,
Berlin, Germany
Areas of study:
 Programming
 Algorithms
 Software Engineering
 Artificial Intelligence
 Heuristics
1997 – 99 Doctorate candidate, HU Berlin
1999 – 03 Doctorate candidate, University of Karlsruhe, Germany
Areas of research:
 Quality-oriented software
development processes
 Verification of software wrt.
formal specification
 Specification languages and
their semantics
2003 – 07 Post-Doc, École Polytechnique Fédérale de Lausanne
(EPFL), Lausanne, Switzerland
- Areas of research:
 System development
 System specification
 System test
 System verification
2007 - 11 Senior Engineer, Software Consultant Company, Berlin
- Clients and areas of work

 Telecommunication industry
●
Team restructure, Process optimization, Tool change
 Postal Services
●
Web Portal Development - Planning, Requirements
Elicitation, Implementation, Integration with other
Systems, Evaluation with Customers
 Federal Office of Administration
●
Product Definition - Requirements Elicitation, Formal
System Specification
from 2011 Professor for Software Engineering,
HTW Berlin
Areas of work
 Teaching in Course Program 'Computer
Engineering' (Bachelor)
 Teaching in Course Program 'Systems
Engineering' (Master)
 Cooperations with Local Industy (Internet
Security Solutions, German Railways, Real
Estate Management, Engineering Services)
 Own Research (Configuration Management,
System Re-engineering, Model-Based
Software Engineering)
Who are you?
Format of Teaching
• Lecture
- Thursday, 8:45 - 10:15 a.m.
- Don't be late!
- Classic lecture but you can ask/interrupt at any time.
- Homework assignments at end of most lectures.
 To be solved individually.
• Excercises
- Thursday, 10:30 - 12:00 a.m.
- Don't be late!
- Solution of homework
- Work on bigger project
Moodle
• (not yet) available at
https://moodle.htw-berlin.de/
• central place to put all artefacts produced in
this course:
- my slides, homework assignments, etc.
- your homework solutions, project documentation
- further readings, links, etc.
- software (snippets)
Change in Schedule
• No Lecture/Excercise next week (October 16th)
- Reason: I will attend a conference in France.
- New date for this lecture: to be announced
Exam of this Course
• Form is not decided yet :-(
Lecture
Today's Topic
Systems Engineering -- Basic Terms
System Engineering is a discipline that proposes methods, approaches,
heuristics for solving problems, no matter of which type the problems
are. System Engineering has many overlaps with other disciplines, e.g.
Project Management, Systems Thinking, Design Thinking .
System Engineering stresses the need to first describe a problem
adequately, i.e. to uncover all persons, technical systems that are
involved in the problem or that might be affected by its solution.
Problem descriptions are often formulated using natural (informal)
language (such as English), but sometimes special notations are used.
These notations aims at showing the essence of the problem, i.e. to

reduce complexity of the problem description. Reduced complexity can
help to find simple and appropriate problem solutions.
What is a "Problem"?
Current Desired
Situation Situation
∆ (Delta)
• Current Situation
- at the beginning, usually not all information are available
- description is not independent from Desired Situation
• Desired Situation
- is to be formulated explicitely: final goal, constraints, variants
• ∆ (Delta) == PROBLEM
- is "difference" between Current and Desired Situation

- might trigger a project to bridge the gap (problem solving)
Problem Solving
Problem
Domain- Situation- Systems

Psychology Ethics
Knowledge Knowledge Engineering
Solution
Systems Engineering = System Thinking + Methodology
Note: Systems Engineering alone, however, does not solve any problem!
System Thinking
• Aims at
- structuring phenomena
- describe relations and dependencies between
identified entities
• Results in
- better understanding of the problem (Current +
Desired Situation)
- larger possibilities to change the situation
Methodology
• defines the steps to reach the project goals
- steps are comparable even across projects in
different domains
- aggregates single steps to manageable chunks
(phases)
- identifies roles of persons (stakeholders)
together with their responsibilities wrt. the
identified steps
Definition Systems Engineering
"Systems Engineering is an interdisciplinary approach and means to enable the
realization of successful systems. It focuses on defining customer needs and
required functionality early in the development cycle, documenting
requirements, then proceeding with design synthesis and system validation
while considering the complete problem:
Operations, Cost & Schedule, Performance, Training & Support, Test, Disposal,
Manufacturing
Systems Engineering integrates all the disciplines and specialty groups into a
team effort forming a structured development process that proceeds from
concept to production to operation. Systems Engineering considers both the
business and the technical needs of all customers with the goal of providing a
quality product that meets the user needs."
Source: International Council on Systems Engineering (INCOSE)
http://www.incose.org/practice/whatissystemseng.aspx
What is a System?
• consists of elements
• elements are interrelated
• all elements together are considered to form
one whole
Open System -
- elements have also relations to elements outside
the system
System Boundary
• separates elements
inside/outside the system Surrounding/Environment
• usually hard to define because

- elements inside the system
System
might have relations to
elements outside
- Note: relations inside the
system are considered to be Boundary
more important
System
Example Factory
• Elements
- Employee, Department, Organizational Rule, Machine,
Product, Material, Intermediate Product, Building
• Relations
- Material Flow, Information Flow, Supervisor
As Open System
• Elements
- Customer, Supplier, Regulations/Laws
Challenges of Project Management
• Project Management has ...
 "to translate complex requirements into working
systems"
 "to deal with fuzzy and shifting requirements "
 "to assess and manage risk"
 "to organize and manage teams"
 "to satisfy customers"
Systems Engineering

Winter 2014/15
Organisational Remarks
Exam of this Course
• Solving Homework-Assignments is strongly
recommendated
- Feedback will be given
- However, no grades
• Course exam is written test at the end of semester
- Proposal for date:
 last week in teaching period
 Thursday: Feb 12th 2015, 8:45 - 10:15 a.m.
Lecture
Today's Topic
Domain Modeling
Systems engineers and all other stakeholders of a project must
be able to understand each other, no matter what the
professional background of each person is. Stakeholders need a
common understanding of the basic terms within the problem
domain.
Domain modeling is a technique to represent the knowledge on a
certain problem domain. Unlike the glossary, which is held
informally using natural language, domain models are
formulated by using Class Diagrams.
Model
A model …
- is a simplified representation of (an abstraction from)
the real world
- should serve a well-defined purpose
- has an tremendous impact on how a problem is attacked
Modeling is a fundamental activity in all engineering disciplines
- Architecture (architect’s plan)
- Physics (Bohr’s atom model, different models of light)
- Chemistry (carbohydrate compounds)
Model
A model can explain some but not all phenomena
- Models have limitations
- If a model is too abstract we cannot deduce all
properties that are relevant
- If a model is too detailed we need extra effort to
distinguish the important from the less important facts
Model - Example
(a pictur of)
the real world
Source: http://www.htw-berlin.de/htw/standorte/campus-wilhelminenhof Oct. 2014

Model - Example
Model
Purpose ?

Model - Example
Model
Purpose ?
Model - Example
Model
Purpose ?
Systems consist
of Elements (aka. Objects)
• A system
- consists of elements
- elements might have relationships
- boundary of system not always clear cut
To characterize elements of systems more precisely, we will

regard them as objects. Objects are not only characterized
by relationships to others, but also by attributes and
behaviour(operations).
Object Modeling
Object Modeling means that the model is given as an ensemble of
objects.
- An object represents (or models) an individual, identifiable

item, unit, or entity, either real or conceptual, in the problem
domain. The object is an abstraction of the real-world entity
- Objects have attributes (aka. properties) whose values form
the state of the object
- Which properties of a real-world entity are modeled by an
attribute and which properties are ignored by the object
depends on the purpose of the object model
Objects -- Examples
The printer Talisker, of type Laserwriter, made by Canon, located in
room PBH2003...
Mr. Rich, business man, 42 years old, living in Zug, Switzerland,

married with Mrs. Dufour, ...
The bank account of Mr. Rich with La Banque du Crédit

International...
The student Sven Svenson has just arrived in Berlin, attends the
Systems Engineering course and is still looking for a flat ...
Objects: Identity and State
Identity is the property that distinguishes an object from all
others
- The identity of an object cannot be changed
- The name of an object should not be confused with its
identity
The state of an object is given by the values of its attributes
- It is always possible to distinguish two distinct objects,
even if they are in the same state
Attribute Values
A data(value) is a characteristic that can be measured, or it is
defined by agreement. A datavalue has no existence by its own, and
therefore no identity.
In domain modeling, the values of attributes should be always

datavalues and never objects. We often restrict the possible values
for an attribute by assigning the attribute to a datatype, i.e. a
representation of a set of values
The attributes of an object remain the same, but their values may
change. The pair <attribute, value> for an object is also called slot.
The attributes describe static properties of an object; they retrieve

or hold information about the state of the object. Attributes, whose
information is retrieved from the state, are called derived
attributes.
Pre-Defined Datatypes
It is handy to agree on name and values of certain data ranges, i.e. to
agree on pre-defined datatypes:
- Integer represents the infinite set of numbers …,-2,-1,0,1,2,…

 one can also use ranges of numbers, e.g. 1..4 represents the
values 1,2,3,4
- String represents all possible sequence of characters; a
concrete string is (usually) set in single or double quotes:
"Hello", 'I am a string, too'
- Boolean is the set true, false
Examples of Attributes
"The height of this building is twelve meters."
• this building is an object,
• it has the attribute height,
• which has the value twelve.
"A floor is added on the top of the building."

• the identity of the building remains the same,
• the building still has the attribute height,
• but its value is changed.
Enumerations as
User-Defined Datatypes
Sometimes, there is a need to agree on the name of (finitely many)
datavalues and to give the set of all these datavalues a name. Such
datatypes are called enumerations.
- typical examples of enumerations are

 set of (occurring) colors
 different status an object can have (e.g. a bill can be
prepared, signed, sent, rejected, paid, etc).
Stereo type
Examples of Attributes
"The color of the building is navy blue."
• the possible values for attribute color are subject of agreement
• What is the difference between blue and navy blue?
• Color could be different for outside / inside - Do we have only one
attribute color?
"The building was built in 1980."

• the attribute constructionYear has the value 1980
• the derived attribute age has the value 34.
Excercise
Identification of Objects and Attributes

• Identify objects with their attributes and values on the following
picture. How would you communicate what you have identified?
-Rathaus
Color=Red
Height(m)=35
-Tram 1
Color= Yellow
Size=20
-Tram 2
Color= Yellow
Size=30
-Tram 3
Color= Yellow
Size=15
Photograph
NumberOfTrams=3
Relationship (shown @)
Class
A class describes a set of objects that share the same attributes,
relationships, and operations. The members of the set are called
instances of the class
Each class declares the attributes which are common among all its
instances. The declaration of the attribute’s datatype is optional in
the domain model
Whereas a given set of objects can model only one situation (a

snapshot) of the real world, a set of classes can model many
situations (all, which are represented by an object set that is an
instantiation of the class set)
The classes of a Domain model are also called concepts

Graphical Representation of Objects :
Object Diagrams
Each Object-Diagram
• represents an ensemble of objects
- an object is represented by a rectangle with two (or more)

compartments
- an object is shown with its slots and its relationships to other
objects (called links)
Instantiated
class (aka
Object
type of object)
Anonymous
object identity
Object identity
Slot
(attributename = value)
Graphical Representation of Classes:
Class Diagrams
• A Class diagram shows the name and structure of classes (and thus the
structure of all their instances) together with possible relationsships
between instances of classes. The structure of a class is given by its set
of attributes (Note, that the value of an attribute belongs to a concrete
object, not the class! Thus, Class diagrams DO NOT show attribute
values!) and its set of operations.
Enumeration
Class Classname Literal

Attributename Attributetype
Combined Class and Object diagram
Excercise
Identification of Objects and Attributes
• Show for the above identified objects and their state a

graphical representation in form of class-/object-diagram.
(Binary) Associations
A (binary) association between (two) classes denotes a relationship that can hold
between the instances of these classes.
- The occurrence of the association between two concrete objects is

indicated by a link in the Object diagram. We also say that the relationship
holds for these two objects.
- For each association there is at most one link between two given objects.
The identity of the link stems from the identity of the connected objects.
Multiplicity Association name
Read direction arrow
Association Role name
(Binary) Associations
Link
Association – Optional Adorments
Class1 role1 Asso > role2 Class 2
Mult 1 Mult 2
• Association name
- describes the Relationship between objects of connected classes
- 'Reading direction arrow' is often not shown
• Role name
- Characterize the Role an object plays wrt. to the opposite object
- Default-Wert ist If no role is shown, the default role is the 'lowercased'
class name at this association end (PrinterMng --> printerMng; only first
letter is made lowercase)
Association – Optional Adorments
Class1 role1 Asso > role2 Class 2
Mult 1 Mult 2
Multiplicity
Each object of Class1 is connected with mult2-many objects of Class
- Is given as a range
 0..1 - zero or one
 1,4,7 - exactly one, exactly four, or exactly seven
 1..10 - one to ten
 1..* - one or more
 0..* - zeor or more
 * - abbreviation for 0..*
 if no multiplicity is given, 0..* is assumed as a default value

Assoziation - Examples
Class-Diagram: Example
Class-Diagram: Example
Homework
Finding Attributes
• Find appropriate attributes:

- A person who might receive a letter
- A person suspected in a criminal case
- A person having a bank account
- The person the phone bill is sent to
- An employee of a company using a security access
Homework
Domain Model
• Draw the Domain Model for the following classes and

associations:
- A person can work for one or several companies
- A car is owned by a person, a bank, or a company
- Banks give loans to persons for buying cars
Systems Engineering

Winter 2014/15
Today's Topic
Advanced Class Diagrams
So far, we have used for Domain Modeling only basic constructs
of Class Diagrams. Although this fragment of Class Diagrams is
already quite expressive and can model many phenomena, there
are further constructs to be used. Examples for such
constructs are Packages, Generalization and Composition.
Packages - Structuring Class Models
Problem: Class Diagrams can become very large when they model real
systems
- It might become hard to keep an overview

- Danger: when creating a new class, an already existing class name
might be chosen for the new class
 would contradict rule that class names have to be unique
Solution: Distribute all classes across different packages. You can
think of a package as being a folder to place classes.
- Packages have the following properties. They ..

 can contain classes
 can contain other packages (i.e. packages are nested)
 create a namespace: Inside a package, each item (class/package)
must have a unique name
The (full/qualified) name of a class/package is the concatenation of

the full name of the parent package, a delimiter (e.g. "::") and the
(normal/simple) name of the class/package.
Package
Classes within Package Nested Package
Full name: event

Full name: event::Contract
Full name: location::company::Contract
Generalization
Generalization is a binary relationship between classes.
Semantically, this indicates that all instances/objects of the
subclass have also all attributes/operations of the superclass.
The relationship is indicated by a connecting line with a triangle
at the superclass' line-end.
Generalization Superclass
Generalization
Subclass
Semantics of Generalization
Generalizations express a IS-A-relationsship for the objects of two
connected classes.
TO BE READ AS: Each

CashPayment/CardPayme
nt/CheckPayment-object
is also a Payment-object
As
Payment Venn-Diagram
Cash- Card- Check-
Payment Payment Payment
Excercise
Propose Generalization-Relationsships for

the following Concepts
1) Person - Student - Teacher - ForeignStudent
2) Company - Bank - Manager - Employee - TaxPayer
Which attributes would be useful for each of these

concepts?
Abstract Classes
One can declare a class to be abstract.
Semantics/Meaning: Class has no direct instance
Notation: Set the classname in italic or add stereotype <<abstract>>
Payment
Cash- Card- Check-

Payment Payment Payment
Keep Object Type Static!
The type of an object is that class from the class diagram, which the
object is an instance of. Class hierarchies should be modeled in such a
way, that there is no need to change type of an object during the
object's lifecycle.
poor better
Composition
Composition is a stronger form of an association (binary
relationship). It is used to indicate a Container-Element- (or
Whole-Part)-relationship between instances of the connected
classes. A composition is marked by a filled diamond at the
Container-end of the connecting line.
Composition - Example
"A company consists of

divisions and exactly one
management board (the top
management). During the
lifecycle of a company,
divisions might be added or
closed, but the management
board will remain the same. A
division consists of multiple
working groups (at least one)
and a management board."
Composition -- Examples
"A company consists of units (at least one). A unit can either be
atomic or it can consists of other units (which are subunits). An
atomic unit is also called ProjectTeam. "
The XOR-constraint is not necessary

here because it is imposed by the two
compositions
(a Unit-object must have exactly one
parent, either a Company-o r a
ComposedUnit-object)
Constraints for Associations
Multiplicities at association ends constrain the number of links an object can
participate in. Sometimes, however, multiplicities are not expressive enough. In this
cases, one can add further constraints in form of notes.
Syntax: Constraint is formulated a semi-formal text, which is enclosed by curly braces
All constraints are satisfied

Constraint as Note
Constraint for p1-headOf-d1

is broken
Constraints for Associations
All Constraints are satisfied
Constraint for c1 and c2

is broken
Derived Associations
• Derived Associations are (as derived attributes) redundant, but
they can improve clearness of a class model
- derived associations are marked with a starting "/"
- a note clarifies how links of derived assocation can be computed
from the current state
Reification
Reification means to model a relationship between objects of two classes
in terms of an additional class. This technique allows to substitute in a
class model an association by a class.
New
Class
Error (not allowed)

allowed
Excercise
(Meta-)Modeling Packages and Classes
When class diagrams are used to describe the structure of

a language, we use the term metamodeling.
You should create a class diagram that expresses the usage

of packages (see the beginning of this lecture) and the
relationship between packages to packages/classes (e.g. a
package contains other packages or classes; the qualified
name for a class/package is computed based on the
container package).
Homework
Find Classes, Associations, Attributes

Create a domain model of the 1. Bundesliga (German Soccer League).
Model things like players, teams, matches, stadiums, results, current
leage table, etc. Get an inspiration from the web portal
www.spiegel.de > Sport > Fussball Liveticker
Homework
Graph / Multigraph
Create a Domain Model for ...
• ... Graphs. A Graph consists of nodes and directed
edges. Each edge connects exactly two nodes. Any two
nodes are connected by at most one edge (for each
direction).
• ... Multigraphs. A Multigraph is a graph, where any tow
nodes can be connected by an arbitrary number of
edges. Furthermore, edges within a multigraph have a
length.
Systems Engineering

Winter 2014/15
Today's Topic
Metamodeling
So far, we have used Domain Modeling for describing facts and
phenomena from different problem domains (sports, university
adminstration, business structure).
Domain Modeling can also be applied to describe the structure of a

language. In this case we prefer the term Metamodeling over (the
less specific) term Domain Modeling. The described languages can
either natural languages (e.g. English, German) or textual technical
languages (e.g. programming languages like C, C++, Java) or graphical
technical languages (e.g., SysML, UML).
A metamodel uncovers the internal structure of a language and can

be of much help when learning a language. Metamodeling became
popular in the 1990ies. Before, the structure of languages was
described by grammars.
Example: English
Suppose, you had to decide, whether the following sentences
are syntactically correct. How would you do this?
1)I read a book.
2)Tom needs some money.
3)He reads these books.
4)Cats need dogs.
5)This boy wants this girl.
6)These dogs want those cats.
7)This dog want this cat.
Structure of English Sentences
Subject Predicate
noun phrase noun phrase
noun verb article noun
1) I read a book.
Subject Predicate
2) Tom needs some money.
3rd Person
Subject Predicate
3) He reads these book.

s
3rd Person Plural
Subject Predicate
article noun verb article noun
6) These dogs want those cats.
Plural Plural
Subject Predicate
7) This dog want this cat.
Inconsistency with 3rd Person
Excercise
English Grammar Rules

Sufficient to Explain Given Examples
1) A sentence consists of a subject and a predicate.
2)A subject is noun phrase.
3)The predicate consists of a verb and optionally a noun
phrase
4) If the noun within the subject is a 3rd-Person-noun,
then the verb within the predicate ends with an 's'
5)A noun phrase consists of an optional article and a noun.
The article and noun must be either both singular or
both plural.
•
Excercise
Create Metamodel for English

Formalize the above rules for the English language in form
of a Domain Model (class model)
Object Model for Parsed
Sentence (Metamodel-Instance)
Object Model for Parsed
Sentence (Metamodel-Instance)
Metamodeling the Syntax of
Class Diagrams
• When metamodeling the syntax of Modeling Languages
(such as Class Diagram) we
- uncover the inner structure of the Modeling Language
- abstract from graphical representations of language
constructs, e.g.
 that a class is represented by an rectangle
 that the class name is put in the first compartment of the
rectangle and the class' attributes in the second
 that multiplicities are placed near the association ends
 ...
Syntax of Class Diagrams Enumeration
Class Classname Literal

Attributename Attributetype

(Simplified) Metamodel for Class Diagrams
*
x
Representing a Class Diagram as MM-Instance
Excercise
Representing a Class Diagram as MM-Instance
Excerpt from Offical Metamodel for Class Diagrams(UML 1.4)
Excerpt from Offical Metamodel for Class Diagrams(UML 1.4)
Syntax of Object Diagrams
Instantiated
class (aka
Object
type of object)
Anonymous
object identity
Object identity
Slot
(attributename = value)
Excercise
Metamodel of Object Diagram

Create a (simplified) metamodel for Object Diagrams.
Homework
Metamodel of Floor Plan

Create a metamodel for Floor Plan Diagrams.
Systems Engineering

Winter 2014/15
Today's Topic
State-Diagrams
Problem: Systems interact with their environment by (1) consuming input
signals (e.g. press a button) and by (2) generating output signals (e.g. switch
on a light). The mapping INPUT -> OUTPUT is in most cases not a static
function ( f(i) = o ). Rather, the generated output depends not only on the
input but also on the current state of the system. Unfortunately, neither
pure mathematical concepts (like sets, functions) nor pure informal
descriptions in natural language are appropriate to describe this input-
output-relationship.
Lösung: Statediagrams offer useful concepts (Event, State, Transition, ...),

in order to describe the Input-/Output-Behaviour of systems in a compact
but precise way.
Literature
• Martin Fowler: UML Distilled.
History of State-Diagrams
• In Computer Science, the state automaton is a very old and proven
concept
- By consuming an input signal, the automaton can switch to a new state
 state change can cause an output signal
• David Harel, Professor at Weizman Institute (Israel) has added in the
80ies many useful concepts to classic state automata and called the
resulting formalism State Charts . The added concepts are:
- Hierarchical States
- Concurrent States
- Conditions for State Transitions
- (History States)
• State Diagrams are heavily influenced by State Charts
Example Digital Watch–
Informal Description
• 2 Modes
- Display the current time
- Set the watch
 Done via
●
Press Button 1: choose which of
the time's constituents (hour,
minute, second) is set
●
Press Button 2: Increase the
value of the selected
constituent by 1
Model 1
Transition
Initial State Aktion
State
Event
Model 1
• States:
- "Time Displayed", "Adjust Hours", "Adjust
Minutes","Adjust Seconds"
• Events:
- "pressBtn1", "pressBtn1"
• Actions:
- none (only explicit state changes)
• State Variables
- "hours", "minutes", "seconds"
Model 2
More Detailed than

Model 1
Model 1 2
• States:
- "Time Displayed", "Adjust Hours", "Adjust Minutes","Adjust
Seconds"
• Events:
- "pressBtn1", "pressBtn1"
• Actions:
- none (only explicit state changes)
• State Variables
- "hours", "minutes", "seconds"
- "flashingH", "flashingM", "flashingS"
Model 3
Same Behaviour as Model 2

but with entry/exit actions
Example ParkingTicketMachine
Guard
Same event at
transitions starting
in same state
Syntax of State Diagrams
Final State
State
• Always finite number of states
• Represents abstraction for different behaviour of the system
wrt. input signals
• During system execution, there is always one "active" state
• Initial State
- Represents start of the system
- No (!) incoming transitions
- Outgoing transitions always without event
• Finale State
- Represents end of system execution
- No outgoing transitions
Event
Event Types:
- Receiving of a message (e.g. button pressed, card
inserted)
- Time event
 after(4Sec)
- Entry/exit – Events for entering/leaving a state
Transition
• State change from Pre-State to Post-State
• Transition "fires" if
- Pre-State of transition is active state of system
- und Annotated Event occurred
- und Annotated Condition (Guard) holds in active state
• Fired Transition causes
- change of active system state Pre-State -> Post-State
- execution of annotated actions
Action
• Represents observable behaviour
- Sending a message to the environment
- Updating system variables
• Triggered by transition execution
Simulation of Entry-/Exit-Actions
both are equivalent
SU XX: XX.XX.14 T.Baar: Systems Engineering XXXX, HTW Berlin 17

Excercise
States of a Door
• Please formalize the following informal statements in form of a
State-Diagram:
- One can open and close the door

- One can lock and unlock the door
- A door can only be locked when it is closed
- A locked door cannot be opened
initially the door is open
Homework
Theater Tickets
State-Diagram:
- A Ticket is always sold as a single ticket. There is a fixed number

of tickets available.
- Tickets for the theater can be bought in advance or at the
evening box-office.
- Only tickets bought in advance can be given back. They have to
be given back before the evening box-office opens.
- There is a fixed number of tickets that can be sold in advanced
(this number is less than the number of available tickets).
-
SU XX: XX.XX.14 T.Baar: Systems Engineering XXXX, HTW Berlin 19

Homework
Theater Tickets
State-Diagram:
- A Ticket is always sold as a single ticket. There is a fixed number

of tickets available.
- Tickets for the theater can be bought in advance or at the
evening box-office.
- Only tickets bought in advance can be given back. They have to
be given back before the evening box-office opens.
- There is a fixed number of tickets that can be sold in advanced
(this number is less than the number of available tickets).
Create a MM of State Diagram- HMWK II
Systems Engineering

Winter 2014/15
Hierarchical State
Hierarchical States contain other states, which react on
(some) events the same way. Hierarchical States can be of
great help to simplify State-Diagrams.
Hierarchical states can be used as start- and end-points of transitions.

These transitions can be read as abbreviations for transitions from/to the
contained sub-states. More precisely:
• An incoming transition
- Abbreviation for transition to that sub-state, which is an initial state
• An outgoing transition
- Abbreviation for all transitions from all sub-states (except initial and final
states) to end-state of transition
Hierarchical State
Hierarchical State
is equivalent to
Game with Markers
Which state is reached after input sequence of events?
• In which state are both systems after ...

- ade ; ahb ; aacf ; aaddeech
Excercise
States of a Door
• Please formalize the following informal statements in form of a State-Diagram:
- Initially, the door is open
• Solve this problem using a state diagram, which has a Hierarchical State.
Using State-Diagrams to Control (the State of)
Other Objects
So far, we encoded the whole system as a State-Diagram (including variables to
store some values). Let's point out input (events), output (actions) and internal
variables:
Events
Variables
(here shown
as attributes)
Operations show
on which events
an object can react
Using State-Diagrams to Control (the State of)
Other Objects
Actions
Using State-Diagrams to Control
(the State of) Other Objects
The outgoing actions were without any effect, so far. However, the
outgoing actions can be the input event for another system.
Please identify input (events), output (actions) and internal variables:
Connecting Controller with Controlled-Object
Homework
Theater Tickets
• Change the solution for the homework 'Theater Tickets' in such a
way, that also Hierarchical States are used in a meaningful way. Do
you think that the new model is now more readable?
Systems Engineering

Winter 2014/15
Determinism vs. Non-Determinism
Deterministic vs. Non-Deterministic
State-Diagrams
Deterministic
- Whenever an event occurs and multiple transitions could fire, the
machine can decide which transition to take
- Structural Criterion: Outgoing transitions annotated with the same
event do have disjunct guards
- Normally, one is interested in deterministic State-Diagrams
Non-Deterministic
- There is at least one combination of state and event, so that
multiple post-states are possible.
Non-deterministic State-Diagrams indicate a very high

level of modeling abstraction.
Example Non-Determinism
Non-Determinism:
On occurence of 'b', there
is no unique post state
Resolving Non-Determinism --
1) Explicit Guards
Resolving Indeterminism:
Guard is added with disjunct
conditions
Resolving Non-Determinism --
2) Refinement of State
Resolving Non-Determinism:
Pre-State is refined by
Hierarchical State
Excercise
Online Banking Account:

State-Diagram:
Before the bank client can use an online banking account, the bank
has to unlock his account. After this, the bank client can login in
order to use all the features of the account. However, after the
client provides three times a wrong password when making the
attempt to login, the bank locks the account. In this case, the bank
client has to go and see bank employees in order to ask to unlock
the account again.
After successful login, the bank client can use the features 'Display
Account's Balance' and 'Money Transfer' as often as he wishes. If
the client does not make any input for 10 minutes, the client is
logged out automatically. He can also log out by himself at any time
he wishes.
Choice - Construct
When there are multiple outgoing transitions from a pre-state with the
same event, then there must be excluding(disjunct) guards annotated to
the transitions to make the State-Diagram deterministic.
The Choice-Construct is a shorthand notation for this case. It can have

one outgoing transition without any guard - this is taken as default when
all guards on the other outgoing transition are evaluated to false.
Excluding (disjunct) guards
make state-diagram deterministic
Choice Construct
Default Outgoing
Transition
Parallel Composition
• Parallel Composition is the besides Hierarchical States the 2nd
form of state composition
• A Parallel (Composed) State consists of so-called Regions.
- Semantics: When the Parallel State is entered (i.e. when it

becomes the active state), all regions of it are activated in
parallel. Each region can consume events independently from
other regions. When the same event triggers multiple
transitions in multiple regions, then all these transitions are
fired simultaneously.
Parallel State
Incoming transitions of the

Parallel State activate start
state of each region
Each region changes its active

state when an event for a
"waiting" transition occurs and
the transition's guard is true
Region
When outgoing transitions fire,

then all regions are deactivated
Outgoing Transition
Often, one wants to model that

the Parallel State is left
whenever all its subregions
reach their final state.
Unfortunately, Yakindu does not
support final states (with the
usual semantics) within regions.
However, one can use a
Synchronization Bar to achieve
exactly the behaviour described
above. The event 'always' is
predefined in Yakindu and means
to fire the annotated transition
Synchronization Bar whenever possible.
Example Parallel Composition
Excercise
States of a Door and Window

State-Diagram:

- One can open and close the window
- Initially, the door and the window are open
Systems Engineering

Winter 2014/15
Today's Topic
Formal Grammars
In the past, we have seen metamodeling mainly as a technique to describe
the structure of technical languages, such as Class Diagrams or State
Diagrams. Often, these languages have a graphical syntax.
However, as the example of the metamodel for the English language has
shown us, metamodeling can also be applied for textual languages.
Traditionally, the internal structure of textual languages is specified by

formal grammars, or grammars for short. In this lecture, we will learn about
the main features of grammars, how to define them, and how grammars can
be applied to define textual languages.
There is a close relationship between grammars and metamodels and we will

discuss the link between both. Technical languages, which usually have a
graphical syntax (such as Class Diagrams), can usually also be defined with a
textual syntax using a grammar.
Literature
• XText Documentation:
http://help.eclipse.org/luna/index.jsp
?topic=%2Forg.eclipse.xtext.doc
%2Fcontents%2F020-domainmodel-step-by-
step.html
EBNF - The Traditional Form to
define Formal Grammars
• EBNF - Extended Backus-Naur-Form
- formalism to specify formal grammars
• Became fundamentally important in Computer Science
(CS), because CS deals with many textual technical
languages, e.g.
- programming languages such as FORTRAN, PASCAL, C++,
Java, ...
- input languages, e.g. in Excel
 Example: compute the content of a cell (e.g.
= SUM(A19, A22))
EBNF - Extended Backus-Naur-Form
• John W. Backus (1924 – 2007)
- US Computer Pioneer
- Head of IBM's development team for
FORTRAN
 Developed FORTRAN-Compiler
1954 – 57
 Invented the Backus-Form to define Source: Wikipedia
structure (syntax) of FORTRAN

- Turing-Award in 1977
• Peter Naur (1928 - )
- Danish Computer Science Pioneer

- Worked on programming language Algo-60
and refined the Backus-Form for syntax
definition to what we know today as
Backus-Naur-Form (BNF)
- Turing-Award 2005
Source: Wikipedia
• is formalism to define a grammar
- Grammar defines the syntax of textual languages
- Grammar is the basis to decide, whether a given text (e.g.
"Cats need dogs.") is a syntactically correct sentence of the
language. The process of checking the correctness is called
parsing.
• Grammar consists of
- Set of (Deriviation)Rules: LHS : RHS
 LHS/RHS – Left-Hand Side/Right-Hand Side
 LHS is a Non-Terminal Symbol
 RHS is made of Non-Terminal and Terminal Symbols
Non-Terminal Symbol EBNF – Example Terminal Symbol
digit : "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
num : digit + Operators, e.g. | * +
char : "a"|"b"|...|"z"|"A"|"B"|...|"Z"
name : char (char | digit)*
factor : num |name
term : factor mulop factor

Derivation rule of form
LHS : RHS
exp : term addop term
mulop : "*" | "/"
addop : "+" | "-"
Start-Symbol is exp
EBNF
• Terminal Symbol – such as "CREATE", "a", "4"
- Atomic part of a sentence
- Quotes (" or ') are used in the language to mark a symbol as terminal symbol
• Non-Terminal Symbol – such as name
- Occurs always as LHS in ONE rule
- Represents a part of a text, which has a structure according to the RHS of the
rule
• (Derivation)Rule – digit : "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
- Meaning: LHS can be substituted by RSH

• Startsymbol – exp
- one Non-Terminal Symbol to start the deriviation when parsing a concrete

sentence
EBNF - Operators
• Sequence X Y
- Meaning: Representation of (Non-Terminal or
Terminal Symbol) Y follows directly after
representation of X
 The representations of X and Y are separated by a
whitespace-character (' ' or tabulator or new line)
Example: A : "x" "y" "z"

 Possible derivation: x y z
EBNF - Operators
• Alternative X | Y
- Meaning: Either (represention of) X or
(representation) of Y
Example: A : "0" | "1" | "2"

 Possible Derivations: 0 or 1 or 2
EBNF - Operators
• (mandatory) Repetition X +
- Meaning: (presentation of) X repeated as many
times as necessary, but at least once
 Remark: (Some) Dialects of EBNF use curly braces
{ X } instead of X +
Example: A : "1"+
 Possible Derivations are 1 or 11 or 111 or ...
EBNF - Operators
• (non-mandatory) Repetition X *
- Meaning: (presentation of) X repeated as many
times as necessary; represent perhaps also
empty input
Example: A : "1"*
 Possible Derivations are (empty) or 1 or 11 or 111 or
...
EBNF - Operators
• Optional Occurrence X ?
- Meaning: empty input or (representation of) X
once
 Remark: (Some) Dialects of EBNF use square brackets
( [ X ] ) instead of X ?
Example: A : "x" "y"? "z"

 Possible Derivation: xyz or xz
EBNF - Operators
• Grouping ( X Y )
- Meaning: Groups the enclosed part (here symbols
X, Y) together; Operators put on () apply to what
is enclosed
Example: A : "x" ( "y" | "a")* "z"

 Possible Derivations: xz or xyz or xaz or xyya or xyaz
or xayz or xaaz or ...
Definining Grammars with XText
XText
• Open-Source Eclipse-Plugin
- Installation:
 Download installation package (Full Eclipse) from
https://eclipse.org/Xtext/download.html
 Create a new folder on your machine
 Unzip the downloaded file into this folder
• same authors as Yakindu-Plugin (we used for
drawing state diagrams)
Usage of XText
• Create an XText-Project ( File > New > Other ... > XText
> Xtext Project )
- Provide Project- and Language-Name

- Extension: File-Extension of those files, that should later be parsed
by this grammar
• Edit the grammar (file with extension .xtext)
- this file is automatically opened; a toy grammar is presented as
example
 Right-click in .xtext-editor and choose Run As >
Generate XText Artifacts to generate the so-called
language infrastructure (editors, parsers, etc.)
!!!Attention!!! If a red question in the console shows up, press 'y' and
enter!
•
Usage of XText
• Right-click in the Project Explorer on that project, in which
the .xtext-file is located and press Run As > Eclipse
Application
- This will start another Eclipse
• (In the New Eclipse) Create a project via File > New >
Project > General > Project
- Provide Project-Name
• (In the New Eclipse) Create a file in the newly created project by
right-click on the project and by choosing New > File
- the file-name should have the same file-extension as the one you
defined when defining the grammar (for the toy language: .mydsl)
 During opening this file, you should get a dialog asking whether your project
should use the NATURE you defined by the grammar
Grammar Constructs in XText
Lexical Elements:
- '0'..'9' (range) - any character within the range
- . (dot) - any character
- '/*' -> '*/' (until) - all characters until the following
char sequence (aka token, here '*/') occurs
- '#'(!'#')* '#' (negation) - all characters that are
different (here from '#')
- EOF (end of file) - the token representing a file end
(cannot be negated)
• Parsing rules
- always finished by a semicolon (;)
- variables to store subexpression of RHS
 State : 'state' name=ID 'end'
●
what has be represented by ID is stored in variable name
– any variable name can be used
– variable name has a special meaning
 assignment operators for variables: +=, ?=, =
Parsing rules
- CrossReferences
 refer to other elements in the sentence
●
referred element seems to be a rule, but is actually a type (which
coincide in many cases with the rule)
 marked by '[' ']'

Transition: event=[Event] '=>' state=[State]
Example English Language
Example: English
Suppose, you had to decide, whether the following sentences
are syntactically correct. How would you do this?
1)I read a book.
2)Tom needs some money.
3)He reads these books.
4)Cats need dogs.
5)This boy wants this girl.
6)These dogs want those cats.
7)This dog want this cat.
Subject Predicate
1) I read a book.
Subject Predicate
2) Tom needs some money.
3rd Person
Subject Predicate
3) He reads these books.
3rd Person Plural
Subject Predicate
6) These dogs want those cats.
Plural Plural
Subject Predicate
7) This dog want this cat.
Inconsistency with 3rd Person
Excercise
English Grammar Rules

Sufficient to Explain Given Examples
phrase
both plural.
Excercise
Simplified English Grammar Rules

phrase
both plural.
Excercise
Grammar for English

• Formalize the above Simplied Rules (non-
gray) in form of grammar rules.
Metamodeling and Grammar
Grammars can be mapped (at least partially) to metamodels. If we know the
metamodel of a language, it is often straightforward to define a
corresponding grammar.
digit : "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
num : digit +
char : "a"|"b"|...|"z"|"A"|"B"|...|"Z"
name : char (char | digit)*
factor : num |name
term : factor mulop factor
exp : term addop term
mulop : "*" | "/"
addop : "+" | "-"
Homework
Metamodel vs. Grammar for English
• Which metamodel would correspond to the

above grammar of English?
Homework
Metamodel vs. Grammar for Class Diagram
• Define a grammar that reflects the following

metamodel for class diagrams:
Homework
Metamodel vs. Grammar for State Diagram

• Define a grammar that reflects the following
metamodel for state diagrams:
Systems Engineering

Winter 2014/15
Lecture
Today's Topic
Use Case Model
Problem: At the very beginning of a project, the customer has
only a rough idea what the system under development (SuD) is
supposed to do and who will use the system.
Use Case (UC) modeling is a technique to express the desired
behavior (i.e. functional requirements for SuD) in a structured
way. After the UC model has been developed, both customer
and system developer have a clear and common(!) idea on the
purpose, possible users, and desired behavior of the SuD.
Literature
Ivar Jacobson:
Use cases - Yesterday, today, and tomorrow; In Journal on
Software and Systems Modeling, 3:210-220, 2004.
• Interesting notes on the history of use cases
Alistair Cockburn:
Writing Effective Use Cases; Addison-Wesley, 2001.
• Most influential book on the art to formulate use cases
Kurt Bittner, Ian Spence:

Use Case Modeling; Addison-Wesley, 2003.
Many real-world examples
Introductory Example
Money Machine (aka Automated Teller Machine (ATM))
How can the functionality of this

system be specified?
Introductory Example
Money Machine (aka Automated Teller Machine (ATM))
Use Case Model - Diagrammatic Part
Subject
Subject Boundary (system, subsystem)
Use Case Automated Teller Machine (ATM)

Actor
WithdrawCash «actor»
Customer BankSystem
Actor
DepositMoney
ChangePIN
ServicePerson
Role Name
Role Name MaintainATM
Actor – Use Case communication

Use Case Model - Diagrammatic Part
The diagrammatic part gives an overview on the desired context of the subject and
interactions between users and subject. UC diagram identifies the desired
functionality (use cases) including all involved actors.
Use Case – represents interaction between actors and subject, UCs are
labeled with the goal of the primary actor
Actor – Primary Actor: uses the subject and tries to achieve a certain goal
Secondary Actor: is used by the subject
Subject boundary – identifies the border between subject and its

context
Use Cases
A Use Case describes how an actor uses the system to do something
important, i.e. to achieve a certain goal.
• UCs must be uncovered early (just after the start of a project)
- engineers should interview users and other stakeholders
- choose the right granularity (rule of thumb: < 40)
• A full Use Case consists of two parts:
- Diagrammatic part shows only label of use case

 label should indicate the goal of the primary actor
- Textual part describes how actors and system interact
 flow of events that is necessary to achieve the goal of primary actor
Use Case -- Labels
• Labels should identify goal of actor
- Active verb phrase ( WithdrawCash, DepositMoney, ... )
- goals are formulated in user's language and not at system level
Technical Language
User's Language (System Level)
 "Ensure consisting formatting of a  "Define a style, apply a style, change a

document" style"
 "Format two files with the same  "Import a style"
style"
Actors
Automated Teller Machine (ATM)
Customer BankSystem
Represent users interacting with DepositMoney
ChangePIN
the subject in a certain role ServicePerson
Typical roles are: MaintainATM
 Customer, Caller, Callee

 Manager, Trader, Administrator, SalesRepresentative
 ServicePerson, Cashier, SupportEngineer
 BillingSystem, BankingSystem
• Can be a person, groups of persons or an (external) system
- Even System under Development (SuD) can have goals and is

seen as an actor
Actors
Customer BankSystem
Represent users interacting with DepositMoney
ChangePIN
the subject in a certain role ServicePerson
MaintainATM
• The same user may play multiple roles
- Don't mix actor names with job titles of involved persons!
• Can be categorized into two groups:
- Primary Actor: Actor with goal on system

- Secondary (Supporting) Actor: Actor used by system
Actors and Goals
A high number of actors simplifies the finding of use cases.
G enerateS oftwareK eys MaintainDiaries
HandleC ustomerQueries E nterC ustomerOrders
SalesManager
G enerateS oftwareK eys MaintainDiaries
HandleC ustomerQueries E nterC ustomerOrders
SupportManager TeamManager OrderAdministrator

Layout of Diagrammatic Part
Customer BankSystem
DepositMoney
ChangePIN
ServicePerson
Computer system
actors are not shown
MaintainATM
in stickman notation
Primary actors on the left and secondary actors on the right

Use Case Model –Textual Part
UC-Descriptions (aka. Stories, Scenarios)
• Story – flow of events showing an interaction between user and subject
• The textual part provides 90% (!) of the UC value

• Events can
- be triggered by user actions

 Customer inserts card, Caller lifts telephone receiver
- be caused by system response
 System checks PIN, System asks BackupSystem
- be time-triggered (At the end of month...)
• Stories have
- basic flow ("Happy Day Scenario"),
- alternative flows
 optional behavior or exceptions/errors
•
Story - Example
DepositCash (basic flow)
1) The Customer inserts the bank card into the ATM and enters the Personal
Identification Number (PIN).
2) The System validates the PIN and queries BankSystem to validate the Customer’s
account.
3) The Customer indicates the wish to deposit cash and inserts all banknotes for deposit.
4) The System checks the banknotes and notifies the overall amount of inserted money.
5) The Customer approves the amount.
6) The System informs the BankingSystem to book the amount on the Customer’s
account.
7) The System ejects the card.
8) The Customer takes the card.
9) The use case ends.
Story – General Structure
1) The primary actor sends request and data to the
system
2) The system validates the request and the data
3) The system alters its internal state
4) The system replies to the actor with the result

Use Case Models -- Practice
UC models ...
• are developed at the very beginning of a project
• have to be complemented by other artifacts
- Glossary with informal description of domain terminology

- Domain Model
• allow effective communication among all stakeholders
• help to understand and to communicate the goals of the stakeholders
- Ask yourself: Is this goal fully intended? Are there alternatives?

• allow simplistic/abstract view on the system
• are never perfect
- use cases are corrected/refined in later phases of system

development
Glossary
• Describes the main entities of the problem domain
• Is written in informal style
• Helps to avoid lengthy descriptions
• Helps to avoid redundant information

- define a technical term once and use it at various
places
Glossary -- Example
• Log:
A permanent record used to prevent against data
loss in the event of a subsequent system failure.
The log contains the following information for
each transaction:
 The identifier, date, and time of the transaction
 The location of the ATM
 The Customer's bank number
 The type of transaction
 The amount of the transaction
Glossary -- Example
• Personal Identification Number (PIN):
An identification number, chosen by the Customer,
used in conjunction with the card for security
purposes. The PIN can be up to 6 numbers in length
and must not include an repeated digits. A PIN is
used to verify the identity of the Customer by
asking the Customer to reenter the PIN; when the
Customer enters the same number as the PIN stored
on the card, the Customer's identity is considered
authenticated.
UC Description - How to Formulate
Clear and consistent writing style makes both reading and writing
easier and more enjoyable.
• Use Simple Grammar: Subject + Verb + Object + PrepositionalPhrase
- Subject: actor/system who is controlling the action (who has the ball)
 The System deducts the amount from the account balance.
• Show clearly "Who has the ball“
- A scenario is similar to a group of children (actors/system) kicking the ball

(message/data passed from actor to actor).
 The Customer takes the card.
• Write from a Bird's Eye View
- Don't fall into the trap to take only the system's perspective.
 The Customer puts card and PIN into the ATM. 
 Get ATM card and PIN. 
• Show the process moving forward
- Find the right granularity for events.
- Ask "Why is the actor doing that?"
- Cockburn: Good main scenarios don't have more than 9 steps.
 User enters name and address. 
 User hits tab key. 
• Show the actor's intent, not the movement

- Don't pollute the use case with your current idea of the user
interface.
 1. User enters name and address. 
1. System asks for name.
}

 2. User enters name.


 3. System prompts for address.
 4. User enters address and clicks "OK".
One step in reality is one step in description
 1. The Customer enters the order number.
 2. The System detects that it matches the winning number of the
month.
 3. The System registers the Customer and order number as the
month's winner, and sends an email to the SalesManager.
 4. The System congratulates the Customer and gives them instructions
on how to collect the prize.
Instead of
 1. The Customer enters the order number. The System detects that it
matches the winning number of the month. The System registers the
Customer and order number as the month's winner, and sends an email
to the SalesManager. The System congratulates the Customer and
gives them instructions on how to collect the prize.
'Validate' instead of 'Check Whether'
- If the system has to verify something, 'check' is a poor word
 Does not move the process forward
 You always had to write later "If the check passes..." "If the check
fails..."
 Better words to use: 'establish', 'validate', 'ensure', 'verify'
1. The System validates that the password is correct.

2. The System asks the Database for User's profile.
Instead of
1. The System checks whether the password is correct.
2. If it is, the System asks the Database for User's profile.
'Validate' instead of 'Check Whether'
●
If the system has to verify something, 'check' is a poor word
– Does not move the process forward
●
You always had to write later "If the check passes..." "If the check
fails..."
• Better words to use: 'establish', 'validate', 'ensure', 'verify'
 1. The System validates that the password is correct.
 2. The System asks the Database for User's profile.
Instead of
 1. The System checks whether the password is correct.
 2. If it is, the System asks the Database for User's profile.
Idiom "Do Steps x - y until Condition"
- Occasionally, one step or group of steps should be repeated. This can

be expressed in the step itself or in form of meta information.
The User selects one or more products.
The User searches through various product catalogs until he finds the one he
wants to use.
1. The Customer supplies either account identifier or name and address.

2. System brings up the Customer's preference information.
3. Customer selects an item to buy, marks it for purchase.
4. System adds the item to the Customer's "shopping cart."
Customer repeats steps 3-4 until indicating that s/he is done.

5. Customer purchases the items in the shopping cart.
• Prevent 'should'/'could' that make sentence weaker
- Keep in mind you describe the solution.
The System validates the amount entered.

Instead of
The amount entered should be validated by the System.

• Be precise
- Avoid vague terminology like 'very', 'more', 'rather', 'appropriate',

'relevant', 'sufficient'.
• Write in present tense
- Avoid 'will do'/'shall do' what is often found in other requirement

documents.
• 'if' only in meaning "if cond then action else skip"
- Flow expresses linear sequence of actions
- Branches for conditionals are explored using extensions

Homework
Story – Example WithdrawCash

• Explain why the UC description given below has some deficiencies. Which important
information are missing? How would you rephrase the text?
WithdrawCash (basic flow)
1) The use case starts when the Customer inserts the bank card.
2) The system reads the card and requests the Customer to enter the Personal
Identification Number(PIN).
3) The system presents a menu of choices.
4) The Customer indicates the wish to withdraw cash.
5) The system requests the amount to be dispensed and the Customer shall enter
the amount.
6) The desired amount of cash is dispensed and card is ejected.
7) The Customer will take the cash and card.
8) The use case ends.

Systems Engineering

Winter 2014/15
Today's Topic
Advanced Use Case Modeling
The last lecture has introduced the most basic elements for
use case modeling: Actor, subject (system), use case, flow of
events, ‘Happy Day Scenario’.
Today, a new element is introduced that makes use case

descriptions more expressive: Alternative flows allow to
specify the behavior of the system in exceptional or abnormal
situations. Alternative flows are formulated as an Extension to
the Happy Day Scenario.
Template for Use Case Descriptions
Use case descriptions are often formulated in a semi-formal way. We use
the following template:
Use Case: Name of the use case.

Brief Description: A summary of the use case.
Primary Actor: The actor who triggers the use case.
Main Success Scenario: The description of the normal, expected
path through the use case (path taken by most of the users most of
the time).
Extensions: Description of variant or optional behavior as part of
the flow of events. They are defined relative to the use case's main
success scenario.
Example: BuyDrink
Use Case: Buy Drink
Brief Description: The Consumer wants to buy a drink from the drink
vending machine. This involves the exchange of a certain amount of money
for a drink.
Primary Actor: Consumer
Main Success Scenario:

 1. Consumer introduces a coin into the machine.
Step 1 can be repeated as many times as the Consumer wishes.
 2. Consumer selects a drink.
 3. System validates that there are sufficient funds for the selection
and takes the specified amount of money (returning the excess amount
of money to Consumer).
 4. System dispenses drink.
 5. Consumer obtains drink from machine.
 6. Use Case ends.
Example: BuyDrink
Extensions:
 (1-2)a. Consumer requests ejection of money.
(1-2)a.1. System ejects money.
(1-2)a.3. Use Case ends in failure.
 1||b. DVM is out of order:

1||b.1. System releases inserted coins.
1||b.2. Use Case ends in failure.
 3a. System determines that there are insufficient funds for the
purchase.
3a.1. System informs Consumer.
3a.2. Use Case continues at step 1 or 2.
Example: BuyDrink
Extensions:
 4a. System determines that there are no drinks left in that
category.
4a.1. System informs Consumer.
4a.2. Use Case continues at step 1 or 2.
 5||a. Money Box informs System that it is full:

5||a.1. System informs Consumer that it is out of order*.
5||a.2. Use Case ends.
- * The System stays out of order until reset by a Service Person.
Example: Authenticate
Use Case: AuthenticateCustomer
Brief Description: The Customer wants to identify him/herself to the

System. A project constraint states that identification is made with a card
and a personal identification number (PIN). The System uses the service of
a Bank Authentication Server (BAS) to verify PIN.
Primary Actor: Customer
Main Success Scenario:

 1. Customer inserts card; System reads card details*.
 2. System validates card type.
 3. Customer provides PIN to System.
 4. System requests BAS to verify identification information*.
 5. BAS informs System that identification information is valid, and
System informs Customer.
5.5 system informs customer
 6. Use case ends.
* -- technical terminology is explained in the glossary
Extensions:
 (1-5)a. (at any time) Customer cancels the authentication process.
1-5.5 (1-5)a.1. System ejects the card.
(1-5)a.2. Use case ends in failure.
 1||b. System is out of service:

1||b.1. System ejects the card and informs the Customer that it is
currently out of service.
1||b.2. Use case ends in failure.
 2b. System ascertains that card type is unknown.

2b.1. The System informs the Customer about unknown card type
and ejects the card;
2b.2. Use case ends in failure.
Extensions:
 3b. System times out on waiting for Customer to provide PIN.
3b.1. System ejects the card.
3b.2 Use case ends in failure.
 5b. BAS informs System that password is incorrect.

5b.1. System informs Customer and prompts him/her to
retry.
5b.2. Use case continues at step 3.
5b.1a. System ascertains that Customer entered an incorrect

PIN for the third time.
– 5b.1a.1. System swallows card and informs Customer to
see Bank for further details.
– 5b.1a.2. Use case ends in failure.
Extensions:
 5c. BAS informs System that card information is invalid.
5c.1. System informs Customer and ejects the card.
5c.2. Use case ends in failure.
 5d. System times out on waiting for response from BAS.

5d.1. System informs Customer that it is now out of
service and ejects the card.
5d.2. Use case ends in failure.
Bird’s Eye View on Scenarios
Use Case starts
Happy Day Szenario
- State
- Event
Extensions
(Step)
Use Case ends Use Case

with success fails
Success and Failure
A use case is usually described by both
successful and unsuccessful scenarios.
Success Scenario
 All of the interests of the actors are satisfied (goal
was achieved). The goal of the primary actor A was achieved
Failure Scenario
 Goal was not achieved.
Primary Actor
Primary actor
 the actor who has invoked the use case and whose goal
should be achieved
 if the use case is triggered by a (time) condition, the
System itself is the primary actor
Numbering scheme
Each step is numbered by a sequence of digits, characters and
auxiliary symbols.
• The last element in the sequence is always ‘.’ (dot), which do not
belong to the current number.
 1. Customer inserts card.
Instead of
 1 Customer inserts card.
• Consecutive numbers mean one after the other (unless you have
specified that order is not important, e.g. “Step 1-4 can occur in
any order")
 1. Customer inserts card.
 2. System validates card type.
Numbering scheme (contd)
There can be some nesting in the occurrence of events. We distinguish 3
cases:
- Alternative flow: CurrentNumber Character

 3.1. Customer selects product
 3.1a. Customer cancels selection dialog.
(If branch 3.1a is taken, the event of 3.1 has not occurred)
- Additional flow: CurrentNumber "||" Character

Condition
 3. The Customer buys a product.
 3||a. The Customer has qualified for bonus program:
3||a.1. System adds 10 bonus points to Customer's profile
(If condition of 3||a holds, then event of 3||a.1 occurs in addition to
occurrence of event of 3.)
Numbering scheme (contd)
- Sequential flow: CurrentNumber "." Digit

 3.1a. Customer cancels selection dialog.
3.1a.1. System informs Customer about re-initialization of
Customer's shopping cart.
3.1a.2. Use case continues at step 2.
Types of Extensions
Extensions are necessary in one of the following situations (among others):
- There exists an alternate success path

 Clerk inserts a shortcut code.
- Lack of response from actor, e.g. time-out for response on

request
 System times out on waiting for Customer to provide PIN.
- Alternative flow for unsuccessful validation

 The System ascertains that the inserted password is not valid.
- Internal failure within the system, which must be detected

 The System detects a jam at the cash dispenser.
Phrases to Structure the Flow
 (1-5)a (at any time in steps 1..5)
 Use case continues at step 5
 Steps 1-4 can be executed in any order
 Steps 1-4 are optional
Homework
Metamodel/Grammar for UseCase
Descriptions
• We have used a template to capture the textual part of
UseCases. The template provides slots, for example, to name the
primary actor or to formulate the Happy-Day-Scenario or the
Extensions of it.
- You are asked to develop a metamodel for the syntax of the

textual part of UseCases (i.e. the template). The metamodel
should also cover the structure of the text one provides in the
slots 'Main Success Scenario' and 'Extensions'.
- Once the metamodel has been finished, please propose an
alternative textual syntax and formalize it in form of an
grammar for XText.

SE Winter1415 All Merged

Uploaded by

Document Information

Original Description:

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

SE Winter1415 All Merged

Uploaded by

Copyright:

Available Formats

Systems Engineering

Prof.Dr. Thomas Baar

1999 – 03 Doctorate candidate, University of Karlsruhe, Germany

- Clients and areas of work

These notations aims at showing the essence of the problem, i.e. to

- is "difference" between Current and Desired Situation

Domain- Situation- Systems

Systems Engineering = System Thinking + Methodology

• usually hard to define because

Prof.Dr. Thomas Baar

Source: http://www.htw-berlin.de/htw/standorte/campus-wilhelminenhof Oct. 2014

Source: http://www.htw-berlin.de/htw/standorte/campus-wilhelminenhof Oct. 2014

Source: http://www.htw-berlin.de/htw/standorte/campus-wilhelminenhof Oct. 2014

Source: http://www.htw-berlin.de/htw/standorte/campus-wilhelminenhof Oct. 2014

To characterize elements of systems more precisely, we will

- An object represents (or models) an individual, identifiable

Mr. Rich, business man, 42 years old, living in Zug, Switzerland,

The bank account of Mr. Rich with La Banque du Crédit

In domain modeling, the values of attributes should be always

The attributes describe static properties of an object; they retrieve

- Integer represents the infinite set of numbers …,-2,-1,0,1,2,…

"A floor is added on the top of the building."

- typical examples of enumerations are

"The building was built in 1980."

• the derived attribute age has the value 34.

Identification of Objects and Attributes

Whereas a given set of objects can model only one situation (a

The classes of a Domain model are also called concepts

- an object is represented by a rectangle with two (or more)

Class Classname Literal

Identification of Objects and Attributes

• Show for the above identified objects and their state a

- The occurrence of the association between two concrete objects is

Association Role name

Association Role name

 if no multiplicity is given, 0..* is assumed as a default value

• Find appropriate attributes:

• Draw the Domain Model for the following classes and

Prof.Dr. Thomas Baar

- It might become hard to keep an overview

- Packages have the following properties. They ..

The (full/qualified) name of a class/package is the concatenation of

Full name: event

TO BE READ AS: Each

Propose Generalization-Relationsships for

Which attributes would be useful for each of these

Cash- Card- Check-

"A company consists of

The XOR-constraint is not necessary

Syntax: Constraint is formulated a semi-formal text, which is enclosed by curly braces

All constraints are satisfied

Constraint for p1-headOf-d1

Constraint for c1 and c2

Error (not allowed)

(Meta-)Modeling Packages and Classes

When class diagrams are used to describe the structure of

You should create a class diagram that expresses the usage

Find Classes, Associations, Attributes

www.spiegel.de > Sport > Fussball Liveticker

Prof.Dr. Thomas Baar

Domain Modeling can also be applied to describe the structure of a

A metamodel uncovers the internal structure of a language and can