L12 Visualizing Architecture
1 like717 views
Diagrams are important communication tools that help visualize software architecture. There are different levels of diagrams including context diagrams, container diagrams, and component diagrams. Context diagrams show the system context and external actors. Container diagrams show high-level technology choices and responsibilities. Component diagrams show the logical components within a container and their relationships. Together these diagrams help communicate the overall architecture vision at different levels of abstraction.
L12 Visualizing Architecture
- 1. HÖNNUN OG SMÍÐI HUGBÚNAÐAR 2015 L12 VISUALIZING ARCHITECTURE
- 2. Agenda Why diagrams? Boxes and lines What are you trying to say? Diagrams Context Container Components
- 3. Reading Simon Brown’s book Part IV, Chapters 31-41
- 6. Why Diagrams? Diagrams are communication tools Architecture is about Structure and Vision How do you communicate this? Visualisation of architecture is very important And easy to get wrong – a rare skill Diagrams tend to be vague and easy to misunderstand Mixing of many concepts into single diagram is confusing Boxes with lines
- 7. Traditional Approaches Formal Rational Unified Process (RUP) and Structured System Analysis and Design (SSADM) Modeling languages such as Unified Modelling Language (UML) In today’s agile world these formal process and strict languages are not favoured Still, there is need to communicated
- 10. Boxes and lines
- 11. Boxes and lines
- 12. Boxes and lines
- 13. Problems with Boxes and Lines Colour coding is unexplained Purpose is not explained Key relationships are missing or ambiguous Generic terms such as “business logic” Technology choices omitted Levels of abstractions mixed Diagrams often try to show too much details Lack context or logical starting point
- 14. The Need for Sketches Some developers favour TDD over diagrams After all, UML “isn’t cool” For some Agile means “No documentation” But still, agile practices still need communication and diagrams are very important tool for that No documentation mentality is dangerous and usually very expensive in the long run
- 15. Why Diagrams? Helps everybody in the team get the “big picture” Shared vision Focal point: what is being build, and how Helps technical conversations about how new features fit in Map that can be used to navigate the source code Helps explain to others what the teams are building Helps new employees get on track
- 16. Why Diagrams? Focus on high-level structure Create a vision that everybody in the team can understand and commit to Class diagrams are too details and should be considered temporary designs replaced by code Context, Containers and Component diagrams are usually sufficient
- 17. Ineffective Sketches Many teams struggle with diagrams They mistakenly abandon documentation and diagrams in favour of agile They don’t like UML but favour creating their own way (often ineffective) Usually, it’s just lack of training
- 18. The C4 Context, Container, Component, Classes
- 19. Goals with Diagrams Create number of diagram with different levels of abstractions Number of simpler diagrams can be more effective than one complex one - There is no one “Big Picture”
- 20. Abstractions
- 22. Abstractions Components: logical grouping of classes Services are components Example: Authentication Service Services are a set of collaborating classes, sitting behind an API
- 23. Abstractions Containers: what the component runs in Web server, application server Typically executable that are started as part of the system Java EJB, .NET
- 24. Abstractions System: highest level of abstraction Made up of multiple containers and defines the links between them
- 25. Diagrams Context: A high-level diagram that shows actors and system dependencies Container: high-level technology choices and responsibilities Component: for each container, what ware the key logical components and their relationships Classes: showing classes and their relationships, useful to explain design patterns
- 26. Context Diagram Useful starting point Intent Helps identify what the system is, who is using it and how it fits into the existing IT environment
- 28. Context Diagram Structure Your system is a block in the middle Surrounded by users and other systems Detail is not important Focus on people and systems, not technology and protocols
- 29. Context Diagram Users, actors, roles, personas etc Normal user, customers Admins Back-office staff IT systems Active Directory User database Relocation servers External vs. internal
- 30. Context Diagram Interactions Annotate the interactions (the lines) with useful information about the purpose For example, list of most likely user stories
- 31. Context Diagram Motivation Why this diagram? It makes the context explicit so there are no assumptions It shows what is being added into the IT environment High-level for technical and non-technical people Good starting point for discussions Audience Technical and non-technical people
- 33. Container Diagram High-level technology choices Intent Helps identify overall shape, high-level technology decisions, responsibilities, container communications and for developers, where the code is
- 35. Container Diagram Structure Simple block diagram showing key technology choices Container is any logical executable or processes that manage life-cycle of components Container is usually a middleware that requires some commitment on operating
- 36. Example Containers Web server (Apache, Tomcat, IIS, Jetty etc) Application servers (Jboss, WebSphere etc) Enterprise servers (Oracle Fusion etc) SQL databases (Oracle, MSSQL, MySQL etc) NoSQL databases (MongoDB, CouchDB, Redis etc) External storage Files systems OS services
- 37. For each container Name Logical name (“web server”, “database” etc) Technology Choice of technology (Apache, Tomcat, Oracle 11g etc) Responsibilities High-level statement of the containers responsibilites
- 38. Interactions and Boundaries The lines show interactions within the system Useful information: Purpose: “reads data from”, “sends reports to” etc Communication method: Web Service, REST, RMI, JMS etc Communication style: synchronous, asynchronous etc Protocols and port: HTTP, HTTPS, SOAP, SMTP etc Boundaries IT systems and users that are outside the boundaries of the system
- 39. Example Containers Motivation Container diagram shows inside the box Shows high-level technology choices Relationships and methods for communications Audience Technical people
- 41. Component Diagram Looking into the container with logical view of major components and their interactions Intent Helps identify what components/services that makes up the system, how the system works at high-level, where components live
- 43. Component Diagram Structure Draw the components/services that are in a single container If there are many services, it might be broken into some logical sections
- 44. Component Diagram What is a component or service Single responsibility Examples: Trade data system importer, risk calculator, authentication service, audit component etc Course grained building blocks For each component specify: Name: “Risk Calculator”, “Audit Component” Technology: Java, C#, Ruby, EJB, WFC Responsibilities: statement of purpose
- 45. Component Diagram Interactions Annotation of the lines between components Purpose (“uses”, “persist data” etc) Communication style (synchronous, asynchronous, batched etc)
- 46. Component Diagram Motivation Communicate logical structure within container, higher- level than class diagram, finer than container diagram Good way to understand how the system works and what it does Shows dependencies and deployable units Audience Devs
- 48. Technology Choices Should technology be included Should diagram be conceptual? Is it important not to include technology? Rules to follow If you know the technology, state it explicitly in the diagram: servers, languages, protocols, message format, communication styles Then answer the “why” questions Draw it like you code it
- 49. Draw it like you code it Shared components If multiple services use the same component (JAR) there should be box in each Layering Draw the communication paths as they are coded
- 50. Packaging Most architecture favour some level of layering Presentation Layer Domain Layer Data Source Layer How do you package code? Package by layer Package by feature Package by component
- 51. Package by layer All components in a layer are packaged together Simple to understand Similar components are grouped together Can impact the team structure Are multiple teams working on the same package? What about communication paths?
- 52. Package by feature/component By feature All components in that implement a feature are packaged together Vertical slice Can reflect team organization better By component Package each component separately Microservices model
- 53. Summary Diagrams are important Often ignored Usually some boxes and lines Without technical details What are you trying to say? Diagrams levels Context Container Components