Project 2 Presentations CS554 – Designs for Software and Systems Team HAND – Seokin Hong, Gieil Lee, Jesung Kim, Yebin Lee Department of Computer Science, KAIST

Page  11  Requirements Quality Attribute (Utility Tree) Rating  Candidate Architecture Style Pipe-filter Client-server  Scenarios Analysis  Architectural Analysis  Rating  Architecture Overview Contents

Page  22 Requirements – Quality Attribute (Utility Tree) Utility Performance Response time Throughput Modifiability Availability Testability Built-in monitor Repair time Deadline time Latency Prevent ripple events

Page  3 3 Requirements – Quality Attribute (Utility Tree) Performance Response time Throughput Deadline time When the fault occurs, fault protection system invoked asynchronously at any time Upper layer component checks parameter of lower layer components Fault occurs when the critical function is running, the fault protection system responses within specific time [H, L] [M, L] [H, H] Latency [H, L] In order to check parameter, a component accesses DB for fetching predefined operating range value

Page  44 Requirements – Quality Attribute (Utility Tree) Modifiability Prevent ripple events Fault protection software can be added into existing fault protection software or replaced or eliminated [M, M] Availability Repair time Fault protection system tests itself for detecting its fault [H, M] Testability Built-in monitor Verification of fault protection system is performed by the combination of inspection, simulation, and analysis [M, H]

Page  55  Quality Attribute Rating Requirements – Rating PriorityQuality AttributeRating 1Performance4.25 2Availability4 3Modifiability3 4Testability2

Page  66  Pipe-filter  Asynchronous, concurrent, Independent  Data stream  Non-recursive, pipeline  Client/Server  Asynchronous / synchronous  Performance, Modifiability, Reliability  N-tier Candidate Architecture Style

Page  77  Performance – Throughput Scenarios Analysis Scenario No. : 1 Scenario: Upper layer component checks parameter of lower layer component s for detecting faults Attributes Performance Environment Normal operation Stimulus Result parameter of operation Response Parameter checking is proceeded. Response measurem ent Parameter checking process starts within specific time. Architectural decisio n Sensitivity pointTradeoff pointRisksNon-risks Bound queue sizes S1R1 Reasons - An upper layer can have many lower layer components. If many lower la yer components send their parameters to upper layer, response time ca n be decreased. - Queue size of upper layer component affects average response time dir ectly. (S1) - If queue is full, some important parameters can be delayed or discarded. (R1)

Page  88  Performance – Throughput Scenarios Analysis ArchitectureComparisonEffect Pipe-filter Performance can be guaranteed by limiting the bound of queue size but fault information may be lost when the queue entries are full thus, reliability may decrease. - Client-server Server can limit the queue entries for the performance while preventing decrement of reliability because if the client requests fault processing when the queue entries of server is full, server sends feedback to client to wait for specific time and client keeps the fault request then attempt to request fault processing again. Fault information is not lost leastwise in this architecture. +

Page  99  Performance – Latency Scenarios Analysis

Page  1010  Performance – Latency Scenarios Analysis ArchitectureComparisonEffect Pipe-filter In pipe-filter architecture, caching component is realized with informal shape of pipe-filter architecture. - Client-server Latency of fetching normal operation range value from database can be reduced by placing caching component between client and server. By using caching component, access traffic of server can decrease and fetching latency can decrease if it is hit in caching component. +

Page  1111  Performance – Response time Scenarios Analysis

Page  1212  Performance – Response time Scenarios Analysis ArchitectureComparisonEffect Pipe-filter Because of its characteristic (data is processed as FIFO order), it cannot make a response for upcoming faults until processing of prior fault is incomplete. - Client-server It can respond rapidly because the client makes connection with server individually. +

Page  1313  Performance – Deadline time Scenarios Analysis

Page  1414  Performance – Deadline time Scenarios Analysis ArchitectureComparisonEffect Pipe-filter Context switching cannot be performed on the data which is already being processed in pipe-filter architecture - Client-server In client-server architecture, the server can process the data which has higher priority by delaying current data processing. +

Page  1515  Modifiability – Prevent ripple events Scenarios Analysis

Page  1616  Modifiability – Prevent ripple events Scenarios Analysis ArchitectureComparisonEffect Pipe-filter Because the filter can communicate only by the pipe, pipe-filter architecture is appropriate to this scenario. one characteristic of pipe-filter is that it can perform the computation by combination of filters. + Client-server Client should know the service what it calls to receive. Service modification of server may require partial or entire modification of the client. -

Page  1717  Testability – Built-in monitor Scenarios Analysis

Page  1818  Testability – Built-in monitor Scenarios Analysis ArchitectureComparisonEffect Pipe-filter Built-in monitor can be realized in informal shape of pipe-filter architecture. - Client-server In client-server architecture, built-in monitor can be implemented easily by inserting the client which is in charge of Q&A about its status. +

Page  1919  Availability – Repair time Scenarios Analysis

Page  2020  Availability – Repair time Scenarios Analysis ArchitectureComparisonEffect Pipe-filter In pipe-filter architecture, filters operate independently from each other thus, triplex system can be implemented by just adding three identical filters and connect them each other. + Client-server Triplex system can be realized by replicating same clients.+

Page  2121  Measurement metrics  + = 3, - = 1  Performance = x 1, Availability = x 0.9  Modifiability = x 0.8, Testability = x 0.7 Rating ArchitectureRating Pipe-filter1.37 Client-server2.48

Page  2222  Client-server Architecture Approach Architecture Overview– client / sever

Page  23 Thank you!