Your SlideShare is downloading. ×
Acronyms
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Acronyms

296
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
296
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. OMP Architecture Design Document Version 1.5 July 7, 2006 Trinity Team Team Members: Eunyoung Cho Minho Jeung Kyu Hou
  • 2. Document Information Document Name Architecture Design Document Property of Trinity Team Document Availability Trinity website (http://azalea.icu.ac.kr/~pos/) Document Revisions No Revision Date Author Comments 1 0.1 May 2, 2006 Minho Jeung Create initial draft Kou Hou Eunyoung Cho 2 0.2 May 3, 2006 Kyu Hou Add allocation diagram 3 0.3 May 3, 2006 Eunyoung Cho Add context diagram 4 0.4 May 4, 2006 Minho Jeung Add Alternatives 5 0.5 May 4, 2006 Eunyoung Cho Review Utility Tree 6 0.6 May 4, 2006 Minho Jeung Review ATAM 7 0.7 May 4, 2006 Minho Jeung Final review Kou Hou Eunyoung Cho 8 0.8 May 6, 2006 Poornima Technical review Bharathy 9 1.0 May 7, 2006 Kyu Hou Revise after client meeting 10 1.5 July 6, 2006 Kyu Hou Revise detail design
  • 3. Architecture Design Document Trinity Team Table of Contents ACRONYMS..............................................................................................................................................4 1 PROJECT OVERVIEW............................................................................................................................5 1.1 BACKGROUND AND CONTEXT ....................................................................................................................5 1.2 OBJECTIVES..........................................................................................................................................6 1.2.1 Project Objectives......................................................................................................................6 1.2.2 Architectural Objectives.............................................................................................................6 1.3 CONSTRAINTS........................................................................................................................................6 1.3.1 Technical Constraints................................................................................................................6 1.3.2 Business Constraints.................................................................................................................6 1.4 REQUIREMENTS......................................................................................................................................6 1.4.1 Major functional requirements of the project.............................................................................6 1.4.2 Non Functional (quality attribute) requirements of the project....................................................7 2 OUTPUT OF ATAM.................................................................................................................................8 PRIORITIZED UTILITY TREE(TABLE).................................................................................................................8 3 DESCRIPTION OF ARCHITECTURE...................................................................................................11 ARCHITECTURAL DECISION...........................................................................................................................11 3.1.1 Division between stream data and node configuration.............................................................11 3.1.2 Using Event Bus for notifying the node configuration changes................................................11 3.1.3 Providing a Text based UI........................................................................................................11 3.1.4 Using dynamic memory for storing stream data and node information....................................11 3.1.5 Applying different communication protocol for each data type (TCP for node data transmission and UDP for stream data transmission)............................................................................................11 3.1.6 Supporting dynamic nodes configuration by heart beating parent nodes ...............................11 C&C VIEW : COMPOSITE STYLE..................................................................................................................11 MODULE VIEW : LAYERED STYLE..................................................................................................................15 ALLOCATION VIEW: DEPLOYMENT STYLE........................................................................................................17 MAPPING BETWEEN ARCHITECTURAL VIEWS.....................................................................................................18 DETAILED DESIGN.....................................................................................................................................19 3.1.7 Class Diagram.........................................................................................................................19 3.1.8 Sequence Diagram..................................................................................................................20 4 ARCHITECTURAL DECISION BASED ON QA SCENARIO................................................................22 KEY ARCHITECTURAL DECISIONS .................................................................................................................22 EVALUATE POSSIBLE ALTERNATIVES..............................................................................................................23 4.1.1 Socket Programming vs. RPC.................................................................................................23 4.1.2 Explicit Invocation vs. Implicit Invocation.................................................................................24 4.1.3 Dynamic memory vs. Non-volatile memory..............................................................................26 4.2 TRADEOFF SUMMARY............................................................................................................................28 5 FUTURE EXTENSION...........................................................................................................................30 6 ATAM PROCESS EVALUATION..........................................................................................................31 REFLECTION OF USING ATAM ON OUR ARCHITECTURE DESIGN (SECTION 3).........................................................31 7 REFERENCES......................................................................................................................................33 APPENDIX – QA SCENARIOS...............................................................................................................34 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 3/40
  • 4. Architecture Design Document Trinity Team Acronyms ADD Architecture Design Document ATAM Architecture Tradeoff, Analysis Method CMU Carnegie Mellon University C&C Component and Connector MSE Master of Software Engineering N-DVR Next Generation Digital Video Recorder OMP Overlay Multicast Protocol OS Operating System QA Quality Attribute RPC Remote Procedure Call SEI Software Engineering Institute TCP Transmission Control Protocol UDP User Datagram Protocol UI User Interface ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 4/40
  • 5. Architecture Design Document Trinity Team 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. Multicast N-DVR OMP Status API Administrator N-DVR (Console) OMP Control Server OMP OMP OMP Status Multicast API Video Stream Administrator Viewer (Console) OMP Control Legend: : Server Layer :Client Layer OMP Interface External Entity External Entity : OMP Boundary (stakeholders) (stakeholders) Figure 1: Context Diagram of OMP ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 5/40
  • 6. Architecture Design Document Trinity Team 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. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 6/40
  • 7. Architecture Design Document Trinity Team • 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. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 7/40
  • 8. Architecture Design Document Trinity Team 2 Output of ATAM Prioritized Utility Tree(Table) Quality Attribute Concerns/ Quality Attribute Scenarios Rank Attributes Characterization (I, D)* Performance Response Time in A video stream (internal) event is sent (H, M) communication between from the OMP server to the client OMP server and 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. Ability of OMP server to A video stream (internal) event is sent (H, H) cater to many clients 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. Usability Ability of user to see the The user commands the OMP server to (L, L) data group management show the snapshot of data group information using a text- management information (connection based user interface at the link between inter-networked nodes and OMP server 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. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 8/40
  • 9. Architecture Design Document Trinity Team Quality Attribute Concerns/ Quality Attribute Scenarios Rank Attributes Characterization (I, D)* Security Ability of OMP to provide A user who is not authorized (has (M, L) security by enabling only nothing to do the N-DVR technology authorized users to access from within or outside POSDATA) tries to access the data group management the system 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. Ability of system to A new authorized client node tries to (M, M) provide security of data connect to the OMP server to access the transmitted between video stream data when the OMP server is connected and on-line. The OMP clients and OMP server 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. Availability Ability of the system to An unanticipated failure of transmission (H, H) address failure of data message is received at the OMP server transmission between (informing that link(s) may be broken or a video stream data could not be sent network nodes and between client nodes) during normal between the OMP server operation. The OMP server tries to and client nodes 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. Portability New authorized clients having different hardware (different speed Intel processors) and software (different OS Ability of the system to like Linux, Windows XP, etc) try to work on diverse hardware connect to the OMP server in normal and software platforms (M, L) operation. The OMP server should existing on connecting provide the heterogeneous connecting client nodes clients with the video stream data and provide connection within 5 seconds of the client request. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 9/40
  • 10. Architecture Design Document Trinity Team Quality Attribute Concerns/ Quality Attribute Scenarios Rank Attributes Characterization (I, D)* Modifiability Ability of the system to A new authorized client node tries to (M, L) provide enhanced security connect to the OMP server to access the requirements that may video stream data when the OMP server come from POSDATA is connected and on-line. The OMP client in the future. 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. * I: Relative Importance of the quality attribute scenario to the project D: Difficulty for the architecture to satisfy quality attribute scenario ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 10/40
  • 11. Architecture Design Document Trinity Team 3 Description of Architecture 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. 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]. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 11/40
  • 12. Architecture Design Document Trinity Team 0..N Parent Node Viewer Viewer Connector Adapter Stream Storage Node Information 0..N Node Stream Stream Server Configuration Buffer Controller Viewer Manager Event Bus Stream Stream Acceptor Buffer Parent Node Server Checker Communicator Digital Video Node Stream Converter Information Controller 0..N Child Node Node Parent Node Node Information Configuration Node Node Checker Configuratio Manager Stream Stream Handler Finder File Buffer Controller Viewer Connector Security Event Bus OMP Handler Viewer Handler Adapter Console Server Communicator Viewer Legend Memory TCP Call-return Publisher Connector Connector Connector Event Bus (Stream Buffer) Subscriber Memory External Project UDP Physical Connector Connector Component Dynamic Event Bus Scope Connector Storage Boundary (Node Info) Memory 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 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 12/40
  • 13. Architecture Design Document Trinity Team [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 Node Configuration Manager located in each client node deals with node Configuration information of its child node and a parent node. Whenever the node Manager information has been change, the node configuration manager announces or receives an event. Parent Node Parent Node Checker periodically (heart beating) checks the status of the Checker 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 Server Communicator takes charge of communication between server and Communicator each node. In case of a node wants to join the OMP or need to another ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 13/40
  • 14. Architecture Design Document Trinity Team 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. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 14/40
  • 15. Architecture Design Document Trinity Team 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]. Server Client Node Management Legacy applications Viewer Applications Viewer Applications Join Request User Interface User Interface OMP Interface OMP Interface Security utilities Security utilities Node configuration utilities Node configuration utilities Node info communication Stream Data Transmission Node info communication Stream Data Transmission utilities utilities utilities utilities TCP UDP TCP UDP Network Network Internet Legend Layer Layer (Project Scope) (Out of Scope) Data Transmission 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 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 15/40
  • 16. Architecture Design Document Trinity Team 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 In the node configuration utilities, node information is updated utilities dynamically and optimizes the node path. Node Node communication utilities are for communicating with node to node communication or node to server. utilities Stream data The utilities play a role in duplicating data for child nodes as well as transmission utilities sending or receiving data. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 16/40
  • 17. Architecture Design Document Trinity Team 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 Description Component ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 17/40
  • 18. Architecture Design Document Trinity Team 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. 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 Module View Allocation View (Physical (Component Name) machines on which C&C objects (Layer Name) may exist) Stream controller Stream 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 Node configuration utilities Client manager Parent node checker Node configuration utilities Client Viewer adapter OMP Interface Client OMP handler OMP interface OMP server Security handler Security utilities Client, server ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 18/40
  • 19. Architecture Design Document Trinity Team Detailed Design 3.1.7 Class Diagram ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 19/40
  • 20. Architecture Design Document Trinity Team 3.1.8 Sequence Diagram 1) Sequence diagram about transmitting packet message and data between server and client node ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 20/40
  • 21. Architecture Design Document Trinity Team 2) Sequence diagram based on TBCP algorithm ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 21/40
  • 22. Architecture Design Document Trinity Team 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. 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. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 22/40
  • 23. Architecture Design Document Trinity Team Evaluate Possible Alternatives 4.1.1 Socket Programming vs. RPC 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 Scenario seconds of its dispatch from the OMP server using the maximum available bandwidth with 11 Mbps. Business The effective bandwidth and cost-saving video stream service of traffic Goal(s) surveillance and company broadcasting system in WAN area Attribute Performance Attribute Response Time in communication between OMP server and client Concern Video stream event it sent from the N-DVR and arrives Stimulus at the client Stimulus OMP server Source Environment Normal conditions Scenario Artifact Video stream Refinement Video stream is processed from the OMP server to the Response client. The client receives the video stream within 5 seconds of Response its dispatch from the OMP server using the maximum Measure available bandwidth with 11 Mbps. Architectural Decision Sensitivity Tradeoff Risk 1.Using of RPC to Socket Programming 1 1 1 2.Using Explicit Invocation style for managing control information (and other node configuration 2 2 information) in place of using the Implicit Invocation Style 3.Using the static non volatile storage like hard disk drives, tapes etc in place of the dynamic 3 3 volatile storage memory 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. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 23/40
  • 24. Architecture Design Document Trinity Team 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.1.2 Explicit Invocation vs. Implicit Invocation Scenario A video stream (internal) event is sent from the OMP server to a number ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 24/40
  • 25. Architecture Design Document Trinity Team 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 The effective bandwidth and cost-saving video stream service of traffic Goal(s) surveillance and company broadcasting system in WAN area Attribute Performance Attribute Ability of OMP server to cater to many clients Concern Video stream event it sent from the N-DVR and arrives Stimulus at many clients Stimulus OMP server Source Environment Normal conditions Scenario Artifact Video stream Refinement Video stream is processed from the OMP server to many Response clients. The number of clients receiving the video stream are Response predefined number 100 from the OMP server using the Measure maximum available bandwidth with 11 Mbps. Architectural Decision Sensitivity Tradeoff Risk 1.Using of RPC to Socket Programming 1 1 1 2.Using Explicit Invocation style for managing control information (and other node configuration 2 information) in place of using the Implicit Invocation Style 3.Using the static non volatile storage like hard 3 2 disk drives, tapes etc in place of the dynamic volatile storage memory 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 (-) ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 25/40
  • 26. Architecture Design Document Trinity Team 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. 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.1.3 Dynamic memory vs. Non-volatile memory 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 Scenario 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 The effective bandwidth and cost-saving video stream service of traffic Goal(s) surveillance and company broadcasting system in WAN area Attribute Availability Attribute Ability of the system to address failure of data transmission between Concern network nodes and between the OMP server and client nodes ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 26/40
  • 27. Architecture Design Document Trinity Team An unanticipated failure of transmission message is Stimulus received Stimulus Internal to the system(omission failure that is Source components to fail to respond to input) Environment During normal operation Scenario Artifact Communication processes between client nodes Refinement The OMP server tries to reestablish the transmission of Response video stream between the appropriate client nodes. Within 5 seconds and logs the failure of transmission Response message with performance information and continues in Measure normal mode Architectural Decision Sensitivity Tradeoff Risk 1.Using of RPC to Socket Programming 1 1,2 1 2.Using Explicit Invocation style for managing control information (and other node configuration 2 information) in place of using the Implicit Invocation Style 3.Using the static non volatile storage like hard 3 3 disk drives, tapes etc in place of the dynamic volatile storage memory 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. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 27/40
  • 28. Architecture Design Document Trinity Team 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. 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 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 2.Using Explicit 3.Using the static non Socket Programming Invocation style for volatile storage like managing control hard disk drives, tapes information (and other etc in place of the node configuration dynamic volatile information) in place storage memory of using the Implicit Invocation Style Performance (Time or + + - response) ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 28/40
  • 29. Architecture Design Document Trinity Team Performance (Number + + - 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. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 29/40
  • 30. Architecture Design Document Trinity Team 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. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 30/40
  • 31. Architecture Design Document Trinity Team 6 ATAM Process Evaluation 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) ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 31/40
  • 32. Architecture Design Document Trinity Team 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 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 32/40
  • 33. Architecture Design Document Trinity Team 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 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 33/40
  • 34. Architecture Design Document Trinity Team Appendix – QA Scenarios Below 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 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 Scenario 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 The effective bandwidth and cost-saving video stream service of traffic Goal(s) surveillance and company broadcasting system in WAN area Attribute Usability Attribute Ability of user to see the data group management information using a text- Concern based user interface at the OMP server The user commands the OMP server to show the Stimulus snapshot of data group management information. Stimulus N-DVR end user Source Environment At runtime Scenario Artifact Data group management information Refinement The OMP server provides to generate data group Response management information. The OMP server generates the data group management Response information for the existing 100 clients at the instant of Measure time the user gives the commands. Architectural Decision Sensitivity Tradeoff Risk 1. Division between stream data and node configuration data 2. Using Event Bus for notifying the node configuration changes 3. Providing a Text based UI 1. U1+S1- 1 1 2. U1+PO1- 4. Using dynamic memory for storing stream data 2 3. U1+S1- and node information 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 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 34/40
  • 35. Architecture Design Document Trinity Team * U1: Usability scenario 1, S1: Security scenario1, PO1: Portability scenario 1  Security 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 Scenario 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 The effective bandwidth and cost-saving video stream service of traffic Goal(s) surveillance and company broadcasting system in WAN area Attribute Security Attribute Ability of N-DVR to provide security by enabling only authorized users to Concern access the system A user tries to access the data group management Stimulus information Stimulus An unauthorized user Source Scenario Environment The OMP server is connected and on-line Refinement Artifact The data group management information The OMP server blocks the authorized user access, and Response warns the user. Response The OMP server provides a continuous audit trail for the Measure system. Architectural Decision Sensitivity Tradeoff Risk 1. Division between stream data and node 1 1. S1+U1- configuration data 2. S1+M1- 2. Using Event Bus for notifying the node configuration changes 3. Providing a Text based UI 4. Using dynamic memory for storing stream data and node information 5. Applying different communication protocol for 2 3. S1+M1- 1 each data type (TCP for node data transmission and UDP for stream data transmission) 6. Supporting dynamic nodes configuration by heart beating parent nodes * U1: Usability scenario 1, S1: Security scenario1, M1: Modifiability scenario 1 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 35/40
  • 36. Architecture Design Document Trinity Team 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 Scenario 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 The effective bandwidth and cost-saving video stream service of traffic Goal(s) surveillance and company broadcasting system in WAN area Attribute Security Attribute Ability of system to provide security of data transmitted between clients and Concern OMP server A new authorized client node tries to connect to the OMP Stimulus server. Stimulus A new authorized client Source Scenario Environment Connected and on-line Refinement Artifact Video stream data The OMP server provides the authorized client node with a Response video stream data. Response The OMP server uses an encryption/decryption algorithm Measure for data transmission and a 128 bits encryption standard. Architectural Decision Sensitivity Tradeoff Risk 1. Division between stream data and node 1 1. S2+P1- 1 configuration data 2. S2+A1- 3. S2+M1- 2. Using Event Bus for notifying the node configuration changes 3. Providing a Text based UI 4. Using dynamic memory for storing stream data 2 4. S2+P1- and node information 5. S2+A1- 6. S2+M1- 5. Applying different communication protocol for 3 7. S2+PO1- 2 each data type (TCP for node data transmission 8. S2+A1- and UDP for stream data transmission) 9. S2+M1- 6. Supporting dynamic nodes configuration by 4 10. S2+P1- heart beating parent nodes 11. S2+A1- 12. S2+M1- * S2: Security scenario2, PO1: Portability scenario1, P1: Performance scenario1, M1: Modifiability scenario 1, A1: Availability scenario1 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 36/40
  • 37. Architecture Design Document Trinity Team  Portability New authorized clients having different hardware (different speed Intel processors) and software (different OS like Linux, Windows XP, etc) try to Scenario 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 The effective bandwidth and cost-saving video stream service of traffic Goal(s) surveillance and company broadcasting system in WAN area Attribute Portability Attribute Ability of the system to work on diverse hardware and software platforms Concern existing on connecting client nodes Having different configuration try to connect to the OMP Stimulus server Stimulus New authorized clients Source Scenario Environment In normal operation Refinement Artifact Video stream data The OMP server should provide the heterogeneous Response connecting clients with the video stream data. Response The OMP server provides connection within 5 seconds of Measure the client request. Architectural Decision Sensitivity Tradeoff Risk 1. Division between stream data and node configuration data 2. Using Event Bus for notifying the node 1. PO1+P1- configuration changes 1 2. PO1+A1- 1 3. PO1+M1- 3. Providing a Text based UI 2 4. PO1+M1- 4. Using dynamic memory for storing stream data 3 5. 2 and node information PO1+P1-6. PO1+A1- 5. Applying different communication protocol for 4 7. PO1+P1- each data type (TCP for node data transmission 8. PO1+M1- and UDP for stream data transmission) 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 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 37/40
  • 38. Architecture Design Document Trinity Team ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 38/40
  • 39. Architecture Design Document Trinity Team  Modifiability 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 Scenario 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 The effective bandwidth and cost-saving video stream service of traffic Goal(s) surveillance and company broadcasting system in WAN area Attribute Modifiability Attribute Ability of the system to provide enhanced security requirements that may Concern come from POSDATA client in the future. A new authorized client node tries to connect to the OMP Stimulus server. Stimulus A new authorized client Source Environment Connected and on-line Artifact Video stream data Scenario The OMP server provides the authorized client node with a Refinement Response video stream data. The OMP server provides the authorized client node with a video stream data using a superior custom built Response encryption/decryption algorithm (which may become an Measure industry standard in the future) for data transmission and the 128 bits encryption standard. Architectural Decision Sensitivity Tradeoff Risk 1. Division between stream data and node 1 1. M1+P1- 1 configuration data 2. M1+A1- 3. M1+S2- 2. Using Event Bus for notifying the node configuration changes 3. Providing a Text based UI 4. Using dynamic memory for storing stream data and node information 5. Applying different communication protocol for 2 4. M1+PO1- 2 each data type (TCP for node data transmission 5. M1+A1- and UDP for stream data transmission) 6. M1+ S2- 6. Supporting dynamic nodes configuration by 3 7. M1+P1- 3 heart beating parent nodes 8. M1+A1- 9. M1+ S2- ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 39/40
  • 40. Architecture Design Document Trinity Team * PO1: Portability scenario 1, P1: Performance scenario 1, S2: Security scenario2, M1: Modifiability scenario 1, A1: Availability scenario 1 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 40/40