1. Mastering OOA/OOD with UML

2. Contents Introduction Requirements Overview OOAOOD

3. Introduction Software development problems Six best practices

4. Introduction Tools Rational Object-oriented Software Engineering (ROSE) Rational Object-oriented Software Engineering (ROSE)Language Don’t care Don’t care Basic Requirement Coding in one or more OO Language Coding in one or more OO Language

5. Symptoms of Software Development Problems User or business needs not met Requirements not addressed Modules not integrating Difficulties with maintenance Late discovery of flaws Poor quality of end-user experience Poor performance under load No coordinated team effort Build-and-release issues

6. Trace Symptoms to Root Causes Symptoms Needs not met Requirement churn Modules do not fit Hard to maintain Late discovery Poor quality Poor performance Colliding developers Build-and-release Root Causes Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Subjective assessment Waterfall development Uncontrolled change Insufficient automation Best Practices Develop Iteratively Manage Requirement Use Component Architectures Model Visually Continuously Verify Quality Manage Change

8. Iterative Development Benefits Resolve major risks early Resolve major risks early Enable user feedback Enable user feedback Make testing and integration continuous Make testing and integration continuous Focus on project short-term objective milestones Focus on project short-term objective milestones Make possible deployment of partial implementations Make possible deployment of partial implementations

9. Requirements Management Making sure you Solve the right problem Solve the right problem Build the right system Build the right system By taking a systematic approach to Eliciting Eliciting Organizing Organizing Documenting Documenting Managing Managing the changing requirements of a software application

10. Aspects of Requirement Management Analyze the problem Understand User Needs Define the system Manage scope Refine the system definition Manage changing requirement

11. Component-Based Architecture Resilient Meets current and future requirements Meets current and future requirements Improves extensibility Improves extensibility Enables reuse Enables reuse Encapsulates system dependencies Encapsulates system dependenciesComponent-based Reuse or customize components Reuse or customize components Select from commercially available components Select from commercially available components Evolve existing software incrementally Evolve existing software incrementally

12. Use UML Captures structure and behavior Shows how system elements fit together Keeps design and implementation consistent Hides or exposes details as appropriate Promotes unambiguous communication UML provides on language for all practitioners UML provides on language for all practitioners

13. Continuously Verify Quality Testing dimensions Usability Usability Reliability Reliability Performance Performance Supportability Supportability Functionality Functionality Test at each iteration of software development

15. Manage Change Control how and when changes are introduced into the project

16. Lifecycle Phases Inception-define system scope Elaboration-plan project, specify features and baseline architecture Construction-build the product Transition-transition the product into end- user community

19. Requirements Overview Use-Case Model

20. Purpose Establish and maintain agreement with the customers and other stakeholders on what system should do Give system developers a better understanding of the Requirement of the system define the system boundary Provide a basis for planning the technical contents of the iteration Provide a basis for estimating cost and time to develop the system Define a user interface of the system

21. Use-Case Modeling Use-Case Model define all functional requirements of a system What system does What system does How system does How system does Glossary defines common terminology Supplementary Specification defines non- functional requirements of a system

22. Use-Case Modeling Actor represents anything (users, devices, other systems) that interacts with the system Client actor Client actor Supplier actor Supplier actor Use-case is a sequence of actions a system performs that yields an observable result of value to a particular actor

23. Use-Case Specifications Name Brief description Flow of events Basic flow Basic flow Alternative flow Alternative flow Special requirements Use-Case diagram Activity diagrams

24. Supplementary Specifications FunctionalityUsabilityReliabilityPerformanceSupportability Design Constraints

25. Use-Case Classification Type A most difficult 20% of all use-case 20% of all use-case Type B 60% of all use-case 60% of all use-case Type C 20% of all use-case 20% of all use-case

26. Works in Each Iteration It#1Requirements, Use-Case model Basic flow of all use-case Basic flow of all use-case Alternative flow Alternative flow It#2—Elaboration phase OOA->OOD->Prototype->Unit testing OOA->OOD->Prototype->Unit testing Alternative flow Alternative flowIt#3 OOA->OOD->Prototype->Unit testing OOA->OOD->Prototype->Unit testing Alternative flow Alternative flow

27. Works in Each Iteration It#4—Implementation phase OOA->OOD->Prototype->Unit testing OOA->OOD->Prototype->Unit testing Imp->Integration testing (I.T.)  Alpha (Biz component) Imp->Integration testing (I.T.)  Alpha (Biz component)It#5 Imp->I.T.  Gamma (Biz component) Imp->I.T.  Gamma (Biz component)It#6 Beta (UI layout) Beta (UI layout)It#7 Version 1.00 Version 1.00

28. Analysis & Design

29. Analysis VS Design Analysis Focus on understanding the problem Focus on understanding the problem Idealized design Idealized design Behavior Behavior System structure System structure Functional requirements Functional requirementsDesign Focus on understanding the solution Operations and attributes Performance Close to real code Object lifecycles Nonfunctional requirements