
B. O. O. M. : Business Object-Oriented Modeling for Business Analysts.
Title:
B. O. O. M. : Business Object-Oriented Modeling for Business Analysts.
Author:
Podeswa, Howard.
Personal Author:
Physical Description:
1 online resource (401 pages)
Contents:
Contents -- Introduction -- chapter 1 Who Are IT Business Analysts? -- Chapter Objectives -- The IT and Non-IT BA -- Perspective on the IT BA Role -- Why Modeling Is a Good Thing -- The Dynamic (Behavioral) Model -- The Static (Structural) Model -- For Those Trained in Structured Analysis -- Chapter Summary -- chapter 2 The BA's Perspective on Object Orientation -- Chapter Objectives -- What Is OO? -- The UML Standard -- Cognitive Psychology and OO? -- Objects -- The BA Perspective -- Attributes and Operations -- The BA Perspective -- Operations and Methods -- The BA Perspective -- Encapsulation -- The BA Perspective -- OO Concept: Classes -- The BA Perspective -- OO Concept: Relationships -- OO Concept: Generalization -- The BA Perspective -- OO Concept: Association -- The BA Perspective -- OO Concept: Aggregation -- The BA Perspective -- OO Concept: Composition -- The BA Perspective -- OO Concept: Polymorphism -- The BA Perspective -- Use Cases and Scenarios -- The BA Perspective -- Business and System Use Cases -- The BA Perspective -- Chapter Summary -- chapter 3 An Overview of Business Object-Oriented Modeling (B.O.O.M.) -- Chapter Objectives -- B.O.O.M. and SDLCs -- The B.O.O.M. Steps -- 1: Initiation -- 2: Analysis -- Sequencing the Steps -- What Do You Define First-Attributes or Operations? -- Chapter Summary -- chapter 4 Analyzing End-to-End Business Processes -- Chapter Objectives -- B.O.O.M. Steps -- 1. Initiation -- Interviews During the Initiation, Analysis, and Test Phases -- Step 1: Initiation -- What Happens During Initiation? -- How Long Does the Initiation Phase Take? -- Deliverables of the Initiation Step: BRD (Initiation Version) -- Business Requirements Document Template -- Timetable -- Step 1a: Model Business Use Cases -- How Do You Document Business Use Cases?.
Step 1a i: Identify Business Use Cases (Business Use-Case Diagram) -- Other Model Elements -- Putting Theory into Practice -- Note to Rational Rose Users -- Case Study D1: Business Use-Case Diagrams -- Problem Statement -- Suggestions -- Step 1a ii: Scope Business Use Cases (Activity Diagram) -- Activity Diagrams for Describing Business Use Cases -- Case Study D2: Business Use-Case Activity Diagram with Partitions -- Problem Statement -- Suggestions -- Business Use Case: Manage Case (Dispute) -- Business Use Case: Administer Payments -- Case Study D2: Resulting Documentation -- Next Steps -- Chapter Summary -- chapter 5 Scoping the IT Project with System Use Cases -- Chapter Objectives -- Step 1b: Model System Use Cases -- Step 1b i: Identify Actors (Role Map) -- Case Study E1: Role Map -- Problem Statement -- Case Study E1: Resulting Documentation -- Step 1b ii: Identify System Use-Case Packages (System Use-Case Diagram) -- Managing a Large Number of Use Cases -- What Criteria Are Used to Group System Use Cases into Packages? -- Naming Use-Case Packages -- Diagramming System Use-Case Packages -- What If a Use-Case Package Is Connected to All of the Specialized Actors of a Generalized Actor? -- Case Study E2: System Use-Case Packages -- Problem Statement -- Suggestions -- Case Study E2: Resulting Documentation -- Step 1b iii: Identify System Use Cases (System Use-Case Diagram) -- System Use Cases -- Features of System Use Cases -- What Is the Purpose of Segmenting the User Requirements into System Use Cases? -- Modeling System Use Cases -- Is There a Rule of Thumb for How Many System Use Cases a Project Would Have? -- Case Study E3: System Use-Case Diagrams -- A) Manage Case -- B) Administer Payments -- C) Other Business Use Cases -- Case Study E3: Resulting Documentation -- Step 1c: Begin Static Model (Class Diagrams for Key Business Classes).
Step 1d: Set Baseline for Analysis (BRD/Initiation) -- Chapter Summary -- chapter 6 Storyboarding the User's Experience -- Chapter Objectives -- Step 2: Analysis -- Step 2a i: Describe System Use Cases -- The Use-Case Description Template -- The Fundamental Approach Behind the Template -- Documenting the Basic Flow -- Use-Case Writing Guidelines -- Basic Flow Example: CPP System Review Case Report -- Documenting Alternate Flows -- Typical Alternate Flows -- Alternate Flow Documentation -- Example of Use Case with Alternate Flows: CPP System/Review Case Report -- Documenting an Alternate of an Alternate -- Documenting Exception Flows -- Guidelines for Conducting System Use-Case Interviews -- Activity Diagrams for System Use Cases -- Related Artifacts -- Decision Tables -- The Underlying Concept -- When Are Decision Tables Useful? -- Example of a Use Case with a Decision Table -- A Step-by-Step Procedure for Using a Decision Table During an Interview to Analyze System Behavior -- Case Study F1: Decision Table -- Suggestion -- Case Study F1: Resulting Documentation -- Decision Trees -- How to Draw a Decision Tree -- Case Study F2: Decision Tree -- Case Study F2: Resulting Documentation -- Condition/Response Table -- Business Rules -- Advanced Use-Case Features -- Case Study F3: Advanced Use-Case Features -- Problem Statement -- Case Study F3: Resulting Documentation -- Chapter Summary -- chapter 7 Life Cycle Requirements for Key Business Objects -- Chapter Objectives -- What Is a State Machine Diagram? -- Step 2a ii: 1. Identify States of Critical Objects -- Types of States -- Case Study G1: States -- Case Study G1: Resulting Diagram -- Step 2a ii: 2. Identify State Transitions -- Depicting State Transitions in UML -- Mapping State Machine Diagrams to System Use Cases -- Case Study G2: Transitions -- Case Study G2: Resulting Documentation.
Step 2a ii: 3. Identify State Activities -- Case Study G3: State Activities -- Case Study G3: Resulting Diagram -- Step 2a ii: 4. Identify Composite States -- Case Study G4: Composite States -- Suggestion -- Case Study G4: Resulting Documentation -- Step 2a ii: 5. Identify Concurrent States -- Concurrent State Example -- Chapter Summary -- chapter 8 Gathering Across-the-Board Rules with Class Diagrams -- Chapter Objectives -- Step 2b: Static Analysis -- FAQs about Static Analysis -- Step 2b i: Identify Entity Classes -- FAQs about Entity Classes -- Indicating a Class in UML -- Naming Conventions -- Grouping Classes into Packages -- The Package Diagram -- Interview Questions for Finding Classes -- Challenge Questions -- Supporting Class Documentation -- Case Study H1: Entity Classes -- Your Next Step -- Suggestions -- Case Study H1: Resulting Documentation -- Notes on the Model -- Step 2b ii: Model Generalizations -- Subtyping -- Generalization -- Case Study H2: Generalizations -- Suggestions -- Case Study H2: Resulting Documentation -- Notes on the Model -- Step 2b iii: Model Transient Roles -- Example of Transient Role -- How Does a Transient Role Differ from a Specialization? -- Some Terminology -- Why Indicate Transient Roles? -- Rules about Transient Roles -- Indicating Transient roles -- Sources of Information for Finding Transient Roles -- Interview Questions for Determining Transient Roles -- What If a Group of Specialized Classes Can All Play the Same Role? -- Case Study H3: Transient Roles -- Case Study H3: Resulting Documentation -- Step 2b iv: Model Whole/Part Relationships -- The "Whole" Truth -- Examples of Whole/Part Relationships -- Why Indicate Whole/Part Relationships? -- How Far Should You Decompose a Whole into Its Parts? -- Sources of Information for Finding Aggregation and Composition.
Rules Regarding Aggregation and Composition -- Indicating Aggregation and Composition in UML -- The Composite Structure Diagram -- Interview Questions for Determining Aggregation and Composition -- Challenge Question -- Case Study H4: Whole/Part Relationships -- Case Study H4: Resulting Documentation -- Notes on the Model -- Step 2b v: Analyze Associations -- Examples of Association -- Why Indicate Association? -- Why Isn't It the Developers' Job to Find Associations? -- Discovering Associations -- Rules Regarding Associations -- The Association Must Reflect the Business Reality -- Redundant Association Rule of Thumb -- Exception to the Rule of Thumb -- Case Study H5: Associations -- Your Next Step -- Case Study H5: Resulting Documentation -- Step 2b vi: Analyze Multiplicity -- Example of Multiplicity -- Why Indicate Multiplicity? -- Indicating Multiplicity in UML -- Rules Regarding Multiplicity -- Sources of Information for Finding Multiplicity -- The Four Interview Questions for Determining Multiplicity -- Case Study H6: Multiplicity -- Your Next Step -- Case Study H6: Resulting Documentation -- Chapter Summary -- chapter 9 Optimizing Consistency and Reuse in Requirements Documentation -- Chapter Objectives -- Where Do You Go from Here? -- Does the Business Analyst Need to Put Every Attribute and Operation on the Static Model? -- Step 2b vii: Link System Use Cases to the Static Model -- Case Study I1: Link System Use Cases to the Static Model -- Suggestions -- Case Study I1: Results -- Step 2b viii: Add Attributes -- Analyzing Attributes -- Example -- Why Indicate Attributes? -- Don't Verification Rules about Attributes Belong with the System Use-Case Documentation? -- Sources of Information for Finding Attributes -- Rules for Assigning Attributes -- Derived Attributes -- Indicating Attributes in the UML -- Meta-Attributes.
Case Study I2: Add Attributes.
Local Note:
Electronic reproduction. Ann Arbor, Michigan : ProQuest Ebook Central, 2017. Available via World Wide Web. Access may be limited to ProQuest Ebook Central affiliated libraries.
Genre:
Electronic Access:
Click to View