Notes

Outline

eXtreme Programming meets UML

The presenter Alan Cameron Wills joint developer of Catalysis design method for CBD, EAI, OOD technical director of TriReme International Ltd Mentoring in software architecture and process Clients in diverse application areas in UK, Europe, USA Software architecture and process http://www.trireme.com

The topic Agile Methods – XP etc – increasingly popular & successful Rigorous testing, frequent refactoring and elaboration Minimal documentation Close links between customer and developers Analysis, architecture, and design used to seem quite useful – UML, use-cases, CRC, patterns, and all that Clarification of goals before rushing into code Definition of interfaces, conventions and standards High-level descriptions of code Can they be used together? Can both sets of benefits be got?

Agenda Incremental Software Development Requirements process must clean up the requirements Requirements models encode vocabulary and business rules Raising issues with consistency checks: Catalytic Modeling Models Generate Tests

Traditional software development

Iterative software development

Feature-driven delivery

Testing ensures stability Add tests monotonically

Incremental development Close coupling between customer and developer Converges on real needs of customer != needs as originally understood by either party

Agenda Incremental Software Development Requirements process must clean up the requirements Requirements models encode vocabulary and business rules Raising issues with consistency checks: Catalytic Modeling Models Generate Tests

Key features and benefits of XP Customer works with developer and tries out software => Design converges on customer’s real needs not the same as initially perceived needs Developers work in (varying) pairs => tends to spread common understanding of aims and architecture Little documentation except Stories, Tests, and Code => little or nothing to get out of step with code Rigorous regression testing => bugs only rarely introduced while refactoring and elaborating code Any changes to the method should not lose these benefits

Difficulties found with pure XP Common understanding of needs is difficult in a big team Tests not easy to read Stories ambiguous Big picture gets lost among details Common understanding of architecture is difficult in big team Big picture difficult to see in the code, without high-level explanation Many developers insufficiently experienced to hold design in the head Customers not always unitary and coherent Can spend much time arguing among themselves Close coupling feeds a lot of noise to the developers Customers focus on superficial features until too late Looking at a working prototype not always best way to see deep issues

Method depends on scale

Clarifying requirements with a model

Tests are an executable specification

Iterative Development Development stages have to be done for each iteration

Rational Unified Process

Pure XP vs Requirements analysis …

… Pure XP vs Requirements analysis

Pure XP vs Requirements Analysis

Agenda Incremental Software Development Requirements process must clean up the requirements Requirements models encode vocabulary and business rules Raising issues with consistency checks: Catalytic Modeling Models Generate Tests

Benefits of requirements model

Specifications don’t model implementation Analysts write Requirements Models don’t assign operations to classes inside the system don’t define collaborations inside the system do define collaborations external to the system do define operations or transactions visible at system interface just define what they achieve, not how they work

Requirements Models vs Implementation Models Designers determine internal structure & collaborations

Requirements Models vs Implementation Models Requirements determine tests

What’s in a Requirements Model? Repository of principal things we know about requirements: Stories Business concept model Use cases Business rules and constraints Website navigation maps GUI style guide External interface definitions (to other systems) Quality requirements Usability, robustness, reliability, latency, capacity, security, … Doesn’t include: Fine detail Internal structure of system

Roles of UML UML for requirements specification UML for design Can almost write code in UML – e.g. Together UML has different interpretations depending on usage

Coding in UML? Some tools maintain a direct correspondence between UML and program code eg. Together/J effectively programming in a UML/Java mix But UML is also useful for: Abstract models that don’t contain all the detail very useful for high-level ‘domain’ or ‘essential’ models, which define business vocabulary and rules clear high-level overview of requirements or design, uncluttered by the fine detail of the code Defining interfaces in frameworks and between components These models are about what the components talk to each other about – not about their internal structure UML programming tools are not so useful for these purposes

UML for abstraction The high level view helps think clearly about designs

Agenda Incremental Software Development Requirements process must clean up the requirements Requirements models encode vocabulary and business rules Raising issues with consistency checks: Catalytic Modeling Models Generate Tests

Catalytic Modeling In requirements analysis, we: Encode the requirements in a model incorporating use-cases class diagrams business rules non-functional requirements We use a battery of techniques and patterns designed to raise issues with the requirements Small selection of Catalytic Modeling techniques follows Techniques drawn from work on ‘Catalysis’ [DeSouza & Wills 1998]

Requirements Model: use-cases

Snapshots illustrate postconditions

Class diagrams provide use-case vocabulary

CRUD: Objects ® use-cases Inspect class diagrams; ask: what changes this association or attribute? what creates/deletes this object or association?

Slide 36

Use-cases and objects – consistency

Static business rules Static rules (“invariants”): statements always true about associations and attributes Look for loops in class diagrams Look for instance diagrams that would conform to class diagram but be wrong within the business Use the vocabulary of the class diagram to express the rules

Static business rules Look for instance diagrams that conform to class diagram but would be wrong in the domain

Loops => invariants Any loops in the type diagram suggest an invariant might be appropriate – raise questions to the customer

Loops => invariants Any loops in the type diagram suggest an invariant might be appropriate

Agenda Incremental Software Development Requirements process must clean up the requirements Requirements models encode vocabulary and business rules Raising issues with consistency checks: Catalytic Modeling Models Generate Tests

Rigorous Testing Incremental development relies on rigorous testing

Interpreting the attributes The model is not necessarily a picture of the internal structure Component is a black box: We don’t know anything about how Flight, captain and copilot are implemented inside the component The model says what questions the component can answer: AirCrewName getCaptain (FlightId fid); AirCrewName getCopilot (FlightId fid);

Translating model to tests So this rule in the model: Flight :: captain != copilot means that for any Flight ID fid, in any scheduler component, at any time: schedulerSystem.getCaptain(fid) !=  schedulerSystem.getCopilot(fid) The requirements model: tells the test team what to test; tells the design team what requirements to meet; doesn’t necessarily tell them how to design it; doesn’t tell them how to test it (harness/monitor/…)

Testing Postconditions Postconditions compare before- and after-states Save before-state

Retrievals: applying abstract postconditions Program code may be much more complex than the abstract model But the associations and attributes of the model can be abstracted from the code by read-only functions all the information in the abstract model is there in the code Postconditions expressed in terms of the abstract model can be tested by applying the abstraction functions

Test case generation White box testing checks each path through code no good if you can’t see the code (as in CBD) Black box testing partition state space into zones, check representative points

Partitioning the state space Theory: For each use-case / operation: Consider space of all parameters and state variables Delineate boundaries where changes in behavior arise Look at preconditions, postconditions and invariants Choose points on the boundaries; and in the intervening zones Set up tests that exercise the operation at each point Boundary points @ one room available; and @ all rooms available Zone @ some rooms available

Summary Separate requirements analysis necessary in big projects Requirements analysis obstructs incremental development unless it gets quickly to a broad view of the big issues, faster than programming raises questions about those issues, to improve consistency and completeness Catalytic Modeling techniques provide ways to raise issues and check consistency Requirements should be ‘black box’, so that pluggable and bought-in components can be used Requirements model should generate tests (not code)

More information Incremental Development eXtreme Programming: http://www.c2.com; books by K Beck et al RUP/ USDP: http://www.rational.com; book by P Kruchten DSDM: http://www.dsdm.org; book by J Stapleton Crystal: books by A Cockburn UML UML standard: http://www.omg.org; book by M Fowler OCL: book by J Warmer & A Kleppe Product Line Architecture Book by Linda Northrop Catalytic Modeling Techniques http://www.trireme.com/xp-uml