1 / 69

Practical Business Modeling in the Unified Process

Learn how to effectively model your business using the Unified Process, from artifact production to requirements use-case modeling. Address challenges and ensure your software directly addresses business issues.

fontenotj
Download Presentation

Practical Business Modeling in the Unified Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services temx@bellsouth.net

  2. Agenda • Brief Business Modeling introduction • Artifact production in reference implementation • Transformation into Requirements Use-Case Model • Simple steps for Business Rules Model

  3. 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)

  4. Find Business Actors and Use Cases – Goal Driven • Step 1: Determine boundaries (or scope) of target business • Main business

  5. Find Business Actors and Use Cases – Goal Driven • Step 1: Determine boundaries (or scope) of target business • Main business comprised of one business part

  6. 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)

  7. Find Business Actors and Use Cases – Goal Driven • Step 1: Determine boundaries (or scope) of target business • Narrow focus the Box Office

  8. Find Business Actors and Use Cases – Goal Driven • Step 1: Determine boundaries of target business • The Box Office is our box, or business boundary • Start outside box with goal to describe inside

  9. Find Business Actors and Use Cases – Goal Driven • 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

  10. Find Business Actors and Use Cases – Goal Driven • Step 2: Finding Business Actors • At this point, consider as candidate Business Actors

  11. Find Business Actors and Use Cases – Goal Driven • Step 2: Finding Business Actors • Refine to same abstraction, eliminate redundant and ambiguous candidates

  12. Find Business Actors and Use Cases – Goal Driven • Step 2: Finding Business Actors

  13. Find Business Actors and Use Cases – Goal Driven • Step 3: Describe All Business Actors • Provide any potentially valuable information

  14. Find Business Actors and Use Cases – Goal Driven • 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

  15. How? Find Business Actors and Use Cases • Zeroing in on correct abstraction level How? Why? How? High Level Why? How? Why? Low Level Why?

  16. Find Business Actors and Use Cases – Goal Driven • Step 4: Finding Business Actor Goals

  17. Find Business Actors and Use Cases – Goal Driven • 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

  18. Find Business Actors and Use Cases – Goal Driven • 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

  19. Find Business Actors and Use Cases – Goal Driven

  20. Initial Survey Diagram Completed

  21. 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)

  22. Detail a Business Use Case

  23. Detail a Business Use Case

  24. 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

  25. 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

  26. 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

  27. Find Business Workers and Entities • 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 whodoeswhat

  28. Find Business Workers and Entities • 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

  29. Find Business Workers and Entities

  30. Find Business Workers and Entities • 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

  31. Find Business Workers and Entities

  32. Find Business Workers and Entities • Responsibilities may be decomposed by asking “How?”, but not too much

  33. Find Business Workers and Entities • Capture Alternates using UML Combined Fragments in RSA

  34. 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

  35. Explore Process Automation • Identify responsibilities needing automation • Identify and describe system components (same stereotype as Worker)

  36. Explore Process Automation • Re-assign responsibilities (manual tasks remain with Worker)

  37. Explore Process Automation • Decompose and refine as necessary

  38. Explore Process Automation - Complete

  39. Find Business Workers and Entities • 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 whouseswhat • Redirect message ending to Business Entities • Remove Automation elements

  40. Find Business Workers and Entities • Add Business Entities to diagram

  41. Find Business Workers and Entities • Detail a Business Entity • Explain role in business • Describe lifecycle (use statechart when needed)

  42. Find Business Workers and Entities • Redirect messages – From Worker to Entity

  43. Find Business Workers and Entities • Remove Automation Elements

  44. 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

  45. Develop a Domain Model • 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

  46. Develop a Domain Model

More Related