02291: System Integration Week 1 Hubert Baumeister

Hubert Baumeister

DTU Compute Technical University of Denmark

Spring 2013

Contents

Overview

Introduction to UML Practical Informations

I 5 ECTS Points

I Audience: Masters / advanced Bachelor students

I Lectures with exercises

I Exam: modelling project with project presentation

I

Time and Location

I Lecture Wednesdays 8:30–10:15 aud 22 building 341

I Exercise session after the lecture (rooms 111, 112, 012 building 450)

I

How to reach me

I hub@imm.dtu.dk; office 322/010

I

Teaching assistant: Bahram Zarrin (baza@imm.dtu.dk)

I

Web Page

I http://www.imm.dtu.dk/courses/02291

Problem in Software Engineering

I

Liggesmeyer 1998

I

Raise the abstraction level of problem and solution description

→ modelthe problem and the solution

→ Feedback

I Model inspection

I Automatic code generation

I Analysis of models

Model (definition)

http://en.wiktionary.org/wiki/model . . .

3.

A simplified representation (usually mathematical) used to explain the workings of a real world system or event.

I ”The computer weather model did not correctly predict the path of the hurricane.”

I A plane in a windtunnel

5.

The structural design of a complex system.

I ”The team developed a sound business model”

→

Abstraction

I Focus on some aspects only

I Disregard the other aspects

I Aggregate details by introducing new concepts

I

Know about

1 (Object-oriented) modelling languages: mainly UML 2 Why model?

3 How to model

4 How to validate a model

I

To be able to

I Modellarger systems

I Use models forunderstanding,designing,communication, analysing,verification, andcreatingSoftware

I Document models

I Analysemodels

I Validatemodels

Why model?

I

Conjecture:

I it suffices to communicate only key abstractions rather than the whole programm

I it is easier to create a model of the system than to program it

I it a model of the system is easier to understand than the program itself

0 6 2

1

5 4 3

Start room Special room

Abstraction: Focus on Functionality

Use Case Diagram for the MUD game

0..*

0..1

0..1 0..*

inventory

0..1 0..*

0..1 0..*

connectedRooms

0..* 1

0..1 0..1 nextLevel 1

1

<<mobile object>>

Level

<<location>>

Phone

<<mobile object>>

Room

<<location>>

Server

<<mobile object>>

StartRoom

<<mobile object>>

PersonalObject

<<mobile object>>

SpecialRoom

<<mobile object>>

Player

Abstraction: Focus on the Behaviour

Take object activity in the MUD game

throw InvalidAction Exception

add object to inventory

remove object from current room

remove object from original room

remove object from other player current room [current room contains object]

[current room does not contain object]

[is clone]

[!is clone]

[all other players notified]

[has other player]

I

informal

I communication

→ problem of ambiguity

I drawings on a black board

I

formal

I verification / validation

I simulation

I code generation

Example for an informal model

Class Responsibility Collaboration (CRC) cards for the HotDraw editor

http://www2.imm.dtu.dk/courses/02291/examples/

draw.html

Checking that trading in the MUD game works

I

No deadlock (the trading protocol always finishes)

I

Player agree on the outcome of a trade

Example verification

Player Obj. 1

User 2 Player Obj. 2

offer

closeTrade _recOffer

_closeTrade _del

User 1

offer closeTrade

Example verification

Model-checking:

„ No Deadlock, but ...

Homomorphic abstraction of the state space

waiting

receivedOffer offer(o,to)/

p._recOffer(o,this)

closeTrade()/

lo.p._closeTrade() successTrade=true has.add(lastOffer.object) p._del(lastOffer.object)

offer(o,from)/

p._recOffer(o,from) _recOffer(o,from)/

u.offer(o,from)

_closeTrade()/

u.closeTrade() has.add(lastOffer.object) p._del(lastOffer.object)

Property does not hold:

Players don‘t agree on outcome of trade

Example verification

How to model?

I

Domain Driven Design:

modelling language

I

Agile Modelling: Values, Principles, Practices

How to model?

I

Domain Driven Design:

I

CRC cards: Informal, complete objects

I

Model Driven Architecture: Dervice code from models

I

Explorative Modelling: Use a programming language as modelling language

I

Agile Modelling: Values, Principles, Practices

How to model?

I

Domain Driven Design:

I

CRC cards: Informal, complete objects

I

Model Driven Architecture: Dervice code from models

How to model?

I

Domain Driven Design:

I

CRC cards: Informal, complete objects

I

Model Driven Architecture: Dervice code from models

I

Explorative Modelling: Use a programming language as modelling language

I

Agile Modelling: Values, Principles, Practices

I

Domain Driven Design:

I

CRC cards: Informal, complete objects

I

Model Driven Architecture: Dervice code from models

I

Explorative Modelling: Use a programming language as modelling language

I

Agile Modelling: Values, Principles, Practices

Contents

Overview

Introduction to UML Practical Informations

I

Family of graphical notations for describing aspects of (object-oriented) software

I ”A picture is more than a thousand words”

I

Based on a metamodel

I

Not a development process

I

UML is an open standard

I managed by the Object Management Group (www.omg.org)

I

Web resources

I http://www.uml.org

I UML Standard Document (Superstructure)

I http://www2.imm.dtu.dk/courses/02291/files/

UML2.1.1_superstructure.pdf

UML’s history

I

1980s

I Objects became main stream (e.g. C++ / Simula / Smalltalk)

I Several different OO methods and graphical notations

I Grady Booch, Peter Coad, Ivar Jacobson, Jim Odell, Jim Rumbaugh, Sally Shlaer and Steve Mellor, Rebecca Wirfs-Brock, . . .

I

1990s

I Grady Booch, Ivar Jacobson and Jim Rumbaugh are all with Rational

I First version of the UML (UML 0.8)

I

1996

I UML is handed over to a standard organisation (The Object Management Group (OMG))

I Driven by tool vendors!

I Tool interoperability!

I 1.x with 1.4 and 1.5 being widely used

I

2005

I 2.x (UML 2.0 is ISO standard now)

UML’s history

I

1980s

I Objects became main stream (e.g. C++ / Simula / Smalltalk)

I Several different OO methods and graphical notations

I Grady Booch, Peter Coad, Ivar Jacobson, Jim Odell, Jim Rumbaugh, Sally Shlaer and Steve Mellor, Rebecca Wirfs-Brock, . . .

I

1990s

I Grady Booch, Ivar Jacobson and Jim Rumbaugh are all with Rational

I First version of the UML (UML 0.8)

I Tool interoperability!

I 1.x with 1.4 and 1.5 being widely used

I

2005

I 2.x (UML 2.0 is ISO standard now)

UML’s history

I

1980s

I Objects became main stream (e.g. C++ / Simula / Smalltalk)

I Several different OO methods and graphical notations

I Grady Booch, Peter Coad, Ivar Jacobson, Jim Odell, Jim Rumbaugh, Sally Shlaer and Steve Mellor, Rebecca Wirfs-Brock, . . .

I

1990s

I Grady Booch, Ivar Jacobson and Jim Rumbaugh are all with Rational

I First version of the UML (UML 0.8)

I

1996

I UML is handed over to a standard organisation (The Object Management Group (OMG))

I Driven by tool vendors!

I Tool interoperability!

I 1.x with 1.4 and 1.5 being widely used

I

2005

I 2.x (UML 2.0 is ISO standard now)

Smalltalk)

I Several different OO methods and graphical notations

I Grady Booch, Peter Coad, Ivar Jacobson, Jim Odell, Jim Rumbaugh, Sally Shlaer and Steve Mellor, Rebecca Wirfs-Brock, . . .

I

1990s

I Grady Booch, Ivar Jacobson and Jim Rumbaugh are all with Rational

I First version of the UML (UML 0.8)

I

1996

I UML is handed over to a standard organisation (The Object Management Group (OMG))

I Driven by tool vendors!

I Tool interoperability!

I 1.x with 1.4 and 1.5 being widely used

I

2005

I 2.x (UML 2.0 is ISO standard now)

Notations and Metamodels

I

UML consists of

I a set of graphical notations

I and a single metamodel

0..*

0..1

0..1 0..*

inventory

0..1 0..*

0..1 0..*

connectedRooms

0..* 1

0..1 0..1 nextLevel 1

1

<<mobile object>>

Level

<<location>>

Phone

<<mobile object>>

Room

<<location>>

Server

<<mobile object>>

StartRoom

<<mobile object>>

PersonalObject

<<mobile object>>

SpecialRoom

<<mobile object>>

Player

Metamodel

I

Abstract syntax of UML diagrams

I

Describes the concepts of UML elements

I e.g. class, association, . . .

I

concepts are mapped to notations

I e.g. the concept of a class is mapped to rectangle with subcompartments

I

Metamodel written in MOF

I MOF (Meta-Object Facility)

I Similar toUML class diagrams

→ MOF can be used to definedones ownmodelling language

→ Courses Advanced topics in SE (02265) and SE II (02162)

I

The metamodel is important for model exchange

I XMI (XML Metadata Interchange)

The meaning of UML

I

The abstract syntax / concepts are well defined

→ metamodel

I

The meaning of the concepts, however, is not well defined

I What does a class mean?

I How are activity diagrams executed?

I How are state machines executed?

I What is the meaning of interaction diagrams?

I

Semantic variation points

I Sometimes different interpretations are intended

I Tool vendors can choose how they interpret the concepts

Ways of using the UML

I

Sketch

I Informal use

→ Use of whiteboards, simple graphic editors

I Executable UML

I Problems

I How to describe the behaviour?

→ Use of CASE tools

Ways of using the UML

I

Sketch

I Informal use

→ Use of whiteboards, simple graphic editors

I

Blueprint

I Forward Engineering: e.g. create class stubs

→ Use of CASE tools

I

Programming language

I Executable UML

I Problems

I How to describe the behaviour?

→ Use of CASE tools

I

Sketch

I Informal use

→ Use of whiteboards, simple graphic editors

I

Blueprint

I Forward Engineering: e.g. create class stubs

→ Use of CASE tools

I

Programming language

I Executable UML

I Problems

I How to describe the behaviour?

→ Use of CASE tools

UML is not enough

I

UML is a general purpose modelling language

I

UML can be extended

I lightweight (UML profile)

I heavy weight

→

Use the modelling language best suited for your purpose

I

Structure Diagrams

I Class Diagram

I Class, features, and relationships

I Object Diagram

I Example configuration of instances

I Package Diagram

I Hierarchical structure for models

I Component Diagram

I Structure and connections of components

I Deployment Diagram

I Deployment of artifacts to nodes

I Composite Structure Diagram

I Runtime decomposition of a class

UML Diagrams (II)

I

Behaviour Diagrams

I Use-Case Diagram

I How users interact with a system

I Activity Diagram

I Procedural and parallel behaviour

I State Machine Diagram

I How events change an object over its life

I Interaction Diagram

I Sequence Diagram: Interaction between objects; emphasis on sequence

I Communication Diagram(formerly calledcollaboration diagram): Interaction between objects; emphasis on links

I Interaction Overview Diagram: Mix of sequence and activity diagram

I Timing Diagram: Interaction between objects; emphasis on timing

I

Many diagrams, but only one model

I

Different Views on the system

I Functionality

I Use Case diagram

I Structure

I Component diagram

I Class diagram

I Validation

I Interaction diagram

I Show how the use cases are realised

I How does the system work

I State machine

I Activity diagram

I ...

Library Example: Use Case Diagram

I

Use Cases

User

LibrarySystem

check out book

return book

search for book

I

Use case borrow book: Basic course of events

I 1. User scans his library card

I 2. User selects check out

I 3. User scans the book

I 4. System confirms loan

Implementation: Component Diagram

LibrarySystem

LibraryInterface

«interface»

LibraryInterface scan library card() check out

scan book() check in ...

Library scan library card() check out scan book() check in ...

Borrower canBorrow()

Book overdue : bool register() deregister() checkout() checkin() isOverdue() : bool

*

* user

0..5

{body: overdue}

LibraryInterface scan library card() check out scan book() check in ...

{body: books->size <= 5 and books->forAll(b | not(b.isOverdue()))}

{pre: not(bor.canBorrow()

post: dueDate = Date.today + 3 weeks and bor.books->containing(self) }

Library SM

Idle User scanned

scan library card (l)

[not users->contains(l)] / return false

[users->contains(l)]/

return true book scanned

scan book(s)/ (cb,msg) := bor.canBorrow()

[cb] / book := books->select(b| b.signature = s);

book.check_out(); return true ...

can borrow?

user ok check out

[not cb] / return (false,msg) after 10min

loop [foreach b' in bor->books]

Use case borrow book : User interactions

I

Use case borrow book: Basic course of events

I 1. User scans his library card

I 2. User selects check out

I 3. User scans the book

I 4. System confirms loan

Idle User scanned scan library card (l)

[not users->contains(l)] / return false

[users->contains(l)]/

return true book scanned

scan book(s)/ (cb,msg) := bor.canBorrow()

[cb] / book := books->select(b| b.signature = s);

book.check_out(); return true can borrow?

user ok check out

[not cb] / return (false,msg) after 10min

loop [foreach b' in bor->books]

Contents

Overview

Introduction to UML Practical Informations

I Class-, Component-, Object-. . .diagrams

I Activity-, Interaction- . . . diagrams

I Object Constraint Language

I

How to model

I Agile modelling

I CRC cards

I Explorative Modelling

I Domain Driven Design

I Model Driven Design

I

Validation / Verification

I Acceptance tests

I (UML) modelchecking

I Use Case Realizations

Course structure

I

Reading assingment to be done before the lecture

I

By Monday: Pre-flight tests: tests that you have done your reading assingment

I

Tuesday: Lectures with exercises

I

Exercises:

I 3 exercises following the structure of the exam project

I

Project

I Task is to model a larger system (requirements,design, validation/verification) so that programmers can implement the design

I Duration 4 weeks at the end of the lecture

I Written report

I Groups: 4—6 people

I

Project presentation

I About the project

I About the lecture

I Date sometime in the examination period

Final project

I

Steps

I Model the requirements

I Domain Model

I Use Cases

I Create a test model

I . . .

I Build a design model

I Component model

I Class diagrams

I OCL constraints

I . . .

I Verify and validate the design

I Use interaction diagrams to show that the use cases are realizable

I . . .

I Reflect on the methods you use

I

Exercises

I Week 2 – Week 4: Requirements model and Acceptance Tests

I Week 4 – Week 7: Design model

I Week 7 – Week 8: Use case validation

I Exercises arenotmandatory but areusefulto getfeedback

I Form groups (4–6) already now: this increases the chances to get feedback on your exercise report

I

Final Project

I Week 9 – Week 13 (4 weeks)

I Teams: 4 – 6 people

Literature: Some general remakrs

I

There is no book covering all the topics introduced in this course.

I

This is a masters course

I You need to be able to get an overview over the literature and then decide what parts to skip, read only lightly, and which parts to read in depth

I You need to be able to know where you can find further information when you need them.

I E.g. looking into standards is a good way to resolve technology questions (sometimes :-)

I

Most books on UML will do. Make sure it deals with UML 2.x. Some options

I

Grady Booch, James Rumbaugh, and Ivar Jacobson The Unified Modeling Language User Guide (2nd Edition) (Users manual from the creators of UML)

I

Martin Fowler UML Distilled. Third Edition (Contains a distilled version of the most important UML diagrams)

I

Perdita Stevens Using UML (A text book for teaching OO

and UML)

Literature: OCL, Modeling

I

OCL

I Jos Warmer and Anneke KleppeThe Object Copnstraint Language. Second Edition

I

Modeling

I Scott AmblerAgile Modeling

I Eric EvansDomain-Driven Design

I Nancy WiklinsonUsing CRC Cards

I Anneke Kleppe, Jos Warmer, Wim BastMDA Explained

I

Further reading and Web resources will be given when

coming to the relevant topics