15SE203-Object Oriented

Analysis and Design

UNIT-II
Session 1
 What is UML?
• Standard language for specifying, visualizing, constructing,
and documenting the artifacts of software systems, business
modeling and other non-software systems.
• The UML represents a collection of best engineering practices
that have proven successful in the modeling of large and
complex systems.
• The UML is a very important part of developing object
oriented software and the software development process.
• The UML uses mostly graphical notations to express the
design of software projects.
• Using the UML helps project teams communicate, explore
potential designs, and validate the architectural design of the
software.
 What is UML?
• Unified Modeling Language
– OMG Standard, Object Management Group
– Based on work from Booch, Rumbaugh, Jacobson
• UML is a modeling language to express and
design documents, software
– Particularly useful for OO design
– Not a process, but some have been proposed
using UML
– Independent of implementation language
 Why use UML
• Open Standard, Graphical notation for
– Specifying, visualizing, constructing, and documenting software
systems
• Language can be used from general initial design to very
specific detailed design across the entire software
development lifecycle
• Increase understanding/communication of product to
customers and developers
• Support for diverse application areas
• Support for UML in many software packages today (e.g.
Rational, plugins for popular IDE’s like NetBeans, Eclipse)
• Based upon experience and needs of the user community
 Brief History
• Inundated with methodologies in early 90’s
– Booch, Jacobson, Yourden, Rumbaugh
• Booch, Jacobson merged methods 1994
• Rumbaugh joined 1995
• 1997 UML 1.1 from OMG includes input from
others, e.g. Yourden
• UML v2.0 current version
History of UML
Contributions to UML
 Systems, Models and Views
• A model is an abstraction describing a subset of a system
• A view depicts selected aspects of a model
• A notation is a set of graphical or textual rules for depicting
views
• Views and models of a single system may overlap each other

Examples:
• System: Aircraft
• Models: Flight simulator, scale model
• Views: All blueprints, electrical wiring, fuel system
 Systems, Models and Views
Flightsimulator
Blueprints
Aircraft
Model 2
View 2
View 1
System
View 3
Model 1
Electrical
Wiring
Scale Model
 UML Models, Views, Diagrams
• UML is a multi-diagrammatic language
– Each diagram is a view into a model
• Diagram presented from the aspect of a particular stakeholder
• Provides a partial representation of the system
• Is semantically consistent with other views
– Example views
Models, Views, Diagrams
 Basic Modeling Steps
• Use Cases
– Capture requirements
• Domain Model
– Capture process, key classes
• Design Model
– Capture details and behaviors of use cases and
domain objects
– Add classes that do the work and define the
architecture
 UML Baseline
• Use Case Diagrams
• Class Diagrams
• Package Diagrams
• Interaction Diagrams
– Sequence
– Collaboration
• Activity Diagrams
• State Transition Diagrams
• Deployment Diagrams
 Summary and Tools
• UML is a modeling language that can be used independent of
development
• Adopted by OMG and notation of choice for visual modeling
– http://www.omg.org/uml/
• Creating and modifying UML diagrams can be labor and time
intensive.
• Lots of tools exist to help
– Tools help keep diagrams, code in sync
– Repository for a complete software development project
– Examples here created with TogetherSoft ControlCenter, Microsoft
Visio, Tablet UML
– Other tools:
• Rational, Cetus, Embarcadero
• See http://plg.uwaterloo.ca/~migod/uml.html for a list of tools, some
free
 Questions
• Expand UML…………. Give its latest version.
• Identify organization that uses UML approach.
• Mentions at least three tools that uses UML
approach.
• Compare and contrast Data Flow Diagram Vs.
UML Diagram.
Session 2
Use Cases
 Use Cases
• Use Cases:
– Text stories
• Some “actor” using system to achieve a goal
– Used to discover and record requirements
– Serve as input to later phases of development
– Emphasizes user goals and perspective
• Not system implementation choices and details
– A way of specifying functional requirements
• Example: Process sale (Brief, informal format)
 Use Cases
• Use cases are text, not diagrams
– UML use case diagrams are auxiliary
• Definitions:
– Actor: Something with behavior
• A person (user)
• A computer system
• An organization
– Scenario: A specific sequence of actions and interactions
between actors and the system
• Also called a “use case instance”
• One particular story of using a system
• One path through the use case
– A use case: A collection of related success and failure
scenarios that describe an actor using a system to achieve
a goal.
 Use Cases
– A use case (Informal format)

– Use case model:

Set of all written use cases + UML use case diagrams
 Use Case Formats
• Three formats
– Brief
– Casual
– Fully dressed (fully detailed)
• Fully-dressed example follows
 Sections of a Use Case
• Scope: Bounds system under design
• Level: User-goal or subfunction
– User goal: Buy some stuff and pay
– Subfunction: Cashier authenticates himself
• Duplicated steps factored out
• Primary actor
• Stakeholders and interests list:
– Functional and non-functional requirements come
from these
 Sections of a Use Case
• Pre-conditions:
– Conditions that must hold before use case is
started
– Noteworthy assumptions
– NOT TESTED within the use case
– Example: Logging in successfully completed
• Post-conditions (success guarantees)
– What is guaranteed to be true upon successful
termination of the use case
– Should meet all needs of all stakeholders
 Sections of a Use Case
• Main success scenario or basic flow
– Defer conditional and branching statements to the
Extensions section
– Records steps of success path
– A step:
• An interaction between actors
• A validation (usually by the system)
• A state change by the system
– Example: Recording or modifying something
– Some sequences of steps may be repeated. See
POS example.
 Sections of a Use Case
• Extensions (Alternate Flows)
– Normally comprise majority of text
– Other scenarios or branches
– Can be both success and failure
– An extension of Step 3 of basic flow is labeled by 3a, 3b, ...
– An extension that can take place at any step is labelled *a, *b
– An extension has two parts
1. The condition: Something that can be detected by the system or the
actor
2. The handling: Response to the alternative condition
– At the end of extension, execution merges with basic flow unless
indicated otherwise
– Sometimes one use case scenario can perform a branch and lead to
another use case scenario.
• Show with underlines
• Special requirements
• Technology and data variations list
 Some Guidelines
• Keep user interface (UI) details out of the use case
– Example: Log in vs. authenticate oneself
• Focus on “intent”. Do not specify a mechanism.
• Write terse use cases. Don’t need to use full
sentences.
• Write “black-box” use cases. Do not specify internal
workings of system, components, design yet.
– These come later. Do not make design decisions during
requirements specification.
 How to find use cases?
• Choose the system boundary
• Just a software application?
• Hardware and application as a unit?
• Entire organization?
• Find primary actors and goals
• Look for nouns and verbs in informal
descriptions
 Fig. 6.2
Enterprise Selling Things

Checkout Service
Sales Tax
Agency
POS System
Goal: Collect
taxes on sales Sales Activity
System Cashier

Customer

Goal: Buy items Goal: Analyze sales Goal: Process sales

and performance data
 Common Mistakes
• Scope of use case too large or too small.
• Examples:
– Negotiate a supplier contract
– Handle returns
– Log in
– Move piece on game board
• Rules of thumb for deciding use case scope
– The boss test:
• Level of task should be an item of business you can report to a boss
– The elementary business process (EBP) test:
• A task performed by one person in one place at one time in response to a
business event which adds measurable business value and leaves the data in
a consistent state.
– The size test:
• 3-10 pages
– Exceptions:
• Subfunctions, e.g. “paying by credit”
 UML Use Case Diagrams
system boundary NextGen POS communication

Process Sale alternate

notation for
Customer a computer
Payment system actor
Authorization
Service
Handle Returns
«actor»
actor Tax Calculator
Cashier

«actor»
Cash In Accounting
System
Manager
«actor»
«actor» Analyze Activity
HR System
Sales Activity
System

Manage Security

System Manage Users

Administrator use case
...
 UML Use Case Diagrams
For a use case context
diagram, limit the use cases to
Show computer system actors
with an alternate notation to
user-goal level use cases. human actors.

NextGen

«actor»
Process Sale Payment
Authorization
Service
Cashier
...

primary actors on supporting actors

the left on the right
UML Use Case Diagrams: Alternative
Actor Notations

NextGen Some UML alternatives to

illustrate external actors that
Process Sale «actor» are other computer systems.
Payment
«system» Authorization The class box style can be
Payment Payment Service used for any actor, computer or
Authorization Authorization human. Using it for computer
...
Service Service actors provides visual
distinction.
Fig. 6.6
 Fig. 6.6
Monopoly

Play Monopoly
Game

Observer
 Monopoly Game
• Very simple use case diagram and text
• Most detail is deferred to Supplementary
Specification (SS)
– Domain rules listed in SS
 Use Cases in Iterative Methods
• Functional requirements recorded in use cases
• Important part of iterative planning
– Work of an iteration decided by choosing use case
scenarios or entire use cases
• Use cases influence organization of user manuals
• Testing builds on use case scenarios
• Iterative interplay between
– Requirements discovery
– Building parts of system
 When Where
Once during inception. Short; do not try to At a requirements workshop.
define or polish all requirements.

Several times during elaboration iterations.

January February

Two adjacent projections.

Use Case: Capture a Sale Use Case: Handle Returns

... ...
Main Success Scenario: Main Success Scenario:
1. ... 1. ...
2. ... 2. ...
3. ... 3. ...
Extensions: Extensions:

System
Analyst Customer

Software
End User Developer Architect

Who
Many, including end users and developers, will play
the role of requirements specifier, helping to write
use cases.
Led by system analyst who is responsible for
requirements definition.
How: Tools
Software:
 For use case text, use a web-enabled requirements tool
that integrates with a popular word processor.
For use case diagrams, a UML CASE tool.
Hyperlink the use cases; present them on the project website.
Hardware: Use two projectors attached to dual video cards and
set the display width double to improve the spaciousness of the
drawing area or display 2 adjacent word processor windows .
Questions
Session 3
 Domain Model
Visualizing Concepts

52
 Comments on diagrams
• Now that we are starting to look at diagrams, I
want to emphasize that this is a class on
analysis and design, not diagramming. While
it may look good on your resume that you can
use UML, your career depends on being able
to translate ideas into good systems. That is
much more difficult.

53
 Domain Model Relationships

Business Model
Domain Model
Classes, attributes, associations

Elaboration on some terms

Domain
objects
Use Case Model Glossary

Requirements

Interaction Diagrams
Design

54
 A Domain Model
• illustrates meaningful conceptual classes in a
problem domain.
• is a visual representation of real-world
concepts, not software components.
• also called Conceptual model
• is NOT a set of diagrams describing software
classes, or software objects and their
responsibilities.

55
 A Domain Model is the most
important OO artifact

• Its development entails identifying a rich set

of conceptual classes, and is at the heart of
object oriented analysis.
• It is a visual representation of the
decomposition of a domain into individual
conceptual classes or objects.
• It is a visual dictionary of noteworthy
abstractions.
56
 Domain Model
UML Notation

• Illustrated using a set of class diagrams for

which no operations are defined.
It may contain:
• Domain Objects or Conceptual Classes
• Associations between conceptual classes
• Attributes of conceptual classes

57
A Domain Model is not a Software
Artifact

A Conceptual class: Software Artifacts:

Sale SalesDatabase

Date vs. Sale

Time
Date
Time
Print()
58
 Think of Conceptual Classes
in terms of:

• Symbols – words or images

• Intensions – its definition
• Extensions – the set of examples to which it
applies
• Symbols and Intensions are the practical
considerations when creating a domain
model.

59
 Decomposition:

• A central distinction between Object-oriented

analysis and structured analysis is the division
by objects rather than by functions during
decomposition.
• During each iteration, only objects in current
scenarios are considered for addition to the
domain model.

60
 Conceptual Class Identification:

• It is better to overspecify a domain with lots

of fine-grained conceptual classes than it is to
underspecify it.
• Discover classes up front rather than later.
• Unlike data modeling, it is valid to include
concepts for which there are no attributes, or
which have a purely behavioral role rather
than an informational role.
61
 Identify Conceptual Classes
by Category List:

Common Candidates for classes include:

Tangible objects, Descriptions, Roles,
Places, Transactions, Containers,
Systems, Abstract nouns, Rules,
Organizations, Events, Processes,
Written Materials, Catalogs, Records,
Financial Instruments and Services
62
 Identify Conceptual Classes
by Noun Phrase:

• Identify Nouns and Noun Phrases in textual

descriptions of the domain.
• Fully dressed Use Cases are good for this type
of linguistic analysis.
It’s not strictly a mechanical process:
• Words may be ambiguous
• Different phrases may represent the same
concepts.
63
 Sales Domain example -
‘Purchase Items’ Use Case

• We find concepts such as Register, Sale, Item,

Customer, Receipt etc. in this use case.

Should we include Receipt in the Model?

• Con: As a report of a sale, it’s duplicate info.
• Pro: Business Rules for a Return require that the
customer has a receipt.
• Suggestion: Include it in the iteration where the
Return Use Case is covered.
64
 Steps to create a
Domain Model

• Identify Candidate Conceptual classes

• Draw them in a Domain Model
• Add associations necessary to record the
relationships that must be retained
• Add attributes necessary for information to
be preserved
• Apply existing Analysis Patterns

65
 Apply the
Mapmaker Strategy

• Use existing names for things, the vocabulary

of the domain
• Exclude irrelevant features
• Do not add things that are not there

66
 A Common Mistake -
Classes as Attributes

• Rule: If we do not think of a thing as a

number or text in the real world, then it is
probably a conceptual class.
• If it takes up space, then it is likely a
conceptual class.
Examples:
• A Store is not an attribute of a Sale
• A Destination is not an attribute of a flight
67
 Specification or Description
Conceptual Classes

• A Class that records information about an

item.
• Even if all Instances of the item are sold out,
the description remains.
• Avoids duplication of recording the
descriptive information with each instance of
the item.

68
 Description of a Service Example
(Flight)

Flight
Date Airport
Flies-to
Time Name
Number vs.

Flight FlightDesc Airport

Described Date Describes
Date Name
-by -flights-to
Time Time

69
Monopoly Concepts (candidates)

Monopoly Game Player Piece

Die Board Square

70
 UML Notation: Multiple
Perspectives
• UML describes raw diagram types, such as class
diagrams. It does not impose a specific method or
process.
• UP, the Unified Process, applies raw UML to defined
methodology models.
UML can be used for 3 different perspectives:
• Essential – describe the real world
• Specifications – software abstractions, such as
components and their interfaces
• Implementation – specific language (Java)
71
 Questions
• Define domain model.
• List the association guidelines.
• Mention some conceptual classes.
• How domain model can be used in Interaction
Diagram?

72
 Session 4
Tutorial- Use Case and Class Diagram
 Objectives
• Describe system behavior and show how to
capture it in a model.
• Demonstrate how to read and interpret:
– A use-case diagram
 Where Are We?
• Concepts in use-case modeling
• Use-case diagrams
 What Is System Behavior?
• System behavior is how a system acts and
reacts.
– It is the outwardly visible and testable activity of a
system.
• System behavior is captured in use cases.
– Use cases describe the system, its environment,
and the relationship between the system and its
environment.
 What Is a Use-Case Model?
• A model that describes a
system’s functional View Report Card

requirements in terms of
use cases. Student
Register for Courses

• A model of the system’s

intended functions (use Login

cases) and its environment

(actors).
 What Are the Benefits of a Use-Case
• Communication Model?
• Identification
• Verification

Communication Use-Case Verification

Identification

Users
End User Domain Expert
 Major Concepts in Use-Case Modeling
• An actor represents anything
that interacts with the system.

Actor

• A use case describes a sequence

of events, performed by the
system, that yields an observable
result of value to a particular
actor. Use Case
 Where Are We?
 Concepts in use-case modeling
 Use-case diagrams
 What Is an Actor?
 Actors represent roles a user of the
system can play.
 They can represent a human, a
machine, or another system.
 They can actively interchange
information with the system.
 They can be a giver of information.
 They can be a passive recipient of
information. Actor
 Actors are not part of the system.
 Actors are EXTERNAL.
 What Is a Use Case?
 Defines a set of use-case instances, where each
instance is a sequence of actions a system
performs that yields an observable result of
value to a particular actor.
 A use case models a dialogue between one or more
actors and the system.
 A use case describes the actions the system takes to
deliver something of value to the actor

Use Case
 Use Cases and Actors
• A use case models a dialog between actors and
the system.
• A use case is initiated by an actor to invoke a
certain functionality in the system.

Actor Use Case

Communicate-association
 How Would You Read This Diagram?
View Report Card

Student
Register for Courses Maintain Professor Information
Course Catalog

Login
Maintain Student Information
Select Courses to Teach

Registrar
Professor

Submit Grades Close Registration

Billing System
 Review
• What is system behavior?
• What is a use-case model? What are
its benefits?
• What is an actor? A use case?

• Open the Lab Manual OOAD and start

your VP tool.
• Follow the steps for drawing diagram’s.
Use Case Diagram in VP Tool
Library Management System
Car Pooling System
 Exercise
• Given:
– Use cases, actors and communicate-
associations.
• Draw:
– A use-case diagram for Online
Shopping System.
Class Diagram
 Objectives
• Describe the static view of the system and
show how to capture it in a model.
• Demonstrate how to read and interpret a class
diagram.
• Model an association and aggregation and
show how to model it in a class diagram.
• Model generalization on a class diagram.
 Where Are We?
• Class diagrams
• Class relationships
– Association
– Aggregation
– Generalization
 What Is a Class Diagram?
• CloseRegistrationForm
Static view of a system
Schedule CloseRegistrationController
- semester
+ is registration open?()
+ open()
+ commit() + close registration()
+ close registration()
+ select alternate()
+ remove offering()
Professor
+ level()
+ cancel() - name
Student - employeeID : UniqueId
+ get cost()
+ delete() - hireDate
+ get tuition() + submit() - status
+ add schedule() + save() - discipline
+ get schedule() + any conflicts?() - maxLoad
+ delete schedule() + create with offerings()
+ has pre-requisites() + update with new selections() + submitFinalGrade()
+ acceptCourseOffering()
+ setMaxLoad()
+ takeSabbatical()
 Class Diagram Usage
• When modeling the static view of a system,
class diagrams are typically used in one of
three ways, to model:
– The vocabulary of a system
– Collaborations
– A logical database schema
 Example: Class Diagram
• Is there a better way to organize class
LoginForm
diagrams?
RegisterForCoursesForm
RegistrationController

Schedule
CloseRegistrationForm CloseRegistrationController

Professor
Student
Course CourseOffering

CourseCatalogSystem
BillingSystem
 Review: What Is a Package?
• A general purpose mechanism for organizing
elements into groups.
• A model element that can contain other
model elements.

University
Artifacts

• A package can be used:

– To organize the model under development
– As a unit of configuration management
Example: Registration Package

Registration

CloseRegistrationForm CloseRegistrationController

RegisterForCoursesForm RegistrationController
 Where Are We?
 Class diagrams
 Class relationships
 Association
 Aggregation
 Generalization
 What Is an Association?
• The semantic relationship between two or more
classifiers that specifies connections among their
instances.
• A structural relationship specifying that objects
of one thing are connected to objects of another
thing.
<<entity>> <<entity>> <<entity>>
Student Schedule Course
 Example: What Associations Can You
Find?
1: submit schedule( )
: RegisterForCoursesForm
2: submit schedule( )
: RegistrationController

: Student
8: any conflicts?( )

3: save( )
4: submit( )

:Schedule 7: still open?( )

9: add student(Schedule)

6: has pre-requisites(CourseOffering)

:CourseOffering
:Student
5: is selected?( )
10: mark as enrolled in( )

:PrimaryScheduleOfferingInfo
 What Is Multiplicity?
• Multiplicity is the number of instances one class
relates to ONE instance of another class.
• For each association, there are two multiplicity
decisions to make, one for each end of the association.
– For each instance of Professor, many Course Offerings may
be taught.
– For each instance of Course Offering, there may be either
one or zero Professor as the instructor.

<<entity>> <<entity>>
instructor
Professor CourseOffering
0..1 0..*
 Multiplicity Indicators
Unspecified
Exactly One 1

Zero or More 0..*

Zero or More *

One or More 1..*

Zero or One (optional scalar role) 0..1

Specified Range 2..4

Multiple, Disjoint Ranges 2, 4..6

 Example: Multiplicity
<<boundary>> <<control>>
1
RegisterForCoursesForm RegistrationController
1

0..1

0..1

<<entity>> <<entity>> <<entity>>

1 0..*
Student Schedule CourseOffering
0..* 0..4
 Where Are We?
 Class diagrams
 Class relationships
 Association
 Aggregation
 Generalization
 What Is an Aggregation?
• A special form of association that models a
whole-part relationship between the aggregate
(the whole) and its parts.
– An aggregation is an “is a part-of” relationship.
• Multiplicity is represented like other
associations.
Whole 1 Part

0..1
 Example: Aggregation
<<boundary>> <<control>>
1
RegisterForCoursesForm RegistrationController
1

0..1

0..1

<<entity>> <<entity>> <<entity>>

1 0..*
Student Schedule CourseOffering
0..* 0..4
 Where Are We?
 Class diagrams
 Class relationships
 Association
 Aggregation
 Generalization
 What Is Generalization?
• A relationship among classes where one class
shares the structure and/or behavior of one or
more classes.
• Defines a hierarchy of abstractions where a
subclass inherits from one or more
superclasses.
– Single inheritance
– Multiple inheritance
• Is an “is a kind of” relationship.
 Example: Single Inheritance
• One class inherits from another.
Ancestor
Account
- balance
Superclass - name
(parent) - number

+ withdraw()
+ createStatement()

Generalization
Relationship

Savings Checking
Subclasses

Descendents
 Example: Multiple Inheritance
• A class can inherit from several other classes.
FlyingThing Animal

Multiple Inheritance

Airplane Helicopter Bird Wolf Horse

Use multiple inheritance only when needed and

always with caution!
Class Diagram in VP Tool
Car Pooling System
Package Diagram
 Review
 What does a class diagram represent?
 What benefits do packages provide to
the model?
 Define association, aggregation, and
generalization.
 How do you find associations?
 What is multiplicity? What information
does multiplicity provide the
modeler?
 Exercise
• Given:
– A set of classes and their relationships
• Draw:
– A class diagram for online shopping system.
Session 5
Class Diagram

116
117
118
119
120
121
122
 Class diagram

Association

logical connection or relationship between classes.

123
Directed Association

Flow of the association by utilizing a directed association

124
Reflexive Association

class may have multiple functions or responsibilities

125
Aggregation

a particular class as a result of one class being aggregated or built as a

collection.

126
Composition

127
7. Generalization/Inheritance

known as an “is a” relationship since the child class is a type of the parent
class.

128
Questions
Session 6-Relationship in Use Case and
Class Diagram
 Relationship in Use Case and Class
Diagram
 Class Diagram Use Case Diagram
- Class Notation - Use Cases under the Microscope
- Object Diagram - Uses and Extends Associations
- Class Interface Notation - Association between actor and use case
- Binary Association Notation - Extend between two use cases
- Association Role - Include between two use cases
- Qualifier - Generalization of a use case
- Multiplicity - Generalization of an actor
- OR Association
- Association Class
- N - Ary Association
- Aggregation and Composition
- Generalization
 Classes
 A class is a description of a set of objects that share the same attributes,
operations, relationships, and semantics.

Graphically, a class is rendered as a rectangle, usually including its

name, attributes, and operations in separate, designated compartments.

Software Design (UML)

 Class Diagram
 Also called object modeling, and it’s the main static diagram.
 Shows the static structure of the Model.
Class Notation : Static Structure
• A class is drawn as a rectangle with three components
separated by horizontal lines.

ClassName

attributes

operations
 Object Diagram
• A static object diagram is an instance of a class
diagram.
• Shows a snapshot of the detailed state of the system
at a point in time, Notation is the same for an object
diagram and a class diagram.
Class Interface Notation
• Class interface notation is used to describe the
externally visible behavior of a class.
Ex: An Operation with public visibility
 Binary Association Notation
• A binary association is drawn as a solid path connecting two
classes, or both ends may be connected to the same class.
• An association may have an association name,
end of an association, where it connects to a class, is called the
association role. See below Figure:
 Association Role
• A simple association- the technical term for it is binary association- is
drawn as a solid line connecting two class symbols.
• The end of an association, where it connects to a class, shows the
association role.

Qualifier
• A Qualifier is an association attribute.
• For example, a person object may be associated to a Bank object. An
attribute of this association is the account#. The account# is the qualifier of
this association.
• The Figure depicts association qualifier
and its multiplicity.
 Multiplicity
• Multiplicity specifies the range of allowable associated classes. It is given
for roles within associations, parts within compositions, and other purposes.
• The terms lower bound and upper bound are integer values, specifying the
range of integers including the lower bound and upper bound.
0………1
0………*
1…3, 7….10, 15, 19,----*

OR Association
• An OR association indicates a situation in which only one several potential
associations may be instantiated at one time for any single object.
• Shown as a dashed line connecting two or more associations, all of which
must have a class in common with the constrained string labeling the
dashed line.
Figure:
An OR association notation. A car may
associate with a person or a company.
 Association Class
• An association class is an association that also has class properties. An
association class is shown as a class symbol attached by a dashed line to an
association path.

N - Ary Association

• An n- ary association is an association among more than two classes.

Figure:
An n-ary (ternary) association that
shows association among class , year,
and student classes.
 Aggregation and Composition (a-part-of)
• Aggregation is a form of association. A hollow diamond is
attached to the end of the path to indicate aggregation.
• Composition , also known as the a-part-of , is a form of
aggregation with strong ownership to represent the component of
a complex object.
• Composition also is referred to as a part-whole relationship.

Generalization
• Generalization is the relationship between a more general class
and a more specific class.
• Shown as a directed line with a closed, hollow arrowhead at the
superclass end.
 Use case Diagram
• A Use Case diagram is a graph of actors, a set of use cases
enclosed by a system boundary, communication associations
between the actors and the use cases, and generalization
among the use cases.
• These relationships are
shown in a use case diagram
i) Communications
ii) Uses
iii) Extends
 Use Cases under the Microscope
• Use Case
• Actors
• In a System
• A measurable value
• Transaction
• Use-case name
Uses and Extends Associations
• The extends association is used when you have one use case
that is similar to another use case but does a bit more or is more
specialized.
• The uses association occurs when you are describing your use
cases and notice that some of them have subflows in common.
 Association between actor and use case
• An actor must be associated with at least one use case.
• An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use case.

Generalization of an Actor
• Generalization of an actor means that one actor can inherit the role of an
other actor. The descendant inherits all the use cases of the ancestor. The
descendant have one or more use cases that are specific to that role.

Extend between two use cases

• An extends shows the relationships between use cases.
• Relationship between use case A and use case B indicates that an instance
of use case B may include (subject to specified in the extension) the
behavior specified by A.
• An 'extends' relationship between use cases is depicted with a directed
arrow having a dotted shaft.
 Include between two use cases
• Include relationship show that the behavior of the included use
case is part of the including (base) use case. The main reason for
this is to reuse the common actions across multiple use cases.
Few things to consider when using the <<include>> relationship.
• The base use case is incomplete without the included use case.
• The included use case is mandatory and not optional.

Generalization of a use case

• The behavior of the ancestor is inherited by the descendant. This

is used when there are common behavior between two use cases
and also specialized behavior specific to each use case.
 Questions
1 . Describe the Class Diagram?
2 What are some forms of associations? Draw their
UML representations?
3 How would you show complete and incomplete
generalizations?
4 What is an association role, Multiplicity, Qualifier?
5 Name and Describe the relationships in a use case
diagram?
 Videos
• https://www.youtube.com/watch?v=OkC7HKti
ZC0
• https://www.youtube.com/watch?v=3cmzqZz
wNDM