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 outside Decompose the system into smaller components and their interconnection ◮ Components based on business responsibilities

Components Components: replaceable BankATM piece of software Clearing− Bank ATM Company CB BC BA AB → 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 BankATM verifyPIN verifyPIN withdraw Bank ATM Clearing− Company CB BC AB BA pinOk pinOk pinNotOK pinNotOK withdrawOK withdrawNotOk

Example Bank–ATM: Configuration (composite structure diagram) :BankATM atm 0 :ATM :AB c:Clearing− b:Bank :BA Company :CB :BC :BA atm 1 :ATM :AB

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 Required Interface Provided Interface by port BA by port AB Port AB Clearing Company Bank ATM Provided Interface Required Interface Port BC Port BA by port BA by port AB

Port BA <<interface>> BankToAtm verifyPIN(iban:IBAN, pin:int) withdraw(iban, amount:Money) Bank ATM <<interface>> AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk «interface» «interface» I1 I2 «refine» C1 m 1 m 1 C2 m 2 m 3 m 3

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 ClearingCompanyToBank BankToATMPort BankToAtm «delegate» «delegate» * * «delegate» «delegate» Bank BankToClearingCompany AtmToBank Account Customer

Detailed Class Diagram for the Bank Component Port BA <<interface>> BankToATMPort BankToAtm verifyPIN(a,p) verifyPIN(a,p) withdraw(a,m) Account * withdraw(a,m) pinOK number : IBAN pinNotOk balance : int <<interface>> AtmToBank withdraw(amount:int): bool ... pinOK 1 atm pinNotOK withdrawOk 1..* withdrawNotOk Bank 1..* name: String Port BC 1 b Customer ... name pinOK <<interface>> address c BankToClearingCompany pinNotOk * * ... accountFor(a): Account pinOK ... pinNotOk <<interface>> ClearingCompanyToBank 1 cc verifyPIN(a,p) ◮ 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?