Institut Universitaire et Stratégique de l’Estuaire

Estuary Academic and Strategic Institute (IUEs/Insam)

Sous la tutelleacadémique des Universités de Dschang et de Buéa.

LECTURE NOTES On Object Oriented Modeling (OOM) using UML (continuation)

SOFTWARE ENGINNERING LEVEL 200

COURSE FACILITATOR : Mr FOTSO ALAIN

Academic Year: 2020/2021

CHAPTER III: CLASS DIAGRAM

UML specification defines two major kinds of UML diagram: structure diagrams and
behavior diagrams.

Structure diagrams show the static structure of the system and its parts on different
abstraction and implementation levels and how they are related to each other. Structure
diagrams is very important in software development because its elements represent the
meaningful concepts of a system, and may include abstract, real world and
implementation concepts. Examples of structure diagrams include class diagram,
object diagram etc.

Behavior diagrams show the dynamic behavior of the objects in a system, which can be
described as a series of changes to the system over time. Example of behavior diagram
include use case diagram, activity diagram etc.

Class diagram is the main building block in object-oriented modeling. It is used to show
the different objects in a system, their attributes, their operations and the relationships
among them.
Class diagram is UML structure diagram which shows structure of the designed system
at the level of classes and interfaces, shows their features, constraints and
relationships - associations, generalizations, dependencies, etc
The following figure is an example of a simple class:

In the example, a class called “loan account” is depicted. Classes in class diagrams are
represented by boxes that are partitioned into three:
1. The top partition contains the name of the class.

2. The middle part contains the class’s attributes.

3. The bottom partition shows the possible operations that are associated with the
class. The example shows how a class can encapsulate all the relevant data of a
particular object in a very systematic and clear way. A class diagram is a collection of
classes similar to the one above.

The first one shows the class’s name, while the middle one shows the class’s attributes
which are the characteristics of the objects. The bottom one lists the class’s operations,
which represents the behavior of the class.
The class notation without the last two compartments is called a simple class and it
only contains the name of the class.

Interface

An interface is a class whereby only the various operations are described with the
attributes.

An interface is like a class, but has no attributes and none of its operations has
implementations.

Abstract Classes

Abstraction is the process of omitting details. We need this to understand complex

objects. Modern programming and modelling languages help us by providing the ideas
of an abstract class and an abstract operation.

An abstract class is a class that has one or more abstract operations. An abstract
operation is not implemented in its class but in classes that are derived from it. A class
with no abstract operations is called a concrete class. An abstract class defines an
incomplete framework into which you can plug in specific implementations.
For example, the class of Animals may be abstract class and Lion may be derived from
it. The Abstract Animal has an operation that returns the number of legs. Lions
implement this legs() operation as returning the number 4. Similarly, a Snake has 0 legs,
and a Bird 2 leg. Here is the UML diagram of the abstract class Animal with abstract

operations. The italic names indicate abstract classes and operations in the UML. The
diagram also shows that Lion, Snake, and Bird implement the abstract class. The

dashed generalization arrow indicates this.

An object that is declared to be in a concrete class (a Snake, Lion, or Bird above) has
defined behavior. If the concrete class implements or relizes an abstract class then the
object must satisfy the abstract operations. So Animal above is realized or
implemented by Lion, Snake, and Bird.

•How to Draw a Class Diagram

Class diagrams go hand in hand with object-oriented design. So knowing its basics is a
key part of being able to draw good class diagrams.

When required to describe the static view of a system or its functionalities, you would
be required to draw a class diagram. Here are the steps you need to follow to create a
class diagram.

Step 1: Identify the class names

The first step is to identify the primary objects of the system.

Step 2: Distinguish relationships

Next step is to determine how each of the classes or objects are related to one another.
Look out for commonalities and abstractions among them; this will help you when
grouping them when drawing the class diagram.

Step 3: Create the Structure

First, add the class names and link them with the appropriate connectors. You can add
attributes and functions/ methods/ operations later.

Relationships in Class Diagrams

Relationships in UML are used to represent a connection between structural, behavioral,

or grouping things. It is also called a link that describes how two or more things can
relate to each other during the execution of a system. Type of UML Relationship are
Association, Dependency , Generalization , and Realization.

We distinguish six types of relationships with class diagram as follows

Association

Association represents a relationship between two or more objects where all objects
have their own life cycle and there is no owner. We take an example of relationship
between Teacher and Student. Many students can have one teacher and one student
can have many teachers. But there is no ownership between the objects and both have
their own lifecycle. Both can be created and deleted independently.
 Other types of relationship in OOP include

Association is a relationship between classes, which is used to show that instances of

class could be either linked to each other or combined logically or physically into some
aggregation.

An association is usually drawn as a solid line connecting two classifiers or a single

classifier to itself. Name of the association can be shown somewhere near the middle
of the association line but not too close to any of the ends of the line. Each end of the
line could be decorated with the name of the association end.

Association Wrote between Professor and Book

with association ends author and textbook.

Inheritance

In OOAD inheritance is usually defined as a mechanism by which more specific classes

(called subclasses or derived classes) incorporate structure and behavior of more
general classes (called superclass’s or base classes).

Example: a dog and a cat are types of animal and can hesitate some features the

class animal as shown in the diagram below

Single Inheritance

When a class inherits from a single base class, it is known as single inheritance.

Multiple Inheritance

Multiple inheritance is implicitly allowed by UML standard, while the standard provides
no definition of what it is.

Classifier in UML can have zero, one or many generalization relationships to more
general classifiers. In OOAD multiple inheritance refers to the ability of a class to inherit
behaviors and features from more than one superclass.

Multiple inheritance for Consultant Manager and Permanent Manager - both inherit from
two classes

Multilevel Inheritance

When the inheritance is such that, the class A serves as a base class for a derived class
B which in turn serves as a base class for the derived class C. This type of inheritance is
called ‘MULTILEVEL INHERITENCE’. The class B is known as the ‘INTERMEDIATE BASE
CLASS’ since it provides a link for the inheritance between A and C. The chain ABC is
called ‘ITNHERITENCE*PATH’ for e.g
Aggregation

 Aggregation is a special form of Association where all objects have their own
life cycle but there is ownership. This represents whole-part or a-part-of
relationship. This is represented by a hollow diamond followed by a line.
We can take an example of relationship between Department and Teacher. A
Teacher may belong to many departments. Hence Teacher is a part of many
departments. But if we delete a Department, Teacher Object will not destroy.

Shared aggregation (aggregation) is a binary association between a property and one

or more composite objects which group together a set of instances. It is a "weak" form
of aggregation when part instance is independent of the composite. Shared aggregation
has the following characteristics:

 it is binary association,
 it is asymmetric - only one end of association can be an aggregation,
Composition

 Composition is a special form of Aggregation. In this relationship child

objects do not have their life cycle without Parent object. If a parent object is
deleted, all its child objects will also be deleted. Composition is based on
PART-OF - death relationship.

Composite aggregation (composition) is a "strong" form of aggregation with the

following characteristics:

 it is binary association,
 it is a whole/part relationship,
 a part could be included in at most one composite (whole) at a time, and
 if a composite (whole) is deleted, all of its composite parts are "normally" deleted
with it.

Note, that UML does not define how, when and specific order in which parts of the
composite are created. Also, in some cases a part can be removed from a composite
before the composite is deleted, and so is not necessarily deleted as part of the
composite.

Notation

Composite aggregation is depicted as a binary association decorated with a filled black

diamond at the aggregate (whole) end.

Folder could contain many files, while each File has exactly one Folder parent.
If Folder is deleted, all contained Files are deleted as well.

Generalization in UML

A generalization is a binary taxonomic (i.e. related to classification) directed

relationship between a more general classifier (superclass) and a more specific
classifier (subclass).
Each instance of the specific classifier is also an indirect instance of the general
classifier, so that we can say "Patient is a Person", "Savings account is an Account", etc.
Because of this, generalization relationship is also informally called "Is A" relationship.

Generalization is owned by the specific classifier.

A generalization is shown as a line with a hollow triangle as an arrowhead between the

symbols representing the involved classifiers. The arrowhead points to the symbol
representing the general classifier. This notation is referred to as the "separate target
style."

Checking, Savings, and Credit Accounts are generalized by Account

Generalization relationships that reference the same general classifier can also be
connected together in the "shared target style."

Checking, Savings, and Credit Accounts are generalized

Dependency in UML

Dependency is a directed relationship which is used to show that some UML element or
a set of elements requires, needs or depends on other model elements for specification
or implementation. Because of this, dependency is called a supplier - client relationship,
where supplier provides something to the client, and thus the client is in some sense
incomplete while semantically or structurally dependent on the supplier element(s).
Modification of the supplier may impact the client elements.

Dependency is a relationship between named elements, which in UML includes a lot of

different elements, e.g. classes, interfaces, components, artifacts, packages, etc. There
are several kinds of dependencies shown on the diagram below.
Dependency relationship overview diagram - usage, abstraction, deployment.

Usage is a dependency in which one named element (client) requires another named
element (supplier) for its full definition or implementation.

The abstraction relates two elements representing the same concept but at different
levels of abstraction.

A dependency is generally shown as a dashed arrow pointing from the client

(dependent) at the tail to the supplier (provider) at the arrowhead. The arrow may be
labeled with an optional stereotype and an optional name. Because the direction of the
arrow goes opposite to what we would normally expect, I usually stereotype it as client
«depends on» supplier.
Class SearchController depends on (requires) SiteSearch interface.

For many years UML specifications provide contradictory example of the dependency
shown below. The explanation for the Figure 7.38 of UML 2.4.1 specification states: "In
the example below, the Car class has a dependency on the CarFactory class. In this
case, the dependency is an instantiate dependency, where the Car class is an instance
of the CarFactory class."

Wrong: Car class has a dependency on the CarFactory class.

Right: CarFactory class depends on the Car class.

This example in fact shows opposite to what UML specification states. CarFactory
depends on the Car class. Car class could be defined without the knowledge of
CarFactory class, but CarFactory requires Car for its definition because it produces Cars.
It is also wrong to say that "... the Car class is an instance of the CarFactory class." The
Car class is instantiated by the CarFactory class.

It is possible to have a set of elements for the client or supplier. In this case, one or
more arrows with their tails on the clients are connected to the tails of one or more
arrows with their heads on the suppliers. A small dot can be placed on the junction if
desired. A note on the dependency should be attached at the junction point.

Dependency could be used on several kinds of UML diagrams:

 class diagram
 composite structure diagram
 package diagram
 component diagram
 deployment diagram

Here's some examples of dependencies:

Web Shopping package uses (depends on) Payment package.

Interface SiteSearch is realized (implemented) by SearchService.

Note, that abstraction dependency has a convention to have more abstract element as
supplier and more specific or implementation element as client but UML specification
also allows to draw it the opposite way.

Component UserService realized by UserServlet and UserDAO.

Realization

In a realization relationship of UML, one entity denotes some responsibility which is not
implemented by itself and the other entity that implements them. This relationship is
mostly found in the case of interfaces.

Realization can be represented in two ways:

Using a canonical form

Using an elided form

Visibility in UML

Visibility allows to constrain the usage of a named element, either in namespaces or in

access to the element. It is used with classes, packages, generalizations, element
import, package import.

UML has the following types of visibility:

 public
 package
 protected
 private

Note, that if a named element is not owned by any namespace, then it does not have a
visibility.

A public element is visible to all elements that can access the contents of the
namespace that owns it. Public visibility is represented by '+' literal.

A package element is owned by a namespace that is not a package, and is visible to

elements that are in the same package as its owning namespace. Only named elements
that are not owned by packages can be marked as having package visibility. Any
element marked as having package visibility is visible to all elements within the nearest
enclosing package (given that other owning elements have proper visibility). Outside the
nearest enclosing package, an element marked as having package visibility is not visible.
Package visibility is represented by '~' literal.

A protected element is visible to elements that have a generalization relationship to the

namespace that owns it. Protected visibility is represented by '#' literal.

A private element is only visible inside the namespace that owns it. Private visibility is
represented by '-' literal.
Operation executeQuery is public, isPoolable - protected,
getQueryTimeout - with package visibility, and clearWarnings is private.

If some named element appears to have multiple visibilities, for example, by being
imported multiple times, public visibility overrides private visibility. If an element is
imported twice into the same namespace, once using a public import and another time
using a private import, resulting visibility is public.

UML Constraint

A constraint is a packageable element which represents some condition, restriction or

assertion related to some element (that owns the constraint) or several elements.
Constraint is usually specified by a Boolean expression which must evaluate to a true or
false. Constraint must be satisfied (i.e. evaluated to true) by a correct design of the
system. Constraints are commonly used for various elements on class diagrams.

In general there are many possible kinds of owners for a constraint. Owning element
must have access to the constrained elements to verify constraint. The owner of the
constraint will determine when the constraint is evaluated. For example, operation can
have pre-condition and/or a post-condition constraints.

Constraint could have an optional name, though usually it is anonymous. A constraint is

shown as a text string in curly braces according to the following syntax:

constraint ::= '{' [ name ':' ] boolean-expression '}'

UML specification does not restrict languages which could be used to express
constraint. Some examples of constraint languages are:

 OCL
 Java
 some machine readable language
 natural language

OCL is a constraint language predefined in UML but if some UML tool is used to draw
diagrams, any constraint language supported by that tool could be applied.
For an element whose notation is a text string (such as a class attribute), the constraint
string may follow the element text string in curly braces.

Bank account attribute constraints

- non empty owner and positive balance.

For a constraint that applies to a single element (such as a class or an association

path), the constraint string may be placed near the symbol for the element, preferably
near the name, if any. A UML tool must make it possible to determine the constrained
element.

For a constraint that applies to two elements (such as two classes or two associations),
the constraint may be shown as a dashed line between the elements labeled by the
constraint string in curly braces.

Account owner is either Person or Corporation,

{xor} is predefined UML constraint.

If the constraint is shown as a dashed line between two elements, then an arrowhead
may be placed on one end. The direction of the arrow is relevant information within the
constraint. The element at the tail of the arrow is mapped to the first position and the
element at the head of the arrow is mapped to the second position in the
constrainedElements collection.

For three or more paths of the same kind (such as generalization paths or association
paths), the constraint may be attached to a dashed line crossing all of the paths.

The constraint string may be placed in a note symbol (same as used for comments)
and attached to each of the symbols for the constrained elements by a dashed line.
Bank account constraints - non empty owner and positive balance.

Exercise one
1- Draw a class diagram representing a book defined by the following statement: “A book is
composed of a number of parts, which in turn are composed of a number of chapters.
Chapters are composed of sections.” Focus only on classes and relationships. (7 marks)

2- Extend the class diagram of the question above to include the following attributes: (8
marks)

A. abook includes a publisher, publication date, and an ISBN

B. apart includes a title and a number

C. achapter includes a title, a number, and an abstract

D. asection includes a title and a number

E.

3) Draw a class diagram representing an airline operates flights. Each airline has an ID.
Each flight has an ID a departure airport and an arrival airport: an airport as a
unique identifier. Each flight has a pilot and a co-pilot, and it uses an aircraft of a
certain type; a flight has also a departure time and an arrival time.
An airline owns a set of aircrafts of different types.
An aircraft can be in a working state or it can be under repair.
In a particular moment an aircraft can be landed or airborne.
A company has a set of pilots: each pilot has an experience level:1 is minimum, 3
 is maximum.
A type of aeroplane may need a particular number of pilots, with a different role
(e.g.: captain, co-pilot, navigator): there must be at least one captain and one co-
pilot, and a captain must have a level 3.

Exercise two
Draw a class diagram representing a university where there are different classrooms,
offices and departments. A department has a name and it contains many offices. A
person working at the university has a unique ID and can be a professor or an employee.

A professor can be a full, associate or assistant professor and he/she is enrolled in

one department.

Offices and classrooms have a number ID, and a classroom has a number of seats.

Every employee works in an office.

Exercise three
Draw a class diagram representing a system for a movie-shop, in order to handle ordering
of movies and browsing of the catalogue of the store, and user subscriptions with
rechargeable cards.

Only subscribers are allowed hiring movies with their own card.

Credit is updated on the card during rent operations.

both users and subscribers can buy a movie and their data are saved in the related
order. When a movie is not available it is ordered.

Exercise four
Draw a class diagram representing a system for management of flights and pilots. An
airline operates flights. Each airline has an ID. Each flight has an ID a departure airport
and an arrival airport: an airport as a unique identifier. Each flight has a pilot and a co-
pilot, and it uses an aircraft of a certain type; a flight has also a departure time and an
arrival time. An airline owns a set of aircrafts of different types. An aircraft can be in a
working state or it can be under repair. In a particular moment an aircraft can be landed
or airborne. A company has a set of pilots: each pilot has an experience level: 1 is
minimum, 3 is maximum. A type of aeroplane may need a particular number of pilots,
with a different role (e.g.: captain, co-pilot, navigator): there must be at least one captain
and one co-pilot, and a captain must have a level 3.

Exercise five
Draw a class diagram representing a bank system which contains data on customers
(identified by name and address) and their accounts. Each account has a balance and
there are 2 type of accounts: one for savings which offers an interest rate, the other for
investments, used to buy stocks. Stocks are bought at a certain quantity for a certain
price (ticker) and the bank applies commission on stock orders.