Mastering OOA/OOD with UML

1. Mastering OOA/OOD with UML

2. Contents • Introduction • Requirements Overview • OOA • OOD

3. Introduction Software development problems Six best practices

4. Introduction • Tools • Rational Object-oriented Software Engineering (ROSE) • Language • Don’t care • Basic Requirement • 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. 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 Trace Symptoms to Root Causes Best Practices Develop Iteratively Manage Requirement Use Component Architectures Model Visually Continuously Verify Quality Manage Change

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

9. Requirements Management Making sure you • Solve the right problem • Build the right system By taking a systematic approach to • Eliciting • Organizing • Documenting • 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 • Improves extensibility • Enables reuse • Encapsulates system dependencies • Component-based • Reuse or customize components • Select from commercially available components • 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

13. Continuously Verify Quality • Testing dimensions • Usability • Reliability • Performance • Supportability • 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 • 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 • 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 • Alternative flow • Special requirements • Use-Case diagram • Activity diagrams

24. Supplementary Specifications • Functionality • Usability • Reliability • Performance • Supportability • Design Constraints

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

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

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

28. Analysis & Design

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