Design Techniques
On This Page
This page provides an overview of six abstract service types plus six line and boundary elements that can be used to model any software system.
For more in depth details, be sure to reference Righting Software.
System Design Diagramming
Abstract Service Types
Six abstract service types suffice to describe the design of any and all software systems.
Click on any of the abstract services types in the diagram below to learn more about each one of them.
Lines and Boundaries
Along with the six abstract service types, six line and boundary types add additional information to a complete system design.
digraph {
rank=LR
subgraph cluster_0{
label="Lines and Boundaries"
0[shape=none label="" width=0]
1[shape=none label="" width=0]
2[shape=none label="" width=0]
3[shape=none label="" width=0]
4[shape=none label="" width=0]
5[shape=none label="" width=0]
6[shape=none label="" width=0]
7[shape=none label="" width=0]
0->1->2->3->4->5->6->7 [style=invis]
PBX [shape=box width=3 label="" color="#CC0000"]
PB [shape=plaintext width=1.5 label="Process Boundary" border=0]
ANX [shape=box width=3 label="" fillcolor="#CC0000" style="filled"]
AN [shape=plaintext width=1.5 label="Authentication"]
AZX [shape=box width=3 label="" fillcolor="#EE000077" style="filled"]
AZ [shape=plaintext width=1.5 label="Authorization"]
DCA [style=invis width=0]
DCB [style=invis width=0]
DC [shape=plaintext width=2 label="Direct Call"]
DCA->DCB [minlen=8]
QCA [style=invis width=0]
QCB [style=invis width=0]
QC [shape=plaintext width=2 label="Queued Call"]
QCA->QCB [minlen=8 style=dashed color="#666666"]
LBA [style=invis width=0]
LBB [style=invis width=0]
LB [shape=plaintext width=2 label="Layer Boundary"]
LBA->LBB [minlen=8 style=dotted color="#444444" arrowhead=none]
{ rank=same; 1; PB; PBX; }
{ rank=same; 2; AN; ANX; }
{ rank=same; 3; AZ; AZX; }
{ rank=same; 4; DC; DCA; DCB; }
{ rank=same; 5; QC; QCA; QCB; }
{ rank=same; 6; LB; LBA; LBB; }
}
}
Abstract Service Types in Detail
The following section describes each of the six Abstract Service Types in more detail.
Client
WHO
Volatility: Presentation
Purpose: Enables an actor (user or service) to interact with the system in order to commmence, continue or complete a use case.
Manager
WHAT
Volatility: Sequence
Purpose: Encapsulates the sequence of actions to be performed in order to commence, continue, complete or cancel a use case.
Engine
HOW (Business)
Volatility: Strategy
Purpose: Encapsulates Business Algorithms.
Accessor
HOW (Resource)
Volatility: Action
Purpose: Encapsulates access to a resource with Atomic Business Verbs.
Resource
WHERE
Volatility: Location
Purpose: Storage and retrieval of information in the form of file systems, databases, queues, or sub-systems.
Utility
HOW & WHEN (Infrastructure)
Volatility: Plumbing
Purpose: Utilities provide services for interconnecting the other service types, as well as providing for cross cutting concerns such as security, logging, monitoring, messaging, scheduling, etc.
Diagram Types
System Design diagrams provide a crucial design validation tool for software architects and developers. They are used to communicate the design of a system to stakeholders, and to validate the design against the requirements. They are kept up to date to reflect the state of the system as the design evolves, all the way through to the implementation. This results in a well documented system that greatly increases understanding, enables ongoing composability and reuse, and enhances maintainability.
Activity Diagram
Activity Diagrams present the non-technical flow of a use case from the perspective of the business. Swimlanes differentiate the entities that participate in the use case such as Client applications and Subsystems.
@startuml diagram-example-activity
|A| Entity One
|B| Entity Two
|A|
start
:<Request>;
:Verify Request;
if (Valid?) then ([no])
|A|
:Error;
else ([yes])
|B|
:<Perform Action>;
endif
|A|
stop
@enduml
See the TradeMe Model for more examples.
Call Chain Diagram
Call Chain Diagrams present the dependency relationship between services that participate in a use case.
digraph d {
rankdir = TD;
pad = .4;
label = "Call Chains Example";
labelloc = "t";
Top [shape = none;label = "";height = 0;];
Top -> Client [style = invis;];
Client [width = 1.4;height = .6;shape = box;class = "client";];
Gateway [width = 1.4;height = .6;shape = box;class = "utility";];
Client -> Gateway [class = "sync";];
Gateway -> Manager [class = "sync";];
Manager [width = 1.4;height = .6;shape = box;class = "manager";];
Engine [width = 1.4;height = .6;shape = box;class = "engine";label = "Engine";];
Access1 [width = 1.4;height = .6;shape = box;class = "access";label = "Access";];
Access2 [width = 1.4;height = .6;shape = box;class = "access";label = "Access";];
Manager -> Engine [class = "sync";];
Manager -> Access2 [class = "sync";];
Engine -> Access1 [class = "sync";];
subgraph {
rank = same;
Access1;
Access2;
}
Access1 -> Resource1 [class = "sync";];
Access2 -> Resource2 [class = "sync";];
Resource2 [shape = cylinder;class = "resource";width = 1.3;height = .6;label = "Resource";];
Resource1 [shape = cylinder;class = "resource";width = 1.3;height = .6;label = "Resource";];
}
See the TradeMe Model for more examples.
Sequence Diagram
Sequence Diagrams, also known as an Interaction Diagrams, present the detailed interactions that occur between services during the execution of a use case. They provide the first step in the detailed design process.
@startuml diagram-example-sequence participant "Client\nApp" as Client #d9ead3 participant "Message\nBus" as MessageBus #ead1dc participant "A\nManager" as Manager #fff2cc participant "Engine\nOne" as Engine #fce5cd participant "Access\nOne" as AccessOne #cccccc participant "Access\nTwo" as AccessTwo #cccccc Client ++ #d9ead3 ||16|| Client --> MessageBus --++ #ead1dc ||16|| MessageBus --> Manager --++ #fff2cc Manager -> Engine ++ #fce5cd ||16|| Engine -> AccessOne ++ #cccccc ||16|| Engine -- AccessOne -- Manager -> AccessTwo ++ #cccccc Manager --> MessageBus --++ #ead1dc ||16|| @enduml
See the TradeMe Model for more examples.
Opportunity to Solution Process
The opportunity to solution process provides guidance for gathering and distilling requirements, and then designing a solutions that meets those requirements.
Service Development Lifecycle
The Service Development Lifecycle provides binary exit criteria for each phase of service development.
