View Based Documentation of Software Architectures from

1
View Based Documentation of Software
Architecturesfromviews and beyond
byClements and lots of people
2
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

3
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

4
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

5
Viewtypes

• The module viewtype
• Document a systems principals units of
  implementations
• The component and connector viewtype
• Document the systems units of execution
• The allocation viewtype
• Document the relationship between a systems
  software and its development and execution
  environment

6
Styles

• In each view type there are a set of commonly
  occurring forms and variations styles
• Layered style, client-server, ..

7
Seven rules for sound Documentation

• Write documentation from the Readerss 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

8
Viewtypes and Styles
9
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..

10
Module Viewtype styles

• Decomposition style
• Uses style
• Generalization style
• Layered style

11
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

12
CC Viewtype Styles

• Pipe-and-filter
• Shared-data
• Publish-subscribe
• Client-server
• Peer-to-peer
• Communicating processes

13
Allocation Viewtype

• Maps software units to elements of the
  environment(hardware, development team..)
• Deployment style
• Implementation style
• Work assignment style

14
Style Guide

• Overview
• Elements, relations and properties
• What its for and not for

• Notations
• Relation to other views
• Examples

15
LINUX ARCHITECTURE

• Different Views

16
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

17

• 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.

18

• MODULE VIEW

19
Module View
Linux
MM
Init
PS
NI
IPC
FS
Lib
20
File System Broken Down
File System
System Call Interface
Executable Formats
Virtual File System
File Quota
Buffer Cache
Device Drivers
Logical File System
21

• Components Connector
• Diagrams

22
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.

23
CnC view
FS
NI
MM
IPC
PS
Init
Lib
24
CnC 2nd Level of Abstractions
FS
NI
MM
PS
IPC
Init
Lib
25
Breakdown of FS
MM
NI

• FS

Sys Call Interface
Virtual FS
Init
IPC
Executable File Format
Logical FS
Device Driver
Buffer Cache
File Quota
PS
Lib
26
Module View
27
Viewtypes

• The module viewtype
• Document a systems principals units of
  implementations
• The component and connector viewtype
• Document the systems units of execution
• The allocation viewtype
• Document the relationship between a systems
  software and its development and execution
  environment

28
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..

29
Module Viewtype styles

• Decomposition style
• Uses style
• Generalization style
• Layered style

30
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

31
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

32
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

33
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

34
Module Viewtype styles

• Decomposition Style
• Uses
• Generalization
• Layered

35
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

36
Criteria for decomposition

• Achievement of certain quality attributes
• Modifiability
• Performance
• Build-versus-buy decisions
• Product line implementations

37
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
38

• 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

39
From Clements etal
40
Relation to other styles

• Module decomposition view can be mapped into
  component-and-connector view either one-to-one
  or one-to-many or fragment to fragment
• Closely related to work assignment style of
  allocation viewtype

41
Module Viewtype styles

• Decomposition Style
• Uses style
• Generalization
• Layered

42
Uses - overview

• What other modules should exist in order to do
  their part of the work properly

43
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
44
Uses style contd.

• Can be documented as a two column table
• Or any graphical notation
• P1 uses P2, if P1s 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

45
Where is it useful?

• Incremental development
• Implement part of the total functionality
• Sub-setting, debugging, testing, impact analysis

46
From Clements etal
47
Decomposition Styles

• Decomposition Style
• Uses
• Generalization
• Layered

48
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

49
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
50
Gen where is it useful?

• Object-oriented designs
• Extension and evolution
• Local change or variation
• Reuse

51
From Clements etal
52
Decomposition - Styles

• Decomposition Style
• Uses style
• Generalization
• Layered

53
Layered - overview

• Each layer represents a virtual machine
• Completely partitions the software
• Strict ordering
• Layer bridging

54
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)
55
Layers - What is it for ?

• Modifiability
• Portability
• Principle of information hiding(VM)
• Run time overhead is more?
• How to reduce it?

56
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

57
From Clements etal
58
From Clements etal
59
Component and Connector ViewType
60
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

61
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)

62
Summary of CC Viewtype
Elements Component Types principal processing unit and datastores Connector Types interaction mechanisms
Relations Attachmentscomponent 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
63
What is CC 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 systems structure change as it
  executes

64
What is CC not for?

• Can not represent design elements which do not
  have a runtime presence
• Example interface of an element - usability

65
CC Viewtype Styles

• Pipe-and-filter
• Shared-data
• Publish-subscribe
• Client-server
• Peer-to-peer
• Communicating processes

66
From Clements etal
67
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

68
What for ..

• Very useful in data transformation
• Signal processing
• compilers
• To reason about system performance, stream
  latency, pipe buffer requirements, schedulability

69
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
70
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..

71
From Clements etal
72
From Clements etal
73
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

74
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 Same as in CC types of data, data performance, data distribution
Topology Data accessors are attached to connectors that are attached to stores
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 CC types of data, data performance, data distribution
Topology Data accessors are attached to connectors that are attached to stores
75
What for..

• Used when there are multiple accessors and
  persistence
• Decouple producer from consumer
• Data store performance, security, privacy,
  compatibility with other stores

76
Similarity to others

• Client-server style
• Publish-subscribe is similar without persistence

77
From Clements etal
78
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

79
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 CC
Topology All components are connected to an event distributor
80
Where to use ..

• To send events and messages to recipients
• Set of recipients are unknown can be added
  dynamically

81
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

82
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

83
(No Transcript)
84
(No Transcript)
85
(No Transcript)
86
Client-Server

• Components interact by requesting services of
  other components
• Communication is initiated by a client

87
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 CC number and type of clients, performance
Topology Unrestricted number of clients tiers
88
What for..

• Assignment of functionality is clear
• Can be independently assigned to tiers
• Can be used to argue about performance
• Example - WWW

89
Peer-to-peer

• Components interact with each other exchanging
  services
• No asymmetry as in client-server
• Connectors are bidirectional

90
Communicating-Processor Style

• Interaction of concurrently executing components
  though various connector mechanisms
• Typically used at design stage

91
From Clements etal
92
Allocation Viewtype
93
Allocation viewtype styles

• Deployment style
• Implementation style
• Work assignment style

94
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
95
Deployment style

• Elements of the CC styles are allocated to
  execution platforms

96
Deployment style summary
Elements Software element usually a process from the CC 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
97
From Clements etal
98
From Clements etal
99
Viewpacket

• Small, digestible part of a view

100
(No Transcript)