a technique for software module specification with examples

CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)

11

A Technique for Software Module A Technique for Software Module Specification with ExamplesSpecification with Examples

Communications of the ACM, May Communications of the ACM, May 1972, Volume 15 Number 51972, Volume 15 Number 5

Presented by:Presented by:Keisha Hill and Kanayo OrjiKeisha Hill and Kanayo Orji


22

OverviewOverview Module Specification TechniqueModule Specification Technique A module is a device having a set of switch inputs and readout A module is a device having a set of switch inputs and readout

indicators, that provide a number of subroutines or functions which can indicators, that provide a number of subroutines or functions which can cause changes in state, and other functions or procedures that can cause changes in state, and other functions or procedures that can give a user program the values of variables making up that state.give a user program the values of variables making up that state.

Goals of the Specification Outline:Goals of the Specification Outline:- Provide all information that user will need to use the program and - Provide all information that user will need to use the program and NOTHING MORE!NOTHING MORE!- Provide the implementer with all information about the use of the - Provide the implementer with all information about the use of the module and needed information to complete the program and module and needed information to complete the program and NOTHING MORENOTHING MORE- Must be sufficiently formal that I t can conceivably be machine tested - Must be sufficiently formal that I t can conceivably be machine tested for consistency, completeness and other desirable properties of a for consistency, completeness and other desirable properties of a specificationspecification- Should discuss the program in the terms normally used by user and - Should discuss the program in the terms normally used by user and implementer rather than some other area of discourse.implementer rather than some other area of discourse.


33

ImpactImpact B Formal Method, TROLL, UMLB Formal Method, TROLL, UML TROLL – developed for TROLL – developed for

specifying information systems specifying information systems at a high level of abstraction.at a high level of abstraction.

Modules – A Module is a Modules – A Module is a CLOSED static unit that CLOSED static unit that encapsulates embedded encapsulates embedded abstractions, such as types, abstractions, such as types, variables, constants, functions, variables, constants, functions, procedures and classes.procedures and classes.

Information HidingInformation Hiding Construction, Validation. Construction, Validation.

Maintaining and Reuse of Maintaining and Reuse of SoftwareSoftware

ModularizationModularization

ParameterizationParameterization Refinement – allowing Refinement – allowing

developers to show that developers to show that program parts satisfy their program parts satisfy their specifications.specifications.

EncapsulationEncapsulation Object Oriented Specification Object Oriented Specification

LanguagesLanguages Frameworks:Frameworks:

Formal methods provide a Formal methods provide a framework within which people framework within which people can specify, develop, and verify can specify, develop, and verify systems in a systematic, rather systems in a systematic, rather than ad hoc, manner.than ad hoc, manner.


44

Towards a Module Concept for Towards a Module Concept for Object Oriented Specification Object Oriented Specification

LanguagesLanguagesS. Eckstein, S. Eckstein,

Proceedings of the Third International Proceedings of the Third International Baltic Workshop on Databases and Baltic Workshop on Databases and

Information SystemsInformation Systems


55

Concurrency and communication issues that Concurrency and communication issues that modules can be allowed to have between each modules can be allowed to have between each other as well as between interfaces that can be other as well as between interfaces that can be developed.developed.

Proposed –Proposed –- Channels provide an asynchronous communication - Channels provide an asynchronous communication mechanism between modulesmechanism between modules- Domains that will allow easy extension and better - Domains that will allow easy extension and better understanding of large systems. Subsystems refer understanding of large systems. Subsystems refer to modules that are structuring units and modules to modules that are structuring units and modules refer those modules which allow reuse.refer those modules which allow reuse.- OFFER and REQUEST actions use objects to - OFFER and REQUEST actions use objects to allow subsystems to pose and acquire information allow subsystems to pose and acquire information from other subsystems.from other subsystems.


66

Parnas looked at the ways in which modules Parnas looked at the ways in which modules should be specified while Eckstein looked should be specified while Eckstein looked also at the concurrency and communication also at the concurrency and communication issues between modules and also interfaces issues between modules and also interfaces that can be developed.that can be developed.

Why does it extend Parnas?Why does it extend Parnas?


77

Formal Definition of UML's Formal Definition of UML's Package ConceptPackage Concept

Schurr and Winter, 1998Schurr and Winter, 1998


88

UML:UML:- First OO modeling language with useful - First OO modeling language with useful modularization and information hiding modularization and information hiding

concept.concept.- Nesting, Import, Refinement.- Nesting, Import, Refinement.- Visibility: Public > Protected > Private- Visibility: Public > Protected > Private- Problems: Ambiguity, Contradictions, - Problems: Ambiguity, Contradictions,

Need more Constraints.Need more Constraints.

OverviewOverview


99

Example of AmbiguityExample of Ambiguity "Elements made available to another package by the use "Elements made available to another package by the use

of generalization have the same visibility in the heir as they of generalization have the same visibility in the heir as they have in the owning package."have in the owning package."

Packages P, Q, R; Element E.Packages P, Q, R; Element E. P is owner of E with Public visibility.P is owner of E with Public visibility. Package Q imports E. Restricts visibility of reference to Package Q imports E. Restricts visibility of reference to

Protected.Protected. Package R references E in Q.Package R references E in Q. Problem: Target of generalization dependency and element Problem: Target of generalization dependency and element

owner are different packages.owner are different packages. Solution: Ensure that a package does not only make Solution: Ensure that a package does not only make

available its own elements by generalization, but also available its own elements by generalization, but also imported elements from other packages.imported elements from other packages.


1010

Example of Contradiction:Example of Contradiction: "Private inheritance (generalization) hides the inherited "Private inheritance (generalization) hides the inherited

features of a class (package).“features of a class (package).“ Statement is made only for classes.Statement is made only for classes. Statements concerning generalization should hold for both Statements concerning generalization should hold for both

classes and packages.classes and packages. Specification forces elements made available by a private Specification forces elements made available by a private

generalization to be visible at the same level as the generalization to be visible at the same level as the generalization itself.generalization itself.

Contradiction: Implies that when the dependency is private, Contradiction: Implies that when the dependency is private, the elements made available by the generalization should the elements made available by the generalization should also be hidden.also be hidden.


1111

TechniqueTechnique Predicate Logic Formulas: Extensions to UML to solve shortcomings.Predicate Logic Formulas: Extensions to UML to solve shortcomings.

ExamplesExamples

- The owner of any element is unique:- The owner of any element is unique:

Formula: ((P owns wE) AND (P' owns w'E)) => ((P=P') AND (w=w'))Formula: ((P owns wE) AND (P' owns w'E)) => ((P=P') AND (w=w'))

- Elements from other packages may be referenced if visible. The visibility of the reference may be - Elements from other packages may be referenced if visible. The visibility of the reference may be restricted:restricted:

Formula: (P references wE) => ((P sees w'E) AND (w<w‘))Formula: (P references wE) => ((P sees w'E) AND (w<w‘))

- The "contains" relationship comprises "owns" and "reference" relationship:- The "contains" relationship comprises "owns" and "reference" relationship:

(P contains wE) <=> ((P owns wE) OR (P references wE))(P contains wE) <=> ((P owns wE) OR (P references wE))

- Many others.- Many others.

Most important consequence:Most important consequence:

Package sees all public elements of contained packages with the visibility of the containership itself.Package sees all public elements of contained packages with the visibility of the containership itself.


1212

Related WorkRelated Work

Transform formulas into specification based on Transform formulas into specification based on PROgrammed Graph REwriting Systems (PROGRES).PROgrammed Graph REwriting Systems (PROGRES).

Specification can then be used to generate UML editor.Specification can then be used to generate UML editor.


1313

Behavioral Interface Contracts Behavioral Interface Contracts for Java.for Java.

Findler and Felleisen, 2000 Findler and Felleisen, 2000

Rice UniversityRice University


1414

OverviewOverview

Programs should consist of off-the-shelf, interchangeable, Programs should consist of off-the-shelf, interchangeable, black-box components.black-box components.

Components should have type signatures and contracts to Components should have type signatures and contracts to ensure proper execution.ensure proper execution.

Four levels of contracts:Four levels of contracts:- Syntactic (Type Streams)- Syntactic (Type Streams)- Behavioral (Conditions)- Behavioral (Conditions)- Synchronization- Synchronization- QoS.- QoS.

Focus on Behavioral Contracts.Focus on Behavioral Contracts.


1515

TechniqueTechnique

Contracts expressed as pre- and post-conditions for externally visible Contracts expressed as pre- and post-conditions for externally visible functions.functions.

Contracts specified in interfaces.Contracts specified in interfaces. Conditions must be validated for function calls.Conditions must be validated for function calls. Multiple pre- and post-conditions may be specified, but only one of Multiple pre- and post-conditions may be specified, but only one of

each must be met.each must be met. If function fails to satisfy contract, system should blame the faulty If function fails to satisfy contract, system should blame the faulty

component.component. Implemented Contract Java, a version of Java with behavioral interface Implemented Contract Java, a version of Java with behavioral interface

contracts.contracts. Pre- and post-conditions can be weakened or strengthened. (Four Pre- and post-conditions can be weakened or strengthened. (Four

Scenarios.)Scenarios.)


1616

Strengthening Pre-ConditionsStrengthening Pre-Conditions

Motivation:Motivation:Often desirable, for instance, in enforcing an input type.Often desirable, for instance, in enforcing an input type.

Problem:Problem:Implicit cast may cause the wrong method to be blamed.Implicit cast may cause the wrong method to be blamed.

Solution:Solution:No solution without compromising Java compatibility.No solution without compromising Java compatibility.Pre-condition strengthening disallowed.Pre-condition strengthening disallowed.


1717

Weakening Pre-ConditionsWeakening Pre-Conditions

Motivation:Motivation:Often desirable, for instance, to allow different Often desirable, for instance, to allow different instantiations when extending an interfaceinstantiations when extending an interface

Problem:Problem:- Java lacks decision procedure to determine if one - Java lacks decision procedure to determine if one contract is weaker than another.contract is weaker than another.- Cannot simultaneously provide pre-condition weakening - Cannot simultaneously provide pre-condition weakening and disallow pre-condition strengthening.and disallow pre-condition strengthening.

Solution:Solution:Contract Java requires that pre-conditions be syntactically Contract Java requires that pre-conditions be syntactically the same as their overridden counterparts.the same as their overridden counterparts.


1818

Strengthening Post-ConditionsStrengthening Post-Conditions

Motivation:Motivation:To provide a stronger guarantee for components using an To provide a stronger guarantee for components using an extension to an interface.extension to an interface.

Solution:Solution:The guarantee is simply put in a contract.The guarantee is simply put in a contract.Easily accommodated in Contract Java.Easily accommodated in Contract Java.


1919

Weakening Post-ConditionsWeakening Post-Conditions

Motivation:Motivation:Useful in extending a class, for instance, extending from Useful in extending a class, for instance, extending from just floating to complex numbers.just floating to complex numbers.

Problem:Problem:Instances of an extended class can be implicitly cast to the Instances of an extended class can be implicitly cast to the parent class.parent class.(Complex numbers may be incorrectly blamed for not being (Complex numbers may be incorrectly blamed for not being floats.)floats.)

Solution:Solution:No solution without compromising Java compatibility.No solution without compromising Java compatibility.Post-condition weakening disallowed.Post-condition weakening disallowed.


2020

The Structure and Value of The Structure and Value of Modularity in Software DesignModularity in Software Design

(Non-Citing Paper)(Non-Citing Paper)K. Sullivan, Y Cai, B. Hallen and W.G GriswoldK. Sullivan, Y Cai, B. Hallen and W.G Griswold

Technical ReportTechnical ReportUniversity of Virginia University of Virginia

Department of Computer ScienceDepartment of Computer ScienceDecember 2001December 2001


2121

OverviewOverview

Draws upon concept of information hiding.Draws upon concept of information hiding. Extends it to propose a new theory based on design Extends it to propose a new theory based on design

structure matrices (DSMs) and real options techniques.structure matrices (DSMs) and real options techniques. Basic Idea:Basic Idea:

- Modularity creates value in the form of - Modularity creates value in the form of optionsoptions..- Improves system by experimenting with new - Improves system by experimenting with new implementations, substituting superior implementations.implementations, substituting superior implementations.


2222

MotivationMotivation

Current modularization formulation does not Current modularization formulation does not address:address:

- Which of the available modularizations is best?- Which of the available modularizations is best?

- At what point should one be selected in the face - At what point should one be selected in the face of uncertainty?of uncertainty?

We lack models for assessing the relative value of We lack models for assessing the relative value of proposed modularizations.proposed modularizations.


2323

GoalGoal

To lend insight into information-hiding modularity.To lend insight into information-hiding modularity.

To find new ways of determining the relative value To find new ways of determining the relative value of different modularizations.of different modularizations.


2424

TechniqueTechnique Evaluate modular structures relative to non-modular designs.Evaluate modular structures relative to non-modular designs.

Modularizations can then be evaluated against each other.Modularizations can then be evaluated against each other.

Design Structure Matrices (DSMs)Design Structure Matrices (DSMs)- Intuitive, qualitative framework for design.- Intuitive, qualitative framework for design.- Represent dependencies among design parameters (data structures, - Represent dependencies among design parameters (data structures, algorithms, type signatures, …).algorithms, type signatures, …).- Rows and columns of matrix labeled by design parameters.- Rows and columns of matrix labeled by design parameters.- Mark in (Row B, Column A) means that choice for B depends on - Mark in (Row B, Column A) means that choice for B depends on choice for A.choice for A.- Interdependence: Symmetric marks in (A,B) and (B,A).- Interdependence: Symmetric marks in (A,B) and (B,A).- Cyclic Interdependence (A->B->C->A): Splitting required.- Cyclic Interdependence (A->B->C->A): Splitting required.- Independence: Design parameters that can be changed individually.- Independence: Design parameters that can be changed individually.- New design parameters added as knowledge improves.- New design parameters added as knowledge improves.


2525

Technique (Continued)Technique (Continued) Net Options Value (NOV)Net Options Value (NOV)

- Options give value.- Options give value.Finance Industry: "A portfolio of options is worth more than an option Finance Industry: "A portfolio of options is worth more than an option on a portfolio."on a portfolio."Example: A system with two modules has four options.Example: A system with two modules has four options.- Used to quantify consequences of a design.- Used to quantify consequences of a design.- Flexibility modeled as a fraction of value of the base system (based - Flexibility modeled as a fraction of value of the base system (based on information hiding).on information hiding).- Used to quantify module complexity, design costs, visibility costs.- Used to quantify module complexity, design costs, visibility costs.


2626

Related WorkRelated Work

Built upon Parnas' work extensively:Built upon Parnas' work extensively:

- DSM-based analysis of KWIC.- DSM-based analysis of KWIC.

- NOV-based analysis of KWIC.- NOV-based analysis of KWIC.

Should have cited Parnas' work on Technique to Module Should have cited Parnas' work on Technique to Module Specification because:Specification because:

- Their technique is based on module design parameters.- Their technique is based on module design parameters.

- The purpose of DSMs and NOVs is to yield testable - The purpose of DSMs and NOVs is to yield testable module specifications.module specifications.


2727

ReferencesReferences [1] D.L. Parnas, “A Technique for Software Module Specification with [1] D.L. Parnas, “A Technique for Software Module Specification with

Examples,” Examples,” Communications of the ACMCommunications of the ACM, Vol. 15, No. 5, May 1972 pp. 330-, Vol. 15, No. 5, May 1972 pp. 330-336.336.

[2] S. Eckstein, “Towards a Module Concept for Object Oriented Specification [2] S. Eckstein, “Towards a Module Concept for Object Oriented Specification Languages,” Proceedings of the Third International Baltic Workshop on Languages,” Proceedings of the Third International Baltic Workshop on Databases and Information Systems, Vol. 2, pp. 180-188, 1998Databases and Information Systems, Vol. 2, pp. 180-188, 1998

[3]A. Schurr and A. Winter,” Formal Definition of UML’s Package Concept, pp. [3]A. Schurr and A. Winter,” Formal Definition of UML’s Package Concept, pp. 144-159, Physica-Verlag and Heidelberg, December 1998. 144-159, Physica-Verlag and Heidelberg, December 1998.

[4] R. B. Findler and M. Felleisen, “Behavioral Interface Contracts for Java,” [4] R. B. Findler and M. Felleisen, “Behavioral Interface Contracts for Java,” Rice University, August 2000 Rice University, August 2000

[5] K. Sullivan., Y. Cai, B. Hallen, and W. G. Griswold, “The Structure and [5] K. Sullivan., Y. Cai, B. Hallen, and W. G. Griswold, “The Structure and Value of Modularity in Software Design,” University of Virginia Department of Value of Modularity in Software Design,” University of Virginia Department of Computer Science, Technical Report CS-2001-13, vol. 15, December 2001Computer Science, Technical Report CS-2001-13, vol. 15, December 2001

[6] D. L. Parnas, “On the Criteria To Be Used in Decomposing Systems into [6] D. L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules,” Modules,” Communications of the ACMCommunications of the ACM, Vol. 15, NO. 12, December 1972 pp. , Vol. 15, NO. 12, December 1972 pp. 1053-1058.1053-1058.

a technique for software module specification with examples

Documents