Agile Modeling with Visual Studio 2010 Ultimate (and Feature Pack 2)

Gary Pedretti – Gary.Pedretti@Centare.com

2/11/2011

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.1

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

• 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

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

Today’s Presentation

Unified Modeling Language - UML

• UML unified the 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)

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)

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

VS 2010 UML Diagram Types

• Class – Shows classes and their relationships such as inheritance, aggregation, cardinality, etc.

VS 2010 UML Diagram Types• Sequence – Shows the interaction of components,

actors, systems, etc. over a period of time

VS 2010 UML Diagram Types

• Use Case – High level view of the interaction between use cases and various actors

VS 2010 UML Diagram Types

• Activity – The “flowchart” we know and love

VS 2010 UML Diagram Types

• Component – Shows classes, functionality, etc. broken down into units of deployment

Other VS 2010 Diagram Types• Layer Diagram - includes validation, forcing

developers to maintain only the dependencies the designer/architect desires

Other VS 2010 Diagram Types• Directed Graph Document – Dependency

Graphs in a very dynamic format

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???

Demo – Visual Studio 2010 Architecture and UML Diagrams

• 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

Today’s Presentation

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?

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

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 planThat is, while there is value in the items on

the right, we value the items on the left more.

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

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

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

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

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

Emergent Architecture – Part 2

• “Just enough” documentation• Architecture exists to serve the team, not the

other way around

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

Modeling Problems – Video…

• 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

Today’s Presentation

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

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

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

Caveats

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

“Pass the Baton” – A Live Example

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 Blog http://blogs.msdn.com/b/camerons/

• Other– www.Centare.com– www.GaryPedretti.com – my blog

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