02291: System Integration Week 4 Hubert Baumeister

(1)

02291: System Integration

Week 4

Hubert Baumeister

huba@dtu.dk

DTU Compute Technical University of Denmark

Spring 2018

(2)

From Requirements to Design

Problem

I

Given a requirements model consisting of:

1 use case diagram

2 detailed use case descriptions 3 glossary

4 non functional requirements

I

how do I get a system design consisting of

a component diagram

b class diagram c behaviour design

(4)

From Requirements to Design: Solution

I

Design process

1 Define the basic architecture of the system

2 The terms in the glossary givefirst candidatesfor classes, attributes, and operations

3 Realize one use case scenario / user story at a time

→ simulate execution

→ CRC cards

(5)

Introduction CRC Cards

I

Class Responsibility Collaboration

I

Developed in the 80’s

I

Used to

I Analyse a problem domain

I Discover object-oriented design

I Teach object-oriented design

I

Object-oriented design

I Objects have state and behaviour

I ”Think objects”

(7)

CRC Card Template

A larger example

I http://c2.com/doc/crc/draw.html

(8)

Process

I

Basic: Simulate the execution of use case scenarios / user stories

I

Steps

1. Brainstorm classes/objects/components

2. Assign classes/objects/components to persons (group up to 6 peopel)

4. Execute the scenarios one by one

a) add new classes/objects/components as needed b) add new responsibilities

c) delegate to other classes / persons

(9)

Library Example: Problem Description and Glossary

I

Problem Description

I Library system forchecking out,returning, andsearching forbooks. No more than 5 books can be loaned by one borrowerat a time. And if a book is returned after its overdue date, a fine has to be paid.

Glossary

I

Librarien

I The object in the system that fulfills User requests to check out, check in, and search for library materials

I

Book

I The set of objects that represent Users who borrow items from the library

I

Borrower

I

. . .

(10)

Library Example: Problem Description and Glossary

I

Problem Description

I Library system forchecking out,returning, andsearching forbooks. No more than 5 books can be loaned by one borrowerat a time. And if a book is returned after its overdue date, a fine has to be paid.

Glossary

I

Librarien

I

Book

I

Borrower

I

. . .

(11)

Library Example: Use Case Diagram

I

Use Cases

User

LibrarySystem

borrow book

return book

search for book

(12)

Library Example: Detailed Use Case Check Out Book

I

Name: Check Out Book

I

Description: The user checks out a book from the library

I

Actor: User

I

Main scenario:

1 A user presents a book for check-out at the check-out counter

2 The system registers the loan

I

Alternative scenarios:

I The user already has 5 books borrowed 2a The system denies the loan

I The user has one overdue book 2b The system denies the loan

(13)

Example II

I

Set of initial CRC cards

I Librarien

I Borrower

I Book

I The set of objects that represent items to be borrowed from the library

I

Use case Check out book main scenario

I ”What happens when Barbara Stewart, who has no accrued fines and one outstanding book, not overdue, checks out a book entitled Effective C++ Strategies+?”

(14)

Library Example: CRC cards

(15)

Library Example: CRC cards

(16)

Library Example: CRC cards

(17)

Library Example: CRC cards

(18)

Library Example: CRC cards

(19)

Library Example: CRC cards

(20)

Library Example: CRC cards

(21)

Library Example: CRC cards

(22)

Library Example: CRC cards

(23)

Library Example: CRC cards

(24)

Library Example: CRC cards

(25)

Library Example: CRC cards

(26)

Library Example: CRC cards

(27)

Library Example: CRC cards

(28)

Library Example: CRC cards

(29)

Library Example: All CRC cards

(30)

Process: Next Steps

I

Repeat the process with other scenarios

→ completes the design

I

Review the result

I Group cards

I Check cards

I Refactor

I

Transfer the result

I UML class diagram

I UML interaction diagrams

(31)

Example: Class Diagram (so far)

0..1 * Borrower

canBorrow

Book isOverdue

checkOut(b:Borrower) calculateDueDate Librarien

checkOutBook(b:Book)

Date compare(d:Date)

* *

0..1 dueDate

(32)

Example: Sequence Diagram for Check-out book

Check Out Book Realization

(33)

Summary

Process

I

Further scenarios give more detail

I

Repeat CRC process on a more detailed level

I e.g. to designdatabase interaction, oruser interface

I

Choose your level of abstraction and stay there

Alternative: Build sequence and class diagrams directly (the

”modern” way)

I

Danger: talk about the system instead of being part of the system

I

Possible when object-oriented principles have been learned

I

CRC cards help with object-oriented thinking

(34)

Software architecture

I

Software architecture

I building blocks: components

I glue: connectors

I ports: interfaces to the outside

I

Decompose the system into smaller components and their interconnection

I E.g.browser,Web server,database

I E.g.presentation layer,application layer,domain layer

(36)

Components

I

Components: replacable piece of software

→ Resuable

→ Pluggable

I

Well-defined interfaces: provided and required

→ ports

→ connectors

I

Similar to classes: better encapsulation

I

Component = set of collaborating classes

I

Microservices are components

(37)

Example Bank–ATM: UML 2.0 Component Diagram

Company

Clearing− Bank ATM

BC BankATM

AB

CB BA

Note: Cannot be expressed in Topcased and MagicDraw (cf. note on the home page)

(38)

Example Bank–ATM: UML 2.0 Component Diagram

pinNotOK pinOk

verifyPIN verifyPIN

withdraw

pinOk pinNotOK withdrawOK withdrawNotOk Company

Clearing− Bank ATM

BC BankATM

AB

CB BA

(39)

Example Bank–ATM: Configuration (composite structure diagram)

Company

b:Bank c:Clearing−

:CB :BC

:AB

:AB :BankATM

:BA :BA

atm0:ATM

atm1:ATM

(40)

Strong encapsulation of components

I

Strong encapsulation

I What is provided to others

I What is needed of others

I

Ports define a portal to a component

I Have interfaces: provided / required

I Connect to other components

(41)

Showing interfaces

Port AB

Bank

Clearing Company ATM

Port BC Port BA

Provided Interface by port AB Required Interface

by port BA

Provided Interface by port BA

Required Interface by port AB

(42)

Port BA

Bank ATM

< < i n t e r f a c e > >

AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk

< < i n t e r f a c e > >

BankToAtm verifyPIN(iban:IBAN, pin:int)

withdraw(iban, amount:Money)

«interface»

I1 m 1 m 2 m 3

«interface»

I2 m 1 m 3

C2 C1

«refine»

(43)

Component Meta-Model

I

Conceptual meta-model (not actual UML 2.0 meta-model)

*

CompositeComponent

*

0..1 Component

SimpleComponent

Protocol

Interface Connector Port

1

2 Assembly ^*

0..1 1

1

*

provided 1

* required *

(44)

Component Notation

Component as a stereotype

(45)

Realizing components

I

No runtime representation (usually)

I

No programming language support (usually)

I

Different types of component concepts

I EJB, CORBA, COM/DCOM, .NET, JavaBeans, . . .

I Microservices

(46)

Bank component with Implementation

Bank component seen from the outside

Bank component seen from the inside

Bank

Customer Account

ClearingCompanyToBank

BankToAtm

*

«delegate»

* BankToATMPort

«delegate»

BankToClearingCompany

AtmToBank

«delegate»

(47)

Detailed Class Diagram for the Bank Component

Bank name: String ...

pinOK pinNotOk accountFor(a): Account ...

«interface»

AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk

Customer name address ...

Account number : IBAN balance : int withdraw(amount:int): bool ...

BankToATMPort verifyPIN(a,p): bool withdraw(a,m): bool pinOK pinNotOk

1 cc

1..*

c*

*

«interface»

BankToAtm verifyPIN(a,p): bool

withdraw(a,m): bool *

1 b

«interface»

ClearingCompanyToBank verifyPIN(a,p)

«interface»

BankToClearingCompany pinOK

pinNotOk

1 a t m

I

Rules for classes implementing components

I Provided interfaces must to be implemented by some class

I Required interfaces must to be used by one or serveral classes

I No access to and from classes of other components (exception: common datatypes)

I

Use packages to indicate classes belonging to a

component

(48)

Marriage Agency: How to implement?

Customer sex:String birthYear:int interests:String[*]

MarriageAgency

matchCustomer(c):Customer[*] *

public class MarriageAgency{

private List<Customer> customers = new ArrayList<Customer>();

public List<Customer> matchCustomer(c) {

List<Customer> matches = new ArrayList<Customer>();

for (Customer candidate : customers) {

... // if customer matches candidate add to variable matches }

return candidate;

} }

(50)

Marriage Agency: centralized control

MarriageAgency matchCustomer(c):Customer[*]

match(c,p) : boolean

*

// if customer matches candidate add to variable matches if (match(c,candidate)) {

matches.add(candidate);

}

return candidate;

} }

public bool match(Customer customer, Customer candidate) { ....

} }

(51)

Marriage Agency: centralized control

sd match centralized

loop [for all customers p]

(52)

Marriage Agency: decentralized/distributed control

sd match decentralized

loop [for all customers]

(53)

Marriage Agency: decentralized/distributed control

Customer sex:String

birthYear:int interests:String[*]

match(c:Customer) hasOppositeSex(c)

hasAppropriateAgeDifference(c) hasOneInterestInCommon(c) MarriageAgency

matchCustomer(c):Customer[*]

*

for (Customer candidate : customers) { if (c.match(candidate)) {

matches.add(candidate);

}

return candidate;

} } }

public class Customer { ...

public bool match(Customer candidate) { ....

} }

(54)

Design for change: centralized control

MarriageAgency matchCustomer(c):Customer[*]

matchCustomerTypeA(c):boolean matchCustomerTypeB(c):boolean

*

CustomerTypeA CustomerTypeB

public List<Customer> matchCustomer(Customer c) { List<Customer> r = new ArrayList<Customer>();

for (Customer p : customers) { if (c instanceof CustomerA) {

if (matchCustomerTypeA(p)) { r.add(p); } continue;

}

if (c instanceof CustomerB) {

if (matchCustomerTypeB(p)) { r.add(p); } continue;

} }

return r;

}

(55)

Design for change: centralized control

sd match centralized

alt [c instanceof CustomerTypeA]

(56)

Design for change: decentralized control

sd match decentralized

alt

(57)

Design for change: decentralized control

match(c:Customer) MarriageAgency

matchCustomer(c):Customer[*]

*

CustomerTypeA match(c:Customer)

CustomerTypeB match(c:Customer)

public List<Customer> matchCustomer(Customer c) { List<Customer> matches = new ArrayList<Customer>();

if (c.match(candidate)) { matches.add(p); } }

return matches;

}

(58)

Centralised control

(59)

Centralized control

Order calculate price calculate base price calculate discounts

Product name

price

Customer name

discount info

OrderLine quantity

*

1 1

(60)

Distributed control

(61)

Class diagram

(62)

Distributed control

(63)

Distributed Control: Class diagram

Order calculate price calculate base price calculate discounts

Product name price

get price for quantity Customer name discount info calculate discount

OrderLine quantity calculate price

*

1 1

(64)

Centralized vs Distributed control

I

Centralized control

I One method

I Data objects

→ procedural programming language

I

Distributed control

I Objectscollaborate

I Objects = dataandbehaviour

→ Object-orientation

I

Advantage

I Easy to adapt

→ Design forchange

I

CRC cards lead to distributed control

(65)

Next Week:

I

UML Class Diagrams

I Read/Skim the lectures notes and the UML user manual on classes and class diagrams

I Send me questions and UML class diagrams for discussion by Monday 26.2

I What is unclear to you?

I What would you like to hear more about?

I Why is this feature used in this digram?

I What does this notation in this diagram mean?

I . . .

I I am going to answer the questions and discuss your class diagrams in the lecture

→ Your questions and diagrams determine the lecture

02291: System Integration Week 4 Hubert Baumeister