Presentation is loading. Please wait.

Presentation is loading. Please wait.

Object-Oriented Analysis and Design Using the UML Module 1: Best Practices of Software Engineering.

Similar presentations


Presentation on theme: "Object-Oriented Analysis and Design Using the UML Module 1: Best Practices of Software Engineering."— Presentation transcript:

1 Object-Oriented Analysis and Design Using the UML Module 1: Best Practices of Software Engineering

2 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 2 Objectives  Identify Steps for Understanding and Solving Software Engineering Problems  Explain the Six Best Practices  Present the Rational Unified Process within the context of the Six Best Practices

3 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 3 Symptoms of Software Development Problems User or business needs not met Requirements churn Modules don’t integrate Hard to maintain Late discovery of flaws Poor quality or end-user experience Poor performance under load No coordinated team effort Build-and-release issues

4 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 4 Trace Symptoms to Root Causes Needs not met Requirements churn Modules don’t fit Hard to maintain Late discovery Poor quality Poor performance Colliding developers Build-and-release Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Subjective assessment Waterfall development Uncontrolled change Insufficient automation SymptomsRoot CausesBest Practices Ambiguous communications Undetected inconsistencies Ambiguous communications Undetected inconsistencies Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Model Visually (UML) Continuously Verify Quality Model Visually (UML) Continuously Verify Quality Modules don’t fit Modules don’t fit

5 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 5 Best Practices Process Made Practical Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Practice 1: Develop Iteratively

6 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 6 Waterfall Development Characteristics  Delays confirmation of critical risk resolution  Measures progress by assessing work- products that are poor predictors of time-to- completion  Delays and aggregates integration and testing  Precludes early deployment  Frequently results in major unplanned iterations Code and unit test Design Subsystem integration System test Waterfall Process Requirements analysis

7 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 7 Iterative Development Produces an Executable Initial Planning Requirements Analysis & Design Implementation Deployment Test Evaluation Management Environment Each iteration results in an executable release

8 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 8 Risk Profiles Risk Reduction Time Iterative Risk Waterfall Risk Risk

9 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 9 Practice 2: Manage Requirements Best Practices Process Made Practical Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

10 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 10 Requirements Management Making sure you  Solve the right problem  Build the right system By taking a systematic approach to  eliciting  organizing  documenting  and managing the changing requirements of a software application.

11 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 11 Aspects of Requirements Management  Analyze the Problem  Understand User Needs  Define the System  Manage Scope  Refine the System Definition  Build the Right System

12 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 12 Problem Solution Space Problem Space Needs Features Use Cases and Software Requirements Test Procedures DesignUser Docs The Product To Be Built Traceability Map of the Territory

13 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 13 Practice 3: Use Component Architectures Best Practices Process Made Practical Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

14 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 14 Resilient, Component-Based Architectures  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

15 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 15 Purpose of a Component-Based Architecture  Basis for reuse  Component reuse  Architecture reuse  Basis for project management  Planning  Staffing  Delivery  Intellectual control  Manage complexity  Maintain integrity System-software Middleware Business-specific Application-specific Component-based Architecture with layers

16 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 16 Practice 4: Model Visually (UML) Best Practices Process Made Practical Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

17 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 17 Why Model Visually?  Capture structure and behavior  Show how system elements fit together  Keep design and implementation consistent  Hide or expose details as appropriate  Promote unambiguous communication  UML: one language for all practitioners

18 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 18 Visual Modeling with Unified Modeling Language Activity Diagrams Models Dynamic Diagrams Static Diagrams  Multiple views  Precise syntax and semantics Sequence Diagrams Collaboration Diagrams Statechart Diagrams Deployment Diagrams Component Diagrams Object Diagrams Class Diagrams Use-Case Diagrams

19 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 19 Visual Modeling Using UML Diagrams Actor A Use Case 1 Use Case 2 Actor B user : Clerk mainWnd : MainWnd fileMgr : FileMgr repository : Repository document : Document gFile : GrpFile 9: sortByName ( ) L 1: Doc view request ( ) 2: fetchDoc( ) 5: readDoc ( ) 7: readFile ( ) 3: create ( ) 6: fillDocument ( ) 4: create ( ) 8: fillFile ( ) Window95 ¹®¼­°ü¸® Ŭ¶óÀ̾ðÆ®.EXE Windows NT ¹®¼­°ü¸® ¿£Áø.EXE Windows NT Windows95 Solaris ÀÀ¿ë¼­¹ö.EXE Alpha UNIX IBM Mainframe µ¥ÀÌŸº£À̽º¼­¹ö Windows95 ¹®¼­°ü¸® ¾ÖÇø´ Document FileManager GraphicFile File Repository DocumentList FileList user mainWndfileMgr : FileMgr repositorydocument : Document gFile 1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) 6: fillDocument ( ) 7: readFile ( ) 8: fillFile ( ) 9: sortByName ( ) ƯÁ¤¹®¼­¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù. È­ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼­ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼­ °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù. È­¸é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡ º¸¿©ÁØ´Ù. Forward and Reverse Engineering Target System Use Case 3 Use-case diagram Class diagram Collaboration diagram Sequence diagram Component diagram Statechart diagram Deployment diagram

20 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 20 Practice 5: Continuously Verify Quality Best Practices Process Made Practical Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

21 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 21 Continuously Verify Your Software’s Quality Cost TransitionConstructionElaborationInception Software problems are 100 to 1000 times more costly to find and repair after deployment  Cost to Repair Software  Cost of Lost Opportunities  Cost of Lost Customers  Cost to Repair Software  Cost of Lost Opportunities  Cost of Lost Customers

22 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 22 Test All Dimensions of Software Quality Functionality Reliability Performance Does my application do what’s required? Does the system perform under production load?  Verification of each usage scenario  Verification of sustained application operation  Test performance under expected and worst- case load Does my application respond acceptably?

23 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 23 UML Model and Implementation Tests Iteration 1 Test Suite 1 Iteration 2 Test Suite 2 Iteration 4 Test Suite 4 Iteration 3 Test Suite 3 Test Each Iteration

24 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 24 Practice 6: Manage Change Best Practices Process Made Practical Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

25 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 25 ALERT REPORT Workspace Management Process Integration Parallel Development Build Management CM is more than just check-in and check-out What Do You Want to Control?  Changes to enable iterative development  Secure workspaces for each developer  Automated integration/build management  Parallel development

26 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 26 Aspects of a CM System  Change Request Management  Configuration Status Reporting  Configuration Management (CM)  Change Tracking  Version Selection  Software Manufacture

27 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 27 Unified Change Management  Management across the lifecycle  System  Project Management  Activity-Based Management  Tasks  Defects  Enhancements  Progress Tracking  Charts  Reports

28 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 28 Best Practices Reinforce Each Other Validates architectural decisions early on Addresses complexity of design/implementation incrementally Measures quality early and often Evolves baselines incrementally Ensures users involved as requirements evolve Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

29 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 29 Rational Unified Process Implements Best Practices Best Practices Process Made Practical Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

30 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 30 Achieving Best Practices  Iterative Approach  Guidance for activities and work products (artifacts)  Process focus on architecture  Use cases which drive design and implementation  Models which abstract the system Implementation Test Analysis & Design Requirements Configuration & Change Management

31 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 31 A Team-Based Definition of Process A process defines Who is doing What, When and How to reach a certain goal. New or changed requirements New or changed system Software Engineering Process

32 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 32 InceptionElaborationConstructionTransition Process Structure - Lifecycle Phases The Rational Unified Process has four phases:  Inception - Define the scope of project  Elaboration - Plan project, specify features, baseline architecture  Construction - Build the product  Transition - Transition the product into end user community time

33 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 33 InceptionElaborationConstructionTransition Phase Boundaries Mark Major Milestones Lifecycle Objective Milestone Lifecycle Architecture Milestone Initial Operational Capability Milestone Product Release time

34 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 34 Iterations and Phases An iteration is a distinct sequence of activities based on an established plan and evaluation criteria, resulting in an executable release (internal or external). PreliminaryIterationArchitect.IterationArchitect.IterationDevel.IterationDevel.IterationDevel.IterationTransitionIterationTransitionIteration InceptionElaborationConstructionTransition Minor Milestones: Releases

35 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 35 Workflows Produce Models

36 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 36 Bringing It All Together: The Iterative Approach Workflows group activities logically In an iteration, you walk through all workflows

37 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 37 Workflows Guide Iterative Development Business Modeling: Workflow Details Requirements: Workflow Details

38 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 38 Notation Role Activity Artifact Detail a Use Case Use-Case Package Use Case responsible for Requirements Specifier A unit of work a role may be asked to perform A piece of information that is produced, modified, or used by a process A role that may be played by an individual or a team in the development organization

39 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 39 Resource Paul Mary Joe Sylvia Stefan Roles Are Used for Resource Planning Each individual in the project is assigned to one or several roles Role Designer Requirements Specifier System Analyst Implementer Architect Activities Define Operations Detail a Use Case Find Actors and Use Cases Perform Unit Tests Identify Design Mechanisms

40 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 40 Roles Perform Activities and Produce Artifacts Example- Requirements: Workflow Detail: Define the System

41 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 41 Overview of Rational Unified Process Concepts

42 Unified Software Practices v2001.03.00 Copyright © 2000 Rational Software, all rights reserved 42 Summary: Best Practices of Software Engineering  Best Practices guide software engineering by addressing root causes  Best Practices reinforce each other  Process guides a team on what to do, how to do it, and when to do it  The Rational Unified Process is a means of achieving Best Practices


Download ppt "Object-Oriented Analysis and Design Using the UML Module 1: Best Practices of Software Engineering."

Similar presentations


Ads by Google