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
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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?
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
77
Formal Definition of UML's Formal Definition of UML's Package ConceptPackage Concept
Schurr and Winter, 1998Schurr and Winter, 1998
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
1313
Behavioral Interface Contracts Behavioral Interface Contracts for Java.for Java.
Findler and Felleisen, 2000 Findler and Felleisen, 2000
Rice UniversityRice University
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.)
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.
CSE870 Advanced Software EngiCSE870 Advanced Software Engineering (HillOrji, Sp2002)neering (HillOrji, Sp2002)
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.