1. Edit session number in Master View Agile Modeling: No, It’s Not An Oxymoron

2. © 2007 IBM Corporation AM022 Who is Terry Quatrani? tquatrani@us.ibm.com

3. © 2007 IBM Corporation AM023 The Importance of Modeling

4. © 2007 IBM Corporation AM024 What is a Model?  A model is an abstraction of a physical system  Typically, you will create different models for a physical system to visualize different points of view –Users –Developers –Graphic Artists –Database developers –Testers –Documenters –And on and on ……

5. © 2007 IBM Corporation AM025 Why do we model?  To manage complexity  To detect errors and omissions early in the lifecycle  To communicate with stakeholders  To understand requirements  To drive implementation  To understand the impact of change  To ensure that resources are deployed efficiently

6. © 2007 IBM Corporation AM026 Why do we model?  To manage complexity  To detect errors and omissions early in the lifecycle  To communicate with stakeholders  To understand requirements  To drive implementation  To understand the impact of change  To ensure that resources are deployed efficiently

7. © 2007 IBM Corporation AM027 The Unified Modeling Language  The UML is the standard language for visualizing, specifying, constructing, and documenting software and systems

8. © 2007 IBM Corporation AM028 TQ’s Golden Rule UML Is HUGE  Only use what you need

9. © 2007 IBM Corporation AM029 Scott Ambler’s Critical Concepts of Agile Modeling  Apply the right artifact(s)  Maximize stakeholder return on investment (ROI)  Active stakeholder participation  Iterate to another artifact  Model in small increments  Create several models in parallel  Collective ownership  Single source information  Prefer executable specifications

10. © 2007 IBM Corporation AM0210 What Are Agile Models?  Agile models: –Fulfill their purpose –Are understandable –Are sufficiently accurate –Are sufficiently consistent –Are sufficiently detailed –Provide positive value –Are as simple as possible  Agile models are just barely enough!

11. © 2007 IBM Corporation AM0211 Requirements – System Context  Actors are people or systems that need to communicate with the system being built  Use cases are a way to capture functional requirements of a system  In theory, you should be able to determine system context by looking at a use case diagram –Works well if there are a limited number of use cases –Does not work as well for larger systems

12. © 2007 IBM Corporation AM0212 Use Case Diagram

13. © 2007 IBM Corporation AM0213 Not Exactly UML but….

14. © 2007 IBM Corporation AM0214 Documenting Use Cases (Functional Requirements)  Use cases are shown in diagrams  Use cases are described in text Register for Courses Student But…. The UML does not specify how a use case should be described

15. © 2007 IBM Corporation AM0215 Simple Sequence Diagram is Worth Hundreds of Words

16. © 2007 IBM Corporation AM0216 Bulleted Outline is Usually Sufficient  Time ordered outline of the steps in the use case –Typically just simple sentences  Concentrate on the steps in the basic flow  List major alternate flows and exceptions  This is just a first cut at the use case flow of events  Benefits –Allow you to get a handle on the complexity of the use case (more steps typically more complexity) –Allow you to get early buy in from the customer that you are building the right system –Provide basis for prototyping

17. © 2007 IBM Corporation AM0217 Add a Course Bulleted Outline  Basic Flow –Student logs onto system –Student opts to add a course to a schedule –Student enters a course number –System verifies that student has satisfied pre-requisites for the course –System displays a list of open course offerings –Student selects an offering –Student is registered for the course  Alternate Flows –Pre-requisites not satisfied –No course offerings available

18. © 2007 IBM Corporation AM0218 User Interface Storyboard

19. © 2007 IBM Corporation AM0219 User Interface Screens

20. © 2007 IBM Corporation AM0220 User Interface Navigation Map

21. © 2007 IBM Corporation AM0221 Analysis Classes  Boundary Class –A class used to model interaction between the system's surroundings and its inner workings  Control Class –A class used to model control behavior specific to one or a few use cases  Entity Class –A class used to model information and associated behavior that must be stored

22. © 2007 IBM Corporation AM0222 Analysis Level Diagram

23. © 2007 IBM Corporation AM0223 User Interface Design Diagram

24. © 2007 IBM Corporation AM0224 Java Class Design Diagram

25. © 2007 IBM Corporation AM0225 Entity-Relationship Modeling UML Notation Crow’s Feet Notation

26. © 2007 IBM Corporation AM0226 Course Registration Physical Data Model

27. © 2007 IBM Corporation AM0227 Roster Database View

28. © 2007 IBM Corporation AM0228 Deployment Diagram

29. © 2007 IBM Corporation AM0229 Component Diagram

30. © 2007 IBM Corporation AM0230 Architecture

31. © 2007 IBM Corporation AM0231 Complex Architecture

32. © 2007 IBM Corporation AM0232 Modeling Sessions

33. © 2007 IBM Corporation AM0233 Synchronizing Models and Code Update ONLY when it hurts

34. © 2007 IBM Corporation AM0234 What About Tools?  Use the simplest tool for the job at hand –May be a whiteboard –May be flipcharts –May be a drawing tool –May be a modeling/CASE tool Tools should help you get the job done NOT Drive how you do the job

35. © 2007 IBM Corporation AM0235 Common Misconceptions About CASE Tools  Agile modelers don’t use CASE tools –Agile modelers use the simplest tool, and if the simplest tool for the job is a CASE tool, then that is what will be used  UML requires CASE tools –Not true. UML drawings are often done by hand  You start modeling with CASE tools –Typically modeling is started with a simple tool (e.g. flip charts) and then you migrate to a CASE tool if needed (e.g. to create persistent models)  The CASE tool is the master –Not true. Once code is either generated from the model or written by hand, the code is the master. One tough decision that has to be made is should the model be updated to reflect the code?

36. © 2007 IBM Corporation AM0236 Survey Says….  DDJ Modeling and Documentation survey –Currently in progress –274 respondents so far  Topics: –Top 5 modeling tools –Why people model –Primary application of tools –What documents we produce

37. © 2007 IBM Corporation AM0237 Top 5 Tools AgileTraditionalAd-Hoc Word Processors (89%) Drawing Tools (83%) Individual Whiteboards (54%) Wikis (48%) Post-It Notes (48%) Drawing Tools (89%) Word Processors (89%) Shared Whiteboards (54%) Individual Whiteboards (52%) Software-based modeling tools (37%) Post-It Notes (37%) Word Processors (83%) Drawing Tools (74%) Post-It Notes (46%) Shared Whiteboards (44%) Individual Whiteboards (43%)

38. © 2007 IBM Corporation AM0238 Primary Approach to Modeling (%)

39. © 2007 IBM Corporation AM0239 Percentage of Teams Creating Deliverable Documentation

40. © 2007 IBM Corporation AM0240 You are Engaged in Agile Modeling if…  Your customers/users are active participants  Changing requirements are welcomed and acted upon  You work on the highest priority requirements first  You take an iterative and incremental approach to modeling  Your primary focus is the development of software, not documentation or models themselves  You model as a team where everyone’s input is welcome  You actively try to keep things as simple as possible  You discard most of your models as development progresses  Customers/business owners make business decisions; developers make techical decisions  The model’s content is recognized as being significantly more important thatn the format/representation of that content  How you test what you describe with your model(s) is a critical issue continually considered as you model

41. © 2007 IBM Corporation AM0241 References and Recommended Reading  www.agilealliance.com  www.agilemodeling.com  www.agiledata.org  www.databaserefactoring.com  www.enterpriseunifiedprocess.com  Ambler, S.W. (2002). Agile Modeling: Effective Practices for XP and the UP. New York: John Wiley & Sons.  Ambler, S.W. (2003). Agile Database Techniques. New York: John Wiley & Sons.  Ambler, S.W. (2004). The Object Primer 3 rd Edition: AMDD with UML 2. New York: Cambridge University Press.  Ambler, S.W. and Sadalage, P.J. (2006). Refactoring Databases: Evolutionary Database Design. Reading, MA: Addison Wesley Longman, Inc.  Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide. Reading, MA: Addison Wesley

42. © 2007 IBM Corporation AM0242 QUESTIONS

43. © 2007 IBM Corporation AM0243 © Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, the on- demand business logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. Learn more at:  IBM Rational software IBM Rational software  IBM Rational Software Delivery Platform IBM Rational Software Delivery Platform  Process and portfolio management Process and portfolio management  Change and release management Change and release management  Quality management Quality management  Architecture management Architecture management  Rational trial downloads Rational trial downloads  Leading Innovation Web site Leading Innovation Web site  developerWorks Rational developerWorks Rational  IBM Rational TV IBM Rational TV  IBM Rational Business Partners IBM Rational Business Partners THANK YOU