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
23.
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
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
34.
35. Caveats You do not have any automatic merge between steps, you must manually difference and resolve.
MS ALM Gold Partner – one of only 5 in the USMS ALM “Inner Circle”
We will start with a quick discussion of the history of UML, agile development, and modeling tools in the Microsoft world. Then we will cover the basics of UML modeling with VS 2010, covering class, layer, dependency graph, and sequence diagrams. Finally, we will talk about establishing an agile modeling and development workflow with forward and reverse engineering using the visualization and modeling features of Feature Pack 2.
Unified ideas and symbols of “The three amigos”Defacto standard controlled by the OMG organization – a consortium of companies such as MS, HP, Sparx, etc.
A system is represented by a model, which is separate from any diagrams that describe the model, and also includes textual artifacts like use casesStructural or static diagrams (class, deployment)Behavioral or dynamic diagrams (sequence, activity)
Solution Introduction and LayeringArchitecture Explorer – drill down, filteringUML Model Explorer – Use Case Diagrams – links to work items, navigable artifactsComponent DiagramActivity DiagramSequence Diagram – reverse engineer Invoice Service GetInvoiceForDisplay, navigableClass Diagram – navigableDependency Diagram – show drill downs and how context-appropriate dependencies are shownLayer Diagram – drag and drop, generate dependencies, demonstrate build validation, show color-coded final
I’m not going to try to cover all of what “agile” might mean.Not only acknowledgingthat change happens, but embracing changeEncourages communication in a tight feedback loop with the business – fail early, build trust, establish a common language- Build what is important for right now, in short iterations, and respond to changes in the business and market at the end of every iterationXP, Scrum, Lean ManufacturingContinuous Integration, TDD, YAGNI, DDD
Very aware of what the real value of documentation is, and what we are trying to achieve with documentation – the ability to understand how we will build a system, and the ability to understand the system after entering the maintenance phase
How can agile methodologies help us out here?
OK, before we even got to the point where we realized there were problems with the cycle, why did we even start modeling in the first place???How about “a picture is worth a thousand words.”
How is this like software development?There was a design, a modelThe vision was NOT shared between Nigel and the developer“I only did what you told me to do”Let’s minimize the problem with a workaround – “keep the dwarf clear from the monument so he doesn’t trod upon it”What went wrong from an agile perspective?No communication, feedback, or iterating with the product owners or stakeholders during development – “dropped a bomb” on the band on opening nightWhat can we learn from this?Modeling and diagrams are important, and can be interpreted literally – they are valuable and carry risk – inches vs. feetKeep communication open, iterate, be transparent
The Visualization and Modeling Feature Pack is now part of VS 2010 Feature Pack 2.
How can agile methodologies help us out here?
Two-way movement between code and diagrams != round-tripping