• Like
From business processes to web services
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

From business processes to web services


Web services often developed bottom-up by exposing legacy system APIs as services. It is difficult to align such services with business goals. This talk presents a complementary approach that starts …

Web services often developed bottom-up by exposing legacy system APIs as services. It is difficult to align such services with business goals. This talk presents a complementary approach that starts from business goals and refines them to business processes.

Published in Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. From Business Processes to Web Services Michael Weiss, Carleton University (approach developed in collaboration with Daniel Amyot, University of 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
  • 3. 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 Architecture Business Model Business Process Stakeholders
  • 4. 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?
  • 5. 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
  • 6. How URN Fits UCMs link to operationalizations (tasks) in GRL models 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 Informal Requirements, Textual Use Cases Structural Diagrams SDL, ODL, or UML Class, Object, Component, & Deployment Diagrams Testing and Performance Languages TTCN, LQN, ... Behavioral Diagrams MSC/SDL, or UML Sequence, Collabor., & Statechart Diagrams ? ? UML Use Case Diagram & Activity Diagram URN-NFR/GRL Goals, non-functional requirements, alterna-tives, rationales URN-FR / UCMs Superimpose visually system level behavior onto structures of abstract components
  • 7. 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 a GRL model
  • 8. Use Case Maps (UCM)
    • UCMs model scenarios as causal flows of responsibilities that can be superimposed on underlying structures of components
    Responsibilities Components
  • 9. 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
  • 10.  
  • 11. 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.
  • 12. Business Objectives – GRL Actors Dependencies Internal Goal Model per Actor
  • 13. Business Process – UCM
    • Create a root map for the business process
    • Stubs as placeholders (eg SubmitOrder) for further refinements in lower-level maps
  • 14. Submit Order
    • Stubs can be refined via plug-ins
    • Plug-in for SubmitOrder stub shows details of the inter-component causal flow …
  • 15. Fulfill Order
    • … and plug-in for FuffillOrder stub possible outcomes of sourcing goods
  • 16. Source Goods
    • Check each Warehouse for availability of line items, and collate the ones we can ship …
  • 17. Replenish Stock
    • … and update the Retailer's inventory if necessary
  • 18. Architectural Alternatives
    • Alternative 1: Replenishment is triggered on decrementing the inventory level
  • 19. Architectural Alternatives
    • Alternative 2: Replenishment is triggered periodically by a timer
  • 20. Non-Functional Requirements
    • Trade-offs are made in terms of non-functional requirements (NFRs) and user priorities: alternatives will affect NFRs in different ways
  • 21. Documenting Trade-Offs
    • GRL model to compare the alternatives (impact of Period Replenishment highlighted)
  • 22. 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
  • 23. 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.PresentCatalog r.PresentCatalog-c.EnterOrderInfo c.EnterOrderInfo-r.ReceiveOrder c: Consumer r: Retailer
  • 24. 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)
  • 25. Service-Based Architecture
    • Service provisioning relationships summarized in a UML deployment diagram
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. Other Current Work
    • Business model design and evolution
    • Modeling business processes in patient care
    • Monitoring processes via KPIs
    • Modeling supporting services using aspects
  • 30. 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