1 / 32

Class Diagramming Notation

Class Diagramming Notation. OOSD 담당조교 석사과정 이정환. Introduction. A class diagram is a static model that defines the system’s legal object configurations

vickiem
Télécharger la présentation

Class Diagramming Notation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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. 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. 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. 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. Basic Class Concepts and Notation (cont’d) • Generally an object must have there properties • Identity • State • behavior

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

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

  9. 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. Basic Class Concepts and Notation (cont’d) • Class Attributes and Methods Figure 2. UML notation for class attributes and methods

  11. 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. 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. 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. Basic Class Concepts and Notation (cont’d) Figure 3. Depicting the purpose of a method

  15. 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. Basic Class Concepts and Notation (cont’d) Figure 4. The Telephone Agent actor class

  17. 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. Links and Associations (cont’d) • An object’s links to other objects may change at execution time

  19. 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. 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. 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. Links and Associations (cont’d) • The customername method returns the results of calling the name method in this Order’s Customer object

  23. Links and Associations (cont’d) • Ternary and Reflexive Associations

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

  25. 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. 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. 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. Links and Associations (cont’d)

  29. 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. 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. 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. Links and Associations (cont’d)

More Related