Presentation is loading. Please wait.

Presentation is loading. Please wait.

Kyung Hee University Class Diagramming Notation OOSD 담당조교 석사과정 이정환.

Similar presentations


Presentation on theme: "Kyung Hee University Class Diagramming Notation OOSD 담당조교 석사과정 이정환."— Presentation transcript:

1 Kyung Hee University Class Diagramming Notation OOSD 담당조교 석사과정 이정환

2 Kyung Hee University Introduction  A class diagram is a static model that defines the system’s legal object configurations  Any objects that exist during the system’s execution must be instances of classes in the class diagram, and any relationships between those objects must be instances of associations between those object’s classes  A class diagram, therefore, is a key component of an object-oriented design

3 Kyung Hee University Introduction (cont’d)  UML offers a very rich class-diagramming notation  Basic class concepts and notation  Links and associations  Uncommon association notation  Aggregation  Class specialization  Dependencies  Notes  Extension mechanisms  A class diagram for order processing

4 Kyung Hee University Basic Class Concepts and Notation  The most fundamental concepts of object- oriented design and programming are classes and objects  Class definitions exist in the implementation source code. So, in that sense, a class diagram defines the overall static structure of a system

5 Kyung Hee University Basic Class Concepts and Notation (cont’d)  Classes and Objects  A class defines a collection of similar instances. It exists at compilation time and serves as a type. It defines the interface and implementation of its instances  An object is a particular instance of a class. Each object represents a particular instance of something in the problem or solution domain and is created as needed

6 Kyung Hee University Basic Class Concepts and Notation (cont’d)  Generally an object must have there properties  Identity  State  behavior

7 Kyung Hee University Basic Class Concepts and Notation (cont’d)  Attributes and Methods Figure 1. UML notation for attributes

8 Kyung Hee University Basic Class Concepts and Notation (cont’d) Figure 2. UML notation for operation

9 Kyung Hee University Basic Class Concepts and Notation (cont’d)  The expanded Java definition of the class is Class order { private int orderNumber; private float totalPrice; public void cancel() { /* implementation omitted here */ } public void commit() { /* implementation omitted here */ }

10 Kyung Hee University Basic Class Concepts and Notation (cont’d)  Class Attributes and Methods Figure 2. UML notation for class attributes and methods

11 Kyung Hee University Basic Class Concepts and Notation (cont’d)  When you need a generate a unique order number for each Order  A simple solution is to keep a running count of the number of orders that have been created and to use that count as an Order’s order number

12 Kyung Hee University Basic Class Concepts and Notation (cont’d) Class order { private static int numberOfOrders //…… public static int numberOfOrders() { /* implementation omitted here */ } //…… }  This means that there will be a single copy of the numberOfOrders fields that is shared by all Order instances

13 Kyung Hee University Basic Class Concepts and Notation (cont’d)  Notations for Method Categories and Class Compartment  Constructor : Initializes the instance (It is invoked only when an instance is created)  Query : Returns a value but does not change the state of the instance  Update : Carries out some action that may change the state of the instance  Destructor : Handles any cleanup required by the deletion of an instance (It is invoked only when an instance is deleted)

14 Kyung Hee University Basic Class Concepts and Notation (cont’d) Figure 3. Depicting the purpose of a method

15 Kyung Hee University Basic Class Concepts and Notation (cont’d)  Actors as Classes  External agents are called actors in UML. They interact with system, but are not a part of the system itself.  They are included in the class diagram so the way that they interact with the objects in the system can be modeled  UML treats actors as special stereotyped classes  Unlike a normal class, however, an actor class is a black box because you don’t have to implement it or understand its internal details

16 Kyung Hee University Basic Class Concepts and Notation (cont’d) Figure 4. The Telephone Agent actor class

17 Kyung Hee University Links and Associations  Links and Associations  Elements in class and object diagrams are not “islands”  Association between classes represents a structural property among the classes where the instances of one class may be linked to the instances of another Figure 5. A link between an Order and its Customer

18 Kyung Hee University Links and Associations (cont’d)  An object’s links to other objects may change at execution time

19 Kyung Hee University Links and Associations (cont’d)  Associations between Classes  An association is a relationship between classes in a class diagram Figure 6. An association between the Order and Customer classes

20 Kyung Hee University Links and Associations (cont’d)  Association Implementations  The association between Order and Customer described in Figure 6 must be implemented in both directions  An Order instance holds a reference to a single Customer instance Class Order { private Customer recipient; //… }

21 Kyung Hee University Links and Associations (cont’d)  The recipient field is of Customer type, meaning that you can store a reference to a Customer instance in that field  You can access that Customer instance using the contents of that field Class Order { private Customer recipient; //… Public String customerName() { return recipient.name(); }

22 Kyung Hee University Links and Associations (cont’d)  The customername method returns the results of calling the name method in this Order’s Customer object

23 Kyung Hee University Links and Associations (cont’d)  Ternary and Reflexive Associations

24 Kyung Hee University Links and Associations (cont’d)  While ternary (and lager) associations are permitted in UML, you should normally try to avoid them during design

25 Kyung Hee University Links and Associations (cont’d)  One reason is based on human cognition : Such associations are not intuitive and are somewhat difficult to describe  Another problem with ternary associations is that they have no standard implementation idioms  UML also allows reflexive (or recursive) associations in which a class has on association with itself

26 Kyung Hee University Links and Associations (cont’d)  Value versus Reference Semantics  Consider the class diagram in the next Figure. According to this diagram, each Customer instance will have a name (String) and a link to an Account instance.  If String is a class(as it is in Java, Smalltalk, and many C++ class libraries, including the C++ Standard Library), both the attribute and the association will be implemented as object references  Why,then,is one modeled as an attribute and the other as an association ?

27 Kyung Hee University Links and Associations (cont’d)  The difference between the two is that name has value semantics, whereas the Account link (in the act field) has reference semantics.  What’s difference ?  Identity  Sharing  Cardinality of values  Direction of navigation

28 Kyung Hee University Links and Associations (cont’d)

29 Kyung Hee University Links and Associations (cont’d)  Role Names  A class inherently plays a role in an association in which participates. From the Order’s point of view, the Customer is playing the role of a recipient – that is the Customer is the one who receives the contents of the Order Figure 7. Specifying the Customer’s role in the association

30 Kyung Hee University Links and Associations (cont’d)  One benefit of role names is that they can indicate (or be mapped to) instance variable names Class Order { private Customer recipient; //… }  Observe that the field name is recipient, which is the role Customer plays in its relationship with an Order

31 Kyung Hee University Uncommon Association Notation  Qualified association  A qualified association is an association in which an object on one end can employ a key to select either one, or a subset of the instances on the other end Figure 8. An association from Product Catalog to Catalog Item

32 Kyung Hee University Links and Associations (cont’d)


Download ppt "Kyung Hee University Class Diagramming Notation OOSD 담당조교 석사과정 이정환."

Similar presentations


Ads by Google