Final Presentation [CS554] Designs for Software and Systems Supreme Design Khalil Mezyaoui, Jun Ho Yi Jongmin Lee, Taeju Park

Final Presentation

[CS554] Designs for Software and Systems

Supreme DesignKhalil Mezyaoui , Jun Ho Yi

Jongmin Lee, Taeju Park

SUPREME DESIGN

www.themegallery.com

Contents

1. Business Driver 1. Business Driver

2. Prioritized Utility Tree 2. Prioritized Utility Tree

3. Architectural Analysis 3. Architectural Analysis

4. Conclusion 4. Conclusion

Business Driver


Business Driver Since space craft is expensive, it should not be damaged or broken.

Since space craft is usually operating in harsh environment, faults can be easily occurred.

Even small failure of space craft have high probability of leading catastrophe.

Business Goal -> protecting faults in a space craft. Fault

Fault Protection System

Space Craft

Business Driver


Business Constraints This business area require huge amount of developing cost and un-

expected developing period. So, it is difficult to manage exact sched-ule and cost.

Technical Constraints FPS always interoperates with space craft system. FPS operates on Space Craft Operating System (SCOS).

Quality Attribute Desired Reliability Efficiency Security

Business Driver

Prioritized Utility Tree



Quality Attribute

Factor Priority Scenario

Efficiency E1: Time Behavior

(H, H)E1.1 : If space craft sends parameters, then the FPS should respond to space craft within specific time. (Ex : 1sec)

(M, L) E1.2 : FDIR should process detection, isolation, recovery for faults within specific time.

(H, H)

E1.3 : If there are faults in given parameter, then all functions related to the faults are stopped by FPS. Then, stopped critical function should be resumed as fast as possible.

Reliability

R1: Recoverability (H, M)R1.1 : Even if faults occur, critical functions should be resumed as soon as possible.

R2 : Operation (H, M)

R2.1 : Fault in individual device should be restored by using recovery and isolation method for individual device level. Fault in function, subsystem, system control should be also restored by using corresponding mechanism.

(M, L) R2.2 : FPS can be controlled by giving commands at any time.



Quality Attribute


Security

S1 : Authorization (M, L) S1.1 : When users try to access FPS, authentication function checks level of authorization of the user. According to the level of authorization, provided works are limited.

S2 : Encryption

(L, M)S2.1 : When information is saved into database server or loaded from database server, the information is encrypted by using SHA algorithm and decrypted by using public key.

(H, M)

S2.2 : Communication messages between base station (Earth) and space craft are encrypted/decrypted before sending mes-sages.

Maintainability

M1 : Changeability

(M, H)M1.1 : User can modify range of parameters safely. Modified range of parameters will be adapted to the FPS immediately. Synchronization should be considered.

(M, L) M1.2 : FPS should adapt any device’s edition/deletion in a space craft system.

M2 : Testability (M, M)M2.1 : Devices for detection, isolation, recovery in FDIR should be testable and if a device don’t operate well, we should easily find the reasons.



Quality Attribute


Usability U1 : Observation (M, M)U1.1 : Status of FPS can be observed by showing it through display at any time.

Portability P1 : Adaptability

(L, H)P1.1 : FPS should be portable for other space craft system.

(M, H)

P1.2 : We should be able to easily modifying FPS modules; if ever we change a module system should adapt the new mod-ule without affecting the other modules.

Analysis of Architecture : Overall System


Analysis of Architectures

EfficiencyScenario E1.1 If space craft sends parameters, then the FPS should respond to space craft within

specific time. (Ex : 1sec)

Attribute EfficiencyEnvironment Normal OperationStimulus Receive out of range parametersResponse The FDIR detects faults. The FPS informs the fact to space craft within specific time.

(Ex : 1sec)

Architectural Style Risk Sensitivity Trade offClient-server style R7 S1 T2Peer-to-Peer style S2 T3

R1 : Server may be overloaded by requests of many clients. In this case, response time will be delayed.






(Ex : 1sec)


S1 : Since server-client model is centralized model, it means that all communica-tion should pass server at least once. It may take long time.

S2 : Since peer-to-peer communication is done directly between peers. So, we can expect that the communication latency is short.






(Ex : 1sec)


T2 : Efficiency(-), Portability(-) vs Security(+) : Client-style is not good at effi-ciency quality attribute because as mentioned S1. However, using server-client model increases security quality attribute because server can authenti-cate and authorize all clients’ request.

T3 : Efficiency(+), Portability(+) vs Security(-) : Peer-to-peer model is good at effi-ciency quality attribute as mentioned S2. It also increases portability because if one peer is disconnected by problem, it can’t affect transaction between other peers. However, it decreases security because it need to manage sepa-rated authentication for each communication.






(Ex : 1sec)


Reasoning

Client-server architectural style is bad candidate in terms of efficiency be-cause of S1, R7.

Peer-to-peer architectural style is good candidate in terms of efficiency be-cause of S2.



SecurityScenario S2.2 S2.2 : Communication messages between base station (Earth) and space craft are en-

crypted/decrypted before sending messages.

Attribute SecurityEnvironment Normal Operation

Stimulus Sending message between base station and space craftResponse Messages become encrypted or decrypted.


S3 : In client-server model, server can handle messages between terminals. So, it can find illegal message and abolish it. It hence security of system.

S4 : Since peer-to-peer communication is done directly between peers. Detecting illegal message like hacking transaction is hard and blocking it is also difficult. So, there is possibility that it makes significant problem.



SecurityScenario S2.2 S2.2 : Communication messages between base station (Earth) and space craft are en-

crypted/decrypted before sending messages.

Attribute SecurityEnvironment Normal Operation

Stimulus Sending message between base station and space craftResponse Messages become encrypted or decrypted.


T4 : Security(+) vs Reliability(-) : Client-server model is good at security quality attribute because of S3. However it decreases reliability quality attribute. Since all the communications must pass through the server, a process can’t succeed within deadline when the server is overloaded.

T5 : Security(-) vs Reliability(+) : Peer-to-peer model decrease security quality at-tribute because of S4. However it increases reliability because it can avoid a problem in T1 by direct communication.



Architectural Decision for Overall System

Architectural Style Efficiency Reliability Security Portability Score

Client-Server style - - + - -2

Peer-to-peer style + + - + 2



Architectural Decision for Overall System

Supreme Design System

Legend

Peer Link

FaultProtectSystem

SpaceCraft

Staff

DBDisplay

Analysis of Architecture : FPS



EfficiencyScenario E1.2 FDIR should process detection, isolation, recovery for faults within specific time.

Attribute EfficiencyEnvironment Normal Operation

Stimulus Input through interfaceResponse Fault detection, isolation, recovery result

Architectural Style Risk Sensitivity Trade offCall-return style R1, R2, R6 S1 T1

Pipe and filter style R3, R4Layered style R5 S2

R1 : The call-return style needs exception handling. Since, we don’t know what kind of exceptions will occur, the call-return style should provide exception handling for any kinds of exceptions.

R3 : When the buffer is full in the pipe and filter style, operation can’t proceeds the

next step. So, predicting completion time is difficult.

R5 : It is hard to define appropriate layers of total processes in FPS because function of each layer should be separated. Separating each layer from this point is very hard.








S1 : Call-return style decreases efficiency of FIDR. Suppose there are several faults in parameters. If the detection device detects one fault of them, then it calls recovery or isolation device. Hence, the other faults can’t be detected until the first fault recovery operation is finished.

S2 : Each layer handles own level of faults. So, managing each faults is not re-quired to much time than managing all types of faults. This makes efficiency good.








T1 : Portability(+) vs Efficiency(-) : Call-return style increases adaptability in portability quality attribute because each module can be revised without mod-ifying interface between modules. However, it decreases efficiency because one module should wait until callee module is finished.








Reasoning

The call-return style is not good candidate because it makes efficiency worse as mentioned S1.

Pipe and filter style doesn’t significantly affect on efficiency quality attribute.

Layered style is good candidate because it improves efficiency as mentioned S2.



ReliabilityScenario R2.1 Fault in individual device should be restored by using recovery and isolation method

for individual device level. Fault in function, subsystem, system control should be also restored by using corresponding mechanism.

Attribute ReliabilityEnvironment Normal Operation

Stimulus Set of faultsResponse Each fault should be processed using fitted detection, isolation, recovery method.

Architectural Style Risk Sensitivity Trade offCall-return style R1, R2, R6

Pipe and filter style R3, R4 S3Layered style R5 S4

S3 : Pipe and filter style decreases operation of reliability because detection, iso-lation and recovery is one of filter in the style. So, all the faults are dealt with in a filter. From this point, a fault can be processed with higher level process-ing mechanism. It leads to increase probability that the fault un-related func-tion stop.

S4 : Because each layer in the layered style deals faults which are corresponded that level, functions in a layer will not be affected by faults in other level.



ReliabilityScenario R2.1 Fault in individual device should be restored by using recovery and isolation method

for individual device level. Fault in function, subsystem, system control should be also restored by using corresponding mechanism.

Attribute ReliabilityEnvironment Normal Operation

Stimulus Set of faultsResponse Each fault should be processed using fitted detection, isolation, recovery method.

Architectural Style Risk Sensitivity Trade offCall-return style R1, R2, R6

Pipe and filter style R3, R4 S3Layered style R5 S4

Reasoning

Call-return doesn’t significantly affect on reliability quality attribute.

Pipe and filter style decreases the operation in reliability because of S3. It also decreases efficiency because it process with all methods for detection, isola-tion, recovery for a faults.

Layered style is good candidate because it improves reliability as mentioned S4.



Architectural Decision for FPS

Architectural Style Efficiency Reliability Portability Score

Call-return style - 0 + 0

Pipe and filter style 0 - 0 0

Layered style + + 0 2



Architectural Decision for FPS

Manual FDIR

System Control

Sub System

Function

Individual Device

FDIR Control Mode

Conclusion


Conclusion

Advantages of ATAM Since the architectural decisions affects the performance of

systems, predicting the architecture’s performance in early is important to save time, costs, and efforts.

Even we didn’t work with stakeholders in this project, it seems that the true requirements of stakeholders will be adapted to the system well because the ATAM forces related people to participate in the steps.

Since the results of the ATAM is formed as documentation, it is easy to make the project outputs to documentations.


Conclusion

Weak points of the ATAM It was hard to adapted the ATAM in our projects,

since the ATAM is not familiar with us at the first.

Judgement of architectural decision is highly de-pends on the experience of the participants. To sup-plement this decision may require additional meth-ods.

Since the ATAM forces related people to participate, it may be hard to meet frequently.

ATAM doesn’t support architectural style decision.

Any Questions?

Documents

Final Presentation [CS554] Designs for Software and Systems Supreme Design Khalil Mezyaoui, Jun Ho Yi Jongmin Lee, Taeju Park