PHX Session #5 : Architecture Without Big Design Up Front (Garibay)
•Descargar como PPTX, PDF•
1 recomendación•777 vistas
This document discusses software architecture and how it relates to agile development. It defines architecture as the fundamental organization of a system, including its components and relationships. The document advocates discovering an existing system's architecture to understand it before making changes. It presents the 4+1 architectural views model and shows how Visual Studio 2010 supports modeling with tools like Architecture Explorer and layer diagrams.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a PHX Session #5 : Architecture Without Big Design Up Front (Garibay)
Similar a PHX Session #5 : Architecture Without Big Design Up Front (Garibay) (20)
Más de Steve Lange
Más de Steve Lange (20)
Último
Último (20)
PHX Session #5 : Architecture Without Big Design Up Front (Garibay)
- 1. VSTS 2010 Architecture Edition Rick G. Garibay rick.garibay@neudesic.com
- 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. Q: How Do You Eat an Elephant?
- 4. Software Architecture • Architecture is important – part of the product – it should be analyzed – should be easy to explain and understand • Architecture is central for communicating – it should be documented – documentation should be targeted at specific stakeholders – documentation should be auditable • Architecture is expensive to change – it is cheaper to analyze early – The key to being emergent is to make the best decisions possible • Architecture affects the entire project – many stakeholders should be involved • Broad requirements can be understood early – architecture should be designed to meet them
- 5. How Does This Relate To Agile?
- 6. How Does This Relate To Agile?
- 7. How Does This Relate To Agile? • For agile teams, Architecture is emergent. • 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
- 8. 4 + 1 Views on Software Architecture Development Logical (Implementation) Scenarios Physical Process (Deployment) Philippe B. Kruchten, IEEE Software 1995
- 9. On Architectural Views • An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective. Philippe B. Kruchten, IEEE Software 1995
- 10. Why 5 Views? • Architecture has several audiences. • Each type of model has its strength and weakness • No single view is sufficient because architecture is such a complex issue Philippe B. Kruchten, IEEE Software 1995
- 11. The Object Management Group (OMG) • Microsoft joined OMG in 2008
- 12. 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.
- 13. Modeling Support in VS 2010 View Category UML Diagrams VSTS2010 Architecture Edition Logical Structure Class Diagram, Object Class diagram , Component Diagram Diagram, Component Diagram Development Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram. Scenarios Behavior Use Case Diagram , Activity Use Case Diagram , and Activity Diagrams Diagram, and State Diagram. Machine Diagram. Process Interaction Sequence Diagram, Sequence Diagram Diagrams Communication Diagram, Timing Diagram, and Interaction Overview Diagram.
- 14. Modeling Support in VS 2010 View Category UML Diagrams VSTS2010 Architecture Edition Logical N/A N/A Call Dependency Visualization: •By Assembly •By Namespace Development •By Class Physical Class Dependency Visualization: •Details •Dependencies Interaction Sequence Visualization •Impact analysis •Call sequences Logical N/A N/A Layer Diagram •Map code to layers •Validate code against the layer design Physical •Visualize interactions and sequences Development between code in layers
- 15. Defining Architecture… • “the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”. (IEEE 1471)
- 16. 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…
- 17. 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.
- 18. Demo VS 2010 ARCHITECTURE EXPLORER
- 19. Defining Architecture… • “The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.” (Garlan and Perry 1995, p. 269)
- 20. 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.
- 21. Demo VSTS 2010 LAYER DESIGN
- 22. Defining Architecture… • “An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization—these elements and their interfaces, their collaborations, and their composition.” (Booch, Rumbaugh, and Jacobson 1999, p. 31)
- 23. Sequence Diagram
- 24. Demo VSTS UML 2.1.1 SEQUENCE DIAGRAM SUPPORT
- 25. A: One Bite at a Time! 26
- 26. 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
- 27. Thank You • October CTP: http://www.microsoft.com/visualstudio • Documenting Software Architecture
Notas del editor
- The ability to right click inside a method, select \"Generate Sequence Diagram...\", resulting in, you guessed it! A sequence diagram! :)
- Reference: http://blogs.msdn.com/camerons/archive/2008/11/10/testing-draft-to-blog.aspx
- Object Management Group (OMG): *Founded in 1989 *Over 470 member companies*The largest and longest standing not-for-profit, open-membership consortium which develops and maintains computer industry specifications.*OMG maintains active relationships with many other standards bodies and consortia. [ISO,OASIS, IEEE, W3C, THE Open GROUP, AIIM International, STAR, and INCOSE] For more information please see http://www.omg.org/news/about/liaison.htm*OMG’s best known Successes: [http://www.omg.org/gettingstarted/specintro.htm]-Common Object Request Broker Architecture (CORBA®)-Unified Modeling Language (UML)-Common Warehouse Metamodel (CWM)-Meta-Object Facility(MOF)- XML Metadata Interchange- XMI, the XML-UML standardMicrosoft Joins OMG:- September 10, 2008, Microsoft announced its membership in the standards body Object Management Group™ (OMG™). [http://www.microsoft.com/presspass/press/2008/sep08/09-10OMGModelingPR.mspx]
- UML® Resource Page: http://www.uml.org/UML Specification:http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UMLIntroduction to OMG's Unified Modeling Language™ (UML®)http://www.omg.org/gettingstarted/what_is_uml.htm
- A diagram is a view into a model. UMLdefines thirteen types of diagrams, divided into three categories: Six diagram types represent static application structure; three represent general types of behavior; and four represent different aspects of interactions:*Structure Diagrams include the Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram. *Behavior Diagrams include the Use Case Diagram (used by some methodologies during requirements gathering); Activity Diagram, and State Machine Diagram. *Interaction Diagrams, all derived from the more general Behavior Diagram, include the Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram.
- A diagram is a view into a model. UMLdefines thirteen types of diagrams, divided into three categories: Six diagram types represent static application structure; three represent general types of behavior; and four represent different aspects of interactions:*Structure Diagrams include the Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram. *Behavior Diagrams include the Use Case Diagram (used by some methodologies during requirements gathering); Activity Diagram, and State Machine Diagram. *Interaction Diagrams, all derived from the more general Behavior Diagram, include the Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram.
- Butterfly Effect is the phenomenon that happens when you make a change in one area of your code and something unforeseen happens somewhere else. Architecture Explorer This overall feature gives you the ability to explorer and visualize your solution / projects inside Visual Studio, allowing you to reason over various questions you may have: \"How is this class dependent on this other?\" \"What assemblies does this assembly reference?\" \"How many lines of code in this method?\" Reference: http://blogs.msdn.com/bharry/archive/2008/06/05/teched-2008-keynote.aspXStandard\" Graphs Common views of your system. In the 2010 CTP, you'll see three menus in the \"Analyze\" menu item, as well as from the Architecture Explorer tool window, seen here: From the \"Analyze\" top level Menu: From the Architecture Explorer toolbar: Selecting any of these menus will result in dependency graphs between Assemblies, Namespaces, or classes. By the time we RTM, we expect to have a few more. Reference: http://blogs.msdn.com/camerons/Default.aspx?p=2#Understand
- Reference: http://blogs.msdn.com/bharry/archive/2008/06/05/teched-2008-keynote.aspXThe layer diagram allows you to design the logical layering of your application and specify the dependencies you intend to have. For example, you wouldn't want your client to have a dependency on you data layer in a 3 tier app. You wouldn't want your server business logic taking a dependency on something in the Windows.Forms assembly, etc.Once you have this logical layering, you can associate the layers with specific assemblies, namespaces or classes in your actual application. Now, the magic happens. VSTS can parse/reverse engineer your code to determine the \"actual\" dependencies in your application. Having done this, it can compare the actual to the \"desired\" as specified in the layer diagram and let you know about any problems you have. Going even further, you can configure a checkin policy to validate this on every single checkin. This way you can prevent people from checking in spaghetti architecture in the first place.It's very hard to communicate an architecture to everyone on the team. It's even harder to prevent them from accidentally violating the architecture. These tools are a huge leap forward in ensuring that you end up with the architecture you designed.On top of this cool new layer diagram and validation is another feature called the \"Architecture Explorer\". It is a very handy tool for visualizing the architecture your code implements today. It allows you to graphically browse through your application and its dependencies and understand them. As you update your code, you can see the Architecture Explorer diagrams change.