Presentation is loading. Please wait.

Presentation is loading. Please wait.

Methods for OO Development USDP and DSDM. 2 Outline Characteristics of OO development USDP UML and DSDM.

Similar presentations


Presentation on theme: "Methods for OO Development USDP and DSDM. 2 Outline Characteristics of OO development USDP UML and DSDM."— Presentation transcript:

1 Methods for OO Development USDP and DSDM

2 2 Outline Characteristics of OO development USDP UML and DSDM

3 3 Focus of OO Analysis & Design Break system down –Classes & Objects –Communication Class Models –Structure & Behaviour Use Case driven –User’s perspective

4 4 OO: Technical Advantage Components –A coherent process, using –Widely accepted concepts and terminology Benefits –Improved software quality –Traceability Beware exaggerated claims…

5 5 OO: Iterative & Incremental Elaboration –Analysis, Design & Implementation A Process of Change –Successive Iterations –Incremental releases Development by Elaboration –Semantically rich - UML

6 6 Activity 1: Why use OO? What are the main reasons for the shift from the structured to object-oriented development approach?

7 7 OO: Project Management Development by Elaboration –No clear boundaries –Documentation evolves continuously Object solutions –More complex Managing the process –USDP to the rescue

8 8 Outline Characteristics of OO development USDP –Unified Software Development Process UML and DSDM

9 9 USDP to the rescue… USDP – a generic process –Tailored to produce specific methods –E.g. RUP – IBM Rational Unified Process The USDP is: –Use Case Driven –Architecture Centric –Iterative and Incremental –Component-Based (a later lecture!) What does this all mean?

10 10 Use-Case Driven In USDP the basic element is a single interaction between user and system Use cases are the start of modelling Unit from which later models are derived Each use case is a thread that links requirements to implementation Has practical significance for users Constant reminder to systems developers that only users’ requirements really matter

11 11 Architecture-Centric In USDP, software architecture is a theme from the earliest stages of a project Reflected most obviously in: –Stereotyping of boundary, control and entity classes –Use of packages to organize both models and development activity –Development of ‘architectural’ models – the outlines of each USDP model – as a basis for development.

12 12 Iterative & Incremental Delivery Iteration1 n Micro Process or mini-project Macro Process

13 13 Iterative Development The USDP lifecycle is cyclic: –Analyse a bit –Design that bit –Code the design –Test the code –Refine the analysis and repeat

14 14 Activity 2: How does this help? “plan a little, design a little, and code a little” –What are the benefits of this approach? –What does it allow managers to do? –How does this approach help in the management of risk? –What about implementation?

15 15 12345678 InceptionElaborationConstructionTransition 12345678 Requirements Analysis Design Implementation Test Phases Workflows Iterations 12345678 Workflows group activities logically In an iteration, you walk through all workflows

16 16 Each major workflow describes how to create and maintain a particular model Models and Workflows Design Model Implementation Model Test Model Requirements Workflow Analysis Workflow Implementation Workflow Test Workflow Use-Case Model Design Workflow Analysis Model Deployment Model verified by implemented by distributed byrealized by specified by Jacobson et al. (1999) This shows dependencies of the use case model.

17 17 Risk Management Identification of the risks Iterative/Incremental Development The prototype or pilot project Early testing and deployment as opposed to late testing in traditional methods

18 18 USDP Phases Inception Phase Elaboration Phase Construction Phase Transition Phase

19 19 12345678 InceptionElaborationConstructionTransition 12345678 Requirements Analysis Design Implementation Test Phases Workflows Iterations 12345678

20 20 InceptionElaborationConstructionTransition Requirements Analysis Design Implementation Test Phases Workflows Iterations 123456781234567812345678

21 21 InceptionElaborationConstructionTransition Requirements Analysis Design Implementation Test Phases Workflows Iterations 123456781234567812345678

22 22 InceptionElaborationConstructionTransition Requirements Analysis Design Implementation Test Phases Workflows Iterations 123456781234567812345678

23 23 RUP Approach – Best-Known USDP Variant Phases Process Workflows Iterations Supporting Workflows Project Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements ElaborationTransitionInceptionConstruction

24 24 12345678 InceptionElaborationConstructionTransition 12345678 Requirements Analysis Design Implementation Test 12345678 Activity 3

25 25 Activity 3: A Typical Development? What is the state of the project? Are there any possible problem areas? How they might have come about? What actions you would take to better manage this project?

26 26 Outline Characteristics of OO development –Focus –Advantages –Management problems USDP –Iterative approach –Workflows –Phases UML and DSDM

27 27 Linking DSDM to other methods Why look at DSDM in isolation ? Why not take the “best” bits of DSDM and combine with other methods ? –We’ve already seen how it combines with XP Why not use the robustness of more formal methods to strengthen DSDM ? Why should organisation be constrained by one method ?

28 28 Design & Build Iteration Agree Schedule Create Design Prototype Identify Design Prototype Review Design Prototype Implementation Implement Review Business Train Users User Approval & User Guidelines Review Prototype Functional Model Iteration Agree Schedule Create Functional Prototype Identify Functional Prototype Feasibility Business Study UML Products at Each DSDM Stage

29 29 Feasibility Output  Initial, High level Use Case Diagrams  Actors (user roles)  Use Case names; no description  Activity Diagrams  Classes What Is A Use Case? A business process Series of transactions between user (Actor) and system Where Do Use Cases Come From? BPM Facilitated Workshops Who Produces the model? Users Business Analysts Specialist Modellers Feasibility Stage

30 30  Output  Use Case Descriptions  Sequence/Collaboration Diagrams For Each Use Case  Ignore Interface; find Business Objects  More Use Cases; Primary/Secondary  Business Static Structure Diagram  Initial Inheritance/Aggregation/Composition/Association  MoSCoW list of Use Cases for increments (PRL)  Initial Package/Component/Deployment Diagrams for System Architecture Definition Feasibility Business Study  Who?  Users  Business Analysts  Specialist Modellers  How?  Facilitated Workshops Business Study Stage

31 31 Functional Model Iteration Output More detail on: –Selected Use Case Sequence/Collaboration Diagrams Business Exceptions/Alternate Courses –Class Diagram for Classes used by selected Use Cases Operations from Sequence/Collaboration Diagrams Operations from Sequence/Collaboration Diagrams Attributes from required domain data Attributes from required domain data Initial Statechart Diagrams for “dynamic” objects –Business rules for objects which must behave differently to messages at different times during the process  Who?  Users  Prototypers  Business Analysts  Specialist Modellers  How?  Facilitated Workshops  Regular (daily) team reviews Review Prototype Functional Model Iteration Agree Plan Create Functional Prototype Identify Functional Prototype

32 32 Design and Build Iteration Output –Reusable classes/components added to model Previous projects/iterations –Language specifics added to all diagrams –Application Control objects added to Sequence/Collaboration Diagrams –Architecture Diagrams Package, Component, Implementation Package, Component, Implementation  Who?  Users  Prototypers  Application Designers  Language specialists  Architecture Designers  Specialist Modellers  How?  Facilitated Workshops  Regular (daily) team reviews Design & Build Iteration Agree Plan Create Design Prototype Identify Design Prototype Review Design Prototype

33 33 Activity 4 What do USDP and DSDM have in common?

34 34 An Excellent Reference Jacobson, I., Booch, G. & and Rumbaugh, J. (1999), The Unified Software Development Process, Addison-Wesley. ISBN – 0-201-57169-2 The authority on USDP.

35 35 Suggested Reading Bennett, McRobb & Farmer (2005), Object-Oriented Systems Analysis and Design using UML, McGraw- Hill, ch.21. DSDM Consortium (2003), “DSDM and UML”, version 2, DSDM Consortium. Best Practices for Software Development Teams, Rational Unified Process, A Rational Software Corporation White Paper http://www- 128.ibm.com/developerworks/rational/library/253.html

36 36 SOLUTIONS

37 37 Why use OO? Advances in hardware and software –which have enabled the widespread application of object solutions –GUIs demand event-driven programming which is best served by object technology –Popularity of OO languages, e.g. Java Essential for large systems that are difficult to maintain and even more difficult to re-engineer into modern solutions. –Object Wrapping Desire for reuse and a component-based approach

38 38 How does this help? Mini-Projects Mini-Projects –Promotes early risk mitigation Plan, design & code a little –Encourages participation –Allowing for correction sooner –Allows software to evolve –Exposes problems earlier Management of Risk

39 39 What do USDP and DSDM have in common? IterativeIncrementalPrototyping Can use UML Testing throughout the lifecycle Controlling risk Definition of roles –Though USDP doesn’t have user roles


Download ppt "Methods for OO Development USDP and DSDM. 2 Outline Characteristics of OO development USDP UML and DSDM."

Similar presentations


Ads by Google