02291: System Integration Components (Part Ia) Hubert Baumeister - - PowerPoint PPT Presentation

02291: System Integration

Components (Part Ia) Hubert Baumeister

huba@dtu.dk

DTU Compute Technical University of Denmark

Spring 2020

Software architecture

Software architecture ◮ building blocks: components ◮ glue: connectors ◮ ports: interfaces to the

• utside

Decompose the system into smaller components and their interconnection ◮ Components based on business responsibilities

Components

Components: replaceable piece of software → Resuable → Pluggable

Company Clearing− Bank ATM BC BankATM AB CB BA

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

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)

Implementing components by components

UML User Manual, Grady Booch

◮ External ports are mapped to some port of a subcomponent.

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

Port BC Port BA <<interface>> BankToClearingCompany pinOK pinNotOk <<interface>> ClearingCompanyToBank verifyPIN(a,p) <<interface>> BankToAtm verifyPIN(a,p) withdraw(a,m) BankToATMPort verifyPIN(a,p) withdraw(a,m) pinOK pinNotOk Account number : IBAN balance : int withdraw(amount:int): bool ... Customer name address ... <<interface>> AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk Bank name: String ... pinOK pinNotOk accountFor(a): Account ... 1 atm * 1 b * c * 1..* 1..* 1 cc

◮ Rules for classes implementing components

◮ Provided interfaces must be implemented by some class ◮ Required interfaces must 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

Realizing components through programming

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

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

Defining components

◮ Take your use cases ◮ Execute the use case scenarios using CRC cards ◮ Play with the level of abstraction

◮ Start with ”hardware” components ◮ Do the ”hardware” components have ”software” subcomponents? ◮ How are your components realized with classes?