System Analysis and Design

(Professional Solutions)
.
Week 9 : Class Diagram

Dr Azida Zainol
Subject Group Computer Science & Software
Engineering
Email : [email protected]
Objectives
• Understand UML notations for conceptual data modeling.
• Explain relationship characteristics such as degree and
multiplicity.
• Describe data relationships such as association,
aggregation, and generalization.
• Develop class diagram

2
What Is a Conceptual Data Model?
• A detailed model that shows the overall structure of organizational
data; it is independent of any database management system or other
implementation considerations.

• Represented by UML class diagrams

3
Class diagram
• A class diagram shows a set of classes, interfaces and collaborations
and their relationships
• It models the static design view of a system
• Important for visualisation, specifying and documenting structural
models for constructing executable system

4
Uses of a class diagram
• To model the vocabulary of the system
• What fall under a system and its responsibilities
• To model simple collaborations
• To model the logical database scheme

5
Conceptual Data Model Elements

1. Objects and classes

2. Attributes
3. Relationships
 Associations,
 Aggregations,
 Compositions,
 Generalizations

6
1. Object/Class
• An entity that encapsulates data and behavior

• Examples: product, employee, order, line item

• Class – a set of objects that share the same

attributes, operations, relationships, and semantics
(abstract)

• Instance – a single object (concrete)

7
Class

Instances

8
UML Class symbol
has three parts:

1) Name
2) List of attributes
3) List of
operations
9
Class Symbol

Client
Class name
compartment - companyAddress private
- companyEmail
Attributes - companyFax public
+ companyName
compartment
# companyTelephone

Operations + getClientInfo( )
protected
compartment - updateClientInfo( )

10
Class > Stereotypes
• Stereotype – a construct that extends the UML vocabulary
• Analysis class stereotypes differentiate the roles objects can play:
1. Boundary/Interface objects model interaction between the system and
actors (and other systems)
2. Entity objects represent information and behaviour in the application
domain
3. Control objects co-ordinate and control other objects

11
Class > Stereotypes

Alternative notations for boundary

class:
<<boundary>>
User Interface::AddAdvertUI
User Interface::AddAdvertUI

startInterface( ) startInterface( )
assignStaff( ) assignStaff( )
selectClient( ) User Interface::AddAdvertUI
selectClient( )
selectCampaign( ) selectCampaign( )

12
Class > Stereotypes

Alternative notations for entity class:

<<entity>>
Campaign
Campaign

title title
campaignStartDate campaignStartDate
campaignFinishDate campaignFinishDate
Campaign
getCampaignAdverts( ) getCampaignAdverts( )
addNewAdvert( ) addNewAdvert( )

13
Class > Stereotypes

Alternative notations for control class:

<<control>>
Control::AddAdvert
Control::AddAdvert

showClientCampaigns( )
showClientCampaigns( )
showCampaignAdverts( )
showCampaignAdverts( ) AddAvert
createNewAdvert( )
createNewAdvert( )

14
Class Diagram: Instance Symbol

Object name FoodCo:Client

compartment
companyAddress=Evans Farm, Norfolk
[email protected]

Attribute values companyFax=01589-008636

companyName=FoodCo
companyTelephone=01589-008638

Instances do not
have operations
15
2. Attributes
Attributes are:
• Part of the essential description of a class
• The common structure of what the class can ‘know’
• Each object has its own value for each attribute in its class

16
Types of attributes

1. Simple attributes – contain single data item

2. Identifiers – connect unique key value
3. Multi valued attributes – contain multiple values
simultaneously
4. Composite attributes – group of related
attributes

17
Attribute Stereotypes in Class Diagrams
• Stereotype – a construct that extends the UML vocabulary
• Identifier stereotype <<PK>> for primary key
• Multivalued stereotype <<multivalued>>

18
Primary key is a
unique identifier;
no two Student
instances will
have the same
studentId value.

19
Multi valued
attribute can
contain multiple
values; a student
may have several
phone numbers

20
• Composite attributes have multiple sections (sub
attributes).
• They are treated as separate classes in conceptual
data models.
21
3. Relationship
• A semantic connection between objects of one or
more classes
• In UML, represented as a line connecting two or
more class boxes (or connecting one class to itself)
• Relationships including : association, generalization,
dependency and realization. (UML Ref Manual,1999)
• Association: provide the connections with which
objects of different classes can interact.

22
Roles identify the purpose of each class in the
relationship.
23
Relationship: Associations

Association role Association

Client
StaffMember
staffContact companyAddress
staffName
companyEmail
staffNo liaises with
companyFax
staffStartDate
companyName
companyTelephone

Association name
Direction in which
name should be read
24
Relationship Degree
• The number of classes that participate in a
relationship
• Main degrees:
1. Unary – a relationship between objects of the same
class
2. Binary – a relationship between objects of two
different classes
3. Ternary – a relationship between objects of three
different classes

25
26
27
Relationship Multiplicity
• Cardinality: how many instances of one class can
be related to one instance of the other class
• Multiplicity : Cardinalities that specify the range
of the number of objects in Class A that can or
must be associated with each object of Class B.
• Multiplicity must be placed at each end of the
association link.

28
Relationship Multiplicity
• A multiplicity is made up of:
1. A minimum cardinality – the minimum number of Class A objects possible
2. A maximum cardinality – the maximum number of Class A objects possible
• Relationships can be:
1. One – to – one
2. One – to – many
3. Many – to – many
4. Fixed cardinality

29
 A movie is stocked as zero to many videotape(s).
* Note : 0..n is referred as zero to many

How to interpret this relationship?

* Note : Multiplicity notation is: min..max

30
 Roles make it
clearer to see
which should be
on the one side
and which should
be on the many
side of the
relationship.
One Supervisor manages
zero to many Subordinates.

31
32
Associations
1. Association – no object is subordinate to any
other.
2. Aggregation – one class represents the whole,
and the other represents the part, but it is a loose
coupling.
• Made-up-of, consists-of, contains, is-part-of
relationship
• Eg: car is made up of parts

whole part 33
Associations
3. Composition – a type of strong aggregation with a
tight coupling. The whole and the part cannot
exist without each other.If the whole is deleted,
the parts are deleted as well.

whole part
34
Generalization
• A superclass – subclass relationship in which one
class forms a broader category in which the other
class is a sub-category
• Sometimes called ‘is-a’ relationship
• Eg: A car is a vehicle
• Inheritance – A subclass will inherit all the
attributes and operations of its superclass; an
instance of the subclass contains all the same
information (plus more) as an instance of the
superclass.
35
• Abstract class is
one that does
not allowed to
have any
objects
• Used only to
inherit from
• Label with
{abstract}
under the class
name

36
37
Multiple
inheritance is
complicated
and not
supported by
all object-
oriented
programming
languages.

38
Preparing a Class Diagram

1. From the problem statement or a scenario, identify

possible classes including its attributes and
operations.
2. Add relationship between classes. Choose a
descriptive name to represent the relationship. You
may add roles to each class if necessary.
3. Add multiplicities for each class.
4. If necessary add generalization, inheritance,
composition or aggregation.
5. Review for completeness.
39
 Hints and Tips
• Every class diagram is a graphical presentation of the
static design view of a system.
• No single class diagram need to capture everything
about a system’s view
• Tips:
1. Give it a name that communicates its purpose
2. Try not to show too many kinds of relationship. One kind of
relationship will tend to dominate each class diagram
• Hints:
1. Show only essentials elements
2. Provide detail consistent with its level of abstraction
40
:: Summary ::
1. Develop data models from use cases.
2. Use UML notation for conceptual modeling.
3. Understand relationship multiplicity and degree.
4. Work with aggregation, composition, and generalization.
5. Build class diagram

41
References
1. George, J. F., Batra, D., Valacich, J., & Hoffer, J. A. (2004). Object-Oriented
Systems Analysis and Design. New Jersey: Pearson Prentice Hall.
2. Hoffer, J. A., George, J.F., & Valacich, J.S. (2004). Modern Systems Analysis and
Design 4th Edition.New Jersey : Pearson Prentice Hall.
3. Bennet, S., McRobb, S., & Farmer, R. (2000). Object Oriented Systems Analysis
and Design using UML. McGraw Hill.
4. Haslina Mohd, Azizah Ahmad, Azida Zainol & Azlin Nordin. (2002). Modul
Analisis dan Rekabentuk Sistem Pendekatan Berorientasikan Objek
Menggunakan UML. Prentice Hall.
5. Dennis, A., Wixom, B. H., & Tegarden, D. (2002). Systems Analysis & Design An
Object –Oriented Approach with UML. McGraw Hill.
6. Pressman, R.(2000). Software Engineering: A Practitioner's Approach. McGraw-
Hill. (Chapter 10).
7. Sommerville, I. and Sawyer, P.(1997). Requirements Engineering. Wiley.
8. Booch, Rambaugh, Jacobson. (1999). The UML User Guide. Addison Wesley.
9. Eriksson, H. E., & Penker, M. (1998). UML Toolkit. Wiley Computer Publishing.

42