Some Software Engineering Research at NJIT

1
(Some) Software Engineering Research at NJIT

• Sergio Bogazzi, Yao Fei Chen, GuanJie Jiang,
  BoYu, Ali Mili

2
Projects

• Software Architecture Analysis
• Verification and Validation of Online Adaptive
  Systems
• Software Engineering Trends
• Analyzing Redundancy

3
Software Architecture Metrics

• A Study of Change and Error Propagations

4
Project Objective

• Defining and Investigating Quality Metrics for
  Software Architectures.
• Applying these Metrics to Large Scale Software
  Architectures.
• Correlate the Metrics with Independent
  Observations of Quality.

5
Research Plan

• Define and validate computable metrics for
  software architectures based on information
  theoretic measures
• Automate the process of computing these metrics.
• Apply the process and metrics to a NASA case
  study.
• Validate the correctness and usefulness of these
  metrics.

6
Selected Quantitative Factors

• Error Propagation. Significance for reliability.
• Change Propagation. Significance for
  Maintainability.
• Requirements Propagation. Signifi- cance for
  Evolvability.

7
What are these Metrics useful for?

• By looking at the Error Propagation Metrics, the
  architect would be able to identify components
  that have high potential to propagate errors
  through the system,
• The error propagation matrices, are also very
  useful in direction of test plans, critical
  components that show high tendency to propagate
  error to other system components should be more
  thoroughly tested.

8
What are these Metrics useful for? (contd)

• By looking at the Change Propagation Metrics
  (CPM), the architect would be able to identify
  components that have high potential to propagate
  the changes inside them to other components.
• From CPM, the architect would also be able to
  identify components that have high potential to
  be affected by the changes in other components

9
Project Overview

• Define Information theoretic metrics
• Coupling, cohesion, redundancy
• Define quantitative factors that are relevant to
  qualitative attributes of the architecture
• Error Propagation
• Change Propagation
• Establishing analytical and/or empirical
  relationship between the metrics and the
  quantitative factors
• Automate computation of the metrics

10
Premises of Our Approach

• Architectural Level precludes a logic,
  semantic-based approach hence we use a
  stochastic approach.
• Information Theory has a wide range of functions
  that quantify random variables.
• We use analytical and empirical means to
  correlate metrics to qualitative properties.

11
Recent Accomplishments

• Further Analysis of the Correlation between Error
  Propagation and Computable Metrics.
• Initiating the Analysis of Change Propagation in
  the Context of State Based Components.
• Automation of the derivation of metrics from
  architectural descriptions (in UML, by Nicholay)
  and from source code (by Sergio).

12
Information Coupling and Cohesion Metrics

• We treat coupling in the true architectural
  sense, as a property of the connector between
  components.
• Coupling in our approach becomes a function of an
  ordered pair of components characterizing their
  informational interdependence.
• Cohesion of a component measures its internal
  information flow.

13
Definition of Quantitative Factors Error
Propagation
Error

• The error propagation (EP) is a measure of the
  likelihood that an error in the message sent by A
  will propagate into B.

14
Static Error Propagation Matrix SEPM (Flattened
architecture of a NASA case study)
Error Propagation Coefficient (static) 0.0503
15
Dynamic Error Propagation Matrix DEPM (Flattened
architecture of a NASA case study)
Error Propagation Coefficient (dynamic) 0.0534
16
Future Work Empirical Validation of Error
Propagation Analysis
17
Change Propagation

• We define Change Propagation from component A to
  component B as the probability that a change in A
  due to corrective/ defective maintenance requires
  a change in B to maintain the overall function of
  the system.
• We are conducting empirical experiment and trying
  to propose an analytical formula that approximate
  change propagation

18
Analyzing Change Propagation Simple Model

• Model architectural components as input-output
  transformers C IC ? OC, from the set of inputs
  (IC ) of the component C to the set of its
  outputs (OC ).
• Consider elementary two-component (pipeline?)
  architecture, where the first component A feeds
  its output to the second component B as its
  input. The functionality of the architecture can
  be presented in the form of the following
  diagram

19
Empirical work

• 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
The experiment is still undergoing
21
Automated Tool

• Simplify application of the theory and methods
  developed to industrial-strength systems
• Give project manager an ability to get a glimpse
  into the quality of software architecture ?
  Project Manager View
• Configure the tool for handling specific ADLs and
  CASE tools ? Analyst View

22
Benefits

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

23
Future Work

• Use a tool such as SIAT TM, or Understand TM to
  measure static information theoretic metrics
• Compare the measures obtained to those obtained
  at the design level
• Compare information coupling and cohesion
  measures with traditional measures based on
  McCabe.
• Perfect the tools

24
Verification and Validation of Online Adaptive
Systems

• Jian GuanJie, Ali Mili, NJIT
• Bojan Cukic, Yan Liu, WVU

25
The Intelligent Flight Control System (IFCS)

• IFCS Project NASA DFRC NASA ARC Boeing ISR
  WVU.

26
Traditional VV Techniques

• Fault Avoidance
• Fault Removal
• Fault Tolerance
• All are inapplicable to adaptive learning systems

27
Refinement-based VV of adaptive systems

• Functional Envelope
• Monotonic Learning
• Safe Learning

28
Functional Envelope
29
(No Transcript)
30
Monotonic Learning----MLP
31
Monotonic Learning----DCS
32
Safe Learning
33
Novelty Detection
34

• Experimental Results of Novelty Detection Using
  Association Rule Learning

35
Programming Language TrendsAn Empirical Study
Yao Fei Chen, Ali Mili New Jersey Institute of
Technology
36
Introduction

• As part of the project of monitoring software
  engineering technical trends, we are trying to
  research the evolution of high level programming
  language.
• What are the possible factors which can affect
  programming language trends?
• How can we quantify these factors?
• How can we watch/predict/adapt to/affect the
  trends based the factors?

37
Possible Factors Which Affect Trends

• Intrinsic factors are the factors which can be
  used to describe the general design criteria of
  programming language.
• Generality
• Orthogonality
• Reliability
• Maintainability
• Efficiency
• Simplicity
• Implementability
• Machine Independence
• Extensibility
• Expressiveness
• Influence/Impact

38

• Extrinsic factors are the factors which are not
  directly related to the general attributes of a
  programming language, but still can affect the
  trend of programming language.
• Institutional Support
• Industrial Support
• Governmental Support
• Organizational Support
• Grassroots Support
• Technology Support

39
Quantifying Factors

• Quantifying intrinsic factors
• All intrinsic factors should be considered when
  one designs a programming language. So, we will
  try to go over all features of a programming
  language to check if it matches these factors.
  Then, we will assign a score to each factor for
  each programming language.
• Quantifying extrinsic factors
• We will do survey for every extrinsic factor and
  assign scores for them.

40
Models ConstructionValidation

• Use statistics method to constructvalidate
  Models

41
Evaluating Programming Languages

• By analyzing a set of programming language, we
  expect that we can find out statistics models and
  use them to predict the future trend of a
  programming language.
•                           COBOL
•                           FORTRAN
•                           LISP
•                           ALGOL
•                           PASCAL
•                           C
•                           C
•                           JAVA
•                           ADA
•                           ML
•                           APL
•                           MODULA
•                           EIFFEL
•                           PROLOG
•                           SMALLTALK
•                           SCHEME

42
Analyzing Redundancy

• Ali Mili, NJIT
• Bojan Cukic, WVU
• Jules Desharnais, Laval University

43
Outgrowth of Dryden Project

• What is Redundancy?
• Does Redundancy characterize a state or its
  representation?
• Is all redundancy amenable to state redundancy?
• Can we talk about redundancy without Fault
  Tolerance?
• Instant Redundancy vs Temporal Redundancy

44
Three Views of Redundancy

• Non-Injectivity of Representation Function
• Duplication of State information
• Scale of Fault Tolerant Capabilities.

45
Non Surjectivity

• Representation function from States to
  Representations
• Total (representability) integers.
• Injective (precision) reals.
• Surjective (Non-redundancy)
• No representation functions satisfy all. Most
  functions satisfy none.

46
Duplication of State Information

• Axiomatization of functions quantifying
  duplication
• Zero for redundancy free state
• One for simple duplication for redundancy free
  state.
• N-1 for N-modular redundancy
• Continuous real values in-between.

47
Scale of Fault Tolerant Capabilities

• Levels of Correctness
• Correctness, Maskability, Recoverability,
  Non-recoverability.
• Recovery is necessary and sufficient
  Recoverability.
• Sufficient conditions of recoverability.