Use
Cases for Analysis in JDeveloper
Dr. Paul Dorsey, Dulcian, Inc.
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 |