Acronyms

OMP Architecture Design Document

Version 1.5July 7, 2006

Trinity Team

Team Members:

Eunyoung Cho Minho Jeung

Kyu Hou

Document Information

Document Name Architecture Design DocumentProperty of Trinity Team Document Availability Trinity website (http://azalea.icu.ac.kr/~pos/)

Document Revisions

No Revision Date Author Comments1 0.1 May 2, 2006 Minho Jeung

Kou HouEunyoung Cho

Create initial draft

2 0.2 May 3, 2006 Kyu Hou Add allocation diagram3 0.3 May 3, 2006 Eunyoung Cho Add context diagram4 0.4 May 4, 2006 Minho Jeung Add Alternatives5 0.5 May 4, 2006 Eunyoung Cho Review Utility Tree6 0.6 May 4, 2006 Minho Jeung Review ATAM7 0.7 May 4, 2006 Minho Jeung

Kou HouEunyoung Cho

Final review

8 0.8 May 6, 2006 Poornima Bharathy

Technical review

9 1.0 May 7, 2006 Kyu Hou Revise after client meeting10 1.5 July 6, 2006 Kyu Hou Revise detail design

Architecture Design Document Trinity Team

Table of Contents

ACRONYMS............................................................................................................................................... 4

1 PROJECT OVERVIEW....................................................................................................................... 5

1.1 BACKGROUND AND CONTEXT.............................................................................................................51.2 OBJECTIVES...................................................................................................................................... 6

1.2.1 Project Objectives.................................................................................................................. 61.2.2 Architectural Objectives..........................................................................................................6

1.3 CONSTRAINTS................................................................................................................................... 61.3.1 Technical Constraints.............................................................................................................61.3.2 Business Constraints..............................................................................................................6

1.4 REQUIREMENTS................................................................................................................................. 61.4.1 Major functional requirements of the project..........................................................................61.4.2 Non Functional (quality attribute) requirements of the project................................................7

2 OUTPUT OF ATAM........................................................................................................................... 8

2.1 PRIORITIZED UTILITY TREE(TABLE)....................................................................................................8

3 DESCRIPTION OF ARCHITECTURE.............................................................................................11

3.1 ARCHITECTURAL DECISION..............................................................................................................113.1.1 Division between stream data and node configuration data.................................................113.1.2 Using Event Bus for notifying the node configuration changes............................................113.1.3 Providing a Text based UI....................................................................................................113.1.4 Using dynamic memory for storing stream data and node information.................................113.1.5 Applying different communication protocol for each data type (TCP for node data transmission and UDP for stream data transmission).......................................................................113.1.6 Supporting dynamic nodes configuration by heart beating parent nodes.............................11

3.2 C&C VIEW : COMPOSITE STYLE......................................................................................................113.3 MODULE VIEW : LAYERED STYLE.....................................................................................................153.4 ALLOCATION VIEW: DEPLOYMENT STYLE..........................................................................................173.5 MAPPING BETWEEN ARCHITECTURAL VIEWS.....................................................................................18

4 ARCHITECTURAL DECISION BASED ON QA SCENARIO...........................................................20

4.1 KEY ARCHITECTURAL DECISIONS.....................................................................................................204.2 EVALUATE POSSIBLE ALTERNATIVES................................................................................................21

4.2.1 Socket Programming vs. RPC..............................................................................................214.2.2 Explicit Invocation vs. Implicit Invocation..............................................................................224.2.3 Dynamic memory vs. Non-volatile memory..........................................................................24

4.3 TRADEOFF SUMMARY...................................................................................................................... 26

5 FUTURE EXTENSION..................................................................................................................... 28

6 ATAM PROCESS EVALUATION.....................................................................................................29

6.1 REFLECTION OF USING ATAM ON OUR ARCHITECTURE DESIGN (SECTION 3).....................................29

7 REFERENCES.................................................................................................................................. 31

APPENDIX – QA SCENARIOS.................................................................................................................32

ICU & CMUMaster of Software Engineering Last Updated: 4/10/20232005-2006

3/39


Acronyms

ADD Architecture Design DocumentATAM Architecture Tradeoff, Analysis MethodCMU Carnegie Mellon UniversityC&C Component and ConnectorMSE Master of Software EngineeringN-DVR Next Generation Digital Video RecorderOMP Overlay Multicast ProtocolOS Operating SystemQA Quality AttributeRPC Remote Procedure CallSEI Software Engineering InstituteTCP Transmission Control ProtocolUDP User Datagram ProtocolUI User Interface


4/39

http://www.sei.cmu.edu/


1 Project Overview

1.1 Background and Context

The major stakeholder in this project is POSDATA Co., Ltd. (POSDATA), an IT service provider. With the advent of the ubiquitous era, POSDATA is going a step further than just providing IT services (which consists of System Integration and outsourcing services) by actively providing strategic business solutions for the future. POSDATA now extends their business area to DVR (Digital Video Recorder), which allows users to monitor, store, and control video streaming of images in real time from a remote location through wide area network.

POSDATA wishes to enlarge the DVR system to the N-DVR (Next generation Digital Video Recorder) system. A major objective of the N-DVR system is that many users should be able to audit the traffic status via the N-DVR system at the same time. Currently, if many users attempt to watch the traffic status concurrently, the visual image will not be shown smoothly because the bandwidth of the Internet might exceed the limit caused by large data transaction. Thus, it is necessary to reduce network load because POSDATA has many branches and factories across Korea.

The client will apply a new protocol to N-DVR where N-DVR will be used to transfer video streaming in an in-house broadcasting system or a factory monitoring system. Applying OMP (Overlay Multicast Protocol) to N-DVR will provide added value to POSDATA as they continue to provide IT solutions and seek to improve their business operations as the Figure 1.

Video StreamViewer

N-DVRServer

OMPAdministrator

(Console)

N-DVR Administrator

(Console)

OMP Control

MulticastAPI

OMP Status

Multicast API

OMPOMP Control

: Server LayerExternal Entity

(stakeholders)

:Client LayerExternal Entity(stakeholders)

OMP Interface

Legend:

: OMP Boundary

OMP Status

Figure 1: Context Diagram of OMP


5/39


1.2 Objectives

1.2.1 Project Objectives

Apply OMP to the OMP Server in order to provide efficient video streaming to clients Solve the network congestion problem that occurs when many clients attempt to view the

stream at the same time via the OMP Server

1.2.2 Architectural Objectives

Evaluate the architecture for OMP with N-DVR according to how well the quality attributes pertaining to the studio objectives mentioned above are addressed and representative of the business drivers for POSDATA.

Develop and Prioritize Quality Attribute Scenarios Conduct an ATAM Evaluation on the architecture for POSDATA

1.3 Constraints

1.3.1 Technical Constraints

Hardware constraints: Use Linux Server and Windows (Operating System) Clients Development Software: C++

1.3.2 Business Constraints

The OMP will run in Linux environment in the OMP server. The client OS is Window 2000 or XP.

1.4 Requirements

1.4.1 Major functional requirements of the project

Group configuration: A group consists of dynamic members (logging into and out of network in real time) that dynamically share data where each group has a unique group id.

Member configuration Each member of a group (as described above in Group Management) can be registered or unregistered at any time.

Multicast routing: The data should be transmitted through an optimized path.


6/39


Data replication: Each parent node (which could be a router for example) in a group should duplicate incoming data according to number of child nodes it possess.

1.4.2 Non Functional (quality attribute) requirements of the project

Performance: The client should be able to watch the video stream within 5 seconds of the request for the stream.

Usability: The configuration of group or group members should be user friendly. Moreover, the system should provide POSDATA with a workable user interface(UI) to manage the network

Security: Access of unregistered users should not be allowed.

Portability: The system should be able to work on diverse hardware and software platforms existing on connecting client nodes.

Modifiability: The system should be able to provide enhanced security requirements that may come from POSDATA client in the future.


7/39


2 Output of ATAM

2.1 Prioritized Utility Tree(Table)

Quality Attributes

Attribute Concerns/Characterization

Quality Attribute Scenarios Rank (I, D)*

Performance Response Time in communication between OMP server and client

A video stream (internal) event is sent from the OMP server to the client during normal operating conditions. The client receives the video stream within 5 seconds of its dispatch from the OMP server using the maximum available bandwidth with 11 Mbps.

(H, M)

Ability of OMP server to cater to many clients

A video stream (internal) event is sent from the OMP server to a number of clients during normal operating conditions. The number of clients receiving the video stream are predefined number 100 from the OMP server using the maximum available bandwidth with 11 Mbps.

(H, H)

Usability Ability of user to see the data group management information using a text-based user interface at the OMP server

The user commands the OMP server to show the snapshot of data group management information (connection link between inter-networked nodes and performance data) using a text-based user interface at runtime. The OMP server generates the data group management information for an existing 100 clients at the instant of time the user gives the commands.

(L, L)

Security Ability of OMP to provide security by enabling only authorized users to access the system

A user who is not authorized (has nothing to do the N-DVR technology from within or outside POSDATA) tries to access the data group management information when the OMP server is connected and on-line. The OMP server blocks the authorized user access, and warns the user of an audit trail and his improper access to the system. The OMP server provides a continuous audit trail for the system.

(M, L)


8/39


Quality Attributes

Attribute Concerns/Characterization

Quality Attribute Scenarios Rank (I, D)*

Ability of system to provide security of data transmitted between clients and OMP server

A new authorized client node tries to connect to the OMP server to access the video stream data when the OMP server is connected and on-line. The OMP server provides the authorized client node with a video stream data using an encryption/decryption algorithm for data transmission and a 128 bits encryption standard.

(M, M)

Availability Ability of the system to address failure of data transmission between network nodes and between the OMP server and client nodes

An unanticipated failure of transmission message is received at the OMP server (informing that link(s) may be broken or a video stream data could not be sent between client nodes) during normal operation. The OMP server tries to reestablish the transmission of video stream between the appropriate client nodes within 5 seconds and logs the failure of transmission message with performance information and continues in normal mode.

(H, H)

Portability

Ability of the system to work on diverse hardware and software platforms existing on connecting client nodes

New authorized clients having different hardware (different speed Intel processors) and software (different OS like Linux, Windows XP, etc) try to connect to the OMP server in normal operation. The OMP server should provide the heterogeneous connecting clients with the video stream data and provide connection within 5 seconds of the client request.

(M, L)

Modifiability Ability of the system to provide enhanced security requirements that may come from POSDATA client in the future.

A new authorized client node tries to connect to the OMP server to access the video stream data when the OMP server is connected and on-line. The OMP server provides the authorized client node with a video stream data using a superior custom built encryption/decryption algorithm (which may become an industry standard in the future) for data transmission and an 128 bits encryption standard.

(M, L)


9/39


* I: Relative Importance of the quality attribute scenario to the projectD: Difficulty for the architecture to satisfy quality attribute scenario


10/39


3 Description of Architecture

3.1 Architectural Decision

3.1.1 Division between stream data and node configuration

Node configuration data are information about nodes’ topology. In order to control stream data and node configuration data fast and reliably (i.e. with availability), OMP system divide the two types of data and control each type separately.

3.1.2 Using Event Bus for notifying the node configuration changes

In each node, there exists an event bus to handle node configuration change and make a request for another node as a parent. The event bus makes the system ensure adding and deleting node configuration related component more easily.

3.1.3 Providing a Text based UI

Instead of applying GUI, the OMP system provides text based UI for managing node configuration data at the server.

3.1.4 Using dynamic memory for storing stream data and node information

Because OMP is based on peer-to-peer communication, it is very likely to join and disjoin the OMP system. For that reason, OMP system should be able to handle both stream data and configuration data by using dynamic memory.

3.1.5 Applying different communication protocol for each data type (TCP for node data transmission and UDP for stream data transmission)

Because correct node information is curtail for reliable data transmission from end to end, the information should guarantee whether the request for node information has been reached correctly or not; however, the stream transmission point of view, the transmission speed is more important so than different protocol should be used in stream data transmission.

3.1.6 Supporting dynamic nodes configuration by heart beating parent nodes

For responding dynamic node configuration, OMP adapts heart beating for checking parent node’s live. In case of a parent node’s failure to response in a certain amount of time, the child node announces the error event and let server communicator try to get the new parent node.

3.2 C&C View : Composite Style

C&C styles specialize the C&C viewtype by introducing a specific set of component-and-connector types and by specifying rues about how elements of those types can be combined [Paul2003]. Additionally, given that C&C views capture runtime aspects of a system, a C&C style is typically also associated with a pattern of interaction that prescribes how computation, data, and control flow through systems [Paul2003].


11/39


Figure 2: C&C architecture diagram of OMP

Based on above C&C style description, the C&C view of OMP describes dynamic behavior of OMP system; join and rejoin as well as data transmission that frequently happened in OMP environment.

Among several C&C viewtype, the Figure 2 combines peer-to-peer, client-server and publish-subscribe style.

In the peer-to-peer style of the C&C viewtype, components directly interact as peers by exchanging services [Paul2003]. In OMP system, each node should keep the information where which node is its parent and which nodes are its child while communicating with surrounded nodes. Because of the dynamic change of node configuration, a node can directly communicate any node while constructing stream path.

In the client-server style of the C&C viewtype, servers provide a set of services though one or more interfaces and clients use zero or more services provided by other servers in the system


12/39


[Paul2003]. The OMP system C&C view architecture follows the client-server style in that the OMP server provides node information and video stream to clients.

The publish-subscribe style is used in the each nodes for dynamic node configuration. The event bus and surrounded components in the figure 2 represents the publish-subscribe style. The style minimizes the dependency among procedures so that the system improves modification. The below table explains each element of the C&C view in detail.

Element Description

Stream Controller The main role of Stream Controller is sending and receiving stream data. Each node may transmit more than one node so that the Stream Controller duplicates the stream as much as the child nodes that the node has. In addition, the Stream Controller stores the video stream in a dynamic memory area so that each node receives the video stream regardless of the network speed.

OMP Handler OMP Handler sets the OMP configuration or changes the configuration file and shows the current node configuration.

Node Handler Node Handler receive join request from client nodes. A client node asks for joining OMP when the node is a new participant or the parent node of the node has disjoined. Once Node controller receives the request, the Node Handler sends the information to node finder.

Node Finder Node Finder plays a role in finding the nearest node of the node that make a request for join. Once the Node Finder find the nearest node, the information are transmitted to the parent node so that the parent node can send the video stream to the new child node.

Node Configuration Manager

Node Configuration Manager located in each client node deals with node information of its child node and a parent node. Whenever the node information has been change, the node configuration manager announces or receives an event.

Parent Node Checker

Parent Node Checker periodically (heart beating) checks the status of the parent node of the node. Once the parent node does not reply in a certain period of time or the parent node return network connection exception, the parent node checker announce an event to the event bus.

Server Communicator

Server Communicator takes charge of communication between server and each node. In case of a node wants to join the OMP or need to another


13/39


parent node because of the disconnection with the parent node, Server Communicator receives an event from event bus and make a connection for join request.

Video Adapter Video Adapter is for sending video stream to third parties viewer application so that each node can watch the incoming stream using the viewer.


14/39


3.3 Module View : Layered Style

Module view represents modular structures of a system’s software which includes implementation units, or modules, of a system, together with the relationships among these units [Paul2003].

Layers completely partition a set of software, and each partition constitutes a virtual machine-with a public interface- that provides a cohesive set of services [Paul2003].

Figure 3: Module view of OMP

Layer Description

Legacy applications Legacy applications are application running on the OMP server which are outside of our project scope.

Viewer applications Viewer applications are third party’s application for viwer. The applications use OMP interface for watching video stream via the viewer.

Node management Node management user interface is for monitoring the nodes information


15/39


user interface of OMP and also for setting node configuration.

OMP interface OMP interface layer consists of set of interfaces supported by OMP system. The outside of the OMP system can interact with OMP via the interface.

User authentication This layer blocks unauthorized users.

Security utilities Encoding and decoding utilities prevent from exposing data to the public without data protection, and also this layer support blocking unauthorized users.

Node configuration utilities

In the node configuration utilities, node information is updated dynamically and optimizes the node path.

Node communication utilities

Node communication utilities are for communicating with node to node or node to server.

Stream data transmission utilities

The utilities play a role in duplicating data for child nodes as well as sending or receiving data.


16/39


3.4 Allocation View: Deployment Style

Figure 4: Allocation view of OMP

Allocation view maps the software architecture to its environment. The view presents a mapping from the elements of either a module or a component-and-connector style onto elements of the environment [Paul2003].

The deployment style describes the mapping of the components and connectors onto the hardware on which the software executes [Paul2003].

In OMP, this viewtype reveals which components are deployed in server or client and what the boundary hardware system that is related with OMP system is. In addition it describes the operating system for each system and different network protocol for different service.

Device or Component

Description


17/39


Surveillance cameras Cameras on the road for auditing traffic flow or speeding. The cameras are distributed.

WEB-TX Digital converter for video stream. It converts analog video stream and send either directly to the OMP server or data storage for future usage.

Storage Data storage for recording video stream. It receives data from WEB-TX. If OMP server request recorded data, the storage sends the video data to the server.

OMP Server Next generation Digital Video Recorder Server. OMP sever application runs on the server. In the server, there exists legacy application and some of them such as viewer interact with OMP applications.

Client PC End user’s PC. The node applications run on the client PC. Each client PC on the OMP system generates structure in order to receive video stream from OMP server via another client PC.

3.5 Mapping between Architectural Views

The table mentioned below defines the architectural mapping between the three views namely the C&C view, the module view and the allocation view. The mapping completes the architectural description by mentioning how each of the three view maps to the other two.

The mapping between the views is given below:

C&C View (Component Name)

Module View

(Layer Name)

Allocation View (Physical machines on which C&C

objects may exist)

Stream controllerStream data transmission utilities OMP server

Node controller Node info communication utilities OMP server

Server communicator Node info communication utilities Client

Node finder Node configuration utilities OMP server

Node configuration manager

Node configuration utilities Client

Parent node checker Node configuration utilities Client

Viewer adapter OMP Interface Client

OMP handler OMP interface OMP server

Security handler Security utilities Client, server


18/39


3.6 Detailed Design

3.6.1 Class Diagram


19/39


3.6.2 Sequence Diagram

1) Sequence diagram about transmitting packet message and data between server and client node


20/39


2) Sequence diagram based on TBCP algorithm


21/39


4 Architectural Decision based on QA Scenario

In this section, we analyze top three quality attribute scenarios based on the utility tree. Other scenarios are available in appendix section.

4.1 Key Architectural Decisions

Based on the architectural decisions taken before, the team found some key architectural alternatives. These decisions are mentioned below:

A1: Using of RPC to Socket Programming for connecting the clients with the OMP server.

The team found that the connection (join) and disconnection (leave) of the client nodes with the OMP server is an important step on the project. The same step can be accomplished by using the socket programming or RPC technology. The socket programming technique requires low level network programming and provides a portable solution. In the RPC approach one does not need to consider the network configuration aspect and only need to focus on the end application but RPC is not as portable as the socket solution.

A2: Using the Explicit Invocation style for managing control information (and other node configuration information) to the Implicit Invocation style to accomplish the same operations.

The team found that the current architectural descriptions could support both the implicit and the explicit style for communication when managing control information internally within the nodes. Although in the explicit communication style each caller knows the identity of the target caller, yet in the implicit invocation style each caller may make an announcement for the callee and wait for the callee’s response. The callee does not get to know the identity of the caller and simply respond to the call.

A3: Using the static non volatile storage like hard disk drives, tapes etc in place of the dynamic volatile storage memory as used by for storing the network (node configuration) control information and also the video stream data.

The team found that there was a situation where one could use the static and non-volatile storage (like hard disks or tape drives) within each of the clients that stored the network management information and also the video stream data in place of the dynamic and volatile storage scheme. The advantage of using dynamic storage is that it consumes no storage space (only dynamic runtime storage) whereas the static storage requires expenditure of space. But as far as reliability is concerned, static storage can remember stored network configurations and recover from nuisances of power failures or interrupts (although being a bit slow), yet dynamic storage (being faster) lacks this reliability feature. In dynamic storage the information is lost when there is a power outage or interruption.


22/39


4.2 Evaluate Possible Alternatives

4.2.1 Socket Programming vs. RPC

Scenario

A video stream (internal) event is sent from the OMP server to the client during normal conditions. The client receives the video stream within 5 seconds of its dispatch from the OMP server using the maximum available bandwidth with 11 Mbps.

Business Goal(s)

The effective bandwidth and cost-saving video stream service of traffic surveillance and company broadcasting system in WAN area

Attribute PerformanceAttribute Concern

Response Time in communication between OMP server and client

Scenario Refinement

StimulusVideo stream event it sent from the N-DVR and arrives at the client

Stimulus Source

OMP server

Environment Normal conditionsArtifact Video stream

ResponseVideo stream is processed from the OMP server to the client.

Response Measure

The client receives the video stream within 5 seconds of its dispatch from the OMP server using the maximum available bandwidth with 11 Mbps.

Architectural Decision Sensitivity Tradeoff Risk

1.Using of RPC to Socket Programming 1 1 12.Using Explicit Invocation style for managing control information (and other node configuration information) in place of using the Implicit Invocation Style

2 2

3.Using the static non volatile storage like hard disk drives, tapes etc in place of the dynamic volatile storage memory

3 3

SENSITIVITY POINTS:1. In both cases the effect to performance is positive. In both cases the performance would

be increased. The RPC is better off as far as network low level programming effort is concerned when compared with Socket programming.


23/39


2. The implicit invocation style is less contributing to performance than the explicit invocation style because of its inherent announcement and response style of operation. The use of explicit invocation style will improve performance

3. The performance is affected in both the cases although for dynamic case it may be increase where as in the static case it is decreased in general due to slowness of static read and write operations to the memory.

TRADEOFFS:1. Performance (+) Versus Portability (-)The performance is comparable whereas the portability is decreased on account of using the RPC mechanism as all systems may not be able to support stubs and registry concept.

RISKS:1. The RPC technology or the Socket technology may not be able to cater to video stream

data with a 5 second of network latency; the technology may not be able to satisfy the non functional requirement of performance and may not meet team or client expectations.

2. The implicit invocation style is slower in performance than the explicit invocation style; the performance quality attribute may not be met by the implicit invocation style of operation.

3. The static storage device may not be able to meet the 5 seconds network latency requirement; the architectural decision may not be able satisfy the quality requirement.

REASONING:1. The team made the architectural decision of trying RPC to Socket programming because

the RPC technology doesn’t require one to setup the network programming effort that the socket option may provide. Although the RPC technology may not be portability wise better than Socket option but it saves on the network programming cost and is performance wise comparable to the Socket solution.

2. The explicit invocation style was selected by the team as performance wise it performs better than the implicit invocation style and also it is more available and reliable with respect to failure.

3. The use of static memory in place of dynamic memory makes the network more available with respect to the failures like power loss or interruptions etc. This enabled the team to go for this alternative over the other performance alternative of dynamic memory usage.

CONCLUSION:The team decided for these architectural choices as the team considers that availability is a higher ranked attribute when it comes to tradeoff between performance and availability and the current solution provides for the same availability.

4.2.2 Explicit Invocation vs. Implicit Invocation

Scenario A video stream (internal) event is sent from the OMP server to a number


24/39


of clients during normal conditions. The number of clients receiving the video stream are predefined number 100 from the OMP server using the maximum available bandwidth with 11 Mbps.

Business Goal(s)


Attribute PerformanceAttribute Concern

Ability of OMP server to cater to many clients

Scenario Refinement

StimulusVideo stream event it sent from the N-DVR and arrives at many clients

Stimulus Source

OMP server

Environment Normal conditionsArtifact Video stream

ResponseVideo stream is processed from the OMP server to many clients.

Response Measure

The number of clients receiving the video stream are predefined number 100 from the OMP server using the maximum available bandwidth with 11 Mbps.


1.Using of RPC to Socket Programming 1 1 12.Using Explicit Invocation style for managing control information (and other node configuration information) in place of using the Implicit Invocation Style

2


3 2

SENSITIVITY POINTS:1. In both cases the effect to performance is positive. In both cases the performance would

be increased. The RPC is better off as far as network low level programming effort is concerned when compared with Socket programming.

2. The implicit invocation style is less contributing to performance than the explicit invocation style because of its inherent announcement and response style of operation. Here the performance is in terms of the number of clients which get access over the allowable bandwidth.

3. The performance is affected in both the cases although for dynamic case it may be increase where as in the static case it is decreased in general due to slowness of static read and write operations to the memory.

TRADEOFFS:1. Performance (+) Versus Portability (-)


25/39


The performance is comparable whereas the portability is decreased on account of using the RPC mechanism as all systems may not be able to support stubs and registry concept.

RISKS:1. The RPC technology or the Socket technology may not be able to cater to video stream

data to 100 or more clients; the technology may not be able to satisfy the non functional requirement of performance and may not meet team or client expectations.

2. The static storage device may not be able to meet the 100 or more client requirement within the allowable bandwidth; the architectural decision may not be able satisfy the quality requirement.

REASONING:1. The team made the architectural decision of trying RPC to Socket programming because

the RPC technology doesn’t require one to setup the network programming effort that the socket option may provide. Although the RPC technology may not be portability wise better than Socket option but it saves on the network programming cost and is performance wise comparable to the Socket solution.

2. The explicit invocation style was selected by the team as performance wise it performs better than the implicit invocation style and also it is more available and reliable with respect to failure.


CONCLUSION:The team decided for these architectural choices as the team considers that availability is a higher ranked attribute when it comes to tradeoff between performance and availability and the current solution provides for the same availability.

4.2.3 Dynamic memory vs. Non-volatile memory

Scenario

An unanticipated failure of transmission message is received at the OMP server (informing that link(s) may be broken or a video stream data could not be sent between client nodes) during normal operation. The OMP server tries to reestablish the transmission of video stream between the appropriate client nodes within 5 seconds and logs the failure of transmission message with performance information and continues in normal mode.

Business Goal(s)


Attribute AvailabilityAttribute Concern

Ability of the system to address failure of data transmission between network nodes and between the OMP server and client nodes

Scenario Stimulus An unanticipated failure of transmission message is


26/39


Refinement

receivedStimulus Source

Internal to the system(omission failure that is components to fail to respond to input)

Environment During normal operationArtifact Communication processes between client nodes

ResponseThe OMP server tries to reestablish the transmission of video stream between the appropriate client nodes.

Response Measure

Within 5 seconds and logs the failure of transmission message with performance information and continues in normal mode


1.Using of RPC to Socket Programming 1 1,2 12.Using Explicit Invocation style for managing control information (and other node configuration information) in place of using the Implicit Invocation Style

2


3 3

SENSITIVITY POINTS:1. In the RPC technology the availability is more as compared to the Socket programming.

This is because in the RPC technology there is no need of network programming and thus due to the lack of human effort in the networking programming area (which is present in Socket technology), the RPC technology would cause less failures and becoming more available.

2. The explicit invocation style is more available than the implicit style as the use of the explicit style provides a better response on tracking the failures due to transmissions as one easily knows where the packets are flowing (i.e. the caller and callee are predefined).

3. The static memory option provides a more reliable alternative which is more available as states are stored and information is not easily lost even in case of network or other types of failures.

TRADEOFFS:1. Availability (+) Versus Portability (-)The availability is increased whereas the portability is decreased on account of using the RPC mechanism as all systems may not be able to support stubs and registry concept.

2. Availability (+) Versus Performance (-)The availability is more as information flow in an RPC is well defined without low level network programming, but due to the processing of the responses in stubs and registry the option may not perform well in terms of performance where the Socket option would prove to perform better.


27/39


3. Availability (+) Versus Performance (-)The static storage makes the system more available but also caters to decreasing the performance to an extent. This decrease on account of performance is due to the slow read and writes in static non-volatile storage devices.

RISKS:1. The availability may be decreased on the use of RPC as the people may not be aware of

the operations of RPC at the grass root levels; the quality attribute may not be met with the alternative

REASONING:1. The team made the architectural decision of trying RPC to Socket programming because the RPC

technology doesn’t require one to setup the network programming effort that the socket option may provide. Although the RPC technology may not be portability wise better than Socket option but it saves on the network programming cost and is availability wise better to the Socket solution.

2. The explicit invocation style was selected by the team as availability wise it performs better than the implicit invocation style and also it is more available and reliable with respect to failure.


CONCLUSION: The team decided for these architectural choices as the team considers that availability is a higher ranked attribute when it comes to tradeoff between performance and availability and the current solution provides for the same availability.

4.3 Tradeoff Summary

The table given below defines the tradeoff summary between quality attributes that the team selected and the architectural alternatives that the team considers for the project. The table clearly depicts what quality attributes are promoted / not promoted by the respective architectural decisions. The columns of the table define the various architectural alternatives and the rows list the quality attributes with respect to those architectural alternatives. The table is given below

Quality Attributes 1.Using of RPC to Socket Programming

2.Using Explicit Invocation style for managing control information (and other node configuration information) in place of using the Implicit Invocation Style


Performance (Time or response)

+ + -

Performance (Number + + -


28/39


of clients)Availability (No failure anywhere)

+ + +

Portability (Ability to work on different platforms)

- - +

The table given above shows that the availability (which one of the most desirable features on the project by the team) is greatly enhanced by all the 3 governing architectural alternatives. The performance quality is also promoted for most part of the decisions. As the team considers that the availability quality is most desired (as compared to any other quality attribute like performance and portability), the architectural alternatives are sound with respect to the desired quality attributes.


29/39


5 Future Extension

As a future alternative the project could be extended on three counts:

1. Provide an N:N server to client multicast connectivity in place of an existing and demanded 1:N sever to client multicast connectivity. Thus, in place of a single OMP server, the project could be enlarged to a number of OMP servers in a distributed environment and the architectural decisions taken by the team have been taken to keep this modifiability aspect into account.

2. Provide a better encryption/decryption standard of security in the future when such a standard is available. The existing security mechanism according to the client should exist for a 128 bits encryption/decryption algorithm and should be extendable for any standard that provides for more than the 128 bits (of the current standard). The quality attribute of modifiability (also mentioned in the utility tree) and broken down into six parts caters to this scenario. The team took into account this modifiability to security feature of providing enhanced security when dealing with the quality attributes for the project.

3. Provide a base architecture for embedded OMP system in which OMP system is ported into specific embedded system so that the embedded system directly interacts with nodes without OMP server. In order for the current OMP system design to adopt a embedded system, several hardware constraints such as memory and CUP speed should be solved.

Thus, based on the quality attributes and their analysis and also the architectural decisions taken by the team, the future extensions to the OMP system look promising and doable by the future MSE teams.


30/39


6 ATAM Process Evaluation

6.1 Reflection of using ATAM on our Architecture Design (Section 3)

ATAM, (Architecture Tradeoff Analysis Method), is a technique used to discover quality attributes and evaluate architectural decisions based on those quality attributes. Although the full process of ATAM may take sometime, in the modified ATAM approach the team prepared a project overview that described functional requirements, quality attributes and the constraints as spelled out by our client on the project. The utility tree was made and the quality attributes were broken down into the six constituting parts and then prioritized by the team based on relative Importance of the quality attribute scenarios to the project and the difficulty for the architecture to satisfy quality attribute scenarios. The quality attribute scenarios were further discussed with our esteem faculty for the course, Professor Tony Lattanze, who also happens to be the expert on the subject and a member of senior staff at the SEI. Later the team evaluated the architectural alternatives for the sensitivity, tradeoffs and risks based upon the high priority quality attribute scenarios.

The ATAM process produces the following important points of reflection:

1. The process of utility tree generation enabled the team to think about not only the quality attributes that were important to the project but state well defined (having six identified parts) scenarios for the same qualities. The team discovered that while defining a large number of qualities in terms of scenarios, they needed to confirm some facts and figures with the client. The justification of the numbers like 11 Mbps of bandwidth and 100 clients (and not “N”) gave some food for thought for the team.

2. The team decided on some architectural decisions and created the architectural diagrams (the three views of the C&C, Module and the Allocation). After the creation of the views and the further discussion within the team and the faculty in Professor Tony Lattanze, the team found that there could be alternative strategies to the architectural decisions and this enabled the team to look for alternative architectures and points for their support with respect to the discovered quality attributes.

3. The focus on finding the sensitivity points, the tradeoffs and the risks based on the quality attributes scenarios and the alternative architectural strategies enabled the team to gain an understanding on what basis their architectural decisions would benefit the project and enable the team to satisfy the qualities desired by the client.

The ATAM process was productive but it could be considered counter productive on the following points:

1. The ATAM process was very expensive in terms of the time spent on carrying out the process. The assessment of the quality attributes in terms of the scenarios (i.e. developing the utility tree)


31/39


took a large amount of time. After this the team spent a large amount of time considering the architectural decisions with respect to the quality attribute scenarios. Due to the same time constraints the team decided to evaluate only the most important architectural decisions and the alternatives with respect to the highest ranked quality attribute scenarios.

As a conclusion, we realized that the ATAM process though demanding in effort is an excellent technique to establish quality attributes (and their breakdown into scenarios) and also evaluate project’s architectural alternatives and key architectural decisions with respect to the scenarios of the maximum priority. ATAM process ensured and provided for a sound architectural development approach on our MSE project


32/39


7 References

[Paul2003] Clements P.; Bachmann F.; Bass L.; Garlan D.; Ivers J., Little R., Nord R., Stafford J. Documenting Software Architectures: Views and Beyond, Addison-Wesley 2003.

[Keum 2005] Chang Sup Keum et al., Software Architecture for TestGen, Team TTA / Rolling Final Project, April 27, 2005

[Kazman2000] R. Kazman, M. Klein, P. Clements, ATAM: Method for Architecture Evaluation, CMU/SEI-2000-TR-004

[Garlan2003] Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, Stafford, Documenting Software Architectures – Views and Beyond, Addison-Wesley, 2003

[SRS] Software Requirements Specification – Trinity Team , Trinity_SRS_V1.0.doc, Mar., 2006


33/39


Appendix – QA ScenariosBelow scenarios are not covered the section 4. Even though that scenario was not mentioned before, the all scenarios are considered when our team makes an architectural decision.

Usability

Scenario

The user commands the OMP server to show the snapshot of data group management information (connection link between inter-networked nodes and performance data) using a text-based user interface at runtime. The OMP server generates the data group management information for an existing number up to 100 of clients at the instant of time the user gives the commands.

Business Goal(s)


Attribute UsabilityAttribute Concern

Ability of user to see the data group management information using a text-based user interface at the OMP server

Scenario Refinement

StimulusThe user commands the OMP server to show the snapshot of data group management information.

Stimulus Source

N-DVR end user

Environment At runtimeArtifact Data group management information

ResponseThe OMP server provides to generate data group management information.

Response Measure

The OMP server generates the data group management information for the existing 100 clients at the instant of time the user gives the commands.


1. Division between stream data and node configuration data2. Using Event Bus for notifying the node configuration changes3. Providing a Text based UI

11. U1+S1-2. U1+PO1-

1

4. Using dynamic memory for storing stream data and node information

2 3. U1+S1-4. U1+PO1-

5. Applying different communication protocol for each data type (TCP for node data transmission and UDP for stream data transmission)

6. Supporting dynamic nodes configuration by heart beating parent nodes


34/39


* U1: Usability scenario 1, S1: Security scenario1, PO1: Portability scenario 1

Security

Scenario

A user who is not authorized (has nothing to do the N-DVR technology from within or outside POSDATA) tries to access the data group management information when the OMP server is connected and on-line. The OMP server blocks the authorized user access, and warns the user of an audit trail and his improper access to the system. The OMP server provides a continuous audit trail for the system.

Business Goal(s)


Attribute SecurityAttribute Concern

Ability of N-DVR to provide security by enabling only authorized users to access the system

Scenario Refinement

StimulusA user tries to access the data group management information

Stimulus Source

An unauthorized user

Environment The OMP server is connected and on-lineArtifact The data group management information

ResponseThe OMP server blocks the authorized user access, and warns the user.

Response Measure

The OMP server provides a continuous audit trail for the system.


1. Division between stream data and node configuration data

1 1. S1+U1-2. S1+M1-

2. Using Event Bus for notifying the node configuration changes3. Providing a Text based UI4. Using dynamic memory for storing stream data and node information5. Applying different communication protocol for each data type (TCP for node data transmission and UDP for stream data transmission)

2 3. S1+M1- 1

6. Supporting dynamic nodes configuration by heart beating parent nodes* U1: Usability scenario 1, S1: Security scenario1, M1: Modifiability scenario 1


35/39


Scenario

A new authorized client node tries to connect to the OMP server to access the video stream data when the OMP server is connected and on-line. The OMP server provides the authorized client node with a video stream data using an encryption/decryption algorithm for data transmission and a 128 bits encryption standard.

Business Goal(s)


Attribute Security

Attribute Concern

Ability of system to provide security of data transmitted between clients and OMP server

Scenario Refinement

StimulusA new authorized client node tries to connect to the OMP server.

Stimulus Source

A new authorized client

Environment Connected and on-lineArtifact Video stream data

ResponseThe OMP server provides the authorized client node with a video stream data.

Response Measure

The OMP server uses an encryption/decryption algorithm for data transmission and a 128 bits encryption standard.



1 1. S2+P1-2. S2+A1-3. S2+M1-

1

2. Using Event Bus for notifying the node configuration changes3. Providing a Text based UI4. Using dynamic memory for storing stream data and node information

2 4. S2+P1-5. S2+A1-6. S2+M1-


3 7. S2+PO1-8. S2+A1-9. S2+M1-

2


4 10. S2+P1-11. S2+A1-12. S2+M1-

* S2: Security scenario2, PO1: Portability scenario1, P1: Performance scenario1, M1: Modifiability scenario 1, A1: Availability scenario1


36/39


Portability

Scenario

New authorized clients having different hardware (different speed Intel processors) and software (different OS like Linux, Windows XP, etc) try to connect to the OMP server in normal operation. The OMP server should provide the heterogeneous connecting clients with the video stream data and provide connection within 5 seconds of the client request.

Business Goal(s)


Attribute PortabilityAttribute Concern

Ability of the system to work on diverse hardware and software platforms existing on connecting client nodes

Scenario Refinement

StimulusHaving different configuration try to connect to the OMP server

Stimulus Source

New authorized clients

Environment In normal operationArtifact Video stream data

ResponseThe OMP server should provide the heterogeneous connecting clients with the video stream data.

Response Measure

The OMP server provides connection within 5 seconds of the client request.


1. Division between stream data and node configuration data2. Using Event Bus for notifying the node configuration changes 1

1. PO1+P1-2. PO1+A1-3. PO1+M1-

1

3. Providing a Text based UI 2 4. PO1+M1-4. Using dynamic memory for storing stream data and node information

3 5. PO1+P1-6. PO1+A1-

2


4 7. PO1+P1-8. PO1+M1-

6. Supporting dynamic nodes configuration by heart beating parent nodes* PO1: Portability scenario 1, P1: Performance scenario 1, S2: Security scenario2, M1: Modifiability scenario 1, A1: Availability scenario 1


37/39


Modifiability

Scenario

A new authorized client node tries to connect to the OMP server to access the video stream data when the OMP server is connected and on-line. The OMP server provides the authorized client node with a video stream data using a superior custom built encryption/decryption algorithm (which may become an industry standard in the future) for data transmission and the 128 bits encryption standard.

Business Goal(s)


Attribute ModifiabilityAttribute Concern

Ability of the system to provide enhanced security requirements that may come from POSDATA client in the future.

Scenario Refinement

StimulusA new authorized client node tries to connect to the OMP server.

Stimulus Source

A new authorized client

Environment Connected and on-lineArtifact Video stream data

ResponseThe OMP server provides the authorized client node with a video stream data.

Response Measure

The OMP server provides the authorized client node with a video stream data using a superior custom built encryption/decryption algorithm (which may become an industry standard in the future) for data transmission and the 128 bits encryption standard.



1 1. M1+P1-2. M1+A1-3. M1+S2-

1

2. Using Event Bus for notifying the node configuration changes3. Providing a Text based UI4. Using dynamic memory for storing stream data and node information5. Applying different communication protocol for each data type (TCP for node data transmission and UDP for stream data transmission)

2 4. M1+PO1-5. M1+A1-6. M1+ S2-

2


3 7. M1+P1-8. M1+A1-9. M1+ S2-

3


38/39


* PO1: Portability scenario 1, P1: Performance scenario 1, S2: Security scenario2, M1: Modifiability scenario 1, A1: Availability scenario 1


39/39

Acronyms

Documents

Transcript of Acronyms