© 2005 course technology1 1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard Podeswa Instructor: Mr. Ahmed Al Astal Chapter 3 An Overview of Business Object-Oriented Modeling (B.O.O.M.)

© 2005 course technology2 2 University Of Palestine Chapter Objectives At the end of this chapter, you will know the steps of B.O.O.M. (Business Object-Oriented Modeling)—a procedure for eliciting, analyzing, documenting, and testing requirements using object-oriented and complementary techniques.

© 2005 course technology3 3 University Of Palestine B.O.O.M. and SDLCs The SDLC defines the specific phases and activities of a project. The names of the phases differ from SDLC to SDLC, but most SDLCs have something close to the following phases: 1.Initiation: Make the initial business case for the project. 2.Analysis: Determine the business requirements. 3.Execution: Design and code the software. 4.Test: Assure quality of the product. 5.Close Out: End project activities.

© 2005 course technology4 4 University Of Palestine B.O.O.M. and SDLCs (Cont.) The B.O.O.M. steps take place during the Initiation and Analysis phases. Testing activities are also included in B.O.O.M., but these occur during the Analysis phase rather than in a separate Testing phase.

© 2005 course technology5 5 University Of Palestine The B.O.O.M. Steps: 1: Initiation The purpose of Initiation is to get a rough cut at the business case for a proposed IT project. The conundrum is that without knowing the requirements, it’s impossible to estimate the cost of the project. On the other hand, without a business justification for the project, it is difficult to justify much requirement analysis.

© 2005 course technology6 6 University Of Palestine The B.O.O.M. Steps: 1: Initiation ( Cont. ) In this course, you’ll learn how to do this using a number of UML techniques that keep you focused on high-level needs. These techniques are: 1.Business use cases: A tool for identifying and describing end- to-end business processes impacted by the project. 2.Activity diagrams: Used to help you and stakeholders form a consensus regarding the workflow of each business use case. 3.Actors: These describe the users and external systems that will interact with the proposed IT system. 4.System use cases: Used to help stakeholders break out the end- to-end business processes into meaningful interactions with the IT system.

© 2005 course technology7 7 University Of Palestine The B.O.O.M. Steps: 1: Initiation ( Cont. ) By the end of this phase, you will: have a rough idea about the project as well as a fairly comprehensive list of system use cases. Know which users will be involved with each system use case. You won’t know the details of each system use case yet, but you will know enough to be able to ballpark the project.

© 2005 course technology8 8 University Of Palestine The B.O.O.M. Steps: 1: Initiation ( Cont. ) The main deliverable of this phase is a Business Requirements Document (BRD). You’ll create it in this phase, and revise it as the project progresses. To help manage scope, you’ll save a copy of the document at the end of each phase. Following are the steps you’ll learn to carry out during this phase :

© 2005 course technology9 9 University Of Palestine The B.O.O.M. Steps: 1: Initiation ( Cont. ) 1a) Model business use cases i) Identify business use cases (business use-case diagram) ii) Scope business use cases (activity diagram) 1b)Model system use cases i) Identify actors (role map) ii) Identify system use-case packages (system use-case diagram) iii) Identify system use cases (system use-case diagram) 1c) Begin static model (class diagrams for key business classes) 1d) Set baseline for analysis (BRD/initiation)

© 2005 course technology10 University Of Palestine The B.O.O.M. Steps: 2: Analysis The purpose of the Analysis phase is to elicit the detailed requirements from stakeholders. Then analyze and document them for verification by stakeholders and for use by the developers. You will exploit a number of UML and complementary techniques to assist in requirements elicitation, analysis, and documentation during this phase.

© 2005 course technology11 University Of Palestine The B.O.O.M. Steps: 2: Analysis (Cont. ) Some of the main techniques you’ll learn to use include: System use-case specifications, storyboarding the interaction between users, and the proposed IT system as each system use case is played out. State machine diagrams, describing the life cycle of key business objects. Class diagrams, describing key business concepts and business rules that apply to business objects, such as accounts, investments, complaints, claims, and so on.

© 2005 course technology12 University Of Palestine The B.O.O.M. Steps: 2: Analysis (Cont. ) Following are the steps you’ll learn to carry out during this phase: 2a) Dynamic analysis i) Describe system use cases (use-case description template) ii) Describe state behavior (state machine diagram) 1. Identify states of critical objects 2. Identify state transitions 3. Identify state activities 4. Identify super states 5. Identify concurrent states

© 2005 course technology13 University Of Palestine The B.O.O.M. Steps: 2: Analysis (Cont. ) 2b) Static analysis (object/data model) (class diagram) i) Identify entity classes ii) Model generalizations iii) Model transient roles iv) Model whole/part relationships v) Analyze associations vi) Analyze multiplicity vii) Link system use cases to the static model viii) Add attributes ix) Add look-up tables x) Distribute operations xi) Revise class structure

© 2005 course technology14 University Of Palestine The B.O.O.M. Steps: 2: Analysis (Cont. ) 2c) Specify testing (test plan/decision tables) i) Specify white-box testing quality level ii) Specify black-box test cases iii) Specify system tests 2d) Specify implementation plan (implementation plan) 2e) Set baseline for development (BRD/analysis)

© 2005 course technology15 University Of Palestine Sequencing the Steps Steps 2a), dynamic analysis, and 2b), static analysis, should be performed in parallel. 1. You begin working on the static model during Initiation, describing key business classes and their relationships to each other. 2. During the Analysis phase, you describe a system use case (step 2ai), then verify it against the existing static model: Does the system use case comply with rules expressed in the static model? Has the system use case introduced new classes?

© 2005 course technology16 University Of Palestine Sequencing the Steps( Cont. ) 3.By the time you have described the last system use case, the static model should be complete and fully verified.

© 2005 course technology17 University Of Palestine What Do You Define First—Attributes or Operations? The OO principle of encapsulation suggests that in understanding how each object is used in a system, it’s more important to know its operations than its attributes. Operations are all that objects see of each other. (However, when doing OOD, I start with the operations.)