Course "UML and Design Patterns" of module "Software Engineering and Design", version February 2011 (X)

Transcription

1 UML Class Diagrams Prof. Dr. Eric Biel Course "UML and Design Patterns" of module "Software Engineering and Design", version February 2011 (X) BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 1 of 32

2 Learning Goals You'll learn: Modeling UML classes UML class properties, attributes, and operations Multiplicities of associations Programming interpretations of UML classes Bidirectional associations Generalization BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 2 of 32

3 Readings [Fowler]: UML Distilled, Martin Fowler, third ed., Addison-Wesley, ISBN [Jeckle]: UML 2 glasklar, Mario Jeckle et al., 2. Auflage, Hanser Verlag, ISBN See also: [UML-Home]: [UML-Specification]: Not all readings are cited in the text that follows. BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 3 of 32

4 Why Modeling? Models abstract from concrete (implementation) details. Models allow, for example: to express structures A B A 1 0..* B to express structural relationships C A 1 0..* B to express temporal behavior A B C loop to express state-based behavior Wait event DoIt otherevent BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 4 of 32

5 Why Modeling (cont'd) Models allows (in general more easily than code): to communicate (first, early) ideas on parts of the software to document aspects of the software And: code can be generated from models (MDA: model driven architecture; executable UML) BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 5 of 32

6 Modeling Levels Models can express different degree of details. Thus, you can: create models for the conceptual-analytical level: abstractness: high, details not expressed A B preciseness: low details: none executable: no create models for the design level: abstractness: lower preciseness: higher details: (some) details are expressed executable: perhaps implementation language independent D 0..* C A 0..* C abstract model is transformed into a more refined one B C' BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 6 of 32

7 What is the UML? The UML... provides a set of (graphical) notations for the modeling and documentation and... of (software) systems has notational elements for expressing the static (structural) and the dynamic (temporal) aspects of a system BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 7 of 32

8 Some UML Diagrams class diagram object diagram package diagram use case diagram sequence diagram activity diagram BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 8 of 32

9 Sample Class Diagram (borrowed from [Fowler]) attributes operations Order datereceived: Date [0..1] ispaid: Boolean [1] number: String [1] X price: Money dispatch close lineitems OrderLine datereceived: Date [0..1] ispaid: Boolean [1] not X * navigable 1 1 X Product * {ordered} multiplicity * 1 association {if Order.customer.getCreditRating is poor then Order.isPrepaid must be true} role name comment contactname X creditrating creditlimit name [1] address [0..1] dispatch close Corporate Customer billformonth(integer) remind() * salesrep Employee Customer Personal Customer creditcardnumber BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 9 of 32 X 0..1 generalization {getcreditcardrating() == poor } constraint String Date class classes used as types of attributes Money Boolean

10 UML Class compartment (each of it is optional) Order class name datereceived: Date [0..1] ispaid: Boolean [1] number: String [1] price: Money dispatch close a class attributes operations Attributes Format: visibility? /? name :type? multiplicity? =default? {property}* 1 Examples + customer : int - address : String [1.. *] # code : String = Test {readonly} 1 X? denotes zero or one occurrence, {X}* denotes zero or more occurrences of the referenced X. BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 10 of 32

11 Attributes (cont'd) Visibility: private: -, protected: #, package: ~, public: + Meaning: UML gives not a precise definition. Convention here: as in Java Convention: If no visibility markers are given then read private visibility for attributes. / : derived attribute: value can be calculated from other properties (= attributes, etc.) Name: Type: Typically corresponds to the name of a field in Java. Restriction on the range of values of an attribute. Multiplicity: see below Default value: The value for a newly created object if the attribute isn't specified during creation. BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 11 of 32

12 Attributes (cont'd) {property-string} indicates additional properties of the attribute. Explained in chapter Advanced Concepts of UML Class Diagrams. BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 12 of 32

13 Associations properties as attributes properties as associations Date association 0..1 * Order +datereceived: Date [0..1] +ispaid: Boolean [1] +lineitems: OrderLine [*] {ordered} multi-valued property / attribute Order association Date Boolean OrderLine Boolean multiplicity A B Can navigate from :A to :B A B Cannot navigate from :A to :B 1 * lineitems {ordered} OrderLine association navigability BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 13 of 32

14 Associations (cont'd) The name of a property goes at the target end of the association, together with its multiplicity. There is a small difference, however, for expressing multiplicities: multiplicities can be expressed at both ends of an association line When using attributes or associations? Use attributes for small things : booleans, strings, dates Use associations to relate classes with business meaning : orders, order items, products, customers employee, employee,... Notice: Attributes and associations, respectively, are properties of a class. BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 14 of 32

15 Multiplicity Multiplicity of a property (I.e., attribute or association): An indication of how many values may fill the property. Format on an attribute: [indication] see next slide Examples: A car has four wheels: wheels : Wheel [4] A student registers with many modules: modules : Module [0..*] A student has one address: address : Address [1] BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 15 of 32

16 Multiplicity (cont'd) The most common multiplicity indications: 0..1: The property may or may not have a value. 1..1: The property has exactly (and always) a value. Usually denoted as 1 only. Default ([Fowler]). shorthand: * 0..*: The property has zero or more values. 1..*: The property has one or more values. n..m: The property has at least n and at most m values. BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 16 of 32

17 Programming Interpretation of Properties There is no one way to interpret properties in code. Most common way:! a UML public property is mapped onto: a private field plus getter and setter methods (as in Java) a property (as in C#) BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 17 of 32

18 *) See: Programming Interpretation: Single-Valued Property UML class diagram excerpt: OrderLine +price {readonly} +quantity A first, implementation-focused interpretation of property price : 1 public class OrderLine { 2 private int quantity; private Money price; 3 private Product product; public int getquantity() { return this.quantity; } 6 public void setquantity(int q) { this.quantity = q; } 7 public Money getprice() { 8 return this.price.multiply(this.quantity); 9 } 10} 1 +product Product *) Value Object: an object whose attributes cannot be changed after initialization! Returns a new Money object having the value of the base price multiplied by quantiy. BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 18 of 32

19 Programming Interpretation: Single-Valued Property (cont'd) Another, more interface-oriented interpretation of property price : 1 public class OrderLine { 2 private int quantity; 3 private Product product; // get/set quantity as before 6 7 public Money getprice() { 8 Money priceofproduct = this.product.getprice(); 9 Money subtotal = 10 priceofpruduct. multiply(this.quantity); 11 return subtotal; 12 } 13} ==> No field for price! OrderLine +price {readonly} +quantity +price 1 Product +product BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 19 of 32

20 Class Money: Value Object 1 public final class Money { final class means that there cannot be subclasses 2 private final BigDecimal value; final means that value can be assigned 3 only once (in the constructor) 4 public Money(BigDecimal value) { 5 if (val == null) throw new IllegalArgumentException( Value... ); 6 this.value = value; test necessary to guarantee 7 } properly initialized object 8 9 public BigDecimal getvalue() { an instance of BigDecimal is 10 return this.value; immutable 11 } 12 public Money multiply(int factor) { 13 return new Money(this.value.multiply(factor)); 14 } 15} multiplies a Money object by a factor and returns a NEW Money object BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 20 of 32

21 Programming Interpretation: Multivalued Attributes If an attribute is multivalued, this implies that a collection is used for the values If the multiplicity of a property is ordered (with / without duplicates) the collection must be ordered: List<OrderLine>,... not duplicates (with / without order) the collection should, strictly, be unordered: Set<Order>,... but often used: List<Order>,... no arrays ( [] ), please: OrderLine[] lineitems; How many? ==> you don't know So don't use an array! (Unless there are other forces...) BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 21 of 32

22 Programming Interpretation: Multivalued Attributes (cont'd) Multivalued properties yield a different interface to single-valued properties: 1 public class Order { 2 private List<OrderLine> lineitems = new ArrayList<OrderLine>(); 3 4 public List<OrderLine> getlineitems() 5 return Collections.unmodifiableList( 6 this.lineitems); 7 } 8 public void addlineitem(orderline item) { 9 this.lineitems.add(item); 10 } 11 public void removelineitem(orderline item) {// Option: discussed during the lecture. 12 this.lineitems.remove(item); 13 } 14} Principle: Information Hiding, i.e., the client of this class need not know which concrete implementation is used for the list. Alternatively, you may return a boolean indicating whether the underlying collection was changed or not. BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 22 of 32

23 Bidirectional Associations Bidirectional association: A pair of properties linked together. Example: Person owner * +cars You may omit the arrows < or > or the X sign. However, you must use these signs to express navigability. Car The Car class has the property: owner : Person [0..1] The Person class has the property: cars : Car [0..*] By convention, omitting the arrows at both ends of the association is still a bidirectional association. 1 1 In UML, omitting the arrows leaves the navigability undefined. BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 23 of 32

24 Bidirectional Associations (cont'd) You can name an association, the name is owns : Here, too: You may omit the arrows < or > or the X sign. However, you must use these signs to express navigability. Person owner owns +cars * Car BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 24 of 32

25 Bidirectional Associations (cont'd) Implementing a bidirectional association is a little bit tricky. Key point: both properties have to be kept in sync. For example: 1 public class Car { Idea: Bidirectional association is 2 private Person owner; managed by the Car side. 3 public Person getowner() { return this.owner; } 4 5 public void setowner(person p) { 6 if (this.owner!= null) { this.owner.friendcars().remove(this); } 7 this.owner = p; 8 if (this.owner!= null) { this.owner.friendcars().add(this); } 9 } 10} BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 25 of 32

26 Class Person looks like (assuming the same package): 1 public class Person { 2 private Set<Car> cars = new HashSet<Car>(); 3 public Set<Car> getcars() { 4 return Collections.unmodifiableSet(this.cars); 5 } 6 public void addcar(car acar) { 7 if (acar!= null &&!this.cars.contains(c)) { 8 acar.setowner(this); 9 } 10 Set<Car> friendcars() { return this.cars; } 15} Friends (here: Car objects) are allowed to update the collection of cars. Notice the visibility! If a Person instance gets a new car then the updating of the association is delegated to the Car instance. BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 26 of 32

27 Operations Operations are the actions that a class knows to carry out. attributes -attr1 : Type1... SomeClass Format: operations visibility? name (parameter*): return-type? {property*}? +method1(p1 T1,...): Tr. Examples + getname() : String {query} # runtest (in count : int = 5) : int - op3 (inout p1 : Address) ~ op4 (out p2 String [1..*] {ordered}) : SomeType BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 27 of 32

28 Operations (cont'd) Visibility: private: -, protected: #, package: ~, public: + Convention: If no visibility markers are given then read public visibility for operations. The name is a string. Parameter: a parameter for the operation, see below. Return-type: The type of the returned value, if there is one. Property-string: Properties of the operation. Among others, such properties are: {query} object state not changed Principle:... {modifier} object state changed Command-Query Separation Principle [B. Meyer] BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 28 of 32

29 Operations (cont'd) Format of a parameter: direction? name: type? =default-value? no corresponding possibility in Java... The name, type, and default are the same as for attributes. direction: nothing or in : The parameter is input. out : The parameter is output: inout : The parameter is input and output. Idea: Program and use a Holder class in Java. BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 29 of 32

30 Operations (cont'd) Modifier versus query operations, Command-Query separation principle (Betrand Meyer) modifier: changes the (observable) state of an object query: gets a value (or a collection of values) from an object without changing the state of the object Operation versus method: operation: invoked on an object (~ procedure declaration or signature) method: the operation's code or body setting/getting (getter) methods getting method: returns a value (or a collection of values) from a field / property setting method: puts a value (or a collection of values) into a field / property BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 30 of 32

31 Generalization Order From the example above: Employee * 1 Corporate C. Customer Personal C. PersonalCustomer and CorporateCustomer have similarities (attributes, operations). The similarities can be placed in a general Customer class (the supertype). On a conceptual level, CorporateCustomer is a subtype of Customer if all instances of CorporateCustomer are also instances of Customer. CorporateCustomer is then said to be a special kind of Customer. Everything we say about a Customer associations, attributes, operations is true also for CorporateCustomer. One programming language interpretation: (implementation/class) inheritance. * 1 BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 31 of 32

32 Generalization (cont'd) Important principle Substitutability: Important Principle: Liskov Substitution Principle (LSP) Wherever the type Customer is used in the program, an instance of CorporateCustomer can be used instead. Instances of different classes may behave differently (due to polymorphism), but the caller need not worry about this. This substitutability is also referred to as the Liskov Substitution Principle (LSP for short) BFH/TI/Software Engineering and Design/UML and Design Patterns/UML Class Diagrams/February 2011 (X)/Prof. Dr. E. Dubuis Page 32 of 32