"Architectural-Level Risk Analysis Using UML"
Architectural-Level Risk Analysis Using UML Software Engineering IEEE Transactions on Software Engineering - Katerina Popstojanova Henri McCracken Risk Analysis According to NASA-STD-8719.13A standard, “risk is a function of the anticipated frequency of occurrence of an undesired event, the potential severity of resulting consequences, and the uncertainties associated with the frequency and severity” Risk Analysis Identify potential problems Efficient testing allocation Types of risk: Availability; Acceptance; Performance; Cost; etc. Reliability based risk – probability of failure Risk Probability of fault and occurrence of fault in specific scenario Failure relative to complexity and coupling Premise: “Active components and connectors are sources of failure” Ibrahim: “Subjective risk assessment techniques are human intensive and error-prone. Risk assessment should be based on product attributes that we can quantitatively measure using product metrics“ – Real world example Main Goal: Detect problems early on! – Save MONEY! Risk Assessment Methodology Architectural Level Overview: Quantitative Metrics Complexity Coupling Metrics Severity Analysis Markov Model for scenario risk System Risk No Domain experts necessarily needed (Medical – Dr. etc. Expensive and Difficult) Goals of Risk Assessment Methodology Scenario Risk Factors Use Case Risk Factors System Risk Factors Distribution of Risk over Severity Component ranking relative to risk Use Cases ranked relative to risk Approach: Pacemaker Case Study “Implanted device that assists cardiac functions when the underlying pathologies make the intrinsic heartbeats low” Life depends on software! Failure unacceptable Based on frequency of execution Component Risk Factors Risk factor of component i in scenario Sx: Svt = Severity level in i-th component DOC = normalized complexity? – HOW? Normalized complexity (DOC) Number of nodes -> Cardinality (Number of Elements in a set) Number of edges -> Cardinality Dynamic Complexity of component i in scenario Sx: Normalized Complexity: Connector Risk Factors Risk factor of connector between component i and j in scenario Sx: svt = Severity level of connector between I and j EOC = normalized export coupling Component Complexity The set of messages sent from component i to j during scenario Sx Set of ALL messages exchanged Export coupling: Severity Analysis Complexity vs. Severity Component with high severity and low complexity… Domain experts determine severity levels Severity indeces (0.25, 0.5, 0.75, 0.95) (linear- but could use any scale – logarithmic, etc.) Markov Property Basically states that: “A model of sequences of events where the probability of an event occurring depends upon the fact that a preceding event occurred” (www.dictionary.com). Allows us to model software execution Gives us the conditional probability of next component execution Risk Model Allows to then determine the risk associated when moving from component to component (risk model for scenario) Overall Use Case Risks Risk factor for all use cases: P = probability of occurence Overal System Risk Averaging use case risk factors: Identifying Critical Components Most risky can undergo more thorough development More Testing for risky items Allows us to see which components are high risk from a high level Most critical components Risk – Scenario - Components Conclusion Use cases and sequence diagrams early in the development Estimate risk for components and connectors based on UML sequence diagrams Markov model for scenario and system risk factors See which connectors are high risk (spend more time implementing) Tool can be easily implemented (mostly analytical methods) – automatic risk assessment! Future Research Development of performance-based risk assessment methodologies Part of article around security risk analysis – using UML as inspiration (Every activity has a negative equivalent) Personal opinion Incredible potential for real-time recommendations for different types of risks (shift risk on one component?) System recommendations Automatic testing for critical components Problems: use on a very large scale Difficult to Need Use cases, sequence diagrams, state charts to be implemented Uncertainties in scenarios – effect on risk Personal Opinion Large Scale Projects – Risk Mitigation essential! (Before building certify that it will work – Money!) More effective spending (know where to put experienced resources) Sources Alaa Ibrahim, Sherif M. Yacoub, Hany H. Ammar. Architectural-Level Risk Analysis FOR UML Dynamic Specifications. IEEE (West Virginia University) Folker den Braber, Chingwoei Gan, Mass Soldal Lund, Ketil Stlen, and Fredrik Vraalsen. A UML Experience Repository Supporting Security Risk Analysis. IEEE (Queen Mary University of London) Katerina Goseva-Popstojanova. Architecture-Level Risk Analysis Using UML. IEEE (West Virginia University)