02291: System Integration Hubert Baumeister hub@imm.dtu.dk Spring - - PDF document

02291: System Integration

Hubert Baumeister

hub@imm.dtu.dk

Spring 2011

Contents

1 Recap 1 2 Components (part Ib) 2 3 Class Diagrams 4 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Attributes and Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Notes and Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 Constraints and Stereotypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6 Derived Properties / Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.7 Generalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.8 Abstract class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.9 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.10 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.11 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.12 Association Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.13 Using Qualified Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.14 Three-way association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 Summary 26

1 Recap

Recap

• Development from Requirements to design
• 1. Define the basic system architecture (can be refined later)
• 2. Use CRC cards to execute the use case scenarios

∗ Improved system architecture / class design ∗ Design of the behaviour of the system → could be documented using interaction diagrams

• 3. Define the components with their ports an interfaces more precisely
• Components

– Replacable units of software – Has ports with provided– and required interfaces ∗ Provided Interface: Operations offered by the component through the port ∗ Required interface: Requirement on the environment 1

• CRC cards

– Class, Responsibility, Collaboration – Design technique for designing OO software

• Object-orientation: decentralized– vs. centralized control

2 Components (part Ib)

Problem for the connection of components

pinNotOK pinOk verifyPIN verifyPIN withdraw pinOk pinNotOK withdrawOK withdrawNotOk

Company Clearing− Bank ATM BC BankATM AB CB BA

Interconnecting Components How can we assure that the components work together? What can go wrong

• One component sends a message that the other does not understand
• One component sends a message that the other does not expect at this time
• One component waits for a message that is not sent by the other component
• One component does not do what one expects from it
• . . .

Solution Ports contain information about

• Which operations are provided by a port
• Which operations are required by a port
• How do two components talk to each other

→ (protocol) state machines the expected message exchange between two components

• What can another component expect from an operation provided by a component?

→ Design by contract

Required Interface by port BA Provided Interface by port BA Required Interface by port BA Provided Interface by port BA Port BA Port BC ATM Clearing Company Bank

2

Port BA

• PortBA provides BankToAtm and requires AtmToBank
• PortAB provides AtmToBank and requires BankToAtm

«interface» BanktToAtm verifyPIN(iban:IBAN, pin:int) withdraw(iban, amount:Money) «interface» AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk ATM Bank

• Note that the provided interface of one port need not exactly match the required interface by the other component

→ It suffices if the provided interface has all operations needed by the required interface (here represented as a refine dependency)

«interface» I1 m 1 m 2 m 3 «interface» I2 m 1 m 3 C2 C1 «refine»

Bank component with Implementation Bank component seen from the outside Bank component seen from the inside

Bank Bank Customer Account ClearingCompanyToBank

*

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

Detailed Class Diagram for the Bank Component 3

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

Components

• A component models the (conceptual) structure of a system

– Difference to packages: A package structures a model

• Ideally components can be exchanged easily because of their defined ports (required and provided inter-

faces)

• Components need not have a runtime representation
• Conceptually components are implemented by one or several classes implementing the port interfaces
• Components can be implemented using a variety of technologies

– Enterprise Java Beans – CORBA – COM/DCOM – .NET – Java Beans – ...

3 Class Diagrams

3.1 Introduction

Class Diagrams

• The UML diagram type used most
• Describes the type of objects in a system and their static relationships
• A class can correspond to

– a concept ∗ real world 4

∗ from a software domain ∗ ... – a Java/C++/Smalltalk/C# ... class – a business entity – an entity in an entity relationship diagram – ...

• Literature: Martin Fowler, UML Distilled

Overview Class Diagram Class Diagrams and Program Code

• Class Diagrams were indented as a means to graphically show object-oriented programs
• As a consequence: Class Diagrams allow one to model all the structural features of a Java class

– e.g. classes, (static) methods, (static) fields, inheritance, . . .

• However class diagrams are more abstract than programs

– Concepts of associations, aggregation/composition, . . . → Modelling with class diagrams is more expressive and abstract than programming in Java → It is important to learn who these abstract, object-oriented concepts embodied in class diagrams are imple- mented in Java programs → Improves your object-oriented design skills 5

Class With Read-Only Attributes

C +a: int {read only}

• Alternative: No setter method; value is set on construction time

public class C { private int a; public int getA() { return a; } public C(int a) { this.a = a; } }

3.2 Attributes and Operations

Attributes

visibility name:type multiplicity = default {property-string}

• Visibility

– public (+), private (-), protected (#), package (∼)

• Multiplicity

– lower bound .. upper bound ∗ 1 ∗ 0..1 ∗ * – optional: lower bound is 0 – mandatory: lower bound is 1 or more – single-valued: upper bound is 1 – multivalued: upper bound greater than 1 or *

• Property-string

– e.g. {readOnly} – {ordered} Operations

visibility name (parameter-list) : return-type {property-string}

+balanceOn (date: Date) : Money

• visibility as with attributes
• property-string

– e.g. {query} ∗ Operation does not change the observable state of the object

• Some tools also allow the Java convention for writing operations

– visibility return-type name(parameter-list) {property-string} ∗ Money balanceOn(Date date) 6

3.3 Associations

Associations

• Multiplicity

– The same as with attributes – lower bound .. upper bound – *

• Navigability

– Default is navigability in both directions – Indicated by an arrow in the direction of the navigation – Non navigability is indicated by a x instead of an arrow – If navigability indication is missing then navigability can be either way ∗ Common interpretation: no arrows → biderectional navigation; one arrow → navigability only in this direction – Usually navigability is used to indicate which programming language class should have the field rep- resenting the association Associations

• Role names

– Default is the class name of the association end – Name is used in plural when the multiplicity is multivalued

• Association names

Attributes and Associations

• Attributes and (navigable) associations can be used interchangeably

7

When to use attributes, when to use associations?

• Attributes

– For standard datatypes (e.g. String, Integer etc.) or value types – When the target class does not appear in the class diagram but the attribute should be shown

• Associations

– When the target class appears in the class diagram – When the relationship between the two classes is important

3.4 Notes and Comments

Notes and Comments

3.5 Constraints and Stereotypes

Keywords

• Not everything is expressible purely graphical

→ Use of keywords to express

• 1. Constraints
• 2. Stereotypes

8

Constraint

• Notes can be constraints
• Constraints can be informal or formal

– With formal constraints, usually the Object Constraint Language (OCL) is used Constraint constraint A constraint restricts a set of possibilities; e.g. a constraint can be used to set attribute values. Abstract Class 9

• Uses curly bracketse.g. {isAbstract = true}
• Refers to a constraint on the model element (in this case the attribute isAbstract should be true in the shown

class)

• Alternative notation:{abstract}

(Standard) Stereotype Stereotype A stereotype with a model element denotes a subclass of that model-element on the meta-model level. Interface 10

• Uses guillemetsEx. interface in a class
• Refers to a specific meta class

– in this case to subclass Interface of class Classifier

3.6 Derived Properties / Associations

Derived attributes

• Attributes / associations are marked with a slash (/)
• Needs constraints to explain how they are derived

11

Derived associations

3.7 Generalisation

Generalisation

• General Rule

– Each instance of the specific classifier is also an indirect instance of the general classifier. → Liskov-Wing Substitution Principle – If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g., correctness). → Note, that this usually implies more than has the same attributes and operations! – i.e.: The execution traces of the specific classifier will be a superset of the execution traces of the general classifier. – UML 2.0 ∗ {substitutable} constraint for a generalisation

• may be implemented as inheritance but
• 1. only structural substitutabiliyt
• 2. this is not always possible because of single inheritance

Generalisation Example 12

Generalisation Sets

• New in UML 2.0!
• Allows for multiple and dynamic classification
• Generalisations can belong to different Generalisation Sets

– Each generalisation set describes the generalisations of a class regarding to different dimensions – Instances ∗ can thus belong to several classes from different generalisation sets (multiple inheritance) ∗ can belong to one or several classes within one generalisation set Example 13

Keywords

• {complete} / {incomplete}

– No more subclasses may be added – It is possible to add further subclasses

• {disjoint / overlapping}

– Instances may only belong to one class – Instances can belong to several classes in the same generalisation set

• Default: {incomplete} and {disjoint}

Generalisation Set: Notations (II) 14

3.8 Abstract class

Abstract class

• Similar as in Java one can mark a class or an operation as being abstract, i.e., some of the operations are not

implemented

• Instead of using the {abstract} keyword, the name of class can be written in italics

3.9 Interfaces

Interfaces

• Correspond to interfaces in Java / C++
• Define a contract that a class that realizes the interface has to fulfil
• Interface descriptions can contain operations and attributes (in contrast to Java, where interfaces can only

contain operations) Example: Abstract classes and Interfaces 15

Requires and implements interface dependency

• As dependencies
• Lollipop notation
• Pre UML 2.x notation

16

3.10 Dependencies

Dependencies

• Dependencies show which class/association/... depends on which class/association/...
• Most dependencies are informal

– e.g. A is presentation class for domain object B Dependencies

• UML defines keywords for special dependencies e.g. for classes

call The source calls an operation in the target create The source creates instances of the target derive The source is derived from the target instantiate The source is an instance of the target permit The target allows the source to access the targets private features realize The source is an implementation of a specification or interface defined by the target refine Refinement indicates a relationship between different semantic levels substitute The source is substitutable for the target trace Used to track such things as requirements to classes or how changes in one model link to

changes elsewhere

use The requires the target for its implementation

• but also for, e.g., use cases

includes A use case includes another use case extends A use case extends another use case at some extension point

3.11 Aggregation

Shared Aggregation

• General ”part of” relationship

17

• Notation: empty diamond
• From the UML specification

– ”Precise semantics of shared aggregation varies by application area and modeller.” (from the UML 2.0 standard) Composite Aggregation

• To be used in a ”part of” relationship
• Notation: filled diamond
• Much more restricted than with aggregation
• The basic two properties of a composite aggregation are:
• 1. A part can only be part of one object
• 2. The life of the part object is tied to the life of the containing object

Composite Aggregation

• A part can only be part of one object
• Allowed

18

• Not Allowed

Composite Aggregation

• The life of the part object is tied to the life of the containing object

→ If the containing object dies, so does the part object 19

20

Composite Aggregation

• But: A part can be removed before the composite object is destroyed

21

22

3.12 Association Classes

Association classes Links in associations can have attributes Implementing Association Classes Association classes can be transformed to three classes and two associations between them Implementing Association Classes (II) But the implementiation is semantically not equivalent to the original association class

• It allows more situations than the original one

23

• The following is not allowed for association classes

Enumerations

• Values are given by enumerating them
• Values are given by sybmolic names have no substructure
• The elements / instances of that data type all listed and given symbolic names (e.g. red, white, blue)

3.13 Using Qualified Associations

Qualified Associations

• A family of associations

– for each element of the qualifier type one association 24

• Qualified associations are implemented as maps

Qualified Associations The importance lies in possible restrictions in multiplicity

• Example: The above qualified association imposes the constraint that for each order there can only be at

most one order line for a given product

• Allowed situation

Qualified Associations (II) Forbidden situation

3.14 Three-way association

Using a ternary association 25

4 Summary

Summary

• Components have

– ports; ports have – interfaces: 1) for the operations they offer 2) for the operations they require – Interface conformance when connecting two port ∗ the operations required by one components port need to be provided by the other components port provided operations – Components are implemented by classes that implement the provided interfaces and use the required interfaces

• Class diagrams

– Motivated by OO languages to present their concepts graphically – Are more abstract than program code – Relations between classes ∗ Generalization ∗ Association ∗ Dependencies 26