The Structure and Value of Modularity in Software Design

Slides:



Advertisements
Similar presentations
Applying Real Option Theory to Software Architecture Valuation Yuanfang Cai University of Virginia.
Advertisements

COMPSCI 105 S Principles of Computer Science 12 Abstract Data Type.
SYSTEM ANALYSIS & DESIGN (DCT 2013)
Systems Analysis and Design 9th Edition
Ken Laskey, co-editor 5th SOA for E-Government Conference 1 May 2008
1 SYSTEM and MODULE DESIGN Elements and Definitions.
Ch3: Software Engineering Principles 1 What is a principle?  Definition:  Goals of accounting principles:  Goals of software engineering principles?
DoD Software Summit,2001 Strategic Software Design Kevin Sullivan University of Virginia Department of Computer Science.
Design Rules: The Power of Modularity Bill Griswold Carliss Y. Baldwin & Kim B. Clark Elucidated with examples from the “common” program and asides about.
NON-FUNCTIONAL PROPERTIES IN SOFTWARE PRODUCT LINES: A FRAMEWORK FOR DEVELOPING QUALITY-CENTRIC SOFTWARE PRODUCTS May Mahdi Noorian
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Motif Discovery in Protein Sequences using Messy De Bruijn Graph Mehmet Dalkilic and Rupali Patwardhan.
Evaluation of Safety Critical Software -- David L. Parnas, -- A. John van Schouwen, -- Shu Po Kwan -- June 1990 Presented By Zhuojing Li.
1 On the Criteria To Be Used in Decomposing Systems into Modules by D.L.Parnas Dec presented by Yuanhua Qu for spring 2003 CS5391.
1 Modularity in Abstract Software Design: A Theory and Applications Yuanfang Cai Dept. of Computer Science University of Virginia Dissertation Proposal.
14 Elements of Nonparametric Statistics
SOFTWARE DESIGN.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Key Principles of Software Architecture and Design (I) adapted from Dave Penny’s.
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
Murielle Florins 1, Francisco Montero Simarro 2, Jean Vanderdonckt 1, Benjamin Michotte 1 1 Université catholique de Louvain 2 Universidad de Castilla-la-Mancha.
“Architecture” The outcome of top-level design, reflecting principal design decisions Can (and should) be modified and updated Analogous to architecture.
Systems Analysis and Design 8th Edition
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Key Principles of Software Architecture and Design (II) adapted from Dave Penny’s.
© 2012 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S.
COMPLIMENTARY TEACHING MATERIALS Farm Business Management: The Fundamentals of Good Practice Peter L. Nuthall.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Audit Sampling: An Overview and Application
Audit Sampling: An Overview and Application to Tests of Controls
Profitability Analysis
CS 325: Software Engineering
Prototyping Lecture # 08.
Design Process You already know the Scientific Method process. Today we are going to learn about the process engineers use when inventing new products.
SOFTWARE DESIGN AND ARCHITECTURE
Decision Making and Relevant Information
Component Based Software Engineering
System Design and Modeling
UNIVERSITY OF MASSACHUSETTS Dept
Lecture 9- Design Concepts and Principles
PowerPoint® Slides to Accompany
Iterative design and prototyping
Research Methods in Computer Science
Rational Perspectives on Decision Making Keys to Decision Making
Software Life Cycle Models
Decision Making and Relevant Information
Tradeoff Analysis of Strategies for System Qualities
Chap 7. Building Java Graphical User Interfaces
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
Model-Driven Analysis Frameworks for Embedded Systems
Search Techniques and Advanced tools for Researchers
Simon: Modeling and Analysis of Design Space Structures
What are your Career Options?
CSE 403: Notkin #2 of 3 on software change
Lecture 9- Design Concepts and Principles
An Introduction to Software Architecture
Channel Dimension Reduction in MU Operation
Cost Estimation Van Vliet, chapter 7 Glenn D. Blank.
CHAPTER 9 (part a) BASIC INFORMATION SYSTEMS CONCEPTS
Design Process You already know the Scientific Method process. Today we are going to learn about the process engineers use when inventing new products.
Modular Analysis of Formal Design Models
Metadata The metadata contains
Presented By: Darlene Banta
Paper by D.L Parnas And D.P.Siewiorek Prepared by Xi Chen May 16,2003
August 22 Bellringer What is engineering?.
Building Valid, Credible, and Appropriately Detailed Simulation Models
Information Theoretical Analysis of Digital Watermarking
Triple DES Network Security.
Module Structure David Parnas Discusses “modularization”
Database management systems
DESIGN CONCEPTS AND PRINCIPLES
Presentation transcript:

The Structure and Value of Modularity in Software Design Kevin J. Sullivan – University of Virginia William G. Griswold – University of California, San Diego Yuanfang Cai, Ben Hallen – University of Virginia

Background Baldwin and Clark’s Theory Based on the idea that modularity adds value in the form of real options An option provides the right to make an investment in the future, without a symmetric obligation to make that investment.

Modularizations Serve Three Purposes Modularity makes complexity manageable Modularity enables parallel work Modularity is tolerant of uncertainty Particular elements of a modular design may be changed after the fact and in unforeseen ways as long as the design rules are obeyed

Non-modular systems Can only be replaced whole even if only by an incrementally better version The designer has one option: To accept a whole “portfolio” of assets – a candidate replacement system with good and bad parts intertwined

Modular Systems A system of independent modules can be kept as is or any or all modules can be replaced independently Improvements can be accepted and regressions can be rejected The replacement decisions are decentralized in the sense that designers responsible for modules can make substitution decisions without coordination.

Summary – Baldwin and Clark A module creates an option to invest in a search for a superior replacement and to replace the current selected module with the best alternative discovered, or to keep the current one if it is still the best choice.

Design Structure Matrix Represents a design space to be searched for valuable designs Represents the design space in terms of: Design Parameters (DP) The values of these parameters (if bound) The dependencies amongst parameter values

Design Parameters Could represent choices of Data structures Algorithms Type Signatures User Interface look and feel Real time response characteristics Security aspects Power Usage …

DSM Rows and Columns labeled by design parameter names The design parameters are represented by diagonal entries A dependence between two design parameters is represented by an off-diagonal mark (X) in the relevant DSM matrix position

Example

Splitting Identify the cause of the dependence and make a separate design parameter The value of the new parameter will constrain the values of the original parameters – they will depend on this new one Fix the value of the parameter in a way that permits the original parameters to be changed independently as long as they are only changed in ways consistent with the new constraint

Splitting applied to Example

Parnas – Case Study KWIC – Key Words In Context A program to compute permuted indices Presented two modularizations of KWIC Strawman Based on the sequence of abstract steps in converting the input to output Information Hiding Uses abstract data type interfaces to decouple key design decisions involving data structure and algorithm choices so they can be changed without unduly expensive ripple effects

Case Study Parnas postulates changes and assesses how well each modularization can accommodate them, measured by the number of modules that would have to be redesigned for each change

Case Study Results Parnas finds that the information-hiding modularization is better He concludes that designers should prefer to use an information hiding design process Begin the design by identifying decisions that are likely to change Then define a module to hide each such decision

Author’s issue A designer is responsible for producing the greatest benefit for any given investment of time, talent, money and other resources BUT the information-hiding decision process does not account explicitly for the costs and benefits of modularization, so it does not help designers most effectively design for value added.

Author’s Two Key Questions Which of the available modularizations is best? At what point should one be selected in the face of uncertainty about the first question? We lack models for assessing the relative values of alternative modularizations for the same system.

Apply both Theories Develop DSMs for Parnas’s modularizations Reveal shortcoming DSMs do not appear to model the environment in which a design is embedded Unable to model the forces that drove the design changes that Parnas hypothesized for KWIC They extended the DSM modeling framework to model environmental parameters (EP)

Strawman Modularization

Strawman Modularization with EPs

Information Hiding Modularization

Information Hiding DSM with EPs

Results The models predict that the information hiding design is superior to the strawman design Consistent with Parnas

Value of Results Provides some evidence that it might be possible to develop a quantitative account of the value of good design Provides limited but significant evidence that such models have the potential to support a discipline of design for value added

Conclusion Identify design decisions that are likely to change and design modules to hide them Modularize early