Chapter 16: UML Class Diagrams

1
Chapter 16 UML Class Diagrams

• 16.1 Introduction
• We already used UML Class Diagrams for domain
  modeling during analysis.
• As with the previous chapter this is just a
  reference chapters
• Many of the notation introduced will only be
  described much later on in the course
• 16.2 Common Class Diagram Notation
• Most elements in class diagrams are optional.
• See Figure 16.1 for a summary of the notation.

2
Figure 16.1 Class Diagram Notation Summary
3

• 16.3 From Domain Model to Design Model
• In the same way as the domain model included
  conceptual class diagram, vision, use cases etc.,
  the design model includes design class diagrams,
  interaction and package diagrams (etc.).
• From analysis to design we move from a conceptual
  view to a software view of the problem

4

• 16.4 Class Attributes Visualisation
• Attributes can be shown visually for class
  associations or in text for basic data types
  only

• Semantically, showing attributes as text or as
  visual association is equivalent the code will
  be the same e.g. for the above
• public class Register
• private int id
• private Sale currentSale
• private Store location
• //

5

• The full format of the attribute text notation
  is
• visibility name type multiplicity default
  property-string
• Visibility marks include (public) and
  (private).
• In a design class diagram the associations have
  the following properties (using the previous
  diagram as example)
• a navigability arrow pointing from the source
  (Register) to target (Sale) object, indicating a
  Register object has an attribute of one Sale
• a multiplicity at the target end, but not the
  source end
• a rolename (currentSale) only at the target end
  to show the attribute name
• no association name
• As mentioned, association ends can have a role
  name, show a multiplicity value but also have a
  keyword
• Examples of keywords include ordered to
  indicate that the elements of a collection are to
  be kept in some kind of order by the data
  structure that will hold the many target objects
  associated with the source object.

6

• We can even specify what data structure should be
  used to hold the many objects (e.g. a List) use
  the user-defined keyword List

• We should prefer the visual version rather than
  the text version

7

• 16.5 Operations and Methods
• Operations syntax in UML is
• visibility name (parameter-list) return-type
  property-string
• Operations are usually assumed public if no
  visibility is shown.
• Property-string contains additional information,
  such as exceptions that may be raised, if the
  operation is abstract, etc.
• An operation is not a method. A UML operation is
  a declaration, with a name, parameters, return
  type, exceptions list, and possibly a pre-and
  post-condition (as in a contract). But, it isn't
  an implementation methods are implementations.
• A UML method is the implementation of an
  operation, it may be illustrated using
• An interaction diagram (which shows the details
  and sequence of messages)
• A note in a class diagram (using actual or
  pseudo-code)

8

• The create message in an interaction diagram is
  normally interpreted as the invocation of the new
  operator and a constructor call. If we wish we
  can show constructors in a class diagram.
• Accessor and mutator operations retrieve or set
  attributes, such as getPrice and setPrice. These
  operations are often excluded (or filtered) from
  the class diagram.
• 16.6 Keywords
• We have already seen some of these
• ltltactorgtgt
• ltltinterfacegtgt
• abstract
• ordered
• There are many other keywords available in the
  UML 2.0

9

• 16.8 Generalisation, Abstract Classes, Abstract
  Operations
• Generalisation relationship scan be shown on
  UMLs class diagram see Figure 16.1.
• Inheritance is specific to an OO programming
  language (e.g. Java and C inheritance
  mechanisms differ).
• Thus, the UML's generalisation relationship is
  not similar to an OOPL inheritance mechanism
  although they are, of course, likely to be very
  closely related the gap between an OO design and
  an OO implementation will be narrow.
• Abstract classes or operations are indicated
  using the abstract keyword.

10

• 16.9 Dependency Relationships
• The UML includes a general dependency
  relationship that indicates that a client element
  (of any kind, including classes, packages, use
  cases, and so on) has knowledge of another
  supplier element and that a change in the
  supplier could affect the client. Dependency is
  illustrated using a dashed arrow line from the
  client to the supplier.
• Dependencies shows coupling between UML elements.
• There are many kinds of dependency here are some
  common types in terms of objects and class
  diagrams
• having an attribute of the supplier type
• sending a message to a supplier the visibility
  to the supplier could be
• an attribute, a parameter variable, a local
  variable, a global variable, or class visibility
  (invoking static or class methods)
• receiving a parameter of the supplier type
• the supplier is a superclass or interface

11

• Of course many of these dependencies have already
  special UML notations e.g. for superclass,
  interface implementation and attributes as
  associations. So, for those cases, it is not
  useful to use the dependency line
• Guideline In class diagrams use the dependency
  line to depict global, parameter variable, local
  variable, and static-method (when a call is made
  to a static method of another class) dependency
  between objects.
• Example
• public class Sale
• public void updatePriceFor( ProductDescription
  description )
• Money basePrice description.getPrice()
• //
• //

12

• In this example the updatePriceFor method
  receives a ProductDescription parameter object
  and then sends it a getPrice message. Therefore,
  the Sale object has parameter visibility to the
  ProductDescription, and message-sending coupling,
  and thus a dependency on the ProductDescription.
  If the latter class changed, the Sale class could
  be affected. This dependency can be shown in a
  class diagram

13

• We can also annotate a dependency line with a
  label such as ltltcallgtgt, ltltcreategtgt etc. to
  indicate more precisely the type of dependency.
• 16.10 Interfaces
• Interfaces (classes that only contain pure
  abstract-virtual in C-operations an interface
  provides no implementation whatsoever) can be
  visualised in UML to show interface
  implementation (aka interface realisation in UML)
  and interface dependency.
• See Figure 16.2

14

• Figure 16.2 Different notations to show
  interfaces in UML.

15

• 16.11 Composition
• Aka composite aggregation is a strong kind of
  whole-part relationship and is useful to show in
  some models.
• A composition relationship implies that
• an instance of the part (such as a Square, a
  Finger) belongs to only one composite instance
  (such as one Board, one hand) at a time
• the part must always belong to a composite (no
  free-floating Fingers)
• the composite is responsible for the creation and
  deletion of its parts either by itself
  creating/deleting the parts, or by collaborating
  with other objects. Related to this constraint is
  that if the composite is destroyed, its parts
  must either be destroyed, or attached to another
  composite (no free-floating Fingers allowed!)

16

• Guideline The association name in composition is
  always implicitly some variation of "Has-part,"
  therefore don't bother to explicitly name the
  association.

17

• 16.12 Constraints
• Constraints may be used on most UML diagrams, but
  are especially common on class diagrams. A UML
  constraint is a restriction or condition on a UML
  element. It is visualized in text between braces
  for example size gt 0 . The text may be
  natural language or anything else, such as UML's
  formal specification language, the Object
  Constraint Language (OCL).

18

• 16.13 Qualified Association
• A qualified association has a qualifier that is
  used to select an object (or objects) from a
  larger set of related objects, based upon the
  qualifier key. Informally, in a software
  perspective, it suggests looking things up by a
  key, such as objects in a Hash Table.

19

• 16.14 Association Class
• An association class allows you treat an
  association itself as a class, and model it with
  attributes, operations, and other features. For
  example, if a Company employs many Persons,
  modelled with an Employs association, you can
  model the association itself as the Employment
  class, with attributes such as startDate.

20

• 16.15 Singleton Classes
• One OO design pattern that is very common is the
  singleton pattern a class with only one instance
  ever instantiated, never two.

21

• 16.16 Template Classes and Interfaces
• Many programming languages support templates (aka
  parameterised types or generics) they are widely
  used for data structures.
• E.g. you can define behaviour for sets in general
  by defining a template class Set
• class Set ltTgt
• void insert (T newElement)
• void remove (T anElement)
• When you have done this, you can use the general
  definition to make Set classes for more specific
  elements
• Set ltEmployeegt employeeSet
• You can also declare template interfaces.
• See below for a UML representation of the Set
  example

22
(No Transcript)
23

• 16.17 Conclusion
• As with the previous chapter on Interaction
  Diagrams, this chapter on Class Diagrams focused
  on the notation only there is no need to
  remember all of the notation that weve seen use
  these chapters as references
• We can view the class diagram as a summary of the
  static characteristics of the design elicited
  during the creation of the interaction diagrams.
• In practice we should reflect changes in the set
  of interaction diagrams as soon as possible the
  partial class diagram to gain an overview of the
  software classes.
• In the next few chapters we will review the much
  more important skills (over knowing the UML
  notation in details) of thinking in terms of
  objects to derive interaction diagrams and a
  class diagram.