The document discusses functional modeling using activity diagrams and use cases. It provides guidelines for creating activity diagrams and use cases, including identifying activities, control flows, decisions, and parallel processes for activity diagrams. It also discusses writing use case descriptions in SVDPI form from an observer perspective and creating use case diagrams by connecting actors to use cases. The overall purpose is to understand and create functional models to document requirements and describe business processes.
2. Objectives
*Understand the rules and style guidelines
for activity diagrams.
*Understand the rules and style guidelines
for use cases and use case diagrams.
*Understand the process used to create
use cases and use case diagrams.
*Be able to create functional models using
activity diagrams, use cases, and use
case diagrams.
際際滷 2
3. Functional models
?Used to document and
understand requirements
?Describe business processes and
interaction with environment
?Used for both as-is and to-be
systems
?Two types: activity diagrams and
use cases.
際際滷 3
4. Functional models
?Both activity diagrams and use
cases are logical models
describe the activities of a
system without specifying how
the activities are implemented
?Focus on how business runs instead
of implementation details
際際滷 4
6. Activity Diagrams
?Used for any process modeling activity, esp.
business process modeling
?Process models show how a business system
operates
?Processes/activities performed
?How objects/data move
際際滷 6
7. BPM With Activity Diagrams
?A number of activities support
a business process across
several departments
?Activity diagrams model the
behavior in a business
process
?Sophisticated data flow diagrams
?Addresses Parallel concurrent activities and
complex processes
際際滷 7
12. Creating Activity Diagrams
1.Since an activity diagram can be used to model
any kind of process ,you should set the context
or scope of the activity being model.
Once you have determined the scope, you should
give the diagram an appropriate title.
2.You must identify the activities, control flows, and
object flows that occur between the activities.
3.You should identify any decisions that are part
of the process being modeled.
4.You should attempt to identify any prospects for
parallelism in the process.
5.You should draw the activity diagram
際際滷
12
14. Use Cases
?Formal way of representing
how system interacts with its
environment.
?Illustrates the activities that are
performed by users of a system
?Provide external or functional
view of a process, not internal
mechanism.
際際滷
14
15. What are Use-Case
Descriptions?
?Describe basic functions of the system
?What the user can do
?How the system responds
?Use cases are building blocks for continued
design activities.
際際滷
15
16. How Are Use-Cases
Created?
?Two steps:
?Write text-based case
descriptions
?Translate descriptions into
diagrams
?Describes one and only one
function, but may have multiple
paths.
際際滷
16
18. Guidelines for Creating
Use-Case Descriptions
際際滷
18
?Write each step in ^SVDPI ̄ form
?Clarify initiator and receivers of action
?Write from independent observer perspective
?Write at same level of abstraction
?Ensure a sensible set of steps
?Apply KISS principle liberally
?Write repeating instructions after the set of
steps to be repeated.
25. Identifying the Major Use-
Cases
?Review the activity diagram
?Identify the system¨s boundaries
?List the primary actors
?List the goals of each primary actor
?Identify and write the major use-
cases
?Carefully review and revise use-
cases
際際滷
25
26. Expand the Major Use-
Cases
?Choose one major use-case to
expand
?Fill in details on the use-case template
?Fill in the steps of the normal flow of
events
?Normalize the size of each step
?Describe alternate or exceptional
flows
?Simplify and organize as necessary
際際滷
26
27. Confirm the Major Use
Cases
?Review the current set
?Consider semantics and syntax
?Helpful to involve the users
?Iterate the entire set of steps until all use cases
are defined
際際滷
27
28. Create the Use-Case
Diagram
?Start with system boundary
?Place elements in order to be easy to read
?Place actors on the diagram
?Conclude by connecting actors to use cases by
lines.
際際滷
28
30. Expanding the Domain
?Additional resources regarding use-cases and
many other object-oriented development topics
can be found at:
?: . .http //www omg org
際際滷
30
31. Summary
?Use-case descriptions are the
basis for further analysis and
design.
?Use-case diagrams present a
graphical overview of the main
functionality of a system.
際際滷
31