Class And Object Diagram

CLASS DIAGRAM
classes were not identified systematically. Because
we have now gone through the processes of business
requirements modeling and system requirements
modeling, we have a good source of candidate classes
in the form of system use cases.
Candidate classes are often indicated by nouns in the
use cases.
A class diagram shows us what classes exist and how they’re
related. (Officially, class diagrams can also show attributes and
operations, but that requires a lot more space.) In the case of
aggregation, composition and association, the class diagram
shows permitted run-time relationships rather than actual ones.
Relationships between classes are shown as lines with various
annotations. Even without particular knowledge of UML, its easy
to pick information out of a class diagram, just from the text.
Although the relationships on a class diagram are usually drawn
between classes, the run-time relationship is actually between
objects
 Attributtes

An attribute is a property of an object, such as its size, position, name,

price, font, interest rate, or whatever. In UML, each attribute can be given
a type, which is either a class or a primitive. If we choose to specify a type,
it should be shown to the right of the attribute name, after a colon. (We
might choose not to specify attribute types during analysis, either
because the types are obvious or because we don’t want to commit
ourselves yet.)
Attributes can be shown on a class diagram by adding a compartment
under the class name. To save space, we can document them separately
instead as an attribute list, complete with descriptions. If we were using a
software development tool, we would expect to be able to zoom in to see
attributes (and their descriptions) or zoom out to see class names only. If
you can’t provide a short description for an attribute at this stage,
perhaps it should be several attributes, or even a class in its own right.
The system itself, for example, ‘system’ or ‘iCoot’: As far as we’re
concerned, the system is just a boundary for the development effort.
Actors, for example, Assistant or Head Office: An exception to this is
when we need to store information about an actor internally (for
example, for Member, we need to store a password). Most of the
time, actors are anonymous driving forces for our boundaries.
Boundaries, for example, ‘customer applet’ or ‘head office link’: At
this stage, we’re trying to identify business-related objects with
interesting information and behavior. Boundaries are particular
pieces of software that allow actors to get at our objects.
Trivial types (for example, strings and numbers): We can assume
that these will be provided by the implementation language or its
libraries.
 Class relationships
Inheritance: A subclass inherits all of the attributes and behavior of its
superclass(es).
Association: Objects of one class are associated with objects of another class.
Aggregation: Strong association – an instance of one class is made up of
instances of another class.
Composition: Strong aggregation – the composed object can’t be shared by
other objects and dies with its composer.
Inheritance is a different kind of relationship to the other three: inheritance
describes a compile-time relationship between classes while the others
describe a run-time connection between objects. According to the UML
standard, all run-time relationships come under the umbrella term
association. However, most people use the term ‘association’ to mean ‘an
association that isn’t aggregation or composition’.
Choosing between relationships can be tricky – you need to use intuition,
experience and guesswork. During analysis, you should expect the frequency
of these kinds of relationship to be:
association > aggregation > inheritance > composition
 Drawing relationships

 shows how inheritance is depicted on a class diagram: a

white filled arrowhead on a solid line is drawn from the
subclass to the superclass. In order to emphasize
hierarchies of subclasses, the arrows can be combined in
the style shown on the left. Thus, SportsCar and Saloon are
both subclasses of Car.
 Associations Classes

Occasionally, an association has some information or

behavior related to it. An association class can be
introduced alongside the association, For each link,
there is a corresponding Reservation object that has a
number, time-stamp and state. There is no name given
to the association in this case, because it is implicit in
the name of the association class.
An association class represents attributes and
operations that exist only because the association
exists: the attributes and operations are not tied to the
objects at either end of the association.
 Aggregation is drawn as a line between two classes with a
white diamond on the aggregator’s end.

 Composition is drawn in a similar way to aggregation, but

with a black diamond on the composer’s end.

 Association is shown as an undecorated line. Thus, a

Driver is associated with a Car, but the Driver is not part
of the Car (that would be aggregation) and the Driver is
not always part of a single Car (that would be
composition).
 Multiplicity

All relationships except inheritance can indicate at either end the number
of run-time objects that are allowed to take part in the relationship (the
multiplicity of the relationship):
 n: Exactly n.
 m..n: Any number in the range m to n (inclusive).
 p..*: Any number in the range p to infinity.
 *: Shorthand for 0..*.
 0..1: Optional.
For composition, the multiplicity at the composer’s end is always 1

because, according to the UML rules, a composed object can’t be shared

among composites – thus a multiplicity would be redundant in this case.
In other cases, if no multiplicity is shown, we must assume that it has not
been specified, or that it is simply not known at this stage. It would be
wrong assume that a missing multiplicity implied some default value,
such as 1.
One to one
One to many
Many to many
Associations, Labels and Comments
All relationships, except inheritance, can be given an association label,
indicating the nature of the association. If it’s not obvious which way the
association name should be read, a black arrowhead can be used.
As well as association names, we can show roles. A role indicates the part
played by an object in the association – the role is shown as a label near
the object that plays the role.
nprinciple, association names and roles can be combined on the same
association, but most of the time they should be considered alternatives
(in order to avoid clutter).
UML comment, an arbitrary piece of text enclosed in an icon that looks
like a piece of paper, connected to the relevant part of the diagram by
means of a dashed line. If the target of the dashed line is unclear, we can
put a small white circle with a black border at the end – this is useful
when the target is another dashed line, for example. A comment, which
can appear on any diagram, can be used to provide extra information
that would be difficult or messy to show using other UML notation.
As far as UML is concerned, attributes and associations (all
three varieties) are just properties of a class. In other words,
every attribute can be shown as an attribute or as an
association with the attribute’s name as the role (although
an association to a primitive value an array would look
odd). This means that we can add multiplicities to
attributes, after the type name, as in *, for a multi-valued
attribute, or [0..1], for an optional attribute. This UML’s
way of avoiding the thorny issue of whether we should show
an attribute or an association in any particular case. In this
book, multiplicities won’t be shown for attributes, except in
the case of optional attributes.
 Adding operations to class

Every message on a communication diagram

corresponds to an operation on a class, so we should
record the operations in order to have a complete set
of use case realizations. Operations can be shown on
a class diagram in a separate compartment below the
attribute Compartment.
 Abstract class

An abstract class is a class with at least one abstract

method – the abstract method may be introduced on
the class itself, or it may be inherited from a
superclass.
Abstract classes have the following advantages:
 They permit richer and more flexible modelings
 They lead to more code sharing, because we can write concrete
methods that use abstract methods;
 Visibility

The visibility of a field specifies which pieces of code are

allowed to read or modify the value.
The following visibilities are enough for most purposes:
Private (shown by - in UML): Only visible within the
defining class.
Package (shown by ˜ in UML): Visible within the defining
class and to all classes in the same package.
Protected (shown by # in UML): Visible within the defining
class, to all classes in the same package, and to all subclasses
of the defining class (whether inside or outside the package).
Public (shown by + in UML): Visible everywhere.
 Package

The UML concept of a package allows us to group related classes.

The package diagram in Figure 9.10 shows each package as a box
with a tab at the top left corner. The package name appears in bold,
either in the middle of the box or, if we want to show the contents of
the package, inside the tab. The contents of a package can be classes
or other packages. In sample, also shows a dependency (the dashed
open-ended arrow) from one package to another: the implication is
that the source package uses something inside the target package.
So far, we’ve discussed what could be referred to as the constituent
pieces of a package diagram:
 Package notation
 Element visibility
 Dependency relationship
 A package can be used to represent:

a layer
a subsystem
a reusable library
a framework
classes that should be deployed together
Many developers will use a package diagram to show layers.
However, there are a couple problems with this approach.
Firstly, layers are chosen before any decision about how
organize source code into packages has been made (and the
organization may well be different). Secondly, a package
diagram doesn’t allow us to show some important information;
for example, the existence of the HTTPCGILayer in iCoot is
important, but it doesn’t map any package that we might
implement or borrow from a library (it’s simply an indication
that we use the HTT P protocol with the CGI extras).
Package diagrams are also not good at showing horizontal
partitions (subsystems); a deployment diagram should be used
instead.
Classes and objects are separate yet intimately related concepts.
Specifically, every object is the instance of some class, and every class
has zero or more instances. For practically all applications, classes
are static; therefore, their existence, semantics, and relationships are
fixed prior to the execution of a program. Similarly, the class of most
objects is static, meaning that once an object is created, its class is
fixed. In sharp contrast, however, objects are typically created and
destroyed at a furious rate during the lifetime of an application.

Although UML allows us to mix classes and objects on the same

diagram, people generally use the term class diagram if there are no
objects and object diagram if there are no classes (it’s up to you what
you call a diagram that has both).
 Constraints

A constraint is the expression of some semantic condition that must

be preserved. Stated another way, a constraint is an invariant of a
class or relationship that must be preserved while the system is in a
steady state. We emphasize steady state because there may be
transitory circumstances wherein the state of the system is changing
(and thus is temporarily in a self-inconsistent state), during which
time it is impossible to preserve all the system’s constraints.
Constraints are guarantees that apply only when the state of the
system is stable. Preconditions and postconditions are examples of
constraints that apply while a system is in a steady state, that is, at the
specific points in time when an operation is invoked and when it is
completed .
The placement of a constraint in a visual diagram depends on the
number of diagram elements affected by the constraint.
Placement of Constraints

Number of Constraint Placement

Diagram
Elements
One 1. In note attached to element by dashed line.
2. Near element.

Two 1. In note attached to each element by dashed line.

2. Near dashed line connecting elements. Dashed line may
have arrowhead on the end pointing to first position in
the collection
Three or more 1. In note attached to each element by dashed line.
2. For associations (including generalizations, aggregations,
and compositions), attached to dashed line crossing
the associations.
Complete: An instance of the supertype is an
instance of at least one of the subtypes.
Incomplete: An instance of the supertype is not an
instance of at least one of the subtypes.
Disjoint: There are no common instances among the
classifiers.
Overlapping: There are common instances among
the classifiers.
 Object Diagrams

An object diagram is used to show the existence of objects and their
relationships in the logical design of a system. Stated another way, an
object diagram represents a snapshot in time of an otherwise transitory
stream of events over a certain configuration of objects. Object diagrams
are thus prototypical—each one represents the structural relationships that
may occur among a given set of class instances. In this sense, a single
object diagram represents a view of the object structure of a system. During
analysis, object diagrams are often used to indicate the semantics of
primary and secondary scenarios that provide a trace of the system’s
behavior. During design, object diagrams are often used to illustrate the
semantics of mechanisms in the logical design of a system. Regardless of
the development phase, object diagrams present concrete examples that
assist in the visualization of the associated class diagrams.
The two essential elements of object diagrams are objects and their
relationships.
 Object Diagrams

 Similar to class diagrams, a horizontal line partitions the text inside the
icon into two regions, one denoting the object’s name and the other
providing an optional view of the object’s attributes and their values.
Here, though, we see a tool-specific implementation that does not use a
horizontal line to completely partition the two regions.
 Object diagrams are useful for illustrating a particular run-time
scenario, but they’re optional. For clarity, we would prefer to avoid
putting classes and objects on the same diagram.
 objectName Object name only
 :ClassName Object class only
 objectName :ClassName Object name and class
For some objects, it may be useful to expose a portion or all of their attributes.
We say “some” because objects represent only a view of the object structure. The
name of each of these attributes must refer to an attribute defined in the object’s
class or any of its superclasses. The syntax includes the ability to specify a value
for each attribute We do not show class properties, such as operations, since they
are shared by all instances of the class.
Objects interact through their links to other objects which is an object diagram. A
link is an instance of an association, analogous to an object being an instance of a
class. A link may exist between two objects if and only if there is an association
between their corresponding classes. This class association may manifest itself in
any way, meaning that the class relationship could be a plain association, a
generalization, an aggregation, or a composition. The existence of an association
between two classes therefore denotes a path of communication (i.e., a link)
between instances of the classes, whereby one object may send messages to
another. All classes implicitly have an association to themselves, and hence it is
possible for an object to send a message to itself.
We’ve discussed objects and their relationships, which
constitute the essential parts of the notation for object
diagrams. However, a number of particularly knotty
development issues require slightly more than this basic
notation. As we warned in our discussion on class diagrams,
we must again emphasize that these advanced features
should be applied only as necessary to capture the intended
semantics of a scenario.
Using the same representation as for class diagrams,
additional notations that we may represent on object
diagrams include constraint, keyword label, navigation, and
link name.