1 / 21

FY2002 Initiative: Software Architecture Metrics

FY2002 Initiative: Software Architecture Metrics. The more information I give the more errors I may pass– Couched by Tim WVU UI: Software Architecture Metrics. Hany Ammar, Mark Shereshevsky, Nicholay Gradetsky, Diaa Eldin Nassar, Walid AbdelMoez, J. Shriver, A. Jalan

jaser
Download Presentation

FY2002 Initiative: Software Architecture Metrics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FY2002 Initiative: Software Architecture Metrics The more information I give the more errors I may pass– Couched by Tim WVU UI: Software Architecture Metrics Hany Ammar, Mark Shereshevsky,Nicholay Gradetsky, Diaa Eldin Nassar, Walid AbdelMoez, J. Shriver, A. Jalan LANE Department of Computer Science and Electrical EngineeringWest Virginia University Ali Mili, Bo Yu, Yan Wang, Krupa Doshi College of Computing ScienceNew Jersey Institute of Technology The OSMA Software Assurance Symposium Berkley Springs, WV, September, 2002

  2. Outline • Core ideaThe amount of information Transferred • What we can do • Benefits • Project Overview • Research Objectives • Quantitative Factors • Error Propagation • Change Propagation • Future Work

  3. Core ideaThe amount of information Transferred • If component A talks to components B • It is important how much information can be transferred • In Information theoretic terms this is measured by the entropy of data and control information • Standard view • Call graphs – control-flow and data-flow information between components • “This talks to that” • What is the amount of information transferred? • example1: • Binary information- entropy is 1-bit • example2: • 1000 possible commands – entropy is 10-bits • Intuition: • Error propagation in example2 > Error propagation in example1

  4. What We Can DoDevelop error propagation matrix (details follow) Component A (talks) Component B (listens) alarm!!! alarm!!!

  5. Benefits • Use metrics to identify and focus on problem areas in the architecture • There is a need to analyze the quality of reference architectures in product-line architectural development (NASA Reference Architecture – the SEEDS project at GFSC, Workshop washeld in June 17 - 19, 2002 in San Diego, CA) http://lennier.gsfc.nasa.gov/seeds/ • The developments of techniques for measuring Error/Change Propagation help analysts identify trouble spots in the architecture (advances the state of the art) • The development of automated tools help the analyst apply these techniques on large architectures (advances the state of the practice)

  6. Project Overview FY01 • Defined quantitative factors that are relevant to qualitative attributes of the architecture • Error Propagation • Change Propagation • Requirements Propagation • Defined information theoretic (Entropy-based) architecture metrics

  7. Project Overview (cont.) FY02 • Establish analytical/and empirical relationships between the Entropy-based metrics and Error/Change propagation factors • Automate computation of the metrics, and apply to a NASA case study, • Architecture Metrics Tool to be presented in the tools session, www.csee.wvu.edu/swarch/

  8. Project Overview (cont.) FY03 • Apply the process and metrics to several NASA case studies - Use sanitized Architecture information to estimate the quantitative factors, (links to SIAT tool project with Mark Suder) - Compare Entropy-based metrics to metrics produced from existing metrics tools such as McCabe, (links to Tim Menzies machine learning tool) • Conduct empirical Studies to validate the analytical and empirical relationships

  9. Research Objectives • Define information metrics for software architectures based on information theoretic measures • Automate the process of computing these metrics. • Apply the process and metrics to NASA projects • Validate the correctness and usefulness of these metrics.

  10. Quantitative Factors Selected and defined the following factors • Error Propagation, Significance for Reliability • Change Propagation, Significance for Maintainability • Requirements Propagation, Significance for Evolvability

  11. S A B X OR x x` x` x Definition of Quantitative Factors: Error Propagation Error • The error propagation (EP) is a measure of the probability that an error in the message sent by A will cause an error in B.

  12. A B v1 VAB S1 S2 v2 v3 EP(A  B) = S3 Error Propagation Observed Message Redundancy (OMR) TR(VAB, SB) measures the average amount of redundancy in messages that B receives from A as seen by component B Intrinsic Message Redundancy (IMR) R(VAB) measures the intrinsic amount of redundancy in the messages that B receives from A

  13. Static Error Propagation Matrix Error Propagation Coefficient (static) = 0.0503

  14. Dynamic Error Propagation Matrix Error Propagation Coefficient (dynamic) = 0.0534

  15. Fault Model Components, Connectors Extract Model Info. Design Experiments .rtmdl Connector, Message SummitBASIC Corrupt Model Simulateand Log Normal Log Analyze Logs Empirical Error Propagation MATLAB Error Logs Controlled ExperimentsEmpirical Validation of Error Propagation Analysis

  16. Error PropagationControlled Experiments Results • The following correlation results are based on 3562 experiments • The correlation goes down as the number of injected faults in the experimental side goes down • The over all correlation coefficient between the two matrices = 0.8335.

  17. Change Propagation We define Change Propagation from component A to component B as the probability that a change in A due to corrective/ perfective maintenance requires a change in B to maintain the overall function of the system. We propose an analytical formula that approximate change propagation, and present conducted empirical study to measure change propagation.

  18. Change PropagationAnalytical study An upper bound on Change Propagation Factor CP between two components A and B • Where |IX| and |OX| stand for the number of inputs and outputs, respectively of component X. • DIR(Deterministic injectivity rate) of X is defined as

  19. Change PropagationEmpirical Study • In our experiment, we randomly select a large amount of changes within each component, then go into the source code level to see, if the change will propagate to other components. • By computing for each pair of components (A,B), the number for which change in A cause a change in B, we are able to derive the change propagation matrix.

  20. Change PropagationMatrix (Empirical study)

  21. Future Work • Investigate correlation between Error Propagation estimates and data measured in several NASA software (SIAT using X34, ITOS case studies) • Investigate correlation between Change Propagation estimates and data measured from several applications, for more examples of changes. • Investigate the correlation between static and dynamic metrics • Develop a methodology for estimating Requirements Propagation

More Related