View Based Documentation
of Software Architectures
from
“views and beyond “
by
Clements and lots of people
Slide 1
Uses of Documentation
• As a means of education – introducing people
to the system
• As a primary vehicle for communication
amongst stakeholders
• As a basis for system analysis
Slide 2
What does the arrow mean?
• C1 calls C2
– C1 passes data to C2 via its
parameters
– C1 obtains a result from C2
– C1 causes C2 to come into
existence
– C1 cannot execute till C2
terminates
• Data flows both ways:
two arrows, double
headed arrow
Component 1
Connector P
Component 2
Slide 3
View types
• Architects need to look at software in three
ways
– How it is structured as a set of implementation units
– How it is structured as a set of elements that have
runtime behavior and interaction
– How it relates to non-software structures and its
environment
Slide 4
Viewtypes
• The module viewtype
– Document a system’s principals units of
implementations
• The component and connector viewtype
– Document the system’s units of execution
• The allocation viewtype
– Document the relationship between a system’s
software and its development and execution
environment
Slide 5
Styles
• In each view type there are a set of
commonly occurring forms and variations –
styles
• Layered style, client-server, ..
Slide 6
Seven rules for sound Documentation
• Write documentation
from the Readers’s Point
of view
• Avoid unnecessary
repetition
• Avoid ambiguity
• Use a standard of
Organisation
• Record Rationale
• Keep documentation
current but not too
current
• Review Documentation
for fitness of purpose
Slide 7
Viewtypes and Styles
Slide 8
Module Viewtype
• A code unit that implements a set of
responsibilities
• Can be a class, a collection of classes, a layer
or any decomposition of the code unit
• Has some properties: responsibility, visibility,
author..
Slide 9
Module Viewtype styles
•
•
•
•
Decomposition style
Uses style
Generalization style
Layered style
Slide 10
Component and connector Viewtype
• Express runtime behavior
• Described in terms of connectors and
components
• Objects, processes, collection of objects are
components
• Pipes, repositories, sockets are connectors
• Middleware is a connector
Slide 11
C&C Viewtype Styles
•
•
•
•
•
•
Pipe-and-filter
Shared-data
Publish-subscribe
Client-server
Peer-to-peer
Communicating processes
Slide 12
Allocation Viewtype
• Maps software units to elements of the
environment(hardware, development team..)
• Deployment style
• Implementation style
• Work assignment style
Slide 13
Style Guide
• Overview
• Elements, relations and
properties
• What it’s for and not
for
• Notations
• Relation to other views
• Examples
Slide 14
LINUX ARCHITECTURE
Different Views
Slide 15
Basic Definitions
• Linux subsystems
– Process Scheduler (PS) – responsible for supporting
multitasking by deciding which user process executes.
– Memory Manager (MM) – provides a separate memory
space for each user process.
– File System (FS)– provides access to hardware
devices
– Network Interface (NI)– encapsulates access to
network devices
Slide 16
• Linux subsystems
– Inter Process Communication (IPC)– allows user
processes to communicate with other processes on
the same computer
– Initialization (Init)– responsible for initializing the
rest of the linux kernel with appropriate usr
configured settings
– Library (Lib)– the kernel core which stores the
routines that are used by other subsystems for their
running.
Slide 17
MODULE VIEW
Slide 18
Module View
Linux
MM
Init
PS
FS
NI
IPC
Lib
Slide 19
File System Broken Down
File System
System
Call
Interface
Executable
Formats
Device
Drivers
Virtual
File
System
File
Quota
Buffer
Cache
Logical
File
System
Slide 20
Components & Connector
Diagrams
Slide 21
CnC View
• 1st level of abstraction – This level only gives
the corresponding relations between the 7
basic modules that construct the Linux
architecture
• Relations used – If x
y then x depends
on y for its running, i.e. for x depends on
certain components present inside y for its
own running.
Slide 22
CnC view
FS
NI
MM
PS
Init
IPC
Lib
Slide 23
CnC – 2nd Level of Abstractions
FS
NI
MM
PS
Init
IPC
Lib
Slide 24
Breakdown of FS
MM
• FS
NI
Sys Call
Interface
Init
Virtual
FS
Executable
File
Format
IPC
Logical
FS
Device
Driver
Buffer
Cache
PS
File
Quota
Lib
Slide 25
Module View
Slide 26
Viewtypes
• The module viewtype
– Document a system’s principals units of
implementations
• The component and connector viewtype
– Document the system’s units of execution
• The allocation viewtype
– Document the relationship between a system’s
software and its development and execution
environment
Slide 27
Module Viewtype
• A code unit that implements a set of
responsibilities
• Can be a class, a collection of classes, a layer
or any decomposition of the code unit
• Has some properties: responsibility, visibility,
author..
Slide 28
Module Viewtype styles
•
•
•
•
Decomposition style
Uses style
Generalization style
Layered style
Slide 29
Overview
• What is a module? – software units with well defined
interfaces providing a set of services
• Module vs. component
– Both are about decomposition
– Module has a design time connotation and component a runtime
connotation
• 4 common styles
– The decomposition style – containment relationship among
modules
– The uses style – functional dependency relationships among
modules
– Generalization style – specialization relationships among modules
– Layered style – allowed-to-use relation in a restricted fashion
among modules
Slide 30
What is it for?
• Construction –
– blueprint for the source code
– Modules and physical structures (source code files) will have
close mapping
• Analysis
– Requirements traceability
– Impact analysis
• Communication – useful for explaining the systems
functionality
Slide 31
What is it not for?
• Cannot make inferences about runtime
behavior
• Hence not used for analysis of performance,
reliability and other runtime qualities; we use
c-and-c and allocation views are used
Slide 32
Relation to other viewtypes
• Module views commonly mapped to c-and-c
viewtypes
• Sometimes one-to-one or one-to-many but
could also be fragments to fragment
Slide 33
Module Viewtype styles
•
•
•
•
Decomposition Style
Uses
Generalization
Layered
Slide 34
Decomposition - overview
• Focus on the is-part-of relationship between elements
and their properties
• How system responsibilities are partitioned across how
these modules are decomposed into sub modules
• All architectures begin with module decomposition style – divide
and conquer
• Useful for communicating the broad picture to new comers
• Since functionality is allocated, modifiability is immediately
addressed
Slide 35
Criteria for decomposition
• Achievement of certain quality attributes
– Modifiability
– Performance
• Build-versus-buy decisions
• Product line implementations
Slide 36
Elements, Relations, Properties
Elements
Modules; an aggregation of
modules is a subsystem
Relations
Decomposition(is-part-of);
criteria to be mentioned
Element
properties
Defined in the module viewtype
Relation
Properties
Visibility
Topology
No loops; A module cannot be part of
more than one module
Slide 37
• What is it for?
– Learning
– New comers
– Work assignment
• What is it not for?
• Notations
– Named boxes within boxes
– Textual notation
• Examples of decomposition style
Slide 38
From Clements etal
Slide 39
Relation to other styles
• Module decomposition view can be mapped into
component-and-connector view; either oneto-one or one-to-many or fragment to
fragment
• Closely related to work assignment style of
allocation viewtype
Slide 40
Module Viewtype styles
•
•
•
•
Decomposition Style
Uses style
Generalization
Layered
Slide 41
Uses - overview
• What other modules should exist in order to
do their part of the work properly
Slide 42
Uses summary
Elements
Modules
Relations
Uses relation
Element properties Defined in the module viewtype
Relation
Properties
Describe the kind of usage
Topology
No constraints; loops make
incremental development
difficult
Slide 43
Uses style contd.
• Can be documented as a two column table
• Or any graphical notation
• P1 uses P2, if P1’s correctness depend on the
correctness of P2
• Two kinds of usage
– CALLS but not USES
» Exception handling – just pass on the name of caller
– CALLS and USES
– No CALL yet USES
» Expect P2 to leave a variable in a certain state
Slide 44
Where is it useful?
• Incremental development
– Implement part of the total functionality
• Sub-setting, debugging, testing, impact
analysis
Slide 45
From Clements etal
Slide 46
Decomposition Styles
•
•
•
•
Decomposition Style
Uses
Generalization
Layered
Slide 47
Overview
• Is-a relation is specialized to generalization
• Parent is a more general version of the child
– In decomposition the parent consists of the child
• Useful for extension and evolution of
architectures and individual elements
• Inheritance of interface and implementation
Slide 48
Generalization summary
Elements
Modules as defined in the
module view type
Relations
generalization relation
Element properties Defined in the module viewtype; can
also have some abstractions
Relation
Properties
Distinguish between interface
and implementation
Topology
Multiple parents possible; cycles
not allowed
Slide 49
Gen: where is it useful?
•
•
•
•
Object-oriented designs
Extension and evolution
Local change or variation
Reuse
Slide 50
From Clements etal
Slide 51
Decomposition - Styles
•
•
•
•
Decomposition Style
Uses style
Generalization
Layered
Slide 52
Layered - overview
•
•
•
•
Each layer represents a virtual machine
Completely partitions the software
Strict ordering
Layer bridging
Slide 53
Layers summary
Elements
layers
Relations
Allowed to use
Element properties Units of software the layer
contains; description of the vm
the layer represents
Relation
Properties
Visibility
Topology
(AB) precludes (BA)
Slide 54
Layers - What is it for ?
•
•
•
•
Modifiability
Portability
Principle of information hiding(VM)
Run time overhead is more?
– How to reduce it?
Slide 55
Relation to other styles
• Layers are not modules
– A layer may be module
– But modules can be decomposed to other modules;
layers are not decomposed to other smaller layers
– segmenting a layer gives rise to modules; modules can
span layers
• Tiers are not layers
– Tiers are hybrid view combining cnc and allocation
view types
Slide 56
From Clements etal
Slide 57
From Clements etal
Slide 58
Component and Connector
ViewType
Slide 59
Overview
• Defines models consisting of
– elements having some runtime presence – processes,
objects, clients, servers, datastores
– Pathways of interaction – communication links,
protocols, information flows, access to shares storage
Slide 60
Runtime entities and their
interactions
• May contain many instances of the same
component type
• Similar to object(collaboration) diagrams as
against class diagrams(which define types of
elements)
Slide 61
Summary of C&C Viewtype
Elements
Component Types: principal processing
unit and datastores
Connector Types: interaction
mechanisms
Relations
Attachments:component ports are
associated with specific connector roles
Properties of
elements
Component: Name, type(general
functionality, number and type of ports)
Other properties(like performance..)
Connector: name, type(nature of
interaction, number and type of roles..),
other properties(protocol of interaction,
performance values..)
Topology
No Inherent constraints
Slide 62
What is C&C for?
• To reason about runtime system quality attributes –
performance, reliability, availability
• What are the systems principal executing components
and how do they interact
• What are the major shared data resources
• Which parts of the system are replicated and how
many times
• How does data progress through a system as it
executes
• What protocols of interaction are used by
communicating entities
• What parts of the system run in parallel
• How can the system’s structure change as it executes
Slide 63
What is C&C not for?
• Can not represent design elements which do
not have a runtime presence
• Example – interface of an element - usability
Slide 64
C&C Viewtype Styles
•
•
•
•
•
•
Pipe-and-filter
Shared-data
Publish-subscribe
Client-server
Peer-to-peer
Communicating processes
Slide 65
From Clements etal
Slide 66
Pipes and Filters
• A filter transforms data that it receives from one or
more pipes and transmits through one or more pipes
• A pipe is a connector that conveys streams of data
from output port of one filter to input port of
another
• Pipes buffer data
• Filters act asynchronously, concurrently
• The overall function is a composition of filter
functions
Slide 67
What for ..
• Very useful in data transformation
– Signal processing
– compilers
• To reason about system performance, stream
latency, pipe buffer requirements,
schedulability
Slide 68
Pipes and filters - summary
Elements
Component Types: filter – ports must be input or
output
Connector Types: pipes – have data-in and data-out
roles
Relations
Attachments: associates filter output ports to data-in
roles of a pipe and.. Out to in
Properties of elements
Component: Name, type(general functionality,
number and type of ports)
Other properties(like performance..)
Connector: name, type(nature of interaction, number
and type of roles..), other properties(protocol of
interaction, performance values..)
Topology
Might be restricted to acyclic graphs
Slide 69
Relationship with other styles
• Different from data flow projections/views
• In pipes-and-filters lines have specific
meaning – transmit streams of data
• In dataflow relationships implies data
communication – could be implemented as a
procedure call, publish-subscribe, via a pipe..
Slide 70
From Clements etal
Slide 71
From Clements etal
Slide 72
Shared data style
• Useful in exchange of persistent data, which
has multiple accessors
• How does the consumer know data is
available?
– Store informs the consumer – blackboard
– Consumer is responsible - repository
Slide 73
Shared data access -summary
Elements
Component types: data stores, data
accessors
Connectors: data reading and writing
Relations
Which accessor is connected to
which store
Computational model
Communication between accessors
mediated by the store;
communication may be initiated by
either
Properties of elements
Same as in C&C; types of data, data
performance, data distribution
Topology
Data accessors are attached to
connectors that are attached to
stores
Slide 74
What for..
• Used when there are multiple accessors and
persistence
• Decouple producer from consumer
• Data store performance, security, privacy,
compatibility with other stores…
Slide 75
Similarity to others
• Client-server style
• Publish-subscribe is similar without
persistence
Slide 76
From Clements etal
Slide 77
Publish-subscribe styles
• Components interact via announced
events
• Components subscribe to a set of events
• P-S runtime ensures that each published
event is delivered to all subscribers
• The connector is an event bus
• Used in message production/consumption
Slide 78
P-S summary
Elements
Component types: any component
with a pub/sub interface
Connectors: publish-subscribe
Relations
Attachment associates components
with pub-sub connector
Computational model
A system of independent components
that announce events and react to
other announced events
Properties of elements
Same as in C&C;
Topology
All components are connected to an
event distributor
Slide 79
Where to use ..
• To send events and messages to recipients
• Set of recipients are unknown – can be added
dynamically
Slide 80
Relationship with other styles
• When used to distribute messages – similar to
shared-data blackboard without persistence
• When components have independent thread of
control P-S is refinement of communicating
processes style
Slide 81
TIBCO Smart Sockets
• Fast and flexible development
• Publish-subscribe for intelligent, streamlined
one-to-many communications
• Adaptive multicast for most efficient network
utilization
• Multithreaded, multiprocessor architecture
for full system exploitation
• Online security safeguards vitalcommunications
• Real-time monitoring of network applications
• Performance optimization for maximum
throughput
• Robust, enterprise-quality fault tolerant GMD
for reliable message delivery
Slide 82
Slide 83
Slide 84
Slide 85
Client-Server
• Components interact by requesting services of
other components
• Communication is initiated by a client
Slide 86
Client-Server summary
Elements
Component types: clients – which ask
for services; servers –which provide
services
Connectors: request-reply
Relations
Attach clients to servers
Computational model
Clients initiate activity and wait for
results
Properties
Same as in C&C; number and type of
clients, performance
Topology
Unrestricted; number of clients;
tiers
Slide 87
What for..
• Assignment of functionality is clear
• Can be independently assigned to tiers
• Can be used to argue about performance
• Example - WWW
Slide 88
Peer-to-peer
• Components interact with each other
exchanging services
• No asymmetry as in client-server
• Connectors are bidirectional
Slide 89
Communicating-Processor Style
• Interaction of concurrently executing
components though various connector
mechanisms
• Typically used at design stage
Slide 90
From Clements etal
Slide 91
Allocation Viewtype
Slide 92
Allocation viewtype styles
• Deployment style
• Implementation style
• Work assignment style
Slide 93
Summary of Allocation Viewtype
Elements
Software elements and environment
elements
Relations
Allocated-to. A software element is
allocated to an environmental element
Properties of
elements
A software element has required
properties. An environmental element
has provided properties that need to be
matched.
Topology
Varies by style
Slide 94
Deployment style
• Elements of the C&C styles are allocated to
execution platforms
Slide 95
Deployment style summary
Elements
Software element: usually a process
from the C$C view
Environmental Element: computing
hardware, processor, disk, ..
Relations
Allocated to: showing the physical
unit the element resides
Migrates-to, copy-migrates to: if
the allocation is dynamic
Properties of elements
Required properties of software
elements
Provided properties of software
elements
Properties of relations
Allocated to – either static or
dynamic
Topology
unrestricted
Slide 96
From Clements etal
Slide 97
From Clements etal
Slide 98
Viewpacket
• Small, digestible part of a view
Slide 99
Slide 100