390 likes | 585 Views
Methods for OO Development. USDP and DSDM. Outline. Characteristics of OO development USDP UML and DSDM. Focus of OO Analysis & Design. Break system down Classes & Objects Communication Class Models Structure & Behaviour Use Case driven User’s perspective. OO: Technical Advantage.
E N D
Methods for OO Development USDP and DSDM
Outline • Characteristics of OO development • USDP • UML and DSDM
Focus of OO Analysis & Design • Break system down • Classes & Objects • Communication • Class Models • Structure & Behaviour • Use Case driven • User’s perspective
OO: Technical Advantage • Components • A coherent process, using • Widely accepted concepts and terminology • Benefits • Improved software quality • Traceability • Beware exaggerated claims…
OO: Iterative & Incremental • Elaboration • Analysis, Design & Implementation • A Process of Change • Successive Iterations • Incremental releases • Development by Elaboration • Semantically rich - UML
Activity 1: Why use OO? • What are the main reasons for the shift from the structured to object-oriented development approach?
OO: Project Management • Development by Elaboration • No clear boundaries • Documentation evolves continuously • Object solutions • More complex • Managing the process • USDP to the rescue
Outline • Characteristics of OO development • USDP • Unified Software Development Process • UML and DSDM
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?
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
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.
Iterative & Incremental Delivery Macro Process Micro Process ormini-project Iteration 1 Iteration n
Iterative Development • The USDP lifecycle is cyclic: • Analyse a bit • Design that bit • Code the design • Test the code • Refine the analysis and repeat
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?
Phases Workflows group activities logically In an iteration, you walk through all workflows Inception Elaboration Construction Transition Iterations 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 Workflows Requirements Analysis Design Implementation Test
Each major workflow describes how to create and maintain a particular model This shows dependencies of the use case model. RequirementsWorkflow Design Workflow Analysis Workflow ImplementationWorkflow Test Workflow Models and Workflows Use-Case Model specified by realized by distributed by AnalysisModel DesignModel Deployment Model implemented by verified by ImplementationModel TestModel Jacobson et al. (1999)
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
USDP Phases • Inception Phase • Elaboration Phase • Construction Phase • Transition Phase
Phases Inception Elaboration Construction Transition Iterations 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 Workflows Requirements Analysis Design Implementation Test
Phases Inception Elaboration Construction Transition Iterations 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 Workflows Requirements Analysis Design Implementation Test
Phases Inception Elaboration Construction Transition Iterations 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 Workflows Requirements Analysis Design Implementation Test
Phases Inception Elaboration Construction Transition Iterations 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 Workflows Requirements Analysis Design Implementation Test
Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Configuration Mgmt Project Management Environment Iter.#m+1 Preliminary Iteration(s) Iter.#1 Iter.#2 Iter.#n Iter.#n+1 Iter.#n+2 Iter.#m RUP Approach – Best-Known USDP Variant Phases Process Workflows SupportingWorkflows Iterations
Activity 3 Inception Elaboration Construction Transition 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 Requirements Analysis Design Implementation Test
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?
Outline • Characteristics of OO development • Focus • Advantages • Management problems • USDP • Iterative approach • Workflows • Phases • UML and DSDM
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 ?
UML Products at Each DSDM Stage Feasibility Business Study Agree Schedule Implement Implementation Create Functional Prototype Identify Functional Prototype Functional Model Iteration Review Business Train Users User Approval & User Guidelines Review Prototype Identify Design Prototype Design & Build Iteration Review Design Prototype Agree Schedule Create Design Prototype
Feasibility Feasibility Stage • 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 Business Study Business Study Stage • 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 • Who? • Users • Business Analysts • Specialist Modellers • How? • Facilitated Workshops
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 • 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 Agree Plan Functional Model Iteration Create Functional Prototype Identify Functional Prototype Review Prototype • Who? • Users • Prototypers • Business Analysts • Specialist Modellers • How? • Facilitated Workshops • Regular (daily) team reviews
Design and Build Iteration Identify Design Prototype • 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 Design & Build Iteration Review Design Prototype Agree Plan Create Design Prototype • Who? • Users • Prototypers • Application Designers • Language specialists • Architecture Designers • Specialist Modellers • How? • Facilitated Workshops • Regular (daily) team reviews
Activity 4 • What do USDP and DSDM have in common?
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.
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
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
How does this help? • 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
What do USDP and DSDM have in common? • Iterative • Incremental • Prototyping • Can use UML • Testing throughout the lifecycle • Controlling risk • Definition of roles • Though USDP doesn’t have user roles