Business Modeling with the UML and Rational Suite AnalystStudio

Citation preview

Business Modeling with the UML and Rational Suite AnalystStudio 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 Analyst

Business Actor Business Modeling Business Object Model* Business Process

Business Use Case

Business Use-case

Someone or something, outside the system that interacts with the system. 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. Someone or something, outside the business that interacts with the business. Encompasses all modeling techniques you can use to visually model a business. The business object model is an object model describing the realization of business use cases. 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. 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) A model of the business intended functions. The business use-case model is used

1

Business Modeling with Rational Suite AnalystStudio

model Business Use-Case Realization Business Worker

Class Domain Model

Requirement

Stakeholder

Stereotype

as an essential input to identify roles and deliverables in the organization. Describes how the workflow of a particular business use case is realized within the business object model, in terms of collaborating business objects. 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. A description of a set of objects that share the same attributes, operations, methods, relationships, and semantics. 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. 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. 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. 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 Business actor

UML representation 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

3

Business Modeling with Rational Suite AnalystStudio

Business use case realization

Collaboration, stereotyped as «business use-case 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

Business Modeling with Rational Suite AnalystStudio

Quote Owner

Customer Sales Interface Proposal Owner

Order

Delivery Project Plan

Proposal

Quote

Figure 5: A class diagram showing a view of participating business workers and business entities in a Proposal process.

1 1..* Order

Proposal

1..*

Quote

Delivery Project Plan

Figure 6: A class diagram showing relationships among business entities in the business model.

Collaboration Diagrams A collaboration diagram documents how business workers and business objects interact to perform a business use-case realization.

9

Business Modeling with Rational Suite AnalystStudio

Figure 7: A collaboration diagram

Identifying Business Requirements from Business Modeling One of the benefits of business modeling is to provide business input to the software requirements, to ensure that the systems we build fulfill business objectives, rather than a desire to build “cool” technology. Entities identified in the business models will drive business requirements on the system to be built. With Rational Suite AnalystStudio, business requirements are captured in a textual Word document, to add context around business rules applied to the system. These documents are stored along with other requirements specifications in the requirement management component of AnalystStudio (Rational RequisitePro). Individual business requirements are marked in the documents and traced to system requirements to ensure changes in the business model are reflected in the system requirements.

Figure 8: Relation between models of the business and models of a system

10

Business Modeling with Rational Suite AnalystStudio

Figure 9: For each business worker, identify a candidate system actor. For each business use case the business actor participates in, create a candidate system use case

Tracking Business Requirements After business requirements have been identified in Rational RequisitePro, traceability links between business requirements and system requirements are established to ensure that the impact of changing business needs can be quickly recognized. Views of requirement traceability can be easily queried to find holes in requirements coverage. Each high-level system requirement (feature requirement) should be traced to at least one business requirement (else why does the system have this requirement?). If a business requirement changes as we are building the system, RequisitePro quickly indicates what part of the system definition needs to be updated to ensure that we eventually still deliver a system of value to our customers.

Business Modeling Example with Rational Suite AnalystStudio In this section, we’ll demonstrate how Rational Suite AnalystStudio helps analysts include business considerations in system definition. As mentioned in earlier sections, several UML diagrams (activity diagrams, class diagrams, use-case diagrams and collaboration diagrams) can be used to document business processes. In this example, we will show how to: • Create an activity diagram for a business process • Elaborate some of the business use cases with textual information attached to use cases • Identify specific business considerations to be tracked (as business requirements) as they may impact system requirements • Establish traceability relationships between these business requirements and system requirements • Display the impact of changing business statements Business models (business use-case model and business object model) are created in Rational Rose. The documenting and tracking of business requirements is performed in Rational RequisitePro by: • marking business requirements in Word documents, • prioritizing business requirements, • measuring the impact of business requirements to the system definition.

11

Business Modeling with Rational Suite AnalystStudio

Business requirements (in RequisitePro) are linked to business models (in Rose) using the Integrated Use Case Management feature in AnalystStudio. This feature adds requirements management properties (requirement attributes, traceability and documentation) to Rose use cases. From a Rose (business or system) use case, you can select use case attributes (for prioritization purposes), trace to other requirements (for impact analysis purposes), and you can attach a Word document in which you can mark specific requirements to be tracked in RequisitePro. For the purpose of this paper, Integrated Use Case Management allows the individual(s) who scope manage the project to include business requirements as driving force to the system definition. To provide organization to our business model, we create two packages in the Rose Use Case View: • a Business Use-case model (for business modeling) • a Use-case model (for system modeling) Our example uses two business processes: Buy Product and Replenish Inventory. We create an activity diagram for the Buy Products business use case to show the flow of this business process. We start our business modeling by creating an activity diagram for the Buy Products business use case. In that activity diagram, we differentiate between the various business workers by using three swimlanes: • Customer, • eCashier and • Credit Line (Officer). *a swimlane represents a business worker responsible for the activities in that swimlane.

12

Business Modeling with Rational Suite AnalystStudio

The next step is to create the starting activity that initiates the business process. In our case, this activity is the customer selecting a product to buy.

Since this is the initial activity, we indicate this by creating a start state with a transition to the activity.

We have two transitions from the decision diamond. One returns to the Select Product to Buy activity. This transition is taken if the customer wishes to select another product to buy.

Since the Customer may select more than one product to buy we need to be able to loop back to the activity if the customer wishes to select another product to buy. This is accomplished by adding a decision point after the Select Product to Buy activity and a transition from the activity to the decision point.

13

Business Modeling with Rational Suite AnalystStudio

Once the customer has selected all the products to be purchased, he must check out. We add this activity to our model.

After the customer checks out, the eCashier must calculate the amount of purchase. We add the Calculate Total activity to the eCashier swimlane along with a transition from the Check Out activity to the Calculate Total activity.

The next logical step for the Customer is to pay the bill, but this cannot be accomplished until the Calculate Total activity is complete.

14

Business Modeling with Rational Suite AnalystStudio

To show this we add a synchronization line to the model and transitions from the Check Out activity and the Calculate Total activity to the synchronization line. This indicates that both activities must be completed before you can continue.

Once we reach the synchronization point, the Customer must pay the bill so we add a Pay activity to the Customer swimlane along with a transition from the synchronization line to the Pay activity.

There are two ways to pay: credit and cash/check. If the customer chooses to pay by credit, the transaction is processed by the Credit Line (Officer). We add an activity called Purchase via Credit Card to the Credit Line (Officer) swimlane with a transition from the Pay activity to the Purchase via Credit Card activity. Since we only want this transition to be taken if the Customer wants to pay by credit card we need to add a guard condition to the transition.

15

Business Modeling with Rational Suite AnalystStudio

If the Customer pays by cash or check, the eCashier must perform the Charge and Dispense Return activity where the eCashier accepts the payment and return change if needed to the Customer.

The transition from the Pay activity to the Charge and Dispense Return activity only occurs if the Customer chooses to pay by cash or check so we add a guard condition to the transition.

The next and last activity in this diagram is the Customer receiving the ordered products. This is shown by adding the activity Receive Merchandise with a transition from both the Charge and Dispense Return and the Purchase via Credit Card activities.

16

Business Modeling with Rational Suite AnalystStudio

Since this is the last activity in the diagram we add the Stop State to show the end of the business process. Now that we have documented the business processes at a high level in our business model, we ensure that our work is taken into account in the systems specification by incorporating requirement management properties to our business use cases Buy Product and Replenish Inventory. To add some textual context to business use cases, we attach a business use case specification (Word) document to the business use cases. That specification is automatically stored as a (RequisitePro) requirements document in which specific business requirements are identified and marked to be tracked as part of the requirement scope management process. This is provided by the Integrated Use Case Management feature that allows easy addition of requirement properties to Rose use cases. Using requirement attributes, business requirements are then prioritized in a (RequisitePro) requirement attribute matrix.

17

Business Modeling with Rational Suite AnalystStudio

Business requirements (BUS) are finally traced to system Feature requirements (FEAT), which are traced to Test requirements (TPL) and system use case requirements (UC). Suspect links marked as a slashed red line indicate potential impact of requirement change. By visualizing changes in business requirements, we can ensure that the impact of that change is fully understood.

Conclusion In this paper, we discussed the value of Rational Suite AnalystStudio to model a business, so that software requirements fully take into account business considerations. Business modeling support in AnalystStudio includes: •

Business modeling guidelines in RUP, to help analysts follow proven steps to perform business modeling activities,

•

A business modeling tool, to effectively model business processes using the same notation (UML) and same tool (Rational Rose) asthe software developers and data modelers on the team,

•

A requirement management tool (Rational RequisitePro) to maintain relationships between business requirements and software requirements, ensuring that as business requirements change, the software team is informed of the impact on software requirements.

Using Rational’s approach, business analysts/modelers and software modelers can work closer together to effectively engineer critical business processes and develop the information systems required to support these processes in the real world.

Additional Reading For a more in-depth discussion of the concepts and principles presented in this paper, consult: • • • • • • •

The Object Advantage--Business Process Reengineering with Object Technology by Ivar Jacobson Managing Software Requirements – a Unified Approach – chapter 5 on Business Modeling - by Dean Leffingwell and Don Widrig UML specification at http://www.rational.com/uml/index.jtmpl The UML Reference Manual by Jim Rumbaugh, 1998 The Rational Unified Process Business Modeling Workflow Business modeling with the UML at http://www.usecasehelp.com/downloads/uml_bp_paper.doc Business Modeling with UML—Business Patterns at Work, Hans-Erik Eriksson and Magnus Penker

18

Business Modeling with Rational Suite AnalystStudio

Appendix

More Information on Rational Solutions About Rational Suite AnalystStudio Rational Suite products were created to unify software development teams while optimizing the effectiveness of individual practitioners on the team. Rational Suite AnalystStudio is optimized for the “analyst role” on the team, including systems analysts, data analysts and business analysts, and is comprised of: • • • • • • •

Rational Rose – Data Modeler Professional Edition, the market-leading tool for visual modeling Rational RequisitePro* for comprehensive requirements management Rational ClearQuest* for change request management Rational Unified Process* providing on-line best practice guidelines Rational SoDA* for software documentation automation Rational TestManager* for test planning Rational ClearCaseLT* for software configuration management

*Common to all Rational Suite products, these tools are part of the Team Unifying Platform serving to unifying the team with a common set of tools pertinent for all roles on the software team. The Rational Suite family of products includes Rational Suite DevelopmentStudio for developers, Rational Suite TestStudio for testers, and Rational Suite Enterprise for those seeking a complete set of Rational’s tools. About Rational Rose Rational Rose uses a common, standard modeling language (UML) accessible to non-programmers wanting to model business processes as well as to programmers modeling application logic. Rational Rose allows the analyst to create a graphical representation of requirements, using use-case diagrams and activity diagrams to increase the understanding of the system to build, prior to drilling into requirements details. About Rational RequisitePro Rational RequisitePro is a flexible, easy-to-adopt requirements management tool used for documenting, organizing and managing requirements throughout the development lifecycle. RequisitePro increases the likelihood to deliver quality systems on time and on budget by unifying all team members  project managers, QA managers, testers, developers, etc.  by communicating and managing all project requirements. About Rational ClearQuest Rational ClearQuest is a flexible change request management and defect tracking system that scales to the needs of any project, for any size team. ClearQuest shortens development cycles by unifying all team members — project managers, testers, developers, and analysts — in managing software development change.

19

Business Modeling with Rational Suite AnalystStudio

About the Rational Unified Process The Rational Unified Process — the e-coach™ for software teams — is a Web-enabled software engineering process that enhances team productivity and delivers software best practices to all team members. This e-coach makes process practical by providing prescriptive guidelines, templates and examples for all critical e-development activities. The e-coach is non-intrusive and tightly integrated with Rational software tools, allowing development teams to gain the full benefits of the Unified Modeling Language (UML), software automation, and other industry best practices. About Rational SoDA Communicating project information can be time consuming and difficult. Project lifecycle documentation and reports are often produced haphazardly, or are neglected altogether because of the effort and time involved in creating and maintaining them. Rational SoDA overcomes these issues by automating the creation and maintenance of comprehensive project documentation and reports. Unlike manual methods, SoDA generates complete documentation more easily and with greater consistency by automatically extracting data from multiple tool sources. About Rational TestManager Rational TestManager is the one place to manage all testing activities - planning, design, development, execution, and analysis. TestManager ties together testing with the rest of the development effort joining your testing assets and tools to provide a single point from which to understand the exact state of your project. About Rational ClearCase-LT Rational ClearCase LT is a software configuration management solution for project workgroups. ClearCase LT offers Unified Change Management (UCM), Rational's "best practices" based, out-of-the-box process enabling project teams to manage change at the activity level and control workflow. Enterprise customers requiring distributed servers or server replication can upgrade to ClearCase from ClearCase LT without changing their process, data or the way they work.

20

Corporate Headquarters 18880 Homestead Rd. Cupertino, CA 95014 Toll-free: 800.728.1212 Tel: 408.863.9900 Fax: 408.863.4120 Email: [email protected] Web site: www.rational.com For International Offices: www.rational.com/corpinfo/worldwide/location.jtmpl Rational, Rational logo, Rational the e-development company, Rational RequisitePro, Rational Rose, Rational ClearQuest, SoDA, Rational Suite, AnalystStudio, TestStudio, PerformanceStudio and the Rational Unified Process are trademarks or registered trademarks of Rational Software Corporation. References to other companies and their products use trademarks owned by the respective companies and are for reference purposes only. ALL RIGHTS RESERVED. Made in the U.S.A.  Copyright 2000 by Rational Software Corporation. TP-802 3/00. Subject to change without notice.