From business processes to web services

From Business Processes to Web Services

Michael Weiss, Carleton University

(approach developed in collaboration with Daniel Amyot, University of Ottawa)

(C) Michael Weiss IT Conference 2007, Ottawa 2

Motivation• Web services often developed bottom-up by

exposing legacy system APIs as services• Difficult to align such services with business goals• Need a complementary approach:

– Refining business goals into business processes

– Derive service requirements from processes

• Central role of business processes: glue between business model and software architecture

• This talk is about modeling business goals and processes in the User Requirements Notation


Business Process Modeling

• Structured method for describing and analyzing opportunities for improving the business objectives of stakeholders (identify roles and activities that contribute to business goals)

Software ArchitectureSoftware Architecture

BusinessBusiness Model Model

Business ProcessBusiness ProcessStakeholdersStakeholders


5 W’s

• Why do this activity?• What should this activity be?• Who is involved?• Where should the activity be performed?• When should it be performed?


User Requirements Notation (URN)

• Semi-formal, lightweight method for modeling and analysis of early user requirements:– Bridge between use cases and UML models– Explicitly addresses non-functional requirements

• Combines goal and scenario modeling: – Goal-oriented Requirement Language (GRL)– Use Case Maps (UCM)

• Emerging ITU standard for reactive systems, with particular focus on telecommunications


How URN Fits

Informal Requirements,

Textual Use Cases

UCMs link to operationalizations

(tasks) in GRL models

Structural Diagrams

SDL, ODL, or UML Class,

Object, Component, &

Deployment Diagrams

Testing and Performance Languages

TTCN, LQN, ...

Behavioral DiagramsMSC/SDL, or UML

Sequence, Collabor., & Statechart Diagrams

UCMs represent visually use cases in terms of causal

responsibilities

UCMs provide a framework for

making high level and detailed

design decisions

UCMs visually associate

behavior with structure at the

system level

?

?UML Use Case

Diagram & Activity Diagram

URN-NFR/GRLGoals, non-functional requirements, alterna-

tives, rationales

URN-FR / UCMsSuperimpose visually system level behavior

onto structures of abstract components


Goal-Oriented Requirements Language (GRL)

• Goals describe the objectives a system should achieve, and allows a strategic level of modeling a current or future system and its environment

Can evaluate aGRL model


Use Case Maps (UCM)

• UCMs model scenarios as causal flows of responsibilities that can be superimposed on underlying structures of components

Responsibilities

Components


Tool Support: jUCMNav

• jUCMNav supports both UCM and GRL diagrams• Supports links between both types of models• Open source Eclipse plug-in• http://www.softwareengineering.ca/jucmnav



Supply Chain Case Study

• Based on the SCM sample application of the Web Service Interoperability Organization (WS-I)

– R1. Retailer offers consumer electronic goods to Consumers.

– R2. Retailer needs to manage stock levels in Warehouses.

– R3. Retailer must restock a good from the respective Manufacturer’s inventory, if its stock falls below a certain level.

– R4. Manufacturer must execute a production run to build the finished goods, if a good is not in stock.

– R5. Key events must be logged to a Monitoring System, which allows monitoring services from a single monitoring service.


Business Objectives – GRL

Actors

DependenciesInternal GoalModel per Actor


Business Process – UCM• Create a root map for the business process• Stubs as placeholders (eg SubmitOrder) for further

refinements in lower-level maps


Submit Order• Stubs can be refined via plug-ins• Plug-in for SubmitOrder stub shows details of the

inter-component causal flow …


Fulfill Order• … and plug-in for FuffillOrder stub possible

outcomes of sourcing goods


Source Goods• Check each Warehouse for availability of line

items, and collate the ones we can ship …


Replenish Stock• … and update the Retailer's inventory if necessary


Architectural Alternatives• Alternative 1: Replenishment is triggered on

decrementing the inventory level


Architectural Alternatives• Alternative 2: Replenishment is triggered

periodically by a timer


Non-Functional Requirements

• Trade-offs are made in terms of non-functional requirements (NFRs) and user priorities: alternatives will affect NFRs in different ways


Documenting Trade-Offs• GRL model to compare the alternatives (impact of

Period Replenishment highlighted)


Mapping to Services

• Map the model to web services• Service: collection of related operations that a

component implements• Operation: set of messages exchanged between

service user and provider• Four basic interaction patterns• Extract service provisioning relationships between

components from the UCM


Extract Service Operations

• Look for paths that cut across component boundaries: each indicates a potential message

• Group those messages into operations

Messages

c.NavigateToSite-r.PresentCatalogr.PresentCatalog-c.EnterOrderInfoc.EnterOrderInfo-r.ReceiveOrder

c: Consumerr: Retailer


Service Template

• Documents grouping of messages into operations, and of operations into services

• Lists messages exchanged and their type

Operation: getCatalog() Request: c.NavigateToSite-r.PresentCatalog (Navigate) Response: r.PresentCatalog-c.EnterOrderInfo (Catalog) Operation: submitOrder() Request: c.EnterOrderInfo-r.ReceiveOrder (OrderInfo) Response: r.OrderSuccessful-c.ShipmentConfirmed (ShipmentConfirmed) OR Response: r.NoSuchProduct-c.RejectOrder (RejectOrder) OR Response: r.NoItemCanBeShipped-c.RejectOrder (RejectOrder)


Service-Based Architecture• Service provisioning relationships summarized in

a UML deployment diagram


Validation

• Simple path data model that can be used to traverse paths in a deterministic way

• Works by defining variables and setting them at start points and responsibilities, and using them to define conditional expressions on branches

• Can extract scenarios for various purposes: define test goals, performance analysis

• UCM supports both informal and formal analysis


Support for the 5 W’s

• Why do an activity? GRL models allow the analyst to link business or system goals to architectural alternatives

• What should this activity be? We can refine business goals into high-level tasks with GRL models, and further into low-level responsibilities using UCM models

• Who is involved in this activity? UCM models can also capture the structure of the organization

• Where and when should the activity be performed? UCM models allows us to define how responsibilities are allocated to components, as well as their temporal ordering


Conclusion

• With URN we can model business processes at different levels of formality – GRL models can describe “soft” aspects of a business

process, and their mapping to operational goals

– In a UCM model we can simulate scenarios under different conditions, and walk through their execution

• Evaluation mechanism in GRL lets us analyze the impact of architectural alternatives on goals

• Unlike use cases, UCM models can also provide input to downstream validation activities


Other Current Work

• Business model design and evolution• Modeling business processes in patient care• Monitoring processes via KPIs• Modeling supporting services using aspects


References

• Weiss, M., and Amyot, D., Business Process Modeling with URN, International Journal of E- Business Research, 1(3), 63-90, Idea, 2005

• Weiss, M., and Amyot, D., Business Model Design and Evolution, in: Khalil, T., Management of Technology, Elsevier, 2007

Date post:	29-Jun-2015
Category:	Business
Upload:	michael-weiss
View:	997 times
Download:	3 times