BSc (Honours) in Computing /

Information Systems
REQ120130 - Requirement Engineering

Class Diagrams

@Lanka Nippon BizTech Institute

ACKNOWLEDGEMENT

Presented by: Ms.C.D.Padmaperuma

Contributors:

Reviewed by: Prof.K.P.Hewagamage

Requirement Engineering | Software Processes

Class Diagrams
UML

 UML is a visual modelling Language

 visual --- UML documents are a diagrams.
 modelling --- UML is for describing systems
 systems --- may be software systems or
domains (e.g. business systems), etc.
 It is semi-formal
 The UML definition tries to give a reasonably well
defined meaning to each construct.
Classes and Class Diagrams

 Classes
 Fields and Operations
 Association
 Composition
 Generalization
 Interfaces and Abstract Classes
Classes

 Classes are specifications for objects

 Consist of (in the main)
 A name
 A set of attributes (aka fields)
 A set of operations
 Constructors: initialize the object state
 Accessors: report on the object state
 Mutators: alter the object state
 Destructors: clean up
Java representation of a class

Name
class Student { Attributes
private long studNum ;
private String name ;
public Student( long sn, String nm ) { Operations
studNum = sn ; name = nm ; }
public String getName() { return name ; }
public long getNumber() { return studNum ;}
}
UML Representation of a class

Note: UML model may contain more info.

Classes in UML

UML can be used for many purposes.

 In software design UML classes usually
correspond to classes in the code.
 But in domain analysis UML classes are
typically classes of real objects (e.g. real
students) rather than their software
representations.
Usage of (software) classes

A class C can be used in 3 ways:

 Instantiation. You can use C to create new
objects.
 Example: new C()
 Extension. You can use C as the basis for
implementing other classes
 Example: class D extends C { … }
 Type. You can use C as a type
 Examples: C func( C p ) { C q ;… }
Relationships Between Classes

 Association
 Aggregation
 Composition
 Dependence
 Generalization
Association Relationships

 Two classes are “associated” if each instance of one

may be associated with instances of the other.
 Associations are typically named.
 Associations are often implemented with pointers
Multiplicity Constraints

 Each Department is
associated with one
DepartmentHead and at
least one
DepartmentMember
 Each DepartmentHead
and DepartmentMember
is associated with one
Department
 No constraint means
multiplicity is unspecified
Role names

 Role names may be

given to the ends of an
association
 Only name roles when
it adds clarity
Navagability

 An arrow-head
indicates the direction
of navigability.
 E.g. Given a student
object, we can easily
find all Sections the
student is taking.
 No arrow-head: means
navigability in both
directions.
Implementing navigable associations

Usually implemented with fields

class Student {
private List<Section> sections ; … }
class Department {
private DepartmentHead deptHead ; … }

*
Implementing associations indirectly

 An association between objects might also

be stored outside of the objects
class Department {
private static
Map<Department,DepartmentHead> heads =
new<Department,DepartmentHead> HashMap();

DepartmentHead getHead() {
return heads.get(this) ; }
…
}
Aggregation

 Aggregation is a special
case of association.
 It is used when there is
a “whole-part”
relationship between
objects.
Composition

 Composition is a special case of aggregation.

 Composition is appropriate when
 each part is a part of one whole
 the lifetime of the whole and the part are the
same.
 Graphically it uses a solid diamond

Student Student
Record Number
Recursive associations

 Associations may relate

an class to itself.
 The objects of the class
may or may not be
associated with
themselves.
 (For example, the left and right
children of a node would not
be that node. But a
GraphNode object might be its
own neighbour.)
Associations vs. attributes

 Both are usually implemented by fields (a.k.a. data

members).
 Use attributes for primitive types such as integer,
boolean, char, etc, and pointers to such.
 Use association (or aggregation) for pointers that
point to classes or interfaces.
 Use composition for data members that are classes.
(Not possible in Java).
 Use composition if the life time of the part is identical
to or contained in the lifetime of the whole.
Degrees of belonging

 Attribute. Lifetime of attribute equals life time

of object that contains it.
 Composition. Lifetime of the part equals or is,
by design, nested within the lifetime of the
whole.
 Aggregation. Whole-part relationship, but
parts could be parts of several wholes, or
could migrate from one container to another.
 Association. Relationship is not part/whole.
Generalization/Specialization

 Represents “is-a-kind-
of’’ relationships.
 E.g. every Chimp is
also an Ape.
 In OO implementation it
represents class
inheritance: Inheritance
of interface and of
implementation too.
Interfaces

 Interfaces are classes

that have no associated
implementation.
 I.e.
 no attributes,
 no implementations for
any operations
 In UML use either
stereotype to indicate
an interface, or
“lollypop”
Realization

 Classes “specialize”
classes, but “realize”
interfaces. Similar
concept, similar
notation. (Note dashes)
 Choice of notations.
Diagrams at right are
equivalent.
Generalization/Specialization and Realization in Java

UML terminology Java terminology

C specializes D C extends D
C realizes D C implements D

class TestCharInput
extends TestInput
implements CharSource
{
…
}
The Substitution Principle

Suppose class C specializes class D

or class C realizes interface D
 Then any properties that should hold true of
all D objects should hold true of all C objects.
 Question:
 Should Rectangle specialize Square, or
 should Square specialize Rectangle, or
 neither should specialize the other?
 More on this later.
Abstract and Concrete classes

 Classes that have abstract operations can not be

instantiated --- since this would mean that there is
no implementation associated with one of the
object’s operations
 Classes that can not be instantiated are called
abstract classes.
 Classes that can be are called concrete
 In UML use the <<abstract>> stereotype for abstract
classes and operations.
 Alternatively: The name of the abstract class or operation is
in italics.
Dependence

A class C depends on class D if the

implementation or interface of C mentions D.
 C extends D or implements D
 C has a field of type D or pointer to D or array of D
 C creates a new D
 C has an operation that has a
 parameter
 local variable
 return type
of type D of a pointer to D or an array of D etc.
Dependence

 Often dependence is implicit in generalization or

association relationships.
 When it is not, you may want to indicate
dependence explicitly.
 Stereotypes and documentation can add detail.
Dependence

 Dependence relations are important to note

because unneeded dependence makes
components
 harder to reuse in another context
 harder to isolate for testing
 harder to write/understand/maintain, as the
depended on classes must also be understood
 It is better to depend on an interface than on
a class.
 More on this later.
Association Classes

 Sometimes associations need attributes themselves.

 An employment relationship between an employer and
employee might have a employee number associated
with it.