INF5120 Modelbased System development...INF5120 ”Modelbased System development” Lecture 11: 25.03.2019 Arne-Jørgen Berre [email protected] and [email protected] Telecom and

Telecom and Informatics 1

INF5120

”Modelbased System development”

Lecture 11: 25.03.2019Arne-Jørgen Berre

[email protected] and [email protected]

mailto:[email protected]

mailto:[email protected]

Telecom and Informatics

Course parts – 2019 (tentative plan)

2

Part I-a -(Introduction to Modeling): 14/1 - Start 1-14/1: Introduction to INF5120 Part I-b -(Introduction to Modeling and Metamodeling and) 2-21/1: Modeling structure and behaviour (UML and UML 2.0 and metamodeling) 3-28/1: MDE with Eclipse EMF, Xtext and SIRIUS 4-4/2: Business Modeling – BMC, LSC, VDML/VDMBee, (w/meta model) - (Business Model Canvas, Value Proposition,

Lean Canvas - VDMBee, VDML Part II - (Business Architecture/Business Modeling Modeling + Server side – Node-RED + THingML + Sensors/IoT/Cloud -

and the Smart Home project): ) 5-11/2: BPMN 6-18/2: ArchiMate 3.0 Modeling, TOGAF 9.0 7-25/2: Node-RED Cognitive Services/AI – Watson services example (for Oblig 2) (IBM Cloud) 8-4/3: Smart Home - Design Thinking + Chatbots 9-11/3: Service Modeling with UML 2.X Collaboration Models and Composite Models and SoaML + CJML 10- 18/3: UML 2.x Sequence Diagrams, UML 2.x State Machines. ArchiMate ArchIsurance, ArhiMetal examples, 11- 25/3 CJML – Customer Journey Modeling Language (Guest lecture, Dr. Ragnhild Halvorsrud and UML OCL) Group presentations – Oblig 1 ideas .. Part IIi - (Modeling –Apps + EA/ArchiMate) 1/4 - Oblig 1: Specification Models Smart Home – Business Architecture – Business Canvases, ++, ArchiMate + IBM

Cloud basis 12- 1/4 DSLs: SysML and ThingML,- Oblig 2, 3 - discussion/ Oblig 1 Group presentation (2nd group)Part IV - (MDE – Creating Your own Domain Specific Language – Eclipse, Xtext/SIRIUS): 13-8/4: Model driven engineering – revisited EASTER – 15/4 and 22/4 29/4 - Oblig 2 – delivery: Individual / Pairs - Metamodeling (Editor) 13-29/4: MDE – Lexical (ThingML) and Graphical (CJML) DSLs and Transformations 14-6/5 Lecture – Model Driven Engineering 15-13/5 Lecture - Model Driven Engineering 13/5 – Oblig 3- : Smart Home – Realisation with Node-RED, IBM Watson/IoT services + ArchiMate/UML++ Application,

Technology, Physical models – Smart Home demonstrations - 10% 16-20/5: Summary of the course - Oblig 4 final discussions - Conclusions, Previous exams – group collaborations for the Exam by old exams 3/6: Exam (4 hours), Mandag June 3rd, (0900-1300) - 70%

VISUALVISUAL

CJML Customer Journey Modeling Language

From the VISUAL project

https://visualproject.org/

See separate CJML presentation by Ragnhild Halvorsrud, SINTEF

About the project VISUAL• VISUAL goal

– develop a visual language for documentation and analysis of services– serving as a "bridge" from a service concept to service specification

• VISUAL "products"– terminology and notation to specify services– methods, tools, prototypes

• About VISUAL– Innovation project (BIA) running until June 2016– partners: Halogen, FINN.no, DIPS, Hafslund, SINTEF, University of Linköping– The main components of the visual language have been made publicly

available, see www.visualproject.org

http://www.visualproject.org/

VISUALVISUAL

The VISUAL language• VISUAL is a domain specific language for modelling and visualizing a service process

• VISUAL differs from other diagrammatic languages in two principal ways– It models the service process from the customer's point of view– It aims at being intuitive for all users, and does not require a technical background

• VISUAL is implacably targeting the part of a service process that can be encountered by the customer (or end-user, consumer, citizen)

• VISUAL builds on the concept of customer journeys and touchpoints. In general, the term customer journey is used both as a metaphor and as a method in the service design domain.

• VISUAL aims at being an instrument for a precise description and modelling of a service process. It provides a conceptual framework, terminology, and a visual notation.

• VISUAL is particularly targeting service processes that are– technology-driven, standardized, and repeated in high volumes– service processes extending over time, being mediated by different communication channels

• The language is less appropriate for modelling in-session sequences of interaction with a system, e.g. completing a web form

5

VISUALVISUAL

Target group

• The core of VISUAL targets a wide user group, in principle "everyone" in a service company

• The advanced and analytic features of VISUAL targets service owners, business developers, analysts, and technologists

• The VISUAL language addresses interactions between a customer and one or more service providers. It describes service processes both in its hypothetical state, and as it is experienced in a real context.

• VISUAL targets only the part of a service that is encountered by the customer or end-user.

• The service processes described by VISUAL may involve more than one customer/user, and also more than one service provider.

• VISUAL should appeal to people working with service delivery or service innovation, independent on their role and background

VISUALVISUAL

The states of a service

The VISUAL language distinguishes two states of a service: The hypothetical, planned service (theory), and the real-time execution of a service (reality).

7

Theory: the planned service delivery• as intended by the service provider

• can be described and modelled

• may branch into sub-journeys, according to choices or conditions

Reality: the actual service delivery• it always results in an individual

experience

• the experience is subjective, context dependent, and changes over time

• the execution of a service may deviate from the plan

Planned journey Actual journey

"Services exist in two different states of being.." Lynn Shostack (1982). How to design a service. Eur. J. Marketing 16, 49-63.

VISUALVISUAL

What is a customer journey?

As a method, customer journey mapping is practiced in various ways, but there are a few common factors across all approaches:

1. The journey is based on the customer's point of view2. The journey has a time dimension - or a process nature3. The journey is divided into steps

Example of a hospitality service: Going to the cinema to watch a movie. The service process comprise ordering and paying the ticket, retrieving the ticket, and several procedures at the movie theatre.

Example of a health service: Having a knee surgery. The service process typically comprise a visit to the general practitioner, an MR imaging service, visit to a specialist, and finally the surgery. The customer has a relation to more than one service provider during a customer journey.

About customer journeysThe term customer journey is generally used as metaphor for taking a customer's (or a user, consumer, citizen) perspective.

Customer journeys or customer journey mapping also denote a method in service design. The method is used to express a service user's experience.

Although the method is commonly used in the service industry, it lacks a theoretical foundation and a formalization.

A customer journey is often divided into "before", "during" and "after" the service. Sometimes, the borders between these phases can be hard to define.

The Customer Journey Modelling Language (CJML) is a domain specific language for modelling and visualizing a service process.

Customer journeyA customer journey is defined as a sequence or constellation of touchpoints involved for a customer to achieve a specific goal or a desired outcome. The start and end of the journey must be seen in context with the purpose of the analysis

Customer

VISUALVISUAL

Who are involved in a customer journey?

Example: In the cinema case, this is the cinema company. If they have outsourced the online ticketing system, a subcontractor is also directly involved.

Example: This could be the newspaper that made the customer aware of the film, or a friend who recommended the film.

Directly involved actorsThe actors on the left side are directly involved in delivering the service to the customer. They are responsible for (parts of) the customer's journey.

External actorsThe actors on the right side may influence the customer's journey, although they are not responsible for any part of the service delivery.

Service provider

Sub-contractor

Friend

Newspaper

Customer

Customer journeys involve a complex combinations of products (tangibles), services (deeds), spaces and information.

The customer often see the set of service providers as "one entity," and does not distinguish (or care) about their interrelation.

VISUALVISUAL

Touchpoints – the "atoms" of the journeyTouchpointA customer journey is modelled as sequences of steps and events that we refer to as touchpoints. A touchpoint is the "atom" of a customer journey.

A sub-class of touchpoints represent instances of communication or interaction between the customer and the other actors. These steps are called communication points, and are associated with a sender, a receiver, and a communication channel.

Communication points are associated with

• a sender• a receiver• a communication

channel

In CJML there are different types of touchpoints:• communication point• action

This will be explained in the following slides.

Sub-contractor

Friend

Newspaper

Customer Service provider

VISUALVISUAL

Touchpoints

The customer sends an e-mail to the service provider

Touchpoints that involve communication or interaction are referred to as communication points. They make up the backbone of the service process, and has several important attributes that are codified in the visual notation.

Both the direction of the communication, and the communication channel itself are made visually distinct. For example, the touchpoints that are initiated by the customer has a different color compared to the ones initiated by the service provider.

The service provider sends an e-mail to the customer

Sub-contractor

Friend

Newspaper

Customer Service provider

VISUALVISUAL

Touchpoint typologyDirectly involved actorsThe actors on the left side are directly involved in delivering the service to the customer. They are responsible for (parts of) the customer's journey.

External actorsThe actors on the right side may influence the customer's journey, although they are not responsible for any part of the service delivery.

Communication with service provider. Part of the planned journey.

Action External action

Communication with external actor (not involved in service provisioning)

Lisa grabs a shopping cart

Lisa writes a shopping list

Communication point External communication point

Action involving the service system.

Action not involving the service system.

TOUCHPOINT INVOLVING THE SERVICE SYSTEM

TOUCHPOINT OUTSIDE THE SERVICE SYSTEM

Direct communication Steps involving a "sender" and a "receiver" in the context of the customer's journey.

A communication channel is always involved.

No communication Steps without communication are called actions. They may or may not involve interaction with the service system.

These are the touchpoints that can be controlled (to some extent) by the service provider.

VISUALVISUAL

Diagrams and examples

13

VISUALVISUAL

Sequential diagram: for visualizing planned and actual customer journeys with few actors involved

Overview of VISUAL diagrams

Deviation diagram: for visualizing actual customer journeys

Swimlane diagram: for visualizing planned and actual customer journeys with many actors involved

Customer journey diagram Swimlane diagram

14

There are two main diagram types in VISUAL for describing service delivery:

VISUALVISUAL

Customer journey• A customer journey is modelled as a sequence of touchpoints involved for a customer to

achieve a specific goal.

• The scope of a customer journey should be defined in relation to the purpose of the journey mapping

– What is the start of the customer journey?

– What is the end of the customer journey?

Communication points are instances of communication or interaction between a customer and a service provider

Actions are non-communicative events or activities conducted by a customer or service provider as part of a customer journey

15

VISUALVISUAL

Communication point – basics • Communication points are represented as circles

• The circle's boundary style carries information about

– the actor initiating the touchpoint

– the status of the touchpoint

• The symbol area carry information about the channel carrying the communication point, or the device being used

• The symbols are introduced in separate slides

Communication point boundary

symbol area

16

service provider customer

completed missingonly used for

actual journeys

failingonly used for

actual journeys

Actor

Status

other actor

The colour of the boundary indicates the actor initiating the communication point

• green: service provider

• orange: customer

• purple: other actor

The boundary style indicates the status of the communication point

• solid boundary: completed

• dashed boundary: missing

• crossed touchpoint: failing

service provider sends an e-mail to customer

customer fails to retrieve ticket

Examples

VISUALVISUAL

Sequential diagramexample planned journey

• Planned customer journey consisting of a sequence of communication points in chronological order.

17

Note: This example journey is used as an illustration throughout this section. It represents a simplified version of the service process for going to the movies.

VISUALVISUAL

Deviation diagram – description

• Touchpoints are shown in two different layers. See descriptions in in figure.

18

Expected elements

Deviations

E1

M1

E2 E3

F1

A1

All the expected elements are shown in the upper level

All the deviations (ad-hoc, missing and failing touchpoints) are shown in the lower level

Missing and failing communication points that are part of the planned journey appear as grey "ghost" symbols in the upper level

Missing and failing communication points that are part of the planned journey appear in the lower "deviations" level showing status and initiator

When a deviation follows as a direct consequence of an ad-hoc, missing, or failing element, it is displayed vertically below the touchpoint it originated from (as shown in this visualization)

When an deviation touchpoint follows an ad-hoc, missing, or failing touchpoint, but is not directly connected to the previous touchpoint, it is displayed horizontally beside this touchpoint


UML OCL

Object Constraint Language

The Object Constraint Language

ISBN 0-201-37940-6

OCL home page

www.klasse.nl/ocl/index.htm


Model examples

ThiNgami

nos

knnn

doZzzkf()

karPhew(zAA)

Editor

text

Font

changeFont(font)

addElem(elem)

spellCheck()

NuclearReactorCore

add(ControlRod, int)

ControlRod

remove(int)


Precise modeling – Details in models

Avoid misunderstanding

Completeness

Baseline for code generation

Model analysis

Consistence among models

Relationships and mappings between models

Analysis of models


Simplify with OCL

Flight Airplane

CargoFlightPassengerFlight

PasssengerPlane CargoPlane1

0..*1

0..*

0..*

1flights


Diagram with invariants

context Flight

inv: type = #cargo implies airplane.type = #cargo

inv: type = #passenger implies airplane.type = #passenger

10..*Flight Airplane

type =

enum{cargo, passenger}

type =

enum{cargo, passenger}

flights


Definition of constraint

“A constraint is a restriction on one or more values of (part of) an object-

oriented model or system.”


Example model

Airport

Flight

Passenger

Airline

*

*

*

*

$minAge: Integer

age: Integer

needsAssistance: Boolean

departTime: Time

/arrivalTime: Time

duration : Interval

maxNrPassengers: Integer

origin

desti-

nation

name: String

name: String

{ordered}

arriving

Flights

departing

Flights

CEO

0..1

flights

passengers

book(f : Flight)

0..1

airline

airline


Constraint context and self

Every OCL expression is bound to a specific context.

The context may be denoted within the expression using the keyword ‘self’.

Who?

Me?


Notation

Constraints may be denoted within the UML model or in a separate document.

the expression:

context Flight inv: self.duration < 4

is identical to:

context Flight inv: duration < 4

is identical to:

Flight

duration: Integer<<invariant>>

duration < 4


Elements of an OCL expression

In an OCL expression these elements may be used:

basic types: String, Boolean, Integer, Real.

classifiers from the UML model and their features

attributes, and class attributes

query operations, and class query operations

associations from the UML model


OCL types

Collection

Set Bag Sequence

OclTypeReal

Integer

String Boolean

OclState

OclExpression

OclAny


Example: OCL basic types

context Airline inv:

name.toLower = ‘klm’

context Passenger inv:

age >= ((9.6 - 3.5)* 3.1).abs implies

mature = true


Model classes and attributes

“Normal” attributes

context Flight inv:

self.maxNrPassengers <= 1000

Class attributes

context Passenger inv:

age >= Passenger.minAge


Example: query operations

context Flight inv:

self.departTime.difference(self.arrivalTime)

.equals(self.duration)

Time

difference(t:Time):Interval

before(t: Time): Boolean

plus(d : Interval) : Time

Interval

equals(i:Interval):Boolean

$Interval(d, h, m : Integer) :

Interval

$midnight: Time

month : String

day : Integer

year : Integer

hour : Integer

minute : Integer

nrOfDays : Integer

nrOfHours : Integer

nrOfMinutes : Integer


Example: navigations

Navigations

context Flight

inv: origin <> destination

inv: origin.name = ‘Amsterdam’

context Flight

inv: airline.name = ‘KLM’


Basic “Navigation” expressions

i: Instructor, c: Course, s: Session

The name of the course:

c.name

The date of the session:

s.date

The instructor assigned to the session:

s.instructor

The course of the session:

s.course

The name of the course of the session:

s.course.name

The instructors qualified for the session:

s.course.qualifiedInstructors

Instructor

name

Course

name

Session

date

qualifiedInstructors qualifiedFor

assignedTo*

0..1

*

**

Let’s navigate on a model


Navigation Example

What does a1.r1.r2.r3 yield?

Assuming the B’s have a boolean attribute “black”; black=false for b6, b8 -

what expression refers from a2 to the set { b1 }

r2

a

* *

* 1

0..11A B C

c1

c2

c3

c4

a1

a2

r3r1

b1

b2

b3

b4

b5

b6

b7

b8


Association classes

context Person inv:

if employer.name = ‘Klasse Objecten’ then

job.type = #trainer

else

job.type = #programmer

endif

Person Company

Job

* 1

employee employer

type : {trainer, programmer}

name : String


Three subtypes to Collection

Set:

arrivingFlights(from the context Airport)

Bag:

arrivingFlights.duration (from the context Airport)

Sequence:

passengers (from the context Flight)


OCL has a great number of predefined operations on the collections types.

Syntax:

collection->operation

Collection operations


The collect operation

Syntax:collection->collect(elem : T | expr)

collection->collect(elem | expr)

collection->collect(expr)

Shorthand:collection.expr

The collect operation results in the collection of the values resulting evaluating expr for all elements in the collection


The select operation

Syntax:

collection->select(elem : T | expression)

collection->select(elem | expression)

collection->select(expression)

The select operation results in the subset of all elements for which expression

is true


The forAll operation

Syntax:

collection->forAll(elem : T | expr)

collection->forAll(elem | expr)

collection->forAll(expr)

The forAll operation results in true if

expr is true for all elements of the

collection


The exists operation

Syntax:

collection->exists(elem : T | expr)

collection->exists(elem | expr)

collection->exists(expr)

The exists operation results in true if

there is at least one element in the

collection for which the expression expr

is true.


Example: exists operation

context Airport inv:

self.departingFlights ->

exists(departTime.hour < 6)


Other collection operations

isEmpty: true if collection has no elements

notEmpty: true if collection has at least one element

size: number of elements in collection

count(elem): number of occurences of elem in collection

includes(elem): true if elem is in collection

excludes(elem): true if elem is not in collection

includesAll(coll): true if all elements of coll are in collection


Iterate example

Example iterate:context Airline inv:

flights->select(maxNrPassengers > 150)->notEmpty

Is identical to:context Airline inv:

flights->iterate(f : Flight; answer : Set(Flight) = Set{ } |

if f.maxNrPassengers > 150 then

answer->including(f)

else answer endif )->notEmpty


OCL — Navigation Details

An association end with cardinality maximum > 1 yields a set or

sequence

anInstructor.Session yields a sequence

anInstructor.qualifiedFor yields a set

An association end with cardinality maximum of 1 yields an object or a

set (with zero or one elements)

aSession.Instructor yields an object

aSession.Instructor->isEmpty yields a Boolean

*

*

qualifiedFor

Instructor

qualifiedFor

CoursequalifiedInstructors

Session

date

evaluation

* {seq}

*

0..1


Collections use

i: Instructor

The courses an instructor is qualified to teach

Course.allInstances ->select ( c | c.qualifiedInstructors ->includes ( i ))

Sessions delivered by an instructor who is no longer qualified to teach it

Session.allInstances ->select ( s | s.delivered and

s.course.qualifiedInstructors ->excludes ( s.instructor ) )

The last can be simplified significantly with “convenience” attributes

Session.allInstances ->select ( s | s.teacherNotQualified )

Instructor

nameCourse

name

Session

date

delivered

qualifiedInstructors qualifiedFor

assignedTo

*0..1

*

**

Let’s navigate on a model


Another Invariant Formalized

Always combine formal and narrative descriptions

-- for every instructor ...

Instructor::invariant

-- for any course

Course.allInstances->forAll ( c |

-- if the evaluation bad

Session->select(Course=c)->forAll(s |

s.evaluation = bad

-- then instructor is disqualified for course

implies qualifiedFor ->excludes (c)) )

Instructor

Course

*

*

qualifiedFor

Session

date

evaluation

* {seq}

*

qualifiedInstructors


Same Invariant on Course

-- for every course ...

Course::invariant

-- for all sessions

Session->forAll ( s |

-- if the evaluation is bad

s.evaluation = bad implies

-- then the instructor is not a qualified

instructor

qualifiedInstructors->excludes(s.Instructor) )

Instructor

Course

*

*

qualifiedFor

Session

date

evaluation

* {seq}

*

qualifiedInstructors


Operation Specification

operation SeminarSystem::pay (in client:Client, out amount: Money)

-- When you pay off an invoice

pre -- Provided the payment amount is not negative and does not

-- exceed amount owed

client .balance >= amount and amount>=0

post -- The balance is reduced by the amount of the payment

client.balance@pre = client.balance + amount

SeminarSystem

pay(client:Client, amount: Money)

Client

balance


let, new: Convenient Names, New Objects

Any specification can introduce local names using let … in ...

operation SeminarSystem::scheduleCourse

(client: Client, date: Date, course: Course)

let ( availableInstructors =

instructors ->select (qualifiedFor(course) and availableOn(date)) )

in ( -- the name “availableInstructors” can be used in pre or post

pre availableInstructors ->notEmpty

post -- some instructor from available instructors is assigned …

)

Actions often result in the creation of a new object

let (s = Session.new) in ( -- s is a new member of Session type

s.client = client and s.date = date and s.course = course

and ….

)


OCL — Misc.

Special words

@pre designates a value at the start of an operation

total = total@pre + amount

self designates the object itself

self.total = self.total@pre + amount

result designates the returned object (if any)

result = total

Comments

-- Two hyphens start a comment that goes through the end of line


OCL Tools

Cybernetics ww.cybernetic.org

University of Dresden www-st.inf.tu-dresden.de/ocl/

Boldsoft www.boldsoft.com

ICON computing www.iconcomp.com

Royal Dutch Navy

Others … …


Conclusions and Tips

OCL invariants allow you to model more precisely

stay implementation independent

OCL pre- and postconditions allow you to specify contracts (design by contract)

precisely specify interfaces of components

OCL usage tips keep constraints simple

always combine natural language with OCL

use a tool to check your OCL


UML og OCL

Skriver OCL som tilleggsdokumentasjon til modeller

Skriver OCL i Constraints

(Verktøy)problem: hvordan bruke aktivt

forfining

konsistens

kodegenerering


OclAny

x,y:OclAny; T is a OclType

x = y

x < > y

x.oclIsNew

x.oclType

x.isKindOf(T)

x.isTypeOf(T)

x.asType(T)

x and y are the same object

not (x=y)

True if x is a new instance

The type of x

True if T is a supertype (transitive) of

the type of x

True if T is equal to the type of x

Results in x, but of type T.


OclType and operators

Logical operators in Boolean expressions

and, or, xor, not, implies

T is a OclType

T.new

T.allInstances

Create a new instance of type T

All of the instances of type T


Collection (1)

c,c2 : Collection(T); x,e:T; P:T Boolean;

f, f2: T Object

c->size Number of elements

c->sum Sum of elements (elements must support

addition)

c->count(e) Number of times e is in c

c->isEmpty c->size = 0

c->notEmpty not c->isEmpty


Collection (2)

c->includes(e) True if e is in c

c->includesAll(c2) True if c2 in c

c->excludes(e) True if e not in c

c->exludesAll(c2) True if none in c2 is in c

c->exists(P) True if an e makes P true

c->forAll(P) True if P true for all e in c

c->isUnique(f) True if f evaluates to different value for all e

in c

c->sortedBy(f) Sequence sorted by f

c->iterate(x;e=f;f2) Iterate x over c and apply f2, initialise e to f


Collection subtypes (1)

Applies to set and bag

set, bag: Collection; e,x:T; P: TBoolean;

f, f2: TObject

set->union(set2)

set->union(bag)

set = set2

set->intersection(set2)

set->intersection(bag)

set – set2

set->including(e)


Collection subtypes (2)

set->excluding(e)

set->symmetricDifference(set2)

The set of elements in set or set2,

but not in both

set->select(x|P) All elements for which P is valid

set->select(P) Same as set->select(self|P)

set->reject(x|P) Same as set->select(x|not P)

set->reject(P) Same as set->select(self|not P)

set->collect(x|f) The bag of elements which results

from applying f to every member of

set

set->asSequence

set->asBag


Sequence

seq->append(e) seq followed by e

seq->prepend(e) e followed by seq

seq->subSequence(lower, upper) Subsequence in range [lower,

upper]

seq->at(i) Element at position i

seq->first seq->at(1)

seq->last seq->at(seq->size)

Documents

INF5120 Modelbased System development...INF5120 ”Modelbased System development” Lecture 11: 25.03.2019 Arne-Jørgen Berre [email protected] and [email protected] Telecom and