View Based Documentation of Software Architectures from views

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? • C 1 calls C 2 – C 1 passes data to C 2 via its parameters – C 1 obtains a result from C 2 – C 1 causes C 2 to come into existence – C 1 cannot execute till C 2 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 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 Call Interface Executable Formats Device Drivers Virtual File System File Quota Buffer Cache Logical File System Slide 20

Components & Connector Diagrams Slide 21

Cn. C View • 1 st 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

Cn. C view FS NI MM PS Init IPC Lib Slide 23

Cn. C – 2 nd 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 one-toone 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 • P 1 uses P 2, if P 1’s correctness depend on the correctness of P 2 • 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 P 2 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 View. Type 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 datain 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