3.3 Class Diagrams Subject/Topic/Focus: ❍ Class Diagrams: Modeling Static Structure Summary: ❍ Perspectives: Conceptual, Specification, Implementation ❍ Attributes, Operations and Methods ❍ Associations, Navigability, Aggregation, Composition, Association Classes ❍ Generalization, Interfaces, Abstract Classes ❍ Multiple and Dynamic Classification ❍ Parameterized Classes Literature: ❍ Fowler ❍ Rumbaugh OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.1 Class Diagrams: Overview ClassClass diagramsdiagrams describedescribe thethe typestypes ofof objectsobjects inin thethe systemsystem andand thethe variousvarious kindskinds ofof staticstatic relationshipsrelationships thatthat existexist amongamong them.them. ❍ There are two principal kinds of static relationships: • associations – “a customer may rent a number of videos” • subtypes – “a student is a kind of person” ❍ Class diagrams also show the attributes and operations of a class and the constraints that apply to the way objects are connected. OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.2 3.3.1 Role of Class Diagrams Use Case Diagrams structures Activity Diagrams are refined by Interaction Diagrams inter-class behavior: scenarios: describe control flow describe typical interaction between classes Class Diagrams sequences between classes structuring intra-class behavior: describe states and Package Diagrams state transitions State Diagrams in classes ClassClass diagrams diagrams are are central central for for analysis, analysis, design design and and implementation. implementation. ClassClass diagrams diagrams are are the the richest richest notation notation in in UML. UML. OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.3 From Use Cases to Class Diagrams The requirements list of a company includes the following textual description of the use case „order“: order customer Textfile Textfile Order:Order: WeWe have have customers customers who who order order our our products. products. WeWe distinguish distinguish corporate corporate customers customers from from personal personal customers, customers, since since corporatecorporate customers customers are are billed billed monthly monthly whereas whereas personal personal customers customers needneed to to prepay prepay their their orders. orders. WeWe want want our our orders orders to to be be lined lined up up product product by by product. product. EachEach line line should should contain contain the the amount amount and and the the price price of of each each product. product. OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.4 3.3.2 Example: Order - Associations Order Customer * 1 Association Multiplicity Order:Order: WeWe have have customers customers who who may may order order several several products. products. WeWe distinguish distinguish corporate corporate customers customers from from personal personal customers, customers, since since corporatecorporate customers customers are are billed billed monthly monthly whereas whereas personal personal customers customers needneed to to prepay prepay their their orders orders with with a a credit credit card. card. WeWe want want our our orders orders to to be be lined lined up up product product by by product. product. EachEach line line should should contain contain the the amount amount and and the the price price of of each each product. product. OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.5 Example: Order - Generalization Order Customer * 1 Generalization Corporate Personal Customer Customer Order:Order: WeWe have have customers customers who who order order our our products. products. WeWe distinguish distinguish corporate corporate customers customers from from personal personal customers, customers, since since corporatecorporate customers customers are are billed billed monthly monthly whereas whereas personal personal customers customers needneed to to prepay prepay their their orders orders with with a a credit credit card. card. WeWe want want our our orders orders to to be be lined lined up up product product by by product. product. EachEach line line should should contain contain the the amount amount and and the the price price of of each each product. product. OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.6 3.3.3 Example: Order - More Associations Order Customer * 1 Role name 1 Line item * Order Line * 1 Product Corporate Personal Customer Customer Order:Order: WeWe have have customers customers who who order order our our products. products. WeWe distinguish distinguish corporate corporate customers customers from from personal personal customers, customers, since since corporatecorporate customers customers are are billed billed monthly monthly whereas whereas personal personal customers customers needneed to to prepay prepay their their orders orders with with a a credit credit card. card. WeWe want want our our orders orders to to be be lined lined up up product product by by product. product. EachEach line line should should contain contain the the amount amount and and the the price price of of each each product. product. OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.7 Example: Order- Attributes & Operations Order Customer dateReceived isPrepaid Attributes name number:String address price:Money Operations creditRating() dispatch() close() Order:Order: WeWe have have customers customers who who order order our our products. products. WeWe distinguish distinguish corporate corporate customers customers from from personal personal customers, customers, since since corporatecorporate customers customers are are billed billed monthly monthly whereas whereas personal personal customers customers needneed to to prepay prepay their their orders orders with with a a credit credit card card.. WeWe want want our our orders orders to to be be lined lined up up product product by by product. product. EachEach line line should should contain contain the the amount amount and and the the price price of of each each product. product. OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.8 3.3.4 Example: Order - Full Class Diagram Order Multiplicity: mandatory Customer dateReceived * 1 name isPrepaid address number:String price:Money Association creditRating() Generalization dispatch() Constraint close() 1 {If Order.customer.creditRating Role name is “poor”, then Order.isPrepaid Corporate Personal must be true} Customer Customer Line item * Attributes contactName creditCard# creditRating Order Line Operations creditLimit Multiplicity: optional quantity:Integer Remind() * 0..1 * 1 billforMonth(Int) Employee price:Money Product isSatisfied:Bool Multiplicity: many-valued OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.9 Perspectives There are three perspectives (views) you can use in drawing class diagrams: ❍ Conceptual • represents the concepts relating to the classes • provides language independence ❍ Specification • represents the software interfaces • hides the implementation ❍ Implementation • shows the real classes used in the programming language • maps directly to the implementation OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.10 3.3.5 Attributes CustomerCustomer Attributes namename addressaddress ❍ Attributes may be specified at different levels of detail: • At the conceptual level a customer’s name attribute indicates that customers have names. • At the specification level, this attribute indicates that a customer object can tell you its name and you can set the name. • At the implementation level, a customer has a field or an instance variable for its name. ❍ The UML syntax for attributes, depending on the level of detail: visibility name: type = default-value ++ identifier identifier : :String String = = “Mr. “Mr. Noname” Noname” OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.11 Operations CustomerCustomer Operation creditRating()creditRating() ❍ Operations are the processes that a class knows to perform. ❍ They correspond to the methods of a class in an OO language. ❍ At specification level operations correspond to public methods on a class. • Normally you do not show those methods that simply set or get attribute values. ❍ In the implementation view usually private and protected methods are shown. ❍ The use of UML syntax for operations may vary with the level of detail: visibility name(parameter-list) : return-type-expression {property string} ++ creditRating(for creditRating(for : :Year) Year) : :Rating Rating {abstract} {abstract} OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.12 3.3.6 UML Meta Description visibility name(parameter-list) : return-type-expression {property string} ❍ Visibility is + : for public, i.e., every other class can see this. – : for private, i.e., only this class can see this. # : for protected, i.e., only subclasses can see this. ❍ Identifier is defined by a string. ❍ Parameter-list contains (optional) arguments whose syntax is the same as that for attributes, i.e., name, type and default value. ❍ Return-type-expression is an optional, language-dependent specification that specifies the type of the return value (if any). ❍ Property-string indicates property values that apply to the given operation, e.g., if this operation is abstract (not implemented in this class, but in subclasses). ++ creditRating(for creditRating(for : :Year) Year) : :Rating Rating {abstract} {abstract} OOA&D © J.W. Schmidt, F. Matthes, TU Hamburg-Harburg 3.3.13 Operations vs. Methods ❍ An operation is something that is invoked on an