USE CASES FOR ANALYSIS IN JDEVELOPER
I. Background
Collecting the business rules of a system is now accepted as a
useful analysis method. It provides a consistent, coherent and complete way of
specifying a system. The problem with a business rule-based approach to
analysis is the large number of rules collected. Specifying only the important
rules for an ERP system may produce 1000 or more rules. Exhaustively gathering
every business rule could easily result in hundreds of thousands of rules being
gathered.
Little progress has been made towards creating a successful and
efficient methodological approach for gathering the business rules of an
organization. Current articles and white papers about business rules and
business rule products have given little attention to the issue of effective
management of large rule sets. Another problem involves knowing when all of the
rules have been gathered.
Use cases from object-oriented (OO) analysis and design can
effectively be used to help solve both problems. Use cases provide an excellent
mechanism for guiding analysts to finding “hidden” rules. Partitioning rules
with use cases helps to place them into manageable groups.
Use cases work well for managing the high-level and mid-level detailed
analysis rules. The very detailed (implementation) rules such as lists of
attributes or classes, their cardinality and access rules can be better handled
through extensions to other UML diagrams or other mechanisms such as “fact
diagrams.”
This paper will present a UML class model representing the structure of a use case-driven application system to support use case-based business rule analysis. How these structures can best be used to drive the analysis process and the support for use cases in JDeveloper will also be discussed.
II. Use Cases
A use case (despite the somewhat confusing term for a very useful
construct) is the way in which one or more “actors” interact with a system to
perform a useful function. There are similar constructs in other analysis
methodologies. In the Oracle Designer methodology (discussed in Koletzke &
Dorsey Oracle Designer Handbook,
Oracle Press, 1998) use cases closely correspond to “functions.” Examples of
business functions that are good candidates for use cases include “employee
fills out timesheet,” “system calculates and distributes payroll,” “customer
purchases a product.” As is always the case with any methodology, there is some
art involved in identifying the appropriate use cases to specify a system.
A. Use Case Structure
What is the structure of a use case? What objects does a use case
interact with? There seems to be no industry consensus in answering these
questions. Different system architects
employ different attributes and will structure their use case models
differently. The only consistency seems to be the idea of a use case itself and
some of the core structures.
B. Sample Use Case Model
The following example shows one way, but by no means a definitive
one, of looking at use cases. The model shown in Figure 1 could easily be
modified by adding or deleting attributes from classes or adding entire
structures.
C. Model Classes
Each class in the model will be described individually along with
its attributes.
1. Source
The rules in a system must come from somewhere and it is
important to track this source. Source types may include interviews, JAD
sessions, system and user documentation, legacy code, etc. Systems analysts may
create their own rules or ideas when performing analysis and these should also
be included as valid source objects.
SOURCE
|
Attribute |
Description |
|
Descr_TX |
Description of class |
|
Intrvw_DT |
Included to help identify a specific interview or JAD session |
|
Name_TX |
Name of class |
|
Type_CD |
Analyst/Interview/JAD session/documentation, etc. |
2. Application
The application class is used to partition the system. It can
refer to departments within an organization, functional grouping, etc. being
supported by the system. For example, in a general ledger system, accounts
payable, accounts receivable, etc. might be separate applications. The
application class in the model is recursive allowing the specification of
applications and sub-applications. Use cases must be attached to an
application.
APPLICATION
|
Attribute |
Description |
|
Descr_TX |
Description of class |
|
Name_TX |
Name of class |
Figure 1: Use Case Model
3. Use Cases
The Use Case class has a recursive relationship (for
specialization) which allows the creation of generalizations between use cases.
This comes in handy in cases such as “employee fills out timesheet” when there
may be special cases such as “contractor fills out timesheet.” The appropriate
use case can be created for the contractor and attached to the more general
“employee fills out timesheet” as a specialization. This means only having to
differentiate how a contractor fills out a timesheet from how an employee fills
out a timesheet.
USECASE
|
Attribute |
Description |
|
Descr_TX |
Description of class |
|
ImpelemNotes_TX |
Provided to allow input about how a use case is implemented in
the design phase |
|
Name_TX |
Name of class |
|
PostCondtn_TX |
Articulates interfaces between use cases; describes the state
of generated objects or system after conclusion of the use case. Ex. “Fill
out timesheet” – post condition would be a processed timesheet. |
|
PreCondtn_TX |
Articulates interfaces between use cases; usually describes use
case inputs or necessary state of the system prior to the use case being
initiated. Ex. “Fill out timesheet” – no preconditions |
|
Status_CD |
Used to represent the usage of the use case in the design
process. For example, assuming a workflow, the status might be “proposed,”
“approved,” “implemented,” etc. |
4. Scenario
All use cases have at least one scenario, commonly called the
“prime scenario.” The prime scenario represents the steps needed to perform the
use case. In the model, individual steps are stored in the Scenario StepClass.
Additional scenarios represent branching or alternatives to how
the use case is accomplished. For example, for filling out a time sheet, the
prime scenario might have the following steps:
1.
Employee fills out timesheet.
2.
Employee submits the timesheet.
3.
Manager approves the timesheet.
4.
System processes the timesheet.
5.
System submits the timesheet to payroll.
An alternative scenario might describe what happens when a
manager rejects a timesheet or when the system detects some variance in
processing a timesheet.
Scenarios must belong to a use case. They may be attached to a
source. If no source is specified for the scenario, it is assumed that the
source is the same as that of the use case. In this instance, Source is only
used to override the use case source.
SCENARIO
|
Attribute |
Description |
|
Descr_TX |
Description of class |
|
ImpelemNotes_TX |
Provided to allow input about how a use case is implemented in
the design phase |
|
Name_TX |
Name of class |
|
Order_NR |
The order number is important since the lowest order number
scenario represents the prime scenario. Other scenarios are ordered by
frequency or commonality. |
|
SourceRefrnc_TX |
If the use case source is in a document, it may be described in
a specific section or come from a specific person. This attribute points to a
specific portion of a document, or the name of a person in a JAD session who
suggested the use case. |
|
Status_CD |
Used to represent the usage of the use case in the design
process. For example, assuming a workflow, the status might be “proposed,”
“approved,” “implemented,” etc. |
5. Scenario Steps
Each scenario is made up of a series of steps. The recursive
relationship on ScenarioStep indicates that a
scenario step may itself be composed of a series of steps. The system
processing a business event may go through many sub-steps. This recursion can
also be handled differently by creating an optional 1-to-1 relationship from
Scenario back to UseCase. This indicates that, in
some cases, a Scenario Step spawns a use case.
SCENARIOSTEP
|
Attribute |
Description |
|
Descr_TX |
Description of class |
|
ImpelemNotes_TX |
Provided to allow input about
how a use case is implemented in the design phase |
|
Order_NR |
Indicates the order of steps |
|
SourceRefrnc_TX |
If the use case source is in a document, it may be described in
a specific section or come from a specific person. This attribute points to a
specific portion of a document, or the name of a person in a JAD session who
suggested the use case. ScenariosStep source behaves like a
Scenario source. If no source is specified for a particular step, the
scenario step source is assumed to be the same as the scenario source. |
|
Status_CD |
Used to represent the usage of the use case in the design
process. For example, assuming a workflow, the status might be “proposed,”
“approved,” “implemented,” etc. |
|
Step_TX |
The description of the steps is stored in Step_TX.
Lengthier descriptions can be stored in DESCR_TX. |
6. Actor
An actor is a person, organization, system or other entity,
either internal or external to the system that will interface in some way with
the system. Actors are usually specified as roles rather than individuals.
However, it may be useful to identify a specific organization as an actor (Ex.
IRS, SSA). An organization can also be specified by role such as “Corporate
Customer.” Internal organizations can also be specified as actors (Audit,
Credit Approval, Personnel).
ACTOR
|
Attribute |
Description |
|
Descr_TX |
Description of class |
|
Name_TX |
Name of class |
|
Type_CD |
Internal Organization, Person, External Organization, etc. |
7. Actor Usage
Actor usage describes the way in which an actor is associated
with a use case. Actor usages are attached to both Actor and Use Case. This is
not represented as a many-to-many association because the same actor may have
multiple roles on the same use case.
ACTORUSAGE
|
Attribute |
Description |
|
Descr_TX |
Description of class |
|
Role_CD |
Role can be specified from a valid list such as: Initiator,
Approver, Data Entry, Processing (for systems) |
8. Rule
A rule in the model shown in Figure 1 is a business rule attached
to a use case that has not already been articulated elsewhere in the model. The
advantage of this structure is that it allows rules to be categorized in one of
the other model classes.
The Rule_TX attribute should be a
sentence following the structure of RuleSpeak™ (BR
Solutions grammar [1]). It is beyond the scope of this paper to
describe RuleSpeak.™ It is useful for rules to follow
such a grammar. As an example consider
the following simple structure:
<Subject> must <Condition>
only if <Modifier>
An example of a rule described using this structure is, “A
purchase order must be approved by a Senior Manager only if the total amount is
greater than $50,000.”
For reporting purposes, short rule names are useful.
RULE
|
Attribute |
Description |
|
ImpelemNotes_TX |
Provided to allow input about how a use case is implemented in
the design phase |
|
Name_TX |
Name of class |
|
Order_NR |
Helpful when many rules are associated with a use case to sort
or group logically |
|
Rule_TX |
Rule stated using the structure: <Subject> must <Condition>
only if <Modifier> |
|
SourceRefrnc_TX |
If the use case source is in a document, it may be described in
a specific section or come from a specific person. This attribute points to a
specific portion of a document, or the name of a person in a JAD session who
suggested the use case. |
|
Status_CD |
Used to represent the usage of the use case in the design
process. For example, assuming a workflow, the status might be “proposed,”
“approved,” “implemented,” etc. |
|
Type_CD |
Validation/Security/Access |
9. Rule Association
One issue with business rules that needs to be supported is that
one rule may have something to do with another rule (replace it, override it,
be equivalent to it, etc.). Rules can also be drilled down in more detail. RuleAssoc represents the relationship between two rules.
RULEASSOC
|
Attribute |
Description |
|
Descr_TX |
Description of class |
|
Reason_CD |
Explains the reason for the association |
III. Rules Analysis Process
The following are the steps for gathering and analyzing the
business rules for designing a system. Appendix A contains some Word document
forms to assist in this process.
A. Create List of Applications
The system must be partitioned at a high level to help create a
plan for approaching analysis. This step does not need to be done very
carefully. Changes can always be made later. Broad partitions merely serve to
guide the analysis and help avoid omissions. Changes are very common and
modifications can easily be made early on in the analysis.
Even for large systems, it is not necessary to specify many
applications or sub-applications. The function of the application is to group
the use cases. Large systems usually contain a few hundred use cases (depending
upon how they are specified). A handful of applications is adequate in the
early stages for partitioning the use cases.
B. Identify Actors
Time and care should be taken with this step in the process. This
step is one of the main advantages to this approach. It is common to have a
large number of actors. Complex systems
may have 100 or more actors. The number of actors is a key early indicator of
the complexity of the system. It is better to include more at the start since
actors can always be combined or deleted later.
C. Initial Use Case Specification
Analysts can then ask the question: “What are the actions that
these actors perform?” The answers to this question usually translate directly
into use cases.
The primary challenge in creating use cases is not to make them
too large or too small. If there are only a few steps in the prime scenario,
the use case is probably a good candidate for combination with another use
case. For example: “fill out timesheet, validate timesheet and approve timesheet
could be combined into the use case “process timesheet.” If all of the
individual actor functions are created as separate use cases, a very large,
often unmanageable, number will be generated. The goal of the process is to
create a document to communicate back to users.
Rules should be organized into manageable chunks. A good rule of
thumb is that if the use case can be described with less than two pages of
text, it is a good candidate for combining with another use case. Anything over
10-20 pages of text indicates that the use case should probably be partitioned.
A common extension to the model is to organize the use cases into
ordered use case groups. To do this, a
class called UseCaseGroup can be added with a
1-to-many relationship to the use case and an ORDER_NR attribute added to the
use case class to indicate which comes first.
There are different opinions about this step in the process.
Should each use case be fully specified at the time of identification or should
a comprehensive use case list be assembled at the outset? When identifying a
use case, attaching the appropriate actors, writing a good description (most
important), identifying the prime scenario, preliminary identification of the
scenario steps and a few key business rules is a sensible strategy. The idea is
to get the development team to think about the business rules for drill down at
a later time.
Spending too much time on use case details at this point is not a
good idea. Many use cases may be clearly out of scope. Many may be combined or
split and any details will need to be moved around.
D. Initial Analysis Review
At this point, a high-level analysis has been completed. This
step involves a more formal examination of the work accomplished in the first
three steps. Have any areas been overlooked? Are all application areas
identified? The structure can be modified accordingly.
In the BRIM®
environment, using class diagrams, activity diagrams and process flows,
high-level formal specifications of the system can be created at this time.
This will validate the current understanding of the system to prevent major
mistakes or omissions in the analysis process.
E. Detailed Analysis
Use cases and prime scenarios have been identified at this point
and must now be fleshed out in more detail. All alternative scenarios must be
identified and described. Simultaneously, modifications should be made to the
detailed implementation repository (In BRIM®, this entails creating class models and activity
diagrams). Particular attention should be paid to the rule area of each use
case.
Use a brainstorming style to gather as many rules as possible.
Rules not captured will not be implemented in the system. If all business rules
are articulated, too many will be gathered. Several hundred or more rules per
use case are too many. An implementation repository helps to confine the rules
and their formal specifications.
As analysis rules are specified, it is important to link them to
the implementation rules. Each analysis rule to be implemented must be represented
in the implementation-level repository. It is critical to provide traceability
back to the original source requirements.
F. Detailed Analysis Review
The following steps should be followed to complete the business
rules analysis:
Review all use cases to find overlaps.
Correct the specification of underlying rules.
Review mapping from analysis rules to the implementation
repository to ensure that each rules has been precisely articulated or declared
out of scope.
Review all rules across use cases to eliminate
contradictions, unpredictable interactions.
The detailed analysis review can be both difficult and time
consuming. There is a temptation to rush into development and deployment.
Ensuring the correctness, completeness and consistency of the business rules is
extremely important.
Use Case Support in JDeveloper
Use cases provide a solid foundation for performing analysis.
Although use cases come out of the object-oriented (OO) programming philosophy,
there is nothing necessarily object-oriented about them. They are an excellent
method of gathering and organizing system requirements.
JDeveloper 10g includes an easy-to-use visual editor to
drag-and-drop actors and use cases onto a diagram and make connections between
them. Behind the scenes, you are really building an HTML document. You can then
double-click on a visual element to edit the associated HTML in a visual mode
that is kind of a WYSIWYG way of editing HTML.
Anything required outside of the analysis framework requires hand
editing of the HTML, although you can also easily edit the templates provided.
What is generated are a series of HTML files, one for each use
case diagram. Elements are added to
those diagrams in the same way in which code elements are added to an HTML
page. The Use Case Editor uses the same
technology as JDeveloper’s HTML editor.
This is not much better or easier than using a word processor to
manage data that should be placed in a repository. JDeveloper currently has no
such repository.
In order to get the benefits of use case requirements analysis,
several hundred pages of text will be needed to articulate all of the use cases
in an enterprise system. Storing these as HTML documents where each diagram of
several use cases is a separate document does not seem like a solid way for
managing this process. To be fair, it is possible that Oracle is assuming a
different purpose for use cases in the overall SDLC. There are several schools
of thought about how to use use cases. However, I do
not see how the vision of utilizing use cases for analysis as described in this
paper can be well supported by JDeveloper’s current implementation. Entering the use cases is cumbersome, and
there is no easy way to manage or search the
When I first started thinking about use cases, there was no
support in JDeveloper. Therefore, I
created a simple repository as shown in Figure 1 and populated it using some
easily built applications. Even though this was just a simple utility, I liked
the idea of having the use case
It should also be mentioned that there is no repository-based
product on the market with a graphical user interface for use case entry. Products seem to going out of their way to
avoid requiring users to have access to a relational database to store a
repository. I, for one, mourn that the
industry seems to be going in that direction.
Conclusion
Use cases provide an excellent means for managing the process of collecting business rules. However, users would be better served by building their own repository or using Word documents to manage their use cases rather than relying on JDeveloper’s use case support. We will have to see how this technology evolves in future versions of the product, but, as of this writing, it has to be declared as “not ready for prime time.”
About the Author
Dr.
Appendix A
The following use case analysis forms can be used to enter
information:
1.
Use Case description form – used to enter information
and descriptions of the use case, actors, prime scenario and any alternate
scenarios.
2.
Business Rules form – Used to list and describe the
relevant business rules.
3.
Area Goals and Objectives - Used to enter objectives,
target dates and criteria for determining when goals are met.
(Form 1) - Use Case
Application Area:
Use Case Name:
Description:
Date Entered: Entered
by:
Supports Goals:
Actors:
|
Type |
Name |
Description |
Role |
|
Indicate whether each actor is either Internal or External AND
whether each actor belongs to one of the following categories: System,
Organization, Person |
Short name of actor |
Short description of
actor |
Role that the actor
plays in this use case, e.g. “Initiator” |
Prime Scenario:
Name:
Description:
Scenario Steps
|
Name |
Description |
|
Step name, e.g. “Approve.” |
Short description of scenario |
Alternate Scenario 1 Name:
Description:
Date Entered: Entered
by:
Scenario Steps
|
Name |
Description |
|
Step name, e.g. “Approve.” |
Short description of scenario step |
(Form 2) - Business Rules
Business Rule Name:
Description:
|
Name |
Date Entered |
Entered by |
Description |
|
|
|
|
|
(Form 3) Area Goals and Objectives
APPLICATION AREA
Name:
Description:
Date Entered: Entered
by:
ACTORS
|
Type |
Name |
Description |
Activities |
|
Indicate whether each actor is either Internal or External AND
whether each actor belongs to one of the following categories: System,
Organization, Person |
Short name of actor |
Short description of actor |
Use Cases |
GOALS & OBJECTIVES
Area Name:
Goal Name:
Description:
Date Entered: Entered by:
SPECIFIC OBJECTIVES
|
Name |
Description |
Date to be met |
Measurement Criteria |
|
Objective name |
Short description of objective |
Target goal completion date |
What will be measured to determine whether or not objective is
met |