ArchitecturalLevel Risk Analysis Using UML

1
Architectural-Level Risk Analysis Using UML

• Software Engineering
• IEEE Transactions on Software Engineering -
  Katerina Popstojanova
• Henri McCracken

2
Risk Analysis

• According to NASA-STD-8719.13A standard27,
  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

3
Risk Analysis

• Identify potential problems
• Efficient testing allocation
• Types of risk
• Availability Acceptance Performance Cost etc.
• Reliability based risk probability of failure

4
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!

5
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)

6
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

7
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

8
(No Transcript)
9

• Based on frequency of execution

10
Component Risk Factors

• Risk factor of component i in scenario Sx
• Svt Severity level in i-th component
• DOC normalized complexity? HOW?

11
(No Transcript)
12
Normalized complexity (DOC)

• Number of nodes -gt Cardinality (Number of
  Elements in a set)
• Number of edges -gt Cardinality
• Dynamic Complexity of component i in scenario Sx
• Normalized Complexity

13
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

14
Component Complexity

• The set of messages sent from component i to j
  during scenario Sx
• Set of ALL messages exchanged
• Export coupling

15
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.)

16
Markov Property

• Basically states that A model ofsequences 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

17
Risk Model

• Allows to then determine the risk associated when
  moving from component to component (risk model
  for scenario)

18
Overall Use Case Risks

• Risk factor for all use cases
• P probability of occurence

19
Overal System Risk

• Averaging use case risk factors

20
(No Transcript)
21
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

22
Risk Scenario - Components
23
(No Transcript)
24
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!

25
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)

26
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
• Difficult to use on a very large scale
• Need Use cases, sequence diagrams, state charts
  to be implemented
• Uncertainties in scenarios effect on risk

27
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)

28
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)