Table Of ContentBBuussiinneessss MMooddeelliinngg
wwiitthh tthhee UUMMLL aanndd
RRaattiioonnaall SSuuiittee
AAnnaallyyssttSSttuuddiioo
A Rational Software White Paper
Table of Contents
Introduction................................................................................................................................................1
Intended Audience......................................................................................................................................1
Background................................................................................................................................................1
What is Business Modeling?......................................................................................................................2
Why Business Modeling?...........................................................................................................................3
Using the UML to Model a Business.........................................................................................................3
RATIONAL SUITE ANALYSTSTUDIO FOR THE BUSINESS ANALYST.......................................4
Using the UML to Model a Business.........................................................................................................4
A Workflow for Business Modeling...........................................................................................................5
UML Diagrams for Business Modeling.....................................................................................................6
Business use-case diagrams....................................................................................................................6
Activity Diagrams..................................................................................................................................6
Class Diagrams.......................................................................................................................................8
Collaboration Diagrams..........................................................................................................................9
Identifying Business Requirements from Business Modeling..................................................................10
Tracking Business Requirements.............................................................................................................11
BUSINESS MODELING EXAMPLE WITH RATIONAL SUITE ANALYSTSTUDIO....................11
Conclusion................................................................................................................................................18
Additional Reading...................................................................................................................................18
Appendix..................................................................................................................................................19
More Information on Rational Solutions..............................................................................................19
Business Modeling with Rational Suite AnalystStudio
Introduction
Rational Suite AnalystStudio is a suite of tools that assists project team members in business modeling
and requirements management activities. Analysts have the critical responsibility to understand the problem
and define requirements for the system to provide a solution to that problem – the overall goal is to create a
system that really solves the customer’s needs. To achieve that goal, a combination of problem analysis,
business modeling, data modeling and requirements management is carried out to ensure that needs from
all stakeholders are appropriately taken into account.
This paper concentrates on AnalystStudio’s functionality as it pertains to the activities of the business
analyst as defined in the Business Modeling workflow of the Rational Unified Process.
The support for business modeling provided in AnalystStudio is not intended to replace business process
modeling tools. Rather, AnalystStudio addresses a particular subset of modelers for whom the primary
issue is bridging the communication gap between business modeling and systems design.
Intended Audience
This paper is written for individuals involved in or managing the business modeling efforts of a software
project, especially as related to system definition. Further information is available in the Business Modeling
workflow of the Rational Unified Process.
Basic UML concepts are assumed (consult the References section for UML books).
Background
We’ll first define some common terms used in this paper:
Actor Someone or something, outside the system that interacts with the system.
Analyst Person/people who must interpret the user needs, and communicate those needs
to the entire team. Job titles of those with Analyst responsibilities include, but
are not limited to, Systems Analyst, Business Analyst, Project Manager, Product
Manager, Systems Engineer, Requirements Engineer, Marketing Manager, etc.
Business Actor Someone or something, outside the business that interacts with the business.
Business Modeling Encompasses all modeling techniques you can use to visually model a business.
Business Object The business object model is an object model describing the realization of
Model* business use cases.
Business Process A group of logically related activities that use the resources of the organization
to provide defined results in support of the organization's objectives. In the
Rational Unified Process, business processes are defined using business use
cases, which show the expected behavior of the business, and business use-case
realizations, which show how that behavior is realized by business workers and
business entities.
Business Use Case A business use case defines a set of business use-case instances, where each
instance is a sequence of actions a business performs that yields an observable
result of value to a particular business actor. A business use-case class contains
all main, alternate workflows related to producing the "observable result of
value".
(In this paper, synonymous with business process)
Business Use-case A model of the business intended functions. The business use-case model is used
1
Business Modeling with Rational Suite AnalystStudio
model as an essential input to identify roles and deliverables in the organization.
Business Use-Case Describes how the workflow of a particular business use case is realized within
Realization the business object model, in terms of collaborating business objects.
Business Worker Role or set of roles inside the business. A business worker interacts with other
business workers and manipulates business entities while participating in
business use-case realizations.
Class A description of a set of objects that share the same attributes, operations,
methods, relationships, and semantics.
Domain Model Captures the most important types of objects in the context of the business
domain. The domain objects represent the entities that exist or events that occur
in the environment in which the system works. The domain model is a subset of
the business object model.
Requirement Describes a condition or capability to which a system must conform; it can be
either derived directly from user needs, or stated in a contract, standard,
specification, or other formally imposed document.
A desired feature, property, or behavior of a system.
Stakeholder An individual who is materially affected by the outcome of the system. End
users are often thought of as the primary stakeholders, but other stakeholders,
such as shareholders and executive management also have a stake in the project.
Stereotype Type of UML modeling element that extends the semantics of the metamodel.
Stereotypes must be based on certain existing types or classes in the metamodel.
Stereotypes may extend the semantics, but not the structure of pre-existing types
and classes. Certain stereotypes are predefined in the UML, others may be user
defined.
What is Business Modeling?
One of the original purposes behind the invention of “Objects” was to more easily understand and design
computer programs by thinking in terms of real-world phenomena, such as people, their working materials
and how they perform their tasks. Business modeling models real-world organizations.
We build models of complex systems because it is difficult to comprehend any such system in its entirety.
Visual models are powerful for two main reasons:
• They make communication easier.
• They allow us to easily manipulate our solutions so we can compare and optimize.
The scope of a business modeling effort may vary. Whether you are aiming at simple productivity increases
by making incremental improvements to existing processes, or you are making significant improvements,
where you substantially change your business processes based on a thorough analysis of your business
mission and who your customers should be. In almost all situations, the supporting information systems are
affected.
In the face of increasingly complex systems, visual modeling becomes essential. As the complexity of
systems increase, so does the importance of good modeling techniques. There are many additional factors
of a project’s success, but having a rigorous modeling language standard is one essential factor.
2
Business Modeling with Rational Suite AnalystStudio
Why Business Modeling?
To ensure we are building customer-oriented solutions, systems that please our customers, we must not
overlook the environment in which these systems will work.
Business models provide ways of expressing the business processes in terms of objects and collaborative
behavior. If business models are not produced you run the risk that developers will only give superficial
attention to the way business is done. They do what they know best, which is to design and create software,
without taking the business processes into account. This could result in a waste of costly business process
engineering effort. You also run the risk that the systems that get built do not support the true needs of the
business.
A good understanding of business processes is important to be able to build the right systems. Some
business modeling efforts have system development as their main underlying goal, the actual task being to
identify good system requirements.
It is valuable to use people's roles and responsibilities, as well as definitions of what "things" are handled
by the business, as a basis for building the system. It is from this more internal view of the business
captured in a business object model that you can see the tightest link to what the models of the system
should look like.
With the advent of e-business, modeling a business is even more important. Building e-business
applications is about building applications that automate business processes.
Once business models are specified, establishing relationships between system use cases and the business
models will enable the analysts to be informed when changes at the business level impact the definition of
the system to be built.
Using the UML to Model a Business
For over 5 years now, the Unified Modeling Language (UML) has been providing system architects
working on system analysis and design with one consistent language for specifying, visualizing,
constructing, and documenting the artifacts of software systems.
The UML is used to model all kinds of systems (software systems, hardware systems, and real-world
organizations). Business modeling uses the UML to model real-world organizations.
This section describes stereotypes that can be used to tailor the UML for business modeling. All of the
UML concepts can be used for business modeling, but supplying business stereotypes for some common
situations provides a common terminology for this domain.
Stereotype icon Name UML representation
Business actor Actor, stereotyped as «business actor».
Business worker Class, stereotyped as «business worker».
Business entity Class, stereotyped as «business entity».
Business use case Use Case, stereotyped as <<business use case>>
3
Business Modeling with Rational Suite AnalystStudio
Business use case Collaboration, stereotyped as «business use-case
realization realization».
Organizational unit Package in the business object model, either its top-level
package, or stereotyped as «organization unit».
These stereotypes have been formalized in the latest version of the UML specification as a UML Profile for
Business Modeling. (UML Profiles provide a standard way to use the UML in a particular area without
having to extend or modify the modeling language itself.)
In brief, the value of using the UML to model a business is to provide a common language and a common
tool for both the business analyst and the system analyst, who is responsible for eliciting requirements and
leading the system definition effort. By sharing a single notation and a single tool across domains, business
analysts and system analysts can better communicate their needs, which is key to building a system that
solves the customers’ problems.
Rational Suite AnalystStudio for the Business Analyst
Using the UML to Model a Business
The business modeling capabilities of Rational Suite AnalystStudio help business analysts represent things
like workflows, responsibilities, and deliverables of their organization in visual models. They also allow the
system analyst to track business objectives, and their relationships to system requirements, so that as
business objectives change, the system definition takes that change into account, resulting in a system that
indeed solves customers’ needs.
Business analysts that will most benefit from the AnalystStudio offerings are:
• Business modelers and software designers seeking to improve the integration between business
models and systems models through a common language and a common tool
• Designers currently using UML for software design and who wish to extend their modeling to include
business processes
In this section, we go into more details on the specific AnalystStudio functionality for the business analysts:
• A workflow for business modeling
• Support for modeling a business using UML
• Tracking changing business requirements as they impact system requirements
The components of AnalystStudio that provide this functionality are: Rational RequisitePro, Rational Rose
and the Rational Unified Process (RUP).
4
Business Modeling with Rational Suite AnalystStudio
A Workflow for Business Modeling
The Rational Unified Process (RUP) provides step-by-step guidance on the various activities of business
modeling, and how they relate to other activities in the software lifecycle. This workflow is depicted in
Figure 1. The activities of the workflow are further explained by RUP tool mentors that instruct you on
how to perform these activities using Rational Rose and Rational RequisitePro.
Figure 1: Business Modeling workflow overview in RUP
The Explore Process Automation workflow detail provides guidelines on how one might derive
requirements for the business activities that can be automated by a new or improved computer system.
5
Business Modeling with Rational Suite AnalystStudio
UML Diagrams for Business Modeling
Business use-case diagrams
The first step in business modeling is to define the interaction between your business processes and entities
outside of your business (suppliers, customers, etc). This is documented in a business use-case diagram.
Rational Rose diagramming capabilities provide an easy mechanism to create use-case diagrams.
A business use-case diagram visually represents the interaction between the primary services (business use
cases) your business provides and those to whom those services are provided (business actors). See Figure
2.
Figure 2: Example of business use-case diagram
All business use cases and their interactions with business actors make up a business use-case model. From
a business use-case model, the business analyst can drill down into each business use case and analyze how
that use case will be performed within the business, creating a business use-case realization for that specific
business use case.
Activity Diagrams
In a business modeling context, an activity diagram is a simple and intuitive illustration of:
• what happens in a workflow,
• what activities can be done in parallel,
• whether there are alternative paths through a workflow.
6
Business Modeling with Rational Suite AnalystStudio
Figure 3: Activity Diagram to document how the business performs a
Proposal process. The vertical fields are called swimlanes, which are used to
show which business worker participates in the realization of the workflow.
Activity diagrams as defined in the Unified Modeling Language represent the dynamics of a system by
expressing flows. They are basically flow charts that are used to show the workflow of the system.
7
Business Modeling with Rational Suite AnalystStudio
Customer Sales Interface Proposal Owner Quote Owner
Figure 4: Activity diagrams can also show ‘object flows’, in this case to visualize how
business entities are delivered throughout the workflow.
Class Diagrams
In a business modeling context, classes represent the high level concepts of a business and the relationships
between those concepts. Class diagrams are used for two main purposes:
• To show what classes are participating in a business use-case realization.
• To show structures and relationships among classes in the business object model.
8
