Scribd
Upload
46 views10 pages

Slide 1 Slide 2

Uploaded by

praba karan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
46 views10 pages

Slide 1 Slide 2

Uploaded by

praba karan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 10

Slide 1

Slide 2
Introduction – UML 2.0 diagrams and When to use which diagrams
Process models
How Does UML Fit Into a Process?
The Waterfall Process
The Spiral Process
The Iterative and Incremental Process
Requirements Phase
Analysis Phase
Slide 3
Use case Models
Use Cases
Why Modeling Use Cases
Benefits of use cases
Problems with use cases
Use Cases and Scenarios
Elements of Use case diagram
Relationships
Relationships between Actors
Relationships between Use Cases & Actors
Relationships between Use Cases
Slide 4
At the end of this lecture You will be able to :
Learn about process models
Elements of use case diagrams
Draw a use case diagram to depict functional requirements of a system.
Write use case description for a use case.

Slide 5
Slide 6
Slide 7
UML 2.0 has 13 diagram types (versus 9 in UML 1.x),
Here’s a sneak preview of what’s coming up later.
You can see that they all have symbols containing text, joined by lines in various
styles
Slide 8

Here are two more


Only significant one here is the class diagram , and then state diagram more
precisely called the state chart diagram
Slide 9

Here are two more activity and package diagram

Slide 10
Slide 11
Slide 12
As we saw in the previous lecture, UML is a language that aids communication
and understanding between the various stakeholders in the system.
Effective communication allows people to determine whether someone has
made a mistake, or, alternatively, if there is something inherently wrong with the
system to be computerised.
Using UML, a complete, accurate and fully consistent description of the system
can be created. This is an essential requirement in software system creation as a
computer will only perform the functions it is programmed to carry out. If there
are errors in the system description, then this will ultimately be transmitted in
the final software system.
Using UML allows mistakes and system errors to be easily identified. This will
mean that the system definition will change. As this may impact on other parts of
the system, it is therefore necessary to revisit the entire system description. This
process of looping though the system, removing errors is absolutely essential and
unavoidable, and is described as Iteration.
Iteration is only possible when there is effective communication between the
stakeholders. And this demonstrates how UML is integral to the software
development process.
Slide 13
Slide 14
Slide 15
Slide 16
Slide 17
Functional requirement are user ‘visible’ features and are typically initiated by
stakeholders of the system – generate report, login, etc.
Non-functional requirements are ‘non-visible’ features and but required for a
effective running of an application – security, backup, etc.
Slide 18
Slide 19
Slide 20
Slide 21
In practice most of the time during the requirements analysis is usually spent
designing the use cases, using these as a means to investigate the intended
behavior of the system. It is impossible to completely cover the entire set of
behaviors in the requirements analysis. Finding the right trade-off between the
completeness of the use cases and the time and effort spent in requirements
analysis is an important aspect of this phase. The use case model (as well as the
other models) will be further extended and refined during the elaboration phase
so it is important to force the requirements analysis phase to a completion when
a sufficient level of understanding has been reached.
When the Use Cases describe the functional aspects of the System to build
When the Conceptual Model expresses the major components of the problem
domain
When the system interface is well defined
When developers feel comfortable estimating the time it will take to develop
each use case
Slide 22
Behavioral models describe the internal dynamic aspects of an information
system that supports business processes in an organization
UML behavioral models are: Use case diagrams, activity diagrams, sequence
diagrams, collaboration diagrams, and statechart diagrams
Slide 23
Slide 24
Slide 25
Slide 26
Slide 27
Use-case diagram consists of three main components:
– Actors
– Use-cases, and their
– communications
A diagram that shows a set of use cases and actors and their relationships.
Use cases represent system functionality, the requirements of the system from
the user’s perspective.
Slide 28
Slide 29
Slide 30
Slide 31
Slide 32
Slide 33
Slide 34
Slide 35
Slide 36
Slide 37
Slide 38
Slide 39
Slide 40
Slide 41
An actor represents a set of roles that users of use case play when interacting
with these use cases.
Actors can be human or automated systems.
Actors are entities which require help from the system to perform their task or
are needed to execute the system’s functions.
Actors are not part of the system.
Slide 42
Slide 43
An actor represents a role that a user can play, but NOT a specific user
• Primary actors are those who use the system’s main functions, deriving
benefits from it directly.
Primary actors are completely outside the system and drive the system
requirements
Secondary actors play a supporting role to facilitate the primary actors to achieve
their goals.
– Secondary actors often appear to be more inside the system than Outside
An actor may be:
– People
– Computer hardware and devices
– External systems
Slide 44
Slide 45
Slide 46
Slide 47
Slide 48
Slide 49
Slide 50
Slide 51
The child use case inherits the behavior and meaning of the parent use case.
In other words, it is valid to put the child usecase
at a place wherever a parent use-case appears
The relationship between the child use-case and the parent use-case is the
generalization relationship
For example: suppose the ATM system can be used to pay bills. Pay Bill has two
child use cases:
Pay Credit Card Bill and Pay Utility Bill
Slide 52
Slide 53
In the process of developing a use case model, we may discover that some use
cases share common behaviors

Slide 54
There are also situations where some use cases are very similar but they have
some additional behaviors
For example, Withdraw Money and Deposit Money both require the user to log-
on to an ATM system

Slide 55
Slide 56
Include relationships are used when two or more use cases share some common
portion in a flow of events
This common portion is then grouped and extracted to form an inclusion use
case for sharing among two or more use cases
Most use cases in the ATM system example, such as Withdraw Money, Deposit
Money or Check Balance, share the inclusion use-case Login Account

Slide 57
Slide 58
Slide 59
Slide 60

In UML modeling, you can use an extend relationship to specify that one use case
(extension) extends the behavior of another use case (base)
This type of relationship reveals details about a system or application that are
typically hidden in a use case
The base use case implicitly incorporates the behavior of another use case at
certain points called extension points.
The base use case may stand alone, but under certain conditions its behavior
may be extended by the behavior of another use case.
Slide 61

• While the base use case is defined independently and is meaningful by itself,
the extension use case is not meaningful on its own
The extend relationship specifies that the incorporation of the extension use case
is dependent on what happens when the base use case executes
The extension use case owns the extend relationship.
You can specify several extend relationships for a single base use case
Slide 62
The extension use case can access and modify the attributes of the base use
case;
however, the base use case is not aware of the extension use case and,
therefore, cannot access or modify the attributes and operations of the
extension use case
Slide 63
Slide 64
Slide 65
You can add extend relationships to a model to show the following situations:
– A part of a use case that is optional system behavior
– A sub flow is executed only under certain conditions
– A set of behavior segments that may be inserted in a base use case
The use of include and extend is discouraged simply because they add
unnecessary complexity to a Use Case diagram.
Since the primary purpose of use cases is to show user centered functionality,
the precedence of use cases takes little importance.
Slide 66
Slide 67

You might also like