Classes and UML Class/Object Diagrams

Class/Object Concepts

• Characteristic properties of an object
  • identity -- name
  • state -- the current collection of data held by an object
  • behavior -- defined by its operations (functions)
• In C++ and Java, a class is a user-defined type
  • defines the layout of an object (like a blueprint for objects)
  • specifies the member data variables (state) and member functions (behavior)
• Object is an instance of a class
• Common relationships between classes
  • Dependency ("uses")
  • Aggregation / Composition ("has-a")
  • Generalization / Inheritance ("is-a")

Dependency

• One class manipulates objects of another class type in some way
• Example: an object passed into a member function of another class, for use inside
• Good Design Goal: Minimize the number of dependency relationships (to reduce coupling between classes)
  • Coupling: the strength of dependencies between two classes

Aggregation

• This is the "has-a" relationship
• Implemented by creating an object of one type (or a pointer or reference) as member data of another class type
• Also known as composition
  • Some designers differentiate, considering composition a stronger form of aggregation -- such that contained objects should not exist independent of their container
• General aggregation also used for things like embedding objects in a manager class (this would not be the strong "composition" form)

Inheritance

• "is-a" relationship -- subclasses and superclasses
• Inheritance used well can lead to powerful and extensible designs
, taking advantage of polymorphic behavior of objects
• There's more overhead involved in polymorphism (virtual functions, etc), so inheritance should not be overused
• Aggregation relationships will typically be more common in designs

UML Class/Object Diagrams

Representing classes

• Classes depicted as rectangles
• Only the name is mandatory, but box can be split into three compartments, for class name, attributes (data), and behaviors (methods)
• Can use names of attributes and methods, or give full signatures
• Formats for full signatures in a UML class diagram:

    For attributes --     attribute_name : type
    For methods --        method_name( list_of_parameters) : return_type
  

• Examples of full signatures (suppose class name is Student):

    // Attributes
    lastName : String
    firstName : String
    age : int
  
    // Methods
    getName() : String
    setAge( val : int ) : boolean
    compareGPA ( other : Student ) : int
  

• Note: Often full signatures are omitted for simplifying a diagram. So if you see methodName(), you cannot assume it has no parameters
• Can represent public, private, and protected
  • public: +
  • private: -
  • protected: #
• Some CASE tools may use more graphical symbols for these access levels
  • Rational Rose uses a blank sheet icon for public, a key icon for protected, and a lock icon for private
• For abstract classes, italicize the class name

Representing Objects

• Rectangle with name, or with 3 compartments, just like a class
• For objects, underline the name. Can also refer to class type, using attribute notation above:

   bob : Student
  

• Other compartments are for attributes and methods -- same as in class diagrams. Although it's more common here to omit the full signatures
• For attrributes, common to list initial values:

    lastName = "Smith"
    firstName = "John"
    age = 24
  

Representing Relationships

• Basic association is a line drawn between classes
  • Can have labels indicating the role that the association plays
  • Example: if Course and Student are classes, one role might be: a Student "registers for" a Course. Can use the label "registers for" on the association line
• Multiplicity -- numeric labels on ends of association lines, to indicate how many instances of each class in a given relationship.
  • N: exactly N
  • *: zero or more
  • 1..*: one or more
  • x..y: at least x, and no more than y (range)
• Aggregation is a line with a diamond at one end
  • Use an open diamond for general aggregation
  • Can use a filled-in diamond for the stronger "composition" form
  • Diamond is on the "aggregate" end (the containing class)
  • Always good to include multiplcities on the "contained" end
• Inheritance is a line with a closed arrow (a triangle) at one end
  • Arrow points to the parent class
• There are some other relationship connector types. We may look at some of these later on:
  • Dependency (dotted line with open arrow) - - - - - >
  • Directed association (solid line, open arrow) ------>
  • interface type implementation (dotted line, closed arrow). Useful for differentiating between inheritance and interfaces in Java

Tips for building good class diagrams and designs

• If a class has tons of attributes, perhaps some should be grouped into other classes
• Use either aggregation or an attribute for a particular feature, but not both.
  • Example: Student class may have a String object for it's lastName variable. So either use aggregation between String and Student, or just list as an attribute
  • In this example, listing it as an attribute is better, since String is such a commonly used class
• Use aggregation only if a class actively manages objects of another type.
  • A classroom "has" students in it, but does the Classroom class actually keep track of the student objects? If not, don't use aggregation
• Should not aim for a comprehensive diagram showing ALL classes and relationships (and attributes and methods) in a system. Especially in large software systems
  • That huge of a diagram would just be an unreadable mess
  • Each class diagram should focus on a specific view, and only include the elements that are relevant to that design aspect
  • Omit distractions!

Links