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 BankATM verifyPIN verifyPIN withdraw Clearing− Bank ATM Company CB BC AB BA pinOk pinOk pinNotOK pinNotOK withdrawOK withdrawNotOk 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 Provided Interface by port BA by port BA Clearing Company Bank ATM Provided Interface Required Interface Port BC Port BA by port BA by port BA 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) Bank ATM «interface» AtmToBank pinOK pinNotOK withdrawOk withdrawNotOk • 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» «interface» I1 I2 «refine» m 1 m 1 C1 C2 m 2 m 3 m 3 Bank component with Implementation Bank component seen from the outside Bank ClearingCompanyToBank BankToATMPort «delegate» «delegate» * * «delegate» «delegate» Bank BankToClearingCompany Account Customer Bank component seen from the inside Detailed Class Diagram for the Bank Component 3
«interface» BankToATMPort BankToAtm verifyPIN(a,p): bool verifyPIN(a,p): bool withdraw(a,m): bool * Account withdraw(a,m): bool number : IBAN balance : int «interface» AtmToBank withdraw(amount:int): bool ... pinOK 1 atm pinNotOK withdrawOk 1..* withdrawNotOk Bank «interface» 1..* name: String BankToClearingCompany Customer 1 b ... pinOK name pinOK pinNotOk address c pinNotOk * * ... accountFor(a): Account «interface» ... ClearingCompanyToBank verifyPIN(a,p) 1 cc 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
Recommend
More recommend
