HÖNNUN OG SMÍÐI HUGBÚNAÐAR 2015L12 VISUALIZING ARCHITECTURE

Agenda

Why diagrams?Boxes and linesWhat are you trying to say?DiagramsContextContainerComponents

Reading

Simon Brown’s bookPart IV, Chapters 31-41

Why Diagrams?

Visualising Software Development

Why Diagrams?

Diagrams are communication toolsArchitecture is about Structure and VisionHow do you communicate this?

Visualisation of architecture is very importantAnd easy to get wrong – a rare skillDiagrams tend to be vague and easy to misunderstandMixing of many concepts into single diagram is confusingBoxes with lines

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 favouredStill, there is need to communicated

Boxes and lines

Boxes and lines

Boxes and lines

Boxes and lines

Boxes and lines

Problems with Boxes and Lines

Colour coding is unexplainedPurpose is not explainedKey relationships are missing or ambiguousGeneric terms such as “business logic”Technology choices omittedLevels of abstractions mixedDiagrams often try to show too much detailsLack context or logical starting point

The Need for Sketches

Some developers favour TDD over diagramsAfter 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

Why Diagrams?

Helps everybody in the team get the “big picture”Shared vision

Focal point: what is being build, and howHelps technical conversations about how new features fit inMap that can be used to navigate the source codeHelps explain to others what the teams are buildingHelps new employees get on track

Why Diagrams?

Focus on high-level structureCreate 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 favour of agile

They don’t like UML but favour creating their own way (often ineffective)

Usually, it’s just lack of training

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 - There is no one “Big Picture”

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

IntentHelps identify what the system is, who is using it and how it fits into the existing IT environment

Context Diagram

StructureYour system is a block in the middleSurrounded by users and other systemsDetail is not importantFocus on people and systems, not technology and protocols

Context Diagram

Users, actors, roles, personas etcNormal user, customersAdminsBack-office staff

IT systemsActive DirectoryUser databaseRelocation serversExternal vs. internal

Context Diagram

InteractionsAnnotate the interactions (the lines) with useful information about the purposeFor example, list of most likely user stories

Context Diagram

MotivationWhy this diagram?It makes the context explicit so there are no assumptionsIt shows what is being added into the IT environmentHigh-level for technical and non-technical peopleGood starting point for discussions

AudienceTechnical and non-technical people

Container Diagram

High-level technology choices

IntentHelps identify overall shape,high-level technology decisions,responsibilities,container communications andfor developers, where the code is

Container Diagram

StructureSimple 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 storageFiles systemsOS services

For each container

NameLogical name (“web server”, “database” etc)

TechnologyChoice of technology (Apache, Tomcat, Oracle 11g etc)

ResponsibilitiesHigh-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” etcCommunication method: Web Service, REST, RMI, JMS etcCommunication style: synchronous, asynchronous etcProtocols and port: HTTP, HTTPS, SOAP, SMTP etc

BoundariesIT systems and users that are outside the boundaries of the system

Example Containers

MotivationContainer diagram shows inside the boxShows high-level technology choicesRelationships and methods for communications

AudienceTechnical people

Component Diagram

Looking into the container with logical view of major components and their interactions

IntentHelps identify what components/services that makes up the system, how the system works at high-level, where components live

Component Diagram

StructureDraw the components/services that are in a single containerIf there are many services, it might be broken into some logical sections

Component Diagram

What is a component or serviceSingle responsibilityExamples: Trade data system importer, risk calculator, authentication service, audit component etcCourse grained building blocks

For each component specify:Name: “Risk Calculator”, “Audit Component”Technology: Java, C#, Ruby, EJB, WFCResponsibilities: statement of purpose

Component Diagram

InteractionsAnnotation of the lines between componentsPurpose (“uses”, “persist data” etc)Communication style (synchronous, asynchronous, batched etc)

Component Diagram

MotivationCommunicate logical structure within container, higher-level than class diagram, finer than container diagramGood way to understand how the system works and what it doesShows dependencies and deployable units

AudienceDevs

Technology Choices

Should technology be includedShould diagram be conceptual?Is it important not to include technology?

Rules to followIf you know the technology, state it explicitly in the diagram: servers, languages, protocols, message format, communication stylesThen answer the “why” questionsDraw it like you code it

Draw it like you code itShared components

If multiple services use the same component (JAR) there should be box in each

LayeringDraw the communication paths as they are coded

Packaging

Most architecture favour some level of layeringPresentation LayerDomain LayerData Source Layer

How do you package code?Package by layerPackage by featurePackage by component

Package by layer

All components in a layer are packaged together

Simple to understandSimilar components are grouped together

Can impact the team structureAre multiple teams working on the same package?What about communication paths?

Package by feature/component

By featureAll components in that implement a feature are packaged togetherVertical sliceCan reflect team organization better

By componentPackage each component separatelyMicroservices model

Summary

Diagrams are importantOften ignored

Usually some boxes and linesWithout technical detailsWhat are you trying to say?

Diagrams levelsContextContainerComponents