Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services [email protected]

Practical Business Modeling in the Unified Process

Tom Morgan Software Architect, Fidelity National Information [email protected]


Tom Morgan [email protected]

Agenda

Brief Business Modeling introduction

Artifact production in reference implementation

Transformation into Requirements Use-Case Model

Simple steps for Business Rules Model



Business Modeling overview

Challenges addressed How do you know your software directly addresses business issues? How do you know your use cases are accurate? What is the big picture, or context, to is being developed?

Small knowledgebase – techniques from various sources A lot of “feel your way” needed Different approaches depending on objective

Lifecycle timing Started in early Inception, peeking near end of Inception, trailing off through Elaboration and

Construction phases.

Consists of: Business Use-Case Model - The “What” (actors, goals, use cases) Business Analysis Model - The “How” (workers, entities, events, automation) Business Rules Model - The “Constraints” on the “How” (rules)



Find Business Actors and Use Cases – Goal Driven

Step 1: Determine boundaries (or scope) of target business Main business




Step 1: Determine boundaries (or scope) of target business Main business comprised of one business part



Find Business Actors and Use Cases

Step 1: Determine boundaries (or scope) of target business Main business comprised of two business parts (others omitted here)




Step 1: Determine boundaries (or scope) of target business Narrow focus the Box Office




Step 1: Determine boundaries of target business The Box Office is our box, or business boundary

Start outside box with goal to describe inside




Step 2: Finding Business Actors

Outside of business boundary – our box

May be inside other business areas, or boxes

Concessions, Accounting, Projection

Identify Roles from real Instances

A Business Actor instance can fill many roles

Avoids confusion when Actors and instances don’t all share common goals




Step 2: Finding Business Actors At this point, consider as candidate Business Actors




Step 2: Finding Business Actors Refine to same abstraction, eliminate redundant and ambiguous candidates




Step 2: Finding Business Actors




Step 3: Describe All Business Actors Provide any potentially valuable information




Step 4: Finding Business Actor Goals

Identify Goals from Business Actor towards the business

Goals should be at same abstraction level

Start high level and refine from there

Experience helps – you’ll get better



Find Business Actors and Use Cases

Zeroing in on correct abstraction level

Why?

Why?

Why?

Why?

How?

How?

How?

How?

High Level

Low Level




Step 4: Finding Business Actor Goals




Step 5: Finding Business Goals from Business Actor Goals

Flip the goal and describe from the business perspective,

Describes Business Goal to address Business Actor Goals




Step 6: Find Business Use Cases

Derive Business Use-Case name from Business Goal and Detail attributes

Begin to establish business vocabulary in glossary

A lot in business modeling

Build Diagram and refine






Initial Survey Diagram Completed



Next Activity: Detail a Business Use Case

Write a Business Use-Case Specification for each one in our model External narrative of business process workflow

Manual perspective without system automation

Major distinction from Use Cases in Requirements

Lessons Learned Many ways and approaches

Study and practice required

Pick a style as a convention

Focus on content, not format

Just writing brings value (discovery, convergence)



Detail a Business Use Case



Detail a Business Use Case

Sell Movie Tickets Business Use-Case Specification

Definition: When a Movie Viewer requests admission to one or more movie features at the box office, the business shows movies and sells tickets for admission.

Actors: Movie Viewer

Actor Goal: Go see a movie

Business view of goal: Show movies and sell tickets for admission

Trigger: Movie Viewer requests admission to one or more movie features at the box office

Pre-conditions: The box office is open and staffed Post-conditions: a) Tickets for admission to scheduled movie features are paid for and seating has been adjusted for the features. b) A request couldn’t be fulfilled.

Basic Flow

Start of use case: The business use case begins when a Movie Viewer wants admission to one or more movie features at the theater.

Prepare order: The box office validates the availability of the shows, times, and seats requested. The box office prepares the order according to business policies, reserves the seats, and calculates the amount due.

Collect payment: The box office collects the amount due for the order from the Movie Viewer and gives the Movie Viewer a receipt showing the amount paid and other order details.

Prepare tickets: The box office prepares the tickets and gives them to the Movie Viewer for admission and the business use case ends.

Alternates

Cancel Order: At any step before paying in Collect payment the Movie Viewer cancels the request or is unable to pay. The box office cancels the order and the business use case ends.



Refine Business Use-Case Model

Add, remove, modify Business Use Cases, Actors, Goals Merge and extract use-case flows

Model with extend, include, and specialization associations

Err to merging, but be sensible

Manage your energy/precision level Err to abstraction until necessary

Transition point to Business Analysis Model



Important Opportunities of Business Analysis Model

Traceable to business processes

Early involvement of architects Core development team playing role to make architecture decisions

Identify automation solutions (both vertical and horizontal)

Components emerge (RUP best practice) and reused

Initiates software engineering through visual models (RUP best practice)

Used to derive Requirements Use-Case Model Mitigates guesswork and risk

Justifies model



Find Business Workers and Entities

Step 1: Create Business Use-Case Realization Associate to the correct Business Use Case

Traceability semantics for artifacts

Same name as Business Use Case




Step 2: Find Business Workers

First sequence diagram – Work Processes

Modeling Steps

Identify and Describe Business Workers

Assign responsibilities to Business Workers

Transforms use-case narrative to UML

Maps use-case behavior to worker responsibility

Roles and tasks inside our box

Identify who does what




Step 3: Identify and Describe Business Workers

Consider need for specialist, privileges, experience level, functional activities

Start with real people

Evolve or start with automated workers

Look-ahead: Transformed into Actors in Requirements Model

Describe same as Business Actors







Step 5: Assign responsibilities to Business Workers

Find proper abstraction level

Consists of a group of activities performed by Worker

Not one event or action

Think of time needed to accomplish

– Avoid instantaneous or single action items – abstraction too low

– Should take longer

Find good sets of verbs to describe

May need another role to solve ambiguities

State with enough focus to avoid future ambiguities







Responsibilities may be decomposed by asking “How?”, but not too much




Capture Alternates using UML Combined Fragments in RSA





Next Step: Explore Process Automation

Second sequence diagram – Process Automation Springboard into Requirements model

Start with copy of Work Processes diagram in RSA

Modeling Steps Identify responsibilities needing automation in business process

Identify and describe system components used for activities

Re-assign responsibilities

Decompose and refine as necessary



Explore Process Automation

Identify responsibilities needing automation

Identify and describe system components (same stereotype as Worker)




Re-assign responsibilities (manual tasks remain with Worker)




Decompose and refine as necessary



Explore Process Automation - Complete




Step 6: Identify Business Entities – Starts Domain Model

Start with the Automation Processes diagram in RSA

Introduce and describe Business Entities

Identify things handled during activities

Identify who uses what

Redirect message ending to Business Entities

Remove Automation elements




Add Business Entities to diagram




Detail a Business Entity

Explain role in business

Describe lifecycle (use statechart when needed)




Redirect messages – From Worker to Entity




Remove Automation Elements





Develop a Domain Model

Concepts of business domain

Significant business information and relationships

Try to avoid attributes – refinements made in A&D Just classes keeps model simple and focus at entity level




Sources Business Entities in Information Processes diagram

Grammatical analysis of Business Use-Case Specification

Stakeholders and business experts

Other guidelines As much as necessary – you decide

Update glossary with new terms

Abstraction level focus on things and relationships - Classes level only












Where to go next?

Overlapping disciplines = parallel activities

Finish Business ModelingStart Requirements AND



Deriving the Requirements Use-Case Model

Step 1 – Focus on a single system lifeline (our new scope boundary)




Step 1 – Focus on a single system lifeline (our new scope boundary)




Step 2 – Transform messages ending on scope boundary to use cases




Step 2 – Transform messages ending on scope boundary to use cases




Step 3 – Transform Business Workers to Actors




Step 3 – Transform Business Workers to Actors




Step 4 – Transform messages affecting scope to <<include>> <<extend>>




Step 4 – Transform messages affecting scope to <<include>> <<extend>>




Step 5 – Repeat for other system lifelines




Step 6 – Preserve business process context



The Business Rules Model

Step 1 - Identify business rules location in business process workflows








Basic Flow





Alternates





Step 2 – Identify high level container for rules








Basic Flow





Alternates


Prepare Order Ruleset




Step 3 – Detail business rule definitions

Business Rule Survey

.

.

.

Rule Name: Purchase Time Rule

Definition: Tickets in an order must be purchased within 1 hour of the time for the show.

.

.

.




Step 4 – Validate rule terms against domain model (refine)




Step 5 – Associate rules to rule containers








Basic Flow





Alternates


Prepare Order Ruleset



Questions




Thank You

Documents

Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services [email protected]