As presented at the Chicago VS ALM User Group, February 9th, 2011.

1. Agile Modeling with Visual Studio 2010 Ultimate (and Feature Pack 2) Gary Pedretti – Gary.Pedretti@Centare.com Logo, Design, and Company Information:© 2011 Centare Group, Ltd. Slide Show and Notes Content: Creative Commons License, Gary Pedretti Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. 2/11/2011 1

2. Centare Group, Ltd. 12th Year Local, Focused, Software Consulting Firm ALM (MS Inner Circle Partner), Mobile and Cloud Solutions Apple (iOS), Microsoft and Open Source

3. Today’s Presentation UML and UML Modeling with VS 2010 Ultimate Agile Development and Agile Modeling An Agile Development Workflowusing the visualization and modeling features of Feature Pack 2

4. Today’s Presentation UML and UML Modeling with VS 2010 Ultimate Agile Development and Agile Modeling An Agile Development Workflow using the visualization and modeling features of Feature Pack 2

5. Unified Modeling Language - UML UML unifiedthe notations of: The Booch Method The Object-Modeling Technique (OMT) Object-Oriented Software Engineering (OOSE) De facto industry standard, controlled by the Object Management Group (OMG)

6. UML Basics A system is represented by a model, which is separate from any diagrams that describe the model, and also includes textual artifacts like use cases Structural or static diagrams (class, deployment) Behavioral or dynamic diagrams (sequence, activity)

7. About the VS 2010 Diagrams The UML diagrams are UML 2.0 compliant Most are navigable – double-click on members to jump to code There is tight integration with TFS – associate use cases with Work Items, etc. There are facilities for reverse engineering and forward engineering – some built in, others via feature packs

8. VS 2010 UML Diagram Types Class – Shows classes and their relationships such as inheritance, aggregation, cardinality, etc.

9. VS 2010 UML Diagram Types Sequence – Shows the interaction of components, actors, systems, etc. over a period of time

10. VS 2010 UML Diagram Types Use Case – High level view of the interaction between use cases and various actors

11. VS 2010 UML Diagram Types Activity – The “flowchart” we know and love

12. VS 2010 UML Diagram Types Component – Shows classes, functionality, etc. broken down into units of deployment

13. Other VS 2010 Diagram Types Layer Diagram - includes validation, forcing developers to maintain only the dependencies the designer/architect desires

14. Other VS 2010 Diagram Types Directed Graph Document – Dependency Graphs in a very dynamic format

15. Caveats Create in VS 2010 Ultimate Edition only, but are also available as read-only in Premium Edition For C and C++ code: Only the Dependency Graphs and Architecture Explorer are supported “Architecture tools” is somewhat of a misnomer for the VS 2010 features (shortcomings of UML…) MS modeling story is still very fragmented Visio 2010 with VS 2010 has re-added reverse-engineering of code to UML diagrams Class Diagrams within a .NET project remain Oslo???

16. Demo – Visual Studio 2010 Architecture and UML Diagrams

17. Today’s Presentation UML and UML Modeling with VS 2010 Ultimate Agile Development and Agile Modeling An Agile Development Workflow using the visualization and modeling features of Feature Pack 2

18. Agile Development What do you think it means? What are some of the methodologies? What are some practices that often go hand-in-hand with agile methodologies?

19. Agile Modeling – What do I mean? Modeling that supports vertical slice, iterative, adaptive development Architecture and design that is just-in-time, right-sized, and allows for deferring the larger architectural decisions to the last responsible moment

20. Agile Manifesto vs. BDUF We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items onthe right, we value the items on the left more.

21. Modeling Problems - A Typical Chain of Events Some up-front design of the system Development begins Design or implementation of the design changes Architecture problems discovered and solved during development Changing requirements Original design documentation is not kept up-to-date Perceived value of design documentation – and eventually design, architecture, and architects themselves – erodes

22. Why Model at All? Improved productivity Reduced technical risk Reduced development time Improved communication Scaling agile software development (provides the technical direction required by sub-teams to define and guide their efforts within the overall project) Improved team organization (Ambler http://www.agilemodeling.com/essays/initialArchitectureModeling.htm ) Reverse Engineering of Existing Systems – to help people wrap their heads around an undocumented, existing system Forward Engineering for New Systems – for communication of architecture and design Software is difficult to explain and detail to both developers and the uninitiated

24. Agile Modeling – AMDD – Scott Ambler Document Late. Write documentation as late as possible, avoiding speculative ideas that are likely to change in favor of stable information Executable Specifications. Specify requirements in the form of executable "customer tests", and your design as executable developer tests, instead of non-executable "static" documentation Iteration Modeling. At the beginning of each iteration you will do a bit of modeling as part of your iteration planning activities

25. Agile Modeling – Part 2 Just Barely Good Enough (JBGE) artifacts. A model or document needs to be sufficient for the situation at hand and no more Model a bit Ahead. Sometimes requirements that are nearing the top of your priority stack are fairly complex, motivating you to invest some effort to explore them Model Storming. Throughout an iteration you will model storm on a just-in-time (JIT) basis for a few minutes to explore the details behind a requirement or to think through a design issue Discard Temporary Models Update Only When It Hurts

26. Emergent Architecture – Scrum.org Architecture is a development task “Architects” are Scrum team members – “architects” Architecture emerges as real deliverables are created It is not valid until it is vetted out in a real system – this has always been true Build at least one piece of business functionality every sprint

27. Emergent Architecture – Part 2 “Just enough” documentation Architecture exists to serve the team, not the other way around

28. Emergent Architecture – Part 3 Build in flexibility to adapt to reasonable changes without building a “meta-product” DRY YAGNI TDD SoC IoC and DI SRP DDD

29. Modeling Problems – Video…

30. Today’s Presentation UML and UML Modeling with VS 2010 Ultimate Agile Development and Agile Modeling An Agile Development Workflow using the visualization and modeling features of Feature Pack 2

31. Modeling Problems - A Typical Chain of Events Some up-front design of the system Development begins Design or implementation of the design changes Architecture problems discovered and solved during development Changing requirements Original design documentation is not kept up-to-date Perceived value of design documentation – and eventually design, architecture, and architects themselves – erodes

32. The Holy Grail vs. Reality The Holy Grail in this situation is probably a full round-tripping system diagram to code code to diagram with differencing and merge resolution in between allowing for solutions to emerge from either side, and to always be kept in sync

33. The Holy Grail vs. Reality A reasonable reality, in the meantime, for forward engineering: Some design upfront – “Planned” diagrams Generate skeleton code from this design Development - actuals can be verified against the original design document, and changes in design or implementation should be justified by the developer Generate diagrams at the end of the cycle – “Actually Implemented” diagrams Actual vs. Planned diagrams can be excellent learning tools and/or post-mortem artifacts

35. Caveats You do not have any automatic merge between steps, you must manually difference and resolve.

36. “Pass the Baton” – A Live Example

38. Resources Agile, Agile Architecture, Agile Modeling www.Scrum.org www.AgileModeling.com VS 2010 Architecture Tools MSDN Library “Modeling the Application” http://msdn.microsoft.com/en-us/library/57b85fsc.aspx Cameron Skinner’s Bloghttp://blogs.msdn.com/b/camerons/ Other www.Centare.com www.GaryPedretti.com – my blog

39. Thank You!! Centare Group, Ltd. Gary.Pedretti@Centare.com