02291: System Integration Week 4 Hubert Baumeister huba@dtu.dk - - PowerPoint PPT Presentation

02291: System Integration

Week 4 Hubert Baumeister

huba@dtu.dk

DTU Compute Technical University of Denmark

Spring 2018

Contents

From Requirements to Design CRC Cards Components (part Ia) Object-orientation: Centralized vs Decentralized Control/Computation Summary

From Requirements to Design

Problem

◮ Given a requirements model consisting of:

1 use case diagram 2 detailed use case descriptions 3 glossary 4 non functional requirements

◮ how do I get a system design consisting of

a component diagram b class diagram c behaviour design

From Requirements to Design: Solution

◮ Design process

1 Define the basic architecture of the system 2 The terms in the glossary give first candidates for classes, attributes, and operations 3 Realize one use case scenario / user story at a time

→ simulate execution → CRC cards

Contents

From Requirements to Design CRC Cards Components (part Ia) Object-orientation: Centralized vs Decentralized Control/Computation Summary

Introduction CRC Cards

◮ Class Responsibility Collaboration ◮ Developed in the 80’s ◮ Used to

◮ Analyse a problem domain ◮ Discover object-oriented design ◮ Teach object-oriented design

◮ Object-oriented design

◮ Objects have state and behaviour ◮ ”Think objects”

CRC Card Template

A larger example

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

Process

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

stories

◮ 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

Library Example: Problem Description and Glossary

◮ Problem Description

◮ Library system for checking out, returning, and searching

for books. No more than 5 books can be loaned by one borrower at a time. And if a book is returned after its

• verdue date, a fine has to be paid.

Library Example: Problem Description and Glossary

◮ Problem Description

◮ Library system for checking out, returning, and searching

for books. No more than 5 books can be loaned by one borrower at a time. And if a book is returned after its

• verdue date, a fine has to be paid.

Glossary

◮ Librarien

◮ The object in the system that fulfills User requests to check

• ut, check in, and search for library materials

◮ Book

◮ The set of objects that represent Users who borrow items

from the library

◮ Borrower

◮ The set of objects that represent Users who borrow items

from the library

◮ . . .

Library Example: Use Case Diagram

◮ Use Cases

User LibrarySystem borrow book return book search for book

Library Example: Detailed Use Case Check Out Book

◮ Name: Check Out Book ◮ Description: The user checks out a book from the library ◮ Actor: User ◮ Main scenario:

1 A user presents a book for check-out at the check-out counter 2 The system registers the loan

◮ Alternative scenarios:

◮ The user already has 5 books borrowed

2a The system denies the loan

◮ The user has one overdue book

2b The system denies the loan

Example II

◮ Set of initial CRC cards

◮ Librarien ◮ The object in the system that fulfills User requests to check

• ut, check in, and search for library materials

◮ Borrower ◮ The set of objects that represent Users who borrow items

from the library

◮ Book ◮ The set of objects that represent items to be borrowed from

the library

◮ Use case Check out book main scenario

◮ ”What happens when Barbara Stewart, who has no

accrued fines and one outstanding book, not overdue, checks out a book entitled Effective C++ Strategies+?”

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: CRC cards

Library Example: All CRC cards

Process: Next Steps

◮ Repeat the process with other scenarios

→ completes the design

◮ Review the result

◮ Group cards ◮ Check cards ◮ Refactor

◮ Transfer the result

◮ UML class diagram ◮ UML interaction diagrams

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

Example: Sequence Diagram for Check-out book

Check Out Book Realization

Summary

Process

◮ Further scenarios give more detail ◮ Repeat CRC process on a more detailed level

◮ e.g. to design database interaction, or user interface

◮ Choose your level of abstraction and stay there

Alternative: Build sequence and class diagrams directly (the ”modern” way)

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

system

◮ Possible when object-oriented principles have been

learned

◮ CRC cards help with object-oriented thinking

Contents

From Requirements to Design CRC Cards Components (part Ia) Object-orientation: Centralized vs Decentralized Control/Computation Summary

Software architecture

◮ Software architecture

◮ building blocks: components ◮ glue: connectors ◮ ports: interfaces to the outside

◮ Decompose the system into smaller components and their

interconnection

◮ E.g. browser, Web server, database ◮ E.g. presentation layer, application layer, domain layer

Components

◮ Components: replacable piece of software

→ Resuable → Pluggable

◮ Well-defined interfaces: provided and required

→ ports → connectors

◮ Similar to classes: better encapsulation ◮ Component = set of collaborating classes ◮ Microservices are components

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)

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

Example Bank–ATM: Configuration (composite structure diagram)

Company b:Bank c:Clearing− :CB :BC :AB :AB :BankATM :BA :BA atm0:ATM atm1:ATM

Strong encapsulation of components

◮ Strong encapsulation

◮ What is provided to others ◮ What is needed of others

◮ Ports define a portal to a component

◮ Have interfaces: provided / required ◮ Connect to other components

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

Port BA

Bank ATM <<interface>> AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk <<interface>> 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»

Component Meta-Model

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

* *

CompositeComponent

* 0..1

Component SimpleComponent Protocol Interface Port Connector

1 2

Assembly

* 0..1 1 1 * provided 1 * required *

Component Notation

Component as a stereotype

Realizing components

◮ No runtime representation (usually) ◮ No programming language support (usually) ◮ Different types of component concepts

◮ EJB, CORBA, COM/DCOM, .NET, JavaBeans, . . . ◮ Microservices

Bank component with Implementation

Bank component seen from the outside Bank component seen from the inside

Bank Bank Customer Account ClearingCompanyToBank BankToAtm

*

«delegate» «delegate» * BankToATMPort «delegate» BankToClearingCompany AtmToBank «delegate»

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..* 1..* * c * «interface» BankToAtm verifyPIN(a,p): bool withdraw(a,m): bool * 1 b «interface» ClearingCompanyToBank verifyPIN(a,p) «interface» BankToClearingCompany pinOK pinNotOk 1 atm

◮ Rules for classes implementing components

◮ Provided interfaces must to be implemented by some class ◮ Required interfaces must to be used by one or serveral

classes

◮ No access to and from classes of other components

(exception: common datatypes)

◮ Use packages to indicate classes belonging to a

component

Contents

From Requirements to Design CRC Cards Components (part Ia) Object-orientation: Centralized vs Decentralized Control/Computation Summary

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; } }

Marriage Agency: centralized control

MarriageAgency matchCustomer(c):Customer[*] match(c,p) : boolean Customer sex:String birthYear:int interests:String[*] * 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 if (match(c,candidate)) { matches.add(candidate); } return candidate; } } public bool match(Customer customer, Customer candidate) { .... } }

Marriage Agency: centralized control

sd match centralized loop [for all customers p]

Marriage Agency: decentralized/distributed control

sd match decentralized loop [for all customers]

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[*] *

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 (c.match(candidate)) { matches.add(candidate); } return candidate; } } } public class Customer { ... public bool match(Customer candidate) { .... } }

Design for change: centralized control

Customer sex:String birthYear:int interests:String[*] 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; }

Design for change: centralized control

sd match centralized loop [for all customers] alt [c instanceof CustomerTypeA]

Design for change: decentralized control

sd match decentralized alt loop [for all customers]

Design for change: decentralized control

Customer sex:String birthYear:int interests:String[*] 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>(); for (Customer candidate : customers) { if (c.match(candidate)) { matches.add(p); } } return matches; }

Centralised control

Centralized control

Order calculate price calculate base price calculate discounts Product name price Customer name discount info OrderLine quantity * 1 1

Distributed control

Class diagram

Distributed control

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

Centralized vs Distributed control

◮ Centralized control

◮ One method ◮ Data objects

→ procedural programming language

◮ Distributed control

◮ Objects collaborate ◮ Objects = data and behaviour

→ Object-orientation

◮ Advantage

◮ Easy to adapt

→ Design for change

◮ CRC cards lead to distributed control

Contents

From Requirements to Design CRC Cards Components (part Ia) Object-orientation: Centralized vs Decentralized Control/Computation Summary

Next Week:

◮ UML Class Diagrams

◮ Read/Skim the lectures notes and the UML user manual on

classes and class diagrams

◮ Send me questions and UML class diagrams for discussion

by Monday 26.2

◮ What is unclear to you? ◮ What would you like to hear more about? ◮ Why is this feature used in this digram? ◮ What does this notation in this diagram mean? ◮ . . . ◮ I am going to answer the questions and discuss your class

diagrams in the lecture → Your questions and diagrams determine the lecture