Professional Documents
Culture Documents
Unit 2 Notes
Unit 2 Notes
SOFTWARE
ENGINEERING &
PROJECT
MANAGEMENT
[310904]
LECTURE NOTES
(2022-2023)
DEPARTMENT OF MCA
Unit 2
Introduction
1.0 Introduction
1.1 Why models?
1.2 What is UML?
1.3 Features of UML
1.4 Need for UML
1.5 What UML is not
1.6 Summary
1.7 Check your Progress - Answers
1.8 Questions for Self – Study
1.9 Suggested Readings
1.0 INTRODUCTION
Models are representations of reality which help simplify the reality. It is not
different in the software development field. The software under development can be
complex. So the models of software can be used. One such modeling technique is
the Unified Modeling Language.
1.1 WHY MODELS?
Models are created to represent reality in a simplified way. They provide a
structure for problem solving. They help in understanding how one can proceed with
the problem at hand. They also allow to experiment with multiple solutions. Since the
models are created before the actual development of the system, we can understand
different possibilities, problems, options etc. This also leads to decrease in the
development costs. Since the time will not be wasted in trials and errors the product
will be ready in lesser time. Models also help manage the complexity of the problem
so the planning of the development, allocation of the resources like machines,
programmers, testers can be done easily.
When models are created, a number of views of the system are described.
The different views give different perspectives of the system.
For example,
The car dashboard and its features interest the car driver. He needs to know
which button to press to switch on the inner lights and so on. But the electronics
person is not concerned about the dashboard in a similar way. He is interested in the
circuitry behind the dashboard. He wants to know which buttons to connect to which
instruments, gadgets so that when the button is pressed on the dashboard the driver
gets the expected operation. The design person is interested in the look and feel of
the dashboard but not all concerned with what goes on behind the panel. Thus
everybody looks at the same object but from different perspectives.
Each view has information that is unique to that view. Each view has the
information that appears in other views. The information that appears in more than
one view is consistent. This information has to be consistent because we are
creating views of the same system. This leads to the need for a variety of views
depicted in a variety of diagrams.
1.2 WHAT IS UML?
The Unified Modeling language, popularly known as the UML is a visual modeling
language that helps system developers to create blueprints that captures their vision
in a standard, easy to understand form, and gives a mechanism to effectively share
and communicate their visions with others.
The Object Management Group gives the formal definition of the UML as
The UML is a graphical language for specifying, visualizing, constructing and
documenting the artifacts of the software system.
Specifying – UML provides the means to model precisely, unambiguously and
completely the system in question.
Visualizing – UML provides graphical notation which articulates and ambiguously
communicates the overall view of the system.
Constructing - UML provides the ‘design’ dimension to the models built. These are
language independent and can be implemented in any programming language.
Documenting – every software project involves a lot of documentation from the
inception phase to the deliverables.
1.6 SUMMARY
In this chapter, initially the need for models is explained. There are a variety of
modeling techniques available. The UML is one such technique which plays an
important role in the object oriented software development.
1.4 -1.6
1. True
2. False
3. False
4. True
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
NOTES
NOTES
Introduction / 5
[Type the document title]
Chapter 2
2.0 Objectives
2.1 Introduction
2.2 Object
2.3 Class
2.4 Encapsulation
2.5 Abstraction
2.6 Inheritance
2.7 Polymorphism
2.7.1 Function Polymorphism
2.7.2 Operator Polymorphism
2.8 Message Passing
2.9 Summary
2.10 Check your Progress – Answers
2.11 Questions for Self – Study
2.12 Suggested Readings
2.0 OBJECTIVES
To revise the following object oriented concepts -
▫ Objects
▫ Classes
▫ Encapsulation
▫ Abstraction
▫ Inheritance
▫ Polymorphism
▫ Message passing
2.1 INTRODUCTION
The UML can be used in a better way with the object oriented technologies.
So there is a need to revise the object concepts. All the important concepts will be
covered in this chapter.
2.2 OBJECT
Every day we come across many things. The things can be a tangible thing like
a car or a printer, a role like an employee or a boss, an incident like a flight or an
overflow, interaction like contract or a sale or a specification like a color or a shape.
Each of these things has some kind of identity, state and behavior.
The identity is the property of an object that distinguishes it from other objects
like myCar, yourCar.
The state describes the data stored in that object like for a car we can specify
the brand name as Tata, the model name as Nano, the color as yellow for myCar
and the brand name Hyundai, the model name as i10, the color as red for yourCar
and so on. The state or the structure is described by the properties or the attributes.
Review of Object Orientation / 7
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
Attributes Operations
brandName stop()
modelName start()
color accelerate()
numberOfGears changeGear()
currentGear applyBrake()
… …
The
behavior
is
describe 2.4 ENCAPSULATION
d by the
The wrapping of data and functions into a single unit
operatio
called a class is known asencapsulation. The data is not
ns or the
directly accessible to the outside world. Only the
methods
.
All
the cars
Unified Modeling System / 8
[Type the document title]
operatio open to the outside. The operations above them form an
ns or insulating cover or wrapper around them.
functions
or
methods
wrapped
in the
class
can
access
it. This
gives
protectio
n and
security
to the
2.5 ABSTRACTION
data.
The data Abstraction is the act of representing the
is essential features without including the background
insulated details or explanations. This is a fundamental principle of
from modeling. A system model is created at different levels,
direct starting at the higher level and adding more levels are
access. more and more details become known about the system.
This A model can be viewed at several levels, each giving
achieves different details about the system. So abstraction is
a way to looking only at the information that is relevant at the time
hide by hiding details so that there is no confusion in
informati understanding the system.
on or For example,
data.
A car is an abstraction which represents the
Fo
features i.e. the attributes like brandName and
r the car
modelName and the operations like start and change
class the
gear. Also a car represents all possible models of all
following
possible cars.
diagram
shows 2.6 INHERITANCE
the
The process by which objects of one class acquire
encapsul
the properties of objects of another class is known as
ation
inheritance. This supports hierarchical classification. This
where
provides reusability. It makes it possible to add
the
additional features to an existing class without modifying
operatio
it. This helps avoid duplication.
ns are
around A class known as the subclass or the child class
the can inherit attributes and operations from another class
attribute known as the superclass or the parent class. The
s. The subclass provides the specialized behavior whereas the
attribute superclass provides the generalized behavior.
s are not
directly
visible or For example:
Review of Object Orientation / 9
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
True or False
4. Instances
2.4 - 2.6
1. False
2. True
3. True
4. True
2.7-2.8
1. Polymorphism
2. An operation
3. different behaviors
4. message
1. What is an object?
2. What are classes?
3. What is abstraction?
4. What is inheritance?
5. What is encapsulation?
6. What is the purpose of message passing?
Review of Object Orientation / 11
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
NOTES
NOTES
Overview of UML
3.0 Objectives
3.1 Introduction
3.2 Things
3.2.1 Structural Things
3.2.2 Behavioral Things
3.2.3 Grouping Things
3.2.4 Annotational Things
3.3 Relationships
3.3.1 Dependency
3.3.2 Association
3.3.3 Generalization
3.3.4 Realization
3.4 Diagrams
3.4.1 Structure Diagrams
3.4.2 Behaviour Diagrams
3.4.3 Interaction Diagrams
3.5 Summary
3.6 Check your Progress – Answers
3.7 Questions for Self – Study
3.8 Suggested Readings
3.0 OBJECTIVES
To understand the building blocks of UML
▫ Things and its four types
▫ Relationships and its four types
▫ Diagrams and its three types.
3.1 INTRODUCTION
UML is constructed from three main building blocks: things, relationships and
diagrams. When these building blocks are understood correctly it is easy to use the
UML.
3.2 THINGS
There are four types of things in the UML. These are structural, behavioral, grouping
and annotational.
Overview of UML / 15
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
Interface – interface defines a set of operations which specifies what a class can do.
Collaboration – collaboration defines an interaction between things to achieve some
goal.
Use case – use case represents a set of actions performed by a system for a
specific goal.
State machine – state machine is useful when the state of an object in its lifecycle is
important. It defines the sequence of states an object goes through in response to
events. Events are external factors responsible for state change
.
3.2.3 Grouping things
This is the organizational part of the UML. It provides a higher level of abstraction.
Following grouping mechanism is available with the UML for use.
Package – a general purpose element that comprises UML elements – structural,
behavioral and even grouping things. These are conceptual groupings of the system
and need not necessarily be implemented as cohesive software modules.
3.3 RELATIONSHIPS
The objects need to interact with each other. The relationships describe the meaning
of the links between things and how the links are to be interpreted while
implementing the system. There are four types of relationships viz. dependency,
association, generalization, realization.
3.3.1 Dependency
Dependency is a semantic relationship where a change in one thing (the
independent thing) causes a change in the semantics of the other thing (the
dependent thing). The notation used for dependency is a dashed line with an
arrowhead.
For example,
When the date of birth (the independent thing) is changed, the age (the dependent
thing) changes with it.
3.3.2 Association
Association is a structural relationship that describes the connection between two
things. It also describes how many objects are taking part in that relationship. The
notation used for association is a simple line segment or a line segment with
arrowhead.
For example,
3.3.3 Generalization
Generalization is a relationship between a general thing (a parent or superclass) and
a more specific kind of that thing (a child or subclass). The notation used for
generalization is a line segment with an empty block triangular arrowhead. The
arrowhead points toward the generalized class or use case or package.
Overview of UML / 17
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
For example,
An animal (generalization) and a cat (specialization) are related by the
generalization-specialization relationship.
3.3.4 Realization
Realization is a semantic relationship between two things where one specifies the
behavior to be carried out and the other carries out the behavior. I.e. one element
describes some responsibility which is not implemented and the other one
implements it. This relationship exists in case of interfaces. The notation used is a
dashed line with a empty triangular block arrowhead.
For example,
The television carries out the behavior specified by the remote.
True or false
2. Association describes how many objects are taking part in that relationship.
3.4 DIAGRAMS
The diagrams are graphical representation of the models which uses various
symbols and text. Each different symbol has a special meaning in the context of the
UML. The user can use text to describe the concepts from the system under
development. There are thirteen different types of diagrams available in the UML 2.0.
Each diagram has its own set of symbols. Each diagram captures a different
dimension, view, perspective of the system.
There two major types of the UML diagrams: structure and behavior. The behavior
diagrams also include the interaction diagrams.
3.4.1 Structure diagrams
This is a set of diagrams that depicts the elements of a specification those are
irrespective of time. This includes class, composite structure, component,
deployment, object and package diagrams. These models represent the framework
for the system.
3.4.2 Behavior diagrams
This is a set of diagrams that depicts behavioral features of a system or business
process. This includes activity, state machine, use case diagrams and the four
interaction diagrams. These models describe the interaction in the system.
3.4.3 Interaction diagrams
This is a set of diagrams which emphasize object interactions. The interaction is very
important to get something done. This diagram type is categorized under behavior
3.5 SUMMARY
In this chapter we learnt the building blocks of the UML. There are three main
building blocks viz. things, relationships and diagrams. The types of diagrams are
mentioned here but the different diagrams available are described in the next
chapter.
3.6 CHECK YOUR PROGRESS - ANSWERS
3.2
1. Structural things
2. Verbs
3. Packages
4. Annotational things
3.3
1. True
2. True
3. False
4. True
3.4
1. Irrespective
2. Behavior diagrams
3. Interaction diagrams
Overview of UML / 19
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
NOTES
Overview of UML / 21
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
NOTES
Chapter 4
4.0 OBJECTIVES
To study the thirteen different diagrams
▫ Activity diagrams
▫ Class diagrams
▫ Communication diagrams
▫ Component diagrams
▫ Composite structure diagrams
▫ Deployment diagrams
▫ Interaction overview diagrams
▫ Object diagrams
▫ Package diagrams
▫ Sequence diagrams
▫ State machine diagrams
▫ Timing diagrams
▫ Use case diagrams
4.1 INTRODUCTION
There are thirteen different diagrams defined by the UML 2.0. The structure
diagrams include class, composite structure, component, deployment, object and
package diagrams. The behavior diagrams include activity, state machine, use case
Overview of UML Diagrams / 23
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
diagrams and the four interaction diagrams. The interaction diagrams include
communication, interaction overview, sequence and timing diagrams.
4.2 ACTIVITY DIAGRAM
This diagram helps describe the flow of control of the target system, such as
the exploring complex business rules and operations, describing the use case as well
as the business process. This is the object oriented equivalent of flow charts and
data flow diagrams. This is a type of behavior diagram.
This diagram will be explained in detail in a later chapter.
4.3 CLASS DIAGRAM
This diagram shows the classes of the system, their interrelationships and the
operations and attributes of the classes. This is a structure diagram.
This diagram will be explained in detail in a later chapter.
\
4.5 COMPONENT DIAGRAM
This diagram shows the dependencies and the interrelationships among
software components and the artifacts that implement them, such as source code
files, binary code files, executable files, scripts, and tables. This is a structure
diagram. This diagram helps in the management of the system. Software artifacts
(classes, interfaces etc.) of a system are arranged in different groups depending
upon their relationships during design phase. These groups are known as
components. This diagram is used to visualize the implementation.
A software component is a modular part of a system. It consists of one or more
classes. A component provides interfaces to other components. A component
defines system’s functionality. The component hides what it does behind an
interface. Other objects ask component to execute its operations. The interface is a
set of operations that a component presents to other objects.
A component diagram contains components along with the interfaces and
relationships. The component is represented as a rectangle with a keyword
<<component>> near the top in UML 2.0. It also can be shown in another manner as
a rectangle with two small rectangles overlaid on its sides as was popular in the prior
versions of UML. A line with a circle at one end represents the interface through
which the components communicate with each other. This communication is shown
through a relationship depicted by a dotted line with an arrowhead toward the
interface.
True or false
2. The nodes in deployment diagram are virtual entities where the components are
deployed.
4.15 SUMMARY
There are thirteen different diagrams available with the UML. Each diagram
gives a different view of the system under construction.
Source: www.objectmentor.com(Link)
Unified Modeling System / 30
[Type the document title]
NOTES
NOTES
Chapter 5
5.0 Objectives
5.1 Introduction
5.2 Need for use cases
5.3 Diagram model elements
5.3.1 Actors
5.3.2 Finding Actors
5.3.3 Use Cases
5.3.4 Finding Use Cases
5.3.5 Relationships
5.4 Use case diagrams
5.5 Summary
5.6 Check your Progress – Answers
5.7 Questions for Self – Study
5.8 Suggested Readings
5.0 OBJECTIVES
To understand the need for use cases
To study different model elements used in the use case diagram
▫ Actors
▫ Use cases
▫ Relationships
5.1 INTRODUCTION
The most important phase in the software development life cycle is the
requirements gathering stage. If the requirements are gathered collected correctly
and unambiguously, the developed system will have high chances of being accepted.
The use case diagrams help in gathering the requirements.
True or false
5.3.5.2.2 Extend
This relationship is used to relate use cases which describe variations in the
normal flow of events for a particular function to the basic use case which describes
the normal flow of events for the function. An extending use case is used to describe
variations in the normal flow of events described by a general use case.
Use case B extends use case A when use case B describes the behavior of
use case A under a particular condition.
The notation used for the extend relationship is a dashed arrow with
<<extend>> written over it. The arrow head is toward the use case representing the
normal flow. To decide the direction of the arrowhead a question should be asked
“what gets extended?” and put the arrow head along that use case.
5.5 SUMMARY
When we wish to start developing a system there is a need to gather the
requirements of the system properly. The use case diagram helps in the
requirements gathering phase. There are three main elements of the use case
diagrams viz. actors, use cases and relationships.
NOTES
Chapter 6
Activity Diagram
6.0 Objectives
6.1 Introduction
6.2 Need for activity diagram
6.3 Creating activity diagram
6.4 When to use activity diagrams
6.5 Elements of activity diagrams
6.5.1 Start symbol
6.5.2 End symbol
6.5.3 Activity
6.5.4 Forks and joins
6.5.5 Decision point / branch
6.5.6 Merges
6.5.7 Guard / condition
6.5.8 Swimlane / partition
6.5.9 Object node
6.5.10 Transition / control flow
6.6 Summary
6.7 Check your Progress - Answers
6.8 Questions for Self – Study
6.9 Suggested Readings
6.0 OBJECTIVES
To understand the activity diagrams
To study the different elements of the activity diagrams
▫ Start symbol
▫ End symbol
▫ Activity
▫ Forks and joins
▫ Decision points / branch
▫ Merges
▫ Guard / condition
▫ Swimlane / partition
▫ Object node
▫ Transition / control flow
6.1 INTRODUCTION
There are certain parts in the system which is very complex. The activity
diagrams describe the flow of control from activity to activity. This helps simplify the
part involving complexity.
6.2 NEED FOR ACTIVITY DIAGRAM
The activity diagram is a diagram that models business processes. It also
emphasizes the flow of control from activity to activity. It is very much similar to the
traditional program flowchart. It is typically used to provide details for complex
Activity Diagram / 41
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
algorithms. This diagram is typically used for business process modeling, for
modeling the logic captured by a single use case or usage scenario.
6.3 CREATING ACTIVITY DIAGRAM
While creating an activity diagram that following steps could be taken.
Set the context or scope of the activity being modeled.
Give the diagram an appropriate title.
Identify the activities, control flows and object flows that occur between the
activities.
Identify any decisions that are part of the process being modeled.
Identify any prospects for parallelism in the process.
Draw the activity diagram.
6.5.3 Activity
This is a behavior an object carries out while in a particular state. A rounded
rectangle specifies an activity. The name of the activity is to be written inside the
rounded rectangle.
Is N
integer?
6.5.6 Merges
This indicates that one or more incoming flows must reach this point until processing
continues, based on any guards on the outgoing flow. This is denoted by a diamond
with several flows entering and one leaving.
6.5.7 Guard/condition
This is given by text written in between ‘[‘ and ‘]’. This is placed on a flow. The guard
must evaluate to TRUE in order to traverse the node.
Activity Diagram / 43
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
6.5.8 Swimlane/partition
The swimlanes or partitions indicate who or what is performing the activities. Every
participant gets a swimlane in which that participant’s activities are shown. The
interactions are shown by transitions across swimlanes.
6.6 SUMMARY
The activity diagram is used to understand the flow of the business functions.
This helps in explaining the parts which are complex to understand. There are a
variety of elements used in these diagrams.
Activity Diagram / 45
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
NOTES
Chapter 7
Sequence Diagrams
7.0 Objectives
7.1 Introduction
7.2 Need for Sequence Diagram
7.3 Creating Sequence Diagram
7.4 Elements of Sequence Diagram
7.4.1 Object
7.4.2 Lifeline
7.4.3 Synchronous message
7.4.4 Asynchronous message
7.4.5 Return
7.4.6 Creation of object
7.4.7 Destruction of object
7.4.8 Looping
7.4.9 Boundary
7.4.10 Naming the Sequence Diagram
7.5 Summary
7.6 Check your Progress – Answers
7.7 Questions for Self – Study
7.8 Suggested Readings
7.0 OBJECTIVES
To understand the need for sequence diagrams
To know the elements involved in the sequence diagrams
▫ Object
▫ Lifeline
▫ Synchronous message
▫ Asynchronous message
▫ Return
▫ Creation of object
▫ Destruction of object
▫ Looping
▫ Boundary
▫ Naming the diagram
7.1 INTRODUCTION
Each use case involves different interactions between a set of objects. These
interactions follow a certain sequence to get the job done. The sequence diagram
shows the interaction based on the time ordering.
7.2 NEED FOR SEQUENCE DIAGRAM
To understand how the different objects interact with each other, some type of
interaction diagram is necessary. If there is a need to understand in what sequence
the interaction takes place, the sequence diagram is best suited for the purpose. This
diagram is best suited to explore the different scenarios or flows of a particular use
Sequence Diagrams / 47
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
case. This diagram also helps understand which classes are needed for the
interaction. These diagrams can be easily drawn. They are also easy to understand
for the developers and clients. These diagrams basically display their lifelines of
participants as they exchange messages. A lifeline shows the life of the participating
object by showing the relevant events that are important to the object in that
interaction.
7.3 CREATING SEQUENCE DIAGRAM
There is no need to draw sequence diagram for each and every use case
and each and every scenario of the use cases.
All the use cases are to be studied well and then which of them are likely to be
complex is to be found out. If the interaction is a typical one, then you may
safely ignore that particular use case.
One by one pick up the use cases which were listed in the above step.
Explore all the scenarios of to find out which are not routine ones. Pick up only
those which have complex interaction involved.
Use the same actor from the use case diagram who initiated that use case.
Find out which other objects need to interact to fulfill the functionality
suggested by the chosen use case and its scenarios.
Decide on the sequence of messages required to be exchanged to fulfill the
requisite functionality. Also find out which object is sending the message and
which one is receiving as well as what message is passed.
Determine the type of the interaction i.e. whether it is synchronous,
asynchronous, return, creation of object, or destruction of object.
Draw the objects at the top with the initiating actor at the extreme left.
Below each of the above objects including the actor draw vertical dashed lines
to indicate the lifelines.
Show interactions between the objects by drawing horizontal arrows between
the corresponding lifelines. (To decide the type of arrow consider the type of
the interaction determined above)
Write text along the arrow to indicate the message passed. The message could
plain text or it could be function or procedure call.
Put a box around all these to indicate that this is interaction for one particular
use case.
At the top left corner using a special notation write the name of the
corresponding use case.
True or false
Sequence Diagrams / 49
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
7.4.2 Lifeline
The lifeline is shown vertical with a dashed line starting from the corresponding actor
going down till after the last interaction.
7.4.5 Return
This is used to indicate return from a call. It is not mandatory to show the return
arrow. It can be assumed that the recipient carries out its job correctly and if asked
returned the requisite information. It is denoted by a dashed line with a plain
arrowhead.
7.4.8 Looping
There might be a situation in which there is a need to perform some set of
interactions again and again. This is a place which is a situation where a loop is
required. Within a sequence diagram all the steps which need to be repeated are
picked up. A box put around these steps. In the top left corner in a rectangle with the
right bottom corner removed is placed. Inside this corner rectangle, the looping
condition is written. The syntax for this is loop minint, maxint,[guard]
This means execute the interaction minint times, then execute interaction up to
maxint times as long as the [guard] is true.
7.4.9 Boundary
The boundary encloses the set of objects, their lifelines, their interactions involved in
the sequence diagram drawn for a particular use case. It is a simple rectangle.
Sequence Diagrams / 51
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
7.5 SUMMARY
The sequence diagrams are used to clarify the complexity in the execution of
any interaction. Here only the complex scenarios for use cases are modeled. This
diagram gives the time ordering of the interactions.
NOTES
Sequence Diagrams / 53
[Type the document title]
Chapter 8
Class Diagrams
8.0 Objectives
8.1 Introduction
8.2 Need for class diagram
8.3 Creating class diagram
8.4 Elements of class diagram
8.4.1 Class
8.4.2 Visibility
8.4.3 Multiplicity
8.4.4 Association
8.4.5 Generalization
specialization
8.4.6 Dependence
8.4.7 Realization
8.4.8 Aggregation
8.4.9 Composition
8.5 Summary
8.6 Check Your Progress – Answers
8.7 Questions for Self – Study
8.8 Suggested Readings
8.0 OBJECTIVES
To understand the need for class diagrams
To know the elements involved in the class diagrams
▫ Class
▫ Visibility
▫ Multiplicity
▫ Association
▫ Generalization-specialization
▫ Dependence
▫ Realization
▫ Aggregation
▫ Composition
8.1 INTRODUCTION
The class diagram shows the different classes involved and the relationships
between different classes. The class also shows the details like the attributes and the
operations carried out by that class. The relationships describe the details like
visibility, multiplicity etc.
8.2 NEED FOR CLASS DIAGRAM
The purpose of a class diagram is to model the static view of an application.
This is the only diagram which finds direct relation to object oriented languages and
thus can be extensively used at the time of construction. This diagram helps in the
analysis and design of the static elements of an application. They describe the
Class Diagrams / 53
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
responsibilities of the system from the implementation point of view. This diagram
can help in the development of the component and deployment diagrams.
This is the most common diagram used in the UML. The class diagram
consists of classes, interfaces, relationships and collaborations. This diagram
basically represents the object oriented view of a system which is static in nature. It
is generally used for development purpose. This is the most widely used diagram at
the time of construction of the system.
True or false
2. Class diagram is the only diagram which finds direct relation to object
oriented languages.
Reservation
operations
guarantee()
cancel ()
change (newDate: Date)
responsibilities
bill no-shows
match to available rooms
exceptions
8.4.2 Visibility
There are three types of visibility modes available with the UML as with many
other object oriented languages. These are public (seen by all), private (seen by
itself) and protected (seen by the derived/child/subclass only). These modes can be
used with the responsibilities of a class or roles in the associations.
This is shown by the symbols + for public, - for private and # for protected. These
symbols precede the name of the attribute, operation or role.
+size, -attach( ), #draw( ), +user, -password
8.4.3 Multiplicity
The classes involved in a relationship may have a relationship which is one-to-
one, one-to-many or many-to-many. That means one instance of a class may be
related to one instance of another class, one instance of a class may be related to
many instances of another class, or many instances of a class may be related to
many instances of another class. This is indicated by a number or n or m or *.
Class Diagrams / 55
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
8.4.4 Association
It is the simplest relationship that can exist between a pair of classes. The
association can have multiplicity. This relationship can also be identified by a name.
Also a direction of the relationship may be specified. The role of the participating
classes also can be mentioned.
It is shown by a plain line joining two classes.
8.4.5 Generalization-specialization
This is the same kind of relationship which was explained under inheritance. This is
the equivalent of the superclass-subclasses hierarchy.
8.4.6 Dependence
When one class changes due to the change in another class, the relationship
between these classes is shown by this relationship. This is shown by a dashed line
with normal arrowhead.
8.4.7 Realization
This is typically shown between a use case and the collaboration or an interface
and the class or component implementing it.
8.4.8 Aggregation
This is a whole-part relationship. Here the part could be part of more than one
wholes. This is a weak relationship. When the whole is deleted the part may still
exist. This is represented by a diamond at the end of an association link. The
diamond is toward the whole end.
8.4.9 Composition
This is a whole-part relationship. Here the part is a part of exactly one whole.
This is a strong relationship. When the whole is deleted the part also gets deleted.
This is represented by a filled diamond at the end of an association link. The
diamond is toward the whole end.
Unified Modeling System / 56
[Type the document title]
W in d o w
2
s c ro l lb a r :S lid e r
1
t it le :H e ad e r
1
b od y :P a n el
8.5 SUMMARY
The class diagrams give the static view of the system. This diagram shows
different classes, their interactions to fulfill the requirements of the system. The
classes and the relationships are the main elements of this diagram.
8.6 CHECK YOUR PROGRESS – ANSWERS
8.2-8.3
1. False
2. True
3. True
8.4
1. Attributes
2. Three
3. one-to-one, one-to-many, many-to-many
4. generalization, specialization
5. dependence
6. aggregation, composition
Class Diagrams / 57
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
NOTES
Class Diagrams / 59
Genba Sopanrao Moze College Of Engineering, Balewadi - Pune
Department of MCA, F.Y SEM – I, Software Engineering and project Management
NOTES