(INDIRA) Call Girl Aurangabad Call Now 8617697112 Aurangabad Escorts 24x7
UseCase Model.pptx
1. Software Engineering, Modeling & Design
Sanjivani Rural Education Society’s
Sanjivani College of Engineering, Kopargaon-423603
(An Autonomous Institute Affiliated to Savitribai Phule Pune University, Pune)
NAAC ‘A’ Grade Accredited, ISO 9001:2015 Certified
Department of Information Technology
(NBA Accredited)
Mr. N. L. Shelake
Assistant Professor
2. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Use Case Modeling
In use-case modeling, the system is looked upon as a black box whose
boundaries are defined by its functionality to external stimuli.
The actual description of the use-case is usually given in plain text. A
popular notation promoted by UML is the stick figure notation
Both visual and text representation are needed for a complete view.
A use-case model represents the use-case view of the system
A use-case view of a system may consist of many Use-case diagrams.
An use-case diagram shows (the system), the actors, the use-cases and the
relationship among them.
3. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Components of Use-case Model
The components of a Use-case model are:
System Name
name
Use-case
Actor
Use Case
Generalization
Symbol
Association
<<include>> <<extend>>
4. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
System
As a part of the use-case modeling, the boundaries of the system are
developed.
System in the use-case diagram is a box with the name appearing on the top.
Define the scope of the system that you are going to design with your
EXAM. (software scope)
EXAM Software Appln.
5. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Actors
An actor is something or someone that interacts with the system.
Actor communicates with the system by sending and receiving messages.
An actor provides the stimulus to activate an Use-case.
Message sent by an actor may result in more messages to actors and to
Use-cases.
Actors can be ranked: primary and secondary; active and passive.
Actor is a role not an individual instance.
6. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Actors Identification
Identifying actors is one of the first steps in use case analysis.
Each type of external entities with which the system must interact is
represented by an actor
7. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
which has the following characteristics:
An actor in use case modeling specifies a role played by a user or any other
system that interacts with the subject.
An Actor models a type of role played by an entity that interacts with the
subject (e.g., by exchanging signals and data), but which is external to the
subject.
Actors may represent roles played by human users, external hardware, or
other subjects.
Actors do not necessarily represent specific physical entities but merely
particular facets (i.e., “roles”) of some entities that are relevant to the
specification of its associated use cases.
8. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Finding Actors
The actors of a system can be identified by answering a number of
questions:
Who will use the functionality of the system?
Who will maintain the system?
What devices does the system need to handle?
What other system does this system need to interact?
Who or what has interest in the results of this system?
9. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Actors classification
Actors can be people, other systems, time triggers, or event triggers.
Primary Actor: a user whose defined user goal and is fulfilled by the
system
The primary actor of a use case is the stakeholder that calls on the system to
deliver one of its services. It has a goal with respect to the system – one that
can be satisfied by its operation. The primary actor is often, but not always,
the actor who triggers the use case.
10. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Actors classification
Supporting Actors: a user who provides a service (e.g., information) to the
system.
A supporting actor (also known as a secondary actor) in a use case in an
external actor that provides a service to the system under design. It might be
a high-speed printer, a web service, or humans that have to do some
research and get back to us.
11. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Types of actors include:
12. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Actors Generalization
refers to the relationship which can exist between two actors in a use case
diagram and which shows that one actor (descendant) inherits the role and
properties of another actor (ancestor).
The generalization relationship also implies that the descendant actor can
use all the use cases that have been defined for its ancestor.
generalization is simply the inheritance relationship
between two actors by which one actor inherits
all the properties and relationships of another actor.
13. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Actors Generalization
14. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Use-cases
A Use-case in UML is defined as a set of sequences of actions a system
performs that yield an observable result of value to a particular actor.
Actions can involve communicating with number of actors as well as
performing calculations and work inside the system.
A Use-case
is always initiated by an actor.
provides a value to an actor.
must always be connected to at least one actor.
must be a complete description.
15. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
UseCase Identification
A use case is a methodology used in system analysis to identify, clarify and
organize system requirements.
The use case is made up of a set of possible sequences of interactions
between systems and users in a particular environment and related to a
particular goal.
Use cases describe the functional requirements of a system from the end
user's perspective
16. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
UseCase Identification
creating a goal-focused sequence of events that is easy for users and
developers to follow
The alternate flow, also known as an extending use case, describes normal
variations to the basic flow as well as unusual situations.
17. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
UseCase Identification
A use case should display the following characteristics:
Organizes functional requirements.
Models the goals of system/actor interactions.
Records paths -- called scenarios -- from trigger events to goals.
Describes one main flow of events and various alternate flows.
Multi-level, so that one use case can use the functionality of another one.
18. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
UseCase Identification
Use cases can be identified in two methods:
i. Use case identification on actor-based: method
(a) Find and specify all the actors by looking at which users will use the
system and which other systems must interact with it.
(b) For each actor, identifying the processes they initiate or participate in by
looking at how the actor communicate/interact with (or use) the system to do
his work.
19. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
UseCase Identification
ii. Use case identification on event-based method
(a) Identify the external events that a system must respond to.
(b) Relate the events to actors and use cases.
20. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
21. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
22. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
To represent complex relationships between different use cases, we can use the
extend and include relationships.
Extend relationship: The use case is optional and comes after the base use
case. It is represented by a dashed arrow in the direction of the base use
case with the notation <<extend>>.
Include relationship: The use case is mandatory and part of the base use
case. It is represented by a dashed arrow in the direction of the included use
case with the notation <<include>>.
Uses/Include and Extend Associations
23. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
24. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
25. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
26. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Class Responsibility Collaborator (CRC) model
is a collection of standard index cards that have been divided into three
sections
A class represents a collection of similar objects, a responsibility is
something that a class knows or does, and a collaborator is another class
that a class interacts with to fulfill its responsibilities.
27. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
28. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Class Modeling
Use Static modelling is the base on which the edifice of object orientation
is built.
A static model signifies the conceptual view of a system.
UML class Diagram is referred as Object Modeling
Static Structure of Model
Doesn’t shows temporal
29. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Class Modeling
Example college library system will definitely have concepts like book,
magazine, library attendant, librarian, student, teacher, book-issue policy,
book return policy, book procurement policy, a procedure to calculate fine
in the case a book/magazine is returned after the due date, a procedure to
determine the book//magazine to be replaced only in the reference section
and those in the take-home section and so on.
30. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Class Modeling
Object can be instantiated from classes
An object has identity, data and operations to be performed on the data.
The identity of the object is indicated by the uniqueness of its name.
This unique name differentiates the particular object from other objects.
The data stored within an object includes the attributes of the object.
The operations serve as a means manipulating data stored in a particular
object
31. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Class Modeling
Thus, the attributes of book in the above-mentioned college library system
can be
Author
Title
Publisher
Catalogue number
Accession number
Number of pages
32. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Operation to be performed on a book object can include operations to set
and get the values for the above-mentioned attributes.
Object structure contains both data and behavior within it.
Two different levels
Conceptual level
Each attribute can have corresponding set & get operations in order
to allocate and retrieve the data respectively
Design level
Implementation can be done by using graphical user interface
consisting of forms that can be designed that purpose
33. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Classes and Objects
A class is a concept within the application domain being modelled
Class diagram is to model the static view of an application
Class diagrams are the only diagrams which can be directly mapped with
object-oriented languages and thus widely used at the time of construction.
Class is what the programmer designs and programs, where as an
object is created from a class at runtime.
34. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Class Name
The name of the class appears in the first partition.
Class Attributes
Attributes are shown in the second partition.
The attribute type is shown after the colon.
Attributes map onto member variables (data members) in code.
Class Operations (Methods)
Operations are shown in the third partition. They are services the class
provides.
The return type of a method is shown after the colon at the end of the
method signature
35. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Classes and Objects
MyClass
36. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Attributes and Operations
Triangle
Base : float
Height : float
Area : float
+setBase(in b:float):void
+getBase(): float
+setHeight(in h:float): void
+getHeight():float
+calculateArea(): void
+getArea():float
37. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Classes and Objects
The purpose of the class diagram can be summarized as −
Analysis and design of the static view of an application.
Describe responsibilities of a system.
Base for component and deployment diagrams.
Forward and reverse engineering.
38. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
How to Draw a Class Diagram
Class diagrams have a lot of properties to consider while drawing but here
the diagram will be considered from a top level view.
Class diagram is basically a graphical representation of the static view of
the system and represents different aspects of the application.
A collection of class diagrams represent the whole system.
39. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
How to Draw a Class Diagram
The following points should be remembered while drawing a class diagram
The name of the class diagram should be meaningful to describe the aspect
of the system.
Each element and their relationships should be identified in advance.
Responsibility (attributes and methods) of each class should be clearly
identified
For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
40. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Use of Class Diagram
Describing the static view of the system.
Showing the collaboration among the elements of the static view.
Describing the functionalities performed by the system.
Construction of software applications using object oriented languages.
41. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Visibility of Attributes and Operations
Private Visibility (-)
Public Visibility (+)
Protected Visibility (#)
42. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Attributes with Default Values
Triangle
-custName:String =“Tom”
-custID:int = 100
//some operations
43. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Multiplicity
Specifies the range of allowable associated classes.
It is gives for roles within associations, parts within compositions, repetitions
Multiplicity specification is shown as text string comprising a period-
separated sequence of integer intervals.
Interval represents
lower bound….upper bound
The star character(*) may be used for the upper bound, denoting an unlimited
upper bound.
44. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Multiplicity
If a single integer value is specified, then integer range contains the single
values .
For example:-
0..1
0..*
1..3, 7…10, 15, 19..*
45. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
has
*
Account Person
0..1
Multiplicity
46. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Binary Association Notation
It is drawn as a solid path connecting two classes, or both ends may be
connected to the same class
May have an association name
May have optional black triangle in it, the point indicating the direction in
which to read the name.
47. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Binary Association
owns
Person Flat
48. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Binary Association
owns
Person Flat
ownedBy
49. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
One to one Association
Unidirectional Association
owns
1
Person Flat
1
50. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
One to Many Association
Unidirectional Association
owns
1
Person Flat
*
51. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Many to Many Association
Unidirectional Association
owns
*
Person Flat
*
52. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Many to one Association
Unidirectional Association
owned by
*
Person Flat
1
53. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
one to Many Association
Bidirectional Association
owns
1
Person Flat
*
ownedBy
54. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Many to Many Association
Bidirectional Association
owns
*
Person Flat
*
ownedBy
55. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
one to Many Association
Bidirectional Association
owns
1
Person Flat
*
ownedBy
Mapping class to Java Code
Public class Person
{
public Flat owns;
}
Public class Flat
{
Public Person ownedby;
}
56. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
One to One Association
Unidirectional Association
owns
1
Person Flat
1
Mapping class to Java Code
Public class Person
{
public Flat owns;
}
Public class Flat
{}
57. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Mapping class to Java Code
Triangle
-Base : float
-Height : float
-Area : float
-nonOfTriangles:int
+setBase(in b:float):void
+getBase(): float
+setHeight(in h:float): void
+getHeight():float
+calculateArea(): void
+getArea():float
+getNumberOfTrainagle():int
Public class Triangle{
private float base;
private float height;
private float area;
private static int noOfTraingles;
public void setBase(float b)
{}
public float getBase()
{}
public void calculateArea()
{}
Class Scope Attribute
58. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Role Names
coached By
1
Coach Player
1..6
Role Name is String placed at the end of an association near the class
to which it applies.
It denotes the role played by the class with respect to the association
Batsman
Bowler
coaches
59. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Role Names
The role is part of the association, not part of the class
Each association has two or more roles which it is connected.
Term association navigation or navigability to specify a role
affiliated with each end of an association relationship.
An arrow may be attached to the end of the path to indicate that
navigation is supported in the direction of the class pointed to.
60. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Association Role
worksFor
employer
Company Person
*
employee
Person
marriedto
61. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Qualified Association
employed By
1
Company Person
*
One to Many association between company and Person
Employee
Employer
employs
62. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Qualified Association
employed By
0..1
Company Person
0..1
Qualified association between company and Person
Employee
Employer
employs
empID
The Qualifier is drawn as small box at the end of an association near the class from
which the navigation should be made
A qualifier is an association attribute
63. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Qualified Association
employed By
0..1
Company Person
0..1
Qualified association between company and Person
Employee
Employer
employs
empID
The qualifier rectangle is part of the association path, not part of the class.
Qualified associations can be used with one to many or many to many
associations
64. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Association Class
An Association Class is a UML construct
that enables an Association to have
attributes and operations (features).
This results in a hybrid relation with the
characteristics of an Association and a
Class.
The association class is a class that is
connected to the association of two
classes using a dashed line.
65. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Association Class
Consider the relationship “person rents flat’. To rent flat, often a contract is required
Now the details of the rent such as the amount and mode of payment of rent are
neither the property of the class person nor the property of the class Flat
It is a property of the association ‘rents’. So an association class called ‘Rent’ can be
made and the properties of rent can be included in it. Operations can also be added
to this class
66. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Ternary association / N-Ary Association
Consider the case of buying reference book for a college library.
Total bills depends on
The publisher
The quantity of books
The price of each book
Assist in finding total bill that will contain the itemized details
Multiplicity on all classes has to be *
67. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Ternary association
Publisher
BookPrice PurchasedQty
68. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Ternary association
Publisher
BookPrice PurchasedQty
TotalBill
|
|
|
69. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Ternary association shows among class, year and student classes
70. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Recursive association
Person
*
Mother
givesBirthTo
1
Child
A class may have an association to itself.
This association is called recursive association
One person (Mother) can give birth to other
persons (child)
At one end the person plays the role of mother and
at the end that of a child
71. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Multiple Associations between Two Classes
Train Station
*
*
1
1
arrivesAt
leavesFrom
Two classes can have multiple associations between them.
Many trains can arrive at a station and many trains can leave a station
Public class Train
{
public Station arrivesAt;
public Station leavesFrom;
}
Public class Station
{
}
72. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Aggregation and Composition
Aggregation is a form of association
A hollow diamond is attached to the end of the path to indicate
aggregation
However, the diamond may not be attached to both ends of a line, and it
need not be presented at all
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 is also referred to as a part-whole relationship
The UML notation for composition is a solid diamond at the end of a path
73. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Aggregation and Composition
74. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Composite Aggregation
This aggregation shows that the parts reside within the whole.
Composition implies a relationship where the child cannot exist independent of the
parent.
more specific and use the composition link in cases where in addition to the part-of
relationship between Class A and Class B
75. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Generalization
Generalization is a mechanism for combining similar classes of objects
into a single, more general class
Generalization identifies commonalities among a set of entities
The commonality may be of attributes, behaviour, or both
In other words, a superclass has the most general attributes, operations,
and relationships that may be shared with subclasses. A subclass may
have more specialized attributes and operations.
Specialization is the reverse process of Generalization means creating
new sub-classes from an existing class
76. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Abstract Class
Abstract class is a class that is not allowed to have any instances.
Attributes and operations are only declared within this class
Subclasses inherit these features from the abstract class
Each subclass will have its own definition for each method declared in
the abstract superclass.
It is represented by italicizing the superclass or using the keyword
{abstract} beside the superclass name, in the name compartment of the
superclass
77. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Abstract Class
Abstract class
CalArea():void{abstract}
AreaOf Circle AreaOfTraingle
78. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Abstract Class
A class that has one abstract operation is compulsorily an abstract class
A subclass that inherits from an abstract superclass must implement all
operations of that superclass, or itself become abstract.
Abstract operations are denoted by the keyword {abstract} beside the
operation declaration.