Modularity in Abstract Software Design: A Theory and Applications - PowerPoint PPT Presentation

Loading...

PPT – Modularity in Abstract Software Design: A Theory and Applications PowerPoint presentation | free to download - id: 6d2f3e-ZTBiM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Modularity in Abstract Software Design: A Theory and Applications

Description:

Dissertation Proposal on Modularity in Abstract Software Design: A Theory and Applications Yuanfang Cai Dept. of Computer Science University of Virginia – PowerPoint PPT presentation

Number of Views:13
Avg rating:3.0/5.0
Date added: 21 December 2019
Slides: 39
Provided by: yc7
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Modularity in Abstract Software Design: A Theory and Applications


1
Modularity in Abstract Software Design A
Theory and Applications
Dissertation Proposal on
  • Yuanfang Cai
  • Dept. of Computer Science
  • University of Virginia

2
Motivation
  • Software Development A Complex Decision-making
    Process
  • Difficult Decision Problems in Practice
  • Design decisions to minimize long term cost of
    change
  • Refactoring existing system vs. feature delivery
  • Best decision-making order to minimize the need
    for rework
  • All the possible ways to accommodate a given
    change in design.
  • Best design minimizes the cost of change over
    time given anticipated changes

3
Motivation
  • Design Coupling Structure is Complex
  • No Theoretical Framework to
  • Represent design and design spaces in abstract
    but precise way
  • Formulate decision problems precisely
  • Solve decision problems analytically

4
Proposal
  • A Theory of Modularity
  • Abstract design representation
  • A theory of coupling
  • Generalized modularization reasoning
  • An Analytical Framework and Tool
  • Formalized decision problems
  • Formalized solutions
  • Automated analysis

5
Solution Outline
  • Key Theoretical Questions Underneath
  • What is the nature of coupling in design?
  • What is the nature of a design space?
  • What is the nature of modularity in design?
  • Two Level Contribution
  • Theoretical
  • Potential to unify disparate modularization
    methods
  • Practical
  • Potential to help with decision-making in
    practice.

6
Solution Framework
  • Represent software design with Constraint
    Networks (CN)
  • Model software design space with Design Automaton
    (DA)
  • Formalize pair-wise dependence and derive design
    coupling relations
  • Formalize methods and analysis techniques

7
Finite Domain Constraint Networks
  • Variables -- dimensions to make decisions
  • Values -- design decisions
  • Constraints -- relation among decisions
  • One Consistent Assignment -- a Design
  • All Consistent Assignments -- a Design Space

8
Represent Software Design with CN
  • Variables
  • V signature, implementation
  • Domain
  • D (signature, sig_1), (signature, unknown),
  • (implementation, impl_1), (implementation,
    unknown)
  • Constraints
  • implementation impl_1 gt signature sig_1
  • A design
  • (signature, sig_1), (implementation,impl_1)
  • A design space
  • (signature, sig_1), (implementation,impl_1)
  • (signature, sig_1), (implementation, unknown)
  • (signature, unknown), (implementation, unknown)

9
Software Design Automaton (DA)
  • Design Automaton
  • A state a design
  • Alphabet decision changes, variable-value
    binding pair
  • Transition function maps a design to another

10
Software Design Automaton (DA)
  • Compute DA from CN
  • Represent CNs using constraint languages
  • Solve CNs into design spaces
  • Generate Design Automata

11
Dependence and Coupling Relation
  • Pair-wise Dependence
  • -- Two design variables are defined to be
    pair-wise dependent if, for some design, there is
    some change to the first for which the second is
    involved in some minimal perturbation of the
    first.
  • Design Coupling Relation of a CN
  • -- The dependence relation over its variables.
  • Complexity NP Complete

12
Dependence and Coupling Relation
  • Asymmetric Dependence Design Rule
  • Implementation can not influence signature

signature sig_1
signature sig_1
implementation unknown
implementation impl_1
implementation unknown
implementation impl_1
signature sig_1
signature unknown
signature unknown
signature unknown
implementation unknown
13
Dependence and Coupling Relation
  • Formal Definitions
  • Asymmetric Coupling Relation

14
Framework Applications
  • Account for Modularization Uniformly
  • Information Hiding
  • Object-Oriented
  • Aspect-Oriented
  • Help with Practical Decision Questions
  • Design structure matrices linking abstract
    design to existing theory and techniques
  • Design rule theory Baldwin01
  • Task scheduling, e.g. DeMaid
  • Cyclic dependence detection
  • Precise impact analysis
  • Bridge to economic analysis

15
Early Evaluation
  • Test case Parnass KWIC Example
  • Representing the two KWIC designs as constraint
    networks using Alloy
  • Derive DA and coupling relations
  • Represent with DSM
  • Two Level Evaluation
  • Is the framework expressive enough to
  • Represent design spaces and their coupling
    structures?
  • Decisions from different levels, from environment
    to design?
  • Modularity in terms of information hiding?
  • Does the framework help to answer
  • Which design is better?
  • What are the possible ways to accommodate a
    change in environment or design?
  • Are the DSMs generated accurate?

16
Early Evaluation
  • KWIC Sequential Design

Environment Variables
Design Rules
17
Early Evaluation
  • KWIC Information Hiding Design

Environment Variables
Design Rules
18
Early Evidence
  • Is the framework general enough to account for
  • Decisions from different levels, from environment
    to design?
  • Both environment conditions and design decisions
    are modeled
  • Modularity in terms of information hiding?
  • Does the framework help to answer
  • Which design is better?
  • Information hiding is better modularized,
    consistent to Parnass comparison
  • What are all the possible ways to accommodate a
    change in environment or design?
  • Are the DSMs generated accurate?
  • Missing ripple effects are found
  • Performance

19
Early Evidence
  • Design Rule, Information Hiding and Modularity
  • Load-bearing walls of an information hiding
    design (the design rules) should be invariant
    with respect to changes in the environment
  • Environment changes should be accommodated by
    changes to hidden (subordinate) design variables.

20
Early Evidence
  • KWIC Sequential Design

21
Early Evidence
  • KWIC Information Hiding Design

22
Current Status on Performance
  • Performance and scalability
  • Sequential Design with 18 Variables, 12018
    Solutions
  • 1 hour (Alloy) 11minutes (MCS) 71 minutes
  • Information Hiding Design with 20 Variables,
    34907 Solutions
  • 3 hours (Alloy) 2 hours 13 minutes (MCS) 313
    minutes

23
What has been done
  • Formalized mapping from a CN to a DA
  • Formalized mapping from a DA to a coupling
    relation
  • A tool prototype for
  • Incrementally build constraint networks
  • Feed them into an underlying constraint solver
  • Automate DA generation
  • Automate DSM generation
  • Early evaluation using KWIC

24
What Remains
  • Fully formulate key decision problems and the
    associated analysis methods -- March, 2005
  • Automate these analyses by the tool -- May, 2005
  • Evaluation by more realistic case studies --
    July, 2005
  • Finish my dissertation
  • Optimistically September, 2005
  • Latest Spring 2006

25
Methods and Analysis to be Formulated
  • Impact Analysis
  • Task Scheduling
  • Cyclic Dependence Detection
  • Coordination Overhead Estimation
  • Evolution Cost Estimation
  • Net Option Value Computation

26
Impact Analysis
  • Given a current design, what if one or more
    decisions are changed? What should the new design
    (s) look like?
  • Input
  • A abstract logical design representation a
    constraint network
  • An initial design an assignment
  • A sequence of changing decisions -- a sequence
    of variable-value binding pairs.
  • Output
  • A set of evolution paths accommodating the
    specified decision changes,
  • A set of new designs the original one could reach
    after the changes
  • Solution
  • find paths from the DA that start from the
    initial design and go along the edges labeled
    with specified changes.
  • Formally

27
Additional Experiments
  • General enough to unify the apparently disparate
    modularization methods?
  • Aspect-oriented experiments
  • Design pattern experiments
  • Has potential as a foundation for methods of
    decision analysis useful in practice?
  • Product line experiments

28
AO Experiments
  • Canonical figure exampleKICZALES97
  • Can this method model cross-cutting concerns?
  • Does the coupling structure derived capture
    modularity in AO?
  • More realistic web application LOPES04,
  • Is it possible to model realistic design?
  • Are the DSMs generated consistent? More
    accurate?
  • Does this modeling reveal the same insights?

29
OO ExperimentsDesign Patterns
  • Model different patterns uniformlyGAMMAS00
  • Can this framework capture the interdependent
    design decisions embedded in different patterns?
  • Do the DAs generated capture the idea that each
    pattern is for a kind of evolution possibility?
  • Model the maze game example GAMMAS00
  • Does this method reveal the essence of the
    different ways the maze game can be implemented?
  • Does the modeling method capture the idea that
    each pattern for the maze game is due to a
    hypothesized environment change?
  • Is our analysis consistent with that of the
    authors?

30
Realistic ExperimentsProduct Line
  • Seeking a canonical product line example
  • Avaya
  • CMU Software Engineering Institute (SEI)
  • Feasibility
  • Utility
  • Scalability
  • Transformations Abstraction, decomposition, etc.
  • How hard is it to do these transformations?
  • Do these transformations improve the performance?
  • Can we still get useful and insightful results?

31
Future Work
  • Infinite domain constraints
  • Tractability
  • Quantification notation
  • Dynamic design spaces
  • Formal theory of value of modularity

32
Questions? Comments?
33
Software Design Automaton (DA)
  • Represent CNs using constraint languages Alloy

sig sig_domain static part sig_1, unknown_sig
extends sig_type sig impl_domain static
part impl_1, unknown_impl extends impl_type
sig design signature sig_domain,
implementation impl_domain implementation
impl_1 gt signature sig_1
34
Software Design Automaton (DA)
  • Solve CNs into design spaces

implementation unknown
3. signature unknown
35
Software Design Automaton (DA)
  • Generate Design Automaton

signature sig_1
signature sig_1
implementation unknown
implementation impl_1
signature unknown
implementation unknown
36
Software Design Automaton (DA)
  • DA is nondeterministic

37
Software Design Automaton (DA)
  • DA is minimal

signature sig_1
signature sig_1
implementation unknown
implementation unknown
implementation impl_1
signature unknown
implementation unknown
38
Dependence and Coupling Relation
  • What is dependence
  • Minimal Change Set a, b and c
  • Minimal Change Group mcsgroup(cn, 1, v, v2)
    a, b
  • Minimal Change Sets mcssets(cn, v) a, b,
    c
About PowerShow.com