Lecture 12Visualizing Architecture

Agenda Why diagrams? Boxes and lines– What are you trying to say?

Diagrams– Context– Container– Components

Reading Simon Brown’s book– Part IV, Chapters 32-41

Why Diagrams?

Visualizing Software Development

Why Diagrams? Diagrams are communication tools Architecture is about Structure and Vision– How do you communicate this?

Visualization of architecture is very important– And easy to get wrong – a rare skill– Diagrams tend to be vague and easy to

misunderstand– Boxes with lines

Traditional Approaches Formal Rational Unified Process (RUP)

and Structured System Analysis and Design (SSADM)

Modeling languages such as Unified Modeling Language (UML)

In today’s agile world these formal process and strict languages are not favored

Still, there is need to communicated

Boxes and lines

Problems with Boxes and Lines Color 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

The Need for Sketches Some developers favor TDD over diagrams After all, UML “isn’t cool” But still, agile practices still need

communication and diagrams are very important tool for that

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

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

Ineffective Sketches Many teams struggle with diagrams– They mistakenly abandon documentation and

diagrams in favor of agile– They don’t like UML but favor creating their

own way (often ineffective)– Training is lacking

The C4Context, container, component, classes

Goals with Diagrams Create number of diagram with different

levels of abstractions Number of simpler diagrams can be more

effective than one complex one

Abstractions

Abstractions Classes: Smallest

building blocks

Abstractions Components:

logical grouping of classes

Services are components

Example:– Authentication

Service Services are a set of

collaborating classes, sitting behind an API

Abstractions Containers: what

the component runs in

Web server, application server

Typically executable that are started as part of the system– Java EJB, .NET

Abstractions System: highest

level of abstraction Made up of multiple

containers and defines the links between them

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

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

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

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

Context Diagram Interactions– Annotate the interactions (the lines) with

useful information about the purpose– For example, list of most likely user stories

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

Container Diagram High-level technology choices Intent– Helps identify overall shape,

high-level technology decisions,responsibilities,container communications andfor developers, where the code is

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

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

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

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

Container Diagram Motivation– Container diagram shows inside the box– Shows high-level technology choices– Relationships and methods for communications

Audience– Technical people

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

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

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, WCF– Responsibilities: statement of purpose

Component Diagram Interactions– Annotation of the lines between components– Purpose (“uses”, “persist data” etc)– Communication style (synchronous,

asynchronous, batched etc)

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

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

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

Packaging Most architecture favor 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

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?

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

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