Session #5: Architecture Without Big Design Up Front

1,107 views
975 views

Published on

Session #5: Architecture Without Big Design Up Front
Presented by: Peter Provost

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,107
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Session #5: Architecture Without Big Design Up Front

  1. 1. VSTS 2010 Architecture Edition Raj Selvaraj rselvara@microsoft.com
  2. 2. Introduction How many times have you walked into a legacy codebase and had no idea what was there? All systems have an architecture, whether you plan it or not Most systems today have evolved into Big Ball of Mud architectures Understanding and discovering what is there is a serious challenge today Ending with a system you want and can maintain is more important than defining the right thing before you start
  3. 3. VSTS 2010 Architecture Edition:
  4. 4. The Object Management Group (OMG) Microsoft joined OMG
  5. 5. Unified Modeling Language (UML) • The OMG Specification States • The Unified Modeling Language is a visual language for specifying, constructing, and documenting the artifacts of systems. It is a general-purpose modeling language that can be used with all major object and component methods, and that can be applied to all application domains and implementation platforms.
  6. 6. Modeling with UML diagrams Category UML Diagrams UML Diagrams supported in VSTS2010 Architecture Edition Structure Class Diagram, Object Class diagram , Component Diagram Diagram, Component Diagram Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram. Behavior Use Case Diagram , Use Case Diagram , and Diagrams Activity Diagram, and Activity Diagram. State Machine Diagram. Interaction Sequence Diagram, Sequence Diagram Diagrams Communication Diagram, Timing Diagram, and Interaction Overview Diagram.
  7. 7. Architectural Discovery • Everyone has existing code bases • Key architectural elements are undocumented • Maintenance is hard, changes are expensive • What can we do? • Let’s begin by discovering what we have using Architecture Explorer…
  8. 8. Architecture Explorer • Understanding a system can prevent the butterfly effect. • Architecture Explorer helps discover and understand how a system works. • Visualize existing code assets and how they connect.
  9. 9. Layer Diagram • Architectural validation ensures code matches intended design. • Layer diagram details the intended design. • Classes and namespaces are mapped to layers in the diagram.
  10. 10. Sequence Diagram
  11. 11. Demos • Architectural Discovery • Exploring Your Existing Application – Visualize call dependencies in the overall solution – Visualize interaction sequences in existing code (Reverse Engineering – Sequence Diagram) • Validating Code Changes with the Layer Design • Associate the code with the corresponding layers • Validate the code against the layer design
  12. 12. How Does This Relate To Agile? • For agile teams, Architecture is a way to organize and communicate about work and not to define the work • All agile teams use models. They just don’t often do a lot of modeling up front • Agile teams will create models on the fly as needed to describe, design and define a candidate design for a user story or task • In today’s globally disbursed environments, whiteboards won’t always suffice. We need to share in a way that can cross geographies and time zones
  13. 13. Conclusions • Every system has an architecture, the trick is figuring out what you have and what you want to do • Communicating effectively with your entire team is paramount • Architectural modeling and discovery tooling is useful regardless of development methodology

×