a technique for software module specification with examples n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
A Technique for Software Module Specification with Examples PowerPoint Presentation
Download Presentation
A Technique for Software Module Specification with Examples

Loading in 2 Seconds...

play fullscreen
1 / 27

A Technique for Software Module Specification with Examples - PowerPoint PPT Presentation


  • 115 Views
  • Uploaded on

A Technique for Software Module Specification with Examples. Communications of the ACM, May 1972, Volume 15 Number 5 Presented by: Keisha Hill and Kanayo Orji. Overview. Module Specification Technique

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'A Technique for Software Module Specification with Examples' - gautam


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
a technique for software module specification with examples

A Technique for Software Module Specification with Examples

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

Presented by:

Keisha Hill and Kanayo Orji

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

overview
Overview
  • Module Specification Technique
  • A module is a device having a set of switch inputs and readout indicators, that provide a number of subroutines or functions which can cause changes in state, and other functions or procedures that can give a user program the values of variables making up that state.
  • Goals of the Specification Outline:

- Provide all information that user will need to use the program and NOTHING MORE!

- Provide the implementer with all information about the use of the module and needed information to complete the program and NOTHING MORE

- Must be sufficiently formal that I t can conceivably be machine tested for consistency, completeness and other desirable properties of a specification

- Should discuss the program in the terms normally used by user and implementer rather than some other area of discourse.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

impact
B Formal Method, TROLL, UML

TROLL – developed for specifying information systems at a high level of abstraction.

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

Information Hiding

Construction, Validation. Maintaining and Reuse of Software

Modularization

Parameterization

Refinement – allowing developers to show that program parts satisfy their specifications.

Encapsulation

Object Oriented Specification Languages

Frameworks:

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

Impact

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

towards a module concept for object oriented specification languages

Towards a Module Concept for Object Oriented Specification Languages

S. Eckstein,

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

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

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

- Channels provide an asynchronous communication mechanism between modules

- Domains that will allow easy extension and better understanding of large systems. Subsystems refer to modules that are structuring units and modules refer those modules which allow reuse.

- OFFER and REQUEST actions use objects to allow subsystems to pose and acquire information from other subsystems.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

why does it extend parnas
Why does it extend Parnas?
  • Parnas looked at the ways in which modules should be specified while Eckstein looked also at the concurrency and communication issues between modules and also interfaces that can be developed.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

formal definition of uml s package concept

Formal Definition of UML's Package Concept

Schurr and Winter, 1998

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

overview1
Overview
  • UML:

- First OO modeling language with useful modularization and information hiding concept.

- Nesting, Import, Refinement.

- Visibility: Public > Protected > Private

- Problems: Ambiguity, Contradictions, Need more Constraints.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

slide9
Example of Ambiguity
  • "Elements made available to another package by the use of generalization have the same visibility in the heir as they have in the owning package."
  • Packages P, Q, R; Element E.
  • P is owner of E with Public visibility.
  • Package Q imports E. Restricts visibility of reference to Protected.
  • Package R references E in Q.
  • Problem: Target of generalization dependency and element owner are different packages.
  • Solution: Ensure that a package does not only make available its own elements by generalization, but also imported elements from other packages.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

slide10
Example of Contradiction:
  • "Private inheritance (generalization) hides the inherited features of a class (package).“
  • Statement is made only for classes.
  • Statements concerning generalization should hold for both classes and packages.
  • Specification forces elements made available by a private generalization to be visible at the same level as the generalization itself.
  • Contradiction: Implies that when the dependency is private, the elements made available by the generalization should also be hidden.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

technique
Technique
  • Predicate Logic Formulas: Extensions to UML to solve shortcomings.
  • Examples

- The owner of any element is unique:

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 restricted:

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

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

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

- Many others.

  • Most important consequence:

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

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

related work
Related Work
  • Transform formulas into specification based on PROgrammed Graph REwriting Systems (PROGRES).
  • Specification can then be used to generate UML editor.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

behavioral interface contracts for java

Behavioral Interface Contracts for Java.

Findler and Felleisen, 2000

Rice University

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

overview2
Overview
  • Programs should consist of off-the-shelf, interchangeable, black-box components.
  • Components should have type signatures and contracts to ensure proper execution.
  • Four levels of contracts:

- Syntactic (Type Streams)

- Behavioral (Conditions)

- Synchronization

- QoS.

  • Focus on Behavioral Contracts.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

technique1
Technique
  • Contracts expressed as pre- and post-conditions for externally visible functions.
  • Contracts specified in interfaces.
  • Conditions must be validated for function calls.
  • Multiple pre- and post-conditions may be specified, but only one of each must be met.
  • If function fails to satisfy contract, system should blame the faulty component.
  • Implemented Contract Java, a version of Java with behavioral interface contracts.
  • Pre- and post-conditions can be weakened or strengthened. (Four Scenarios.)

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

strengthening pre conditions
Strengthening Pre-Conditions
  • Motivation:

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

  • Problem:

Implicit cast may cause the wrong method to be blamed.

  • Solution:

No solution without compromising Java compatibility.

Pre-condition strengthening disallowed.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

weakening pre conditions
Weakening Pre-Conditions
  • Motivation:

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

  • Problem:

- Java lacks decision procedure to determine if one contract is weaker than another.

- Cannot simultaneously provide pre-condition weakening and disallow pre-condition strengthening.

  • Solution:

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

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

strengthening post conditions
Strengthening Post-Conditions
  • Motivation:

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

  • Solution:

The guarantee is simply put in a contract.

Easily accommodated in Contract Java.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

weakening post conditions
Weakening Post-Conditions
  • Motivation:

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

  • Problem:

Instances of an extended class can be implicitly cast to the parent class.

(Complex numbers may be incorrectly blamed for not being floats.)

  • Solution:

No solution without compromising Java compatibility.

Post-condition weakening disallowed.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

the structure and value of modularity in software design non citing paper

The Structure and Value of Modularity in Software Design(Non-Citing Paper)

K. Sullivan, Y Cai, B. Hallen and W.G Griswold

Technical Report

University of Virginia

Department of Computer Science

December 2001

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

overview3
Overview
  • Draws upon concept of information hiding.
  • Extends it to propose a new theory based on design structure matrices (DSMs) and real options techniques.
  • Basic Idea:

- Modularity creates value in the form of options.

- Improves system by experimenting with new implementations, substituting superior implementations.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

motivation
Motivation
  • Current modularization formulation does not address:

- Which of the available modularizations is best?

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

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

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

slide23
Goal
  • To lend insight into information-hiding modularity.
  • To find new ways of determining the relative value of different modularizations.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

technique2
Technique
  • Evaluate modular structures relative to non-modular designs.

Modularizations can then be evaluated against each other.

  • Design Structure Matrices (DSMs)

- Intuitive, qualitative framework for design.

- Represent dependencies among design parameters (data structures, algorithms, type signatures, …).

- Rows and columns of matrix labeled by design parameters.

- Mark in (Row B, Column A) means that choice for B depends on choice for A.

- Interdependence: Symmetric marks in (A,B) and (B,A).

- Cyclic Interdependence (A->B->C->A): Splitting required.

- Independence: Design parameters that can be changed individually.

- New design parameters added as knowledge improves.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

technique continued
Technique (Continued)
  • Net Options Value (NOV)

- Options give value.

Finance Industry: "A portfolio of options is worth more than an option on a portfolio."

Example: A system with two modules has four options.

- Used to quantify consequences of a design.

- Flexibility modeled as a fraction of value of the base system (based on information hiding).

- Used to quantify module complexity, design costs, visibility costs.

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

related work1
Related Work
  • Built upon Parnas' work extensively:

- DSM-based analysis of KWIC.

- NOV-based analysis of KWIC.

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

- Their technique is based on module design parameters.

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

CSE870 Advanced Software Engineering (HillOrji, Sp2002)

references
[1] D.L. Parnas, “A Technique for Software Module Specification with Examples,” Communications of the ACM, Vol. 15, No. 5, May 1972 pp. 330-336.

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

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

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

[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 Computer Science, Technical Report CS-2001-13, vol. 15, December 2001

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

References

CSE870 Advanced Software Engineering (HillOrji, Sp2002)