1 / 17

Jianjun Hu Yakub Sailanawala CSE870 MSU 2002

Designing Abstract Interfaces for Device Independency Review of A Procedure for Designing Abstract Interfaces for Device Interface Modules by D. L. Parnas et al. Jianjun Hu Yakub Sailanawala CSE870 MSU 2002. PROBLEM SOLUTION GOAL.

selima
Download Presentation

Jianjun Hu Yakub Sailanawala CSE870 MSU 2002

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Designing Abstract Interfaces for Device IndependencyReview of A Procedure for Designing Abstract Interfaces for Device Interface Modules by D. L. Parnas et al. Jianjun Hu Yakub Sailanawala CSE870 MSU 2002

  2. PROBLEM SOLUTION GOAL Changes in hardware device interfaces often lead to widespread changes in the whole system The device interface module [DIM] containing the device dependent code The remaining software components that should be independent of device specific details. design good abstract interfaces for DIM A Procedure for Designing Abstract Interfaces for Device Interface ModulesHeninger, K. Parker, R. Parnas, D.L.IEEE Fifth International Conference on Software Engineering - 1981 Naval Research Lab's redesign of the flight SW for A-7 aircraft

  3. … is to obtain its dual description Assumption List: List of all the assumptions about the characteristics of the hardware devices the user programs are allowed to make Functional Description: API & Events Specification Assumption List explicitly states the assumptions about the characteristics that are implicit in the Functional description These descriptions must be reviewed by the users, hardware engineers and experienced programmers Designing Abstract Interfaces

  4. Some Problems and Tradeoffs' • Characteristics that change independently should be contained in sub-modules • Certain variable parameters can be specified either at system generationtime or at run time based on the cost of change and probability of change • Predictable changes or enhancements in the hardware device should be mentioned in assumptions even if not implemented

  5. Cited Paper 1 Commonality Analysis: A Systematic Process for Defining FamiliesDavid M. Weiss Proceedings of IEEE Second International Workshop on Development and Evolution of Software Architectures for Product Families 1998 Analytical technique for defining families • Structured format for all the elements that go into designing and defining families • Process Description • Commonality Analysis refers to both, the end product of this analysis in the form of a document as well as the process

  6. Contents of a Commonality Analysis document • Introduction • Overview • Dictionary of Terms - Standard set of terms used for the description of the family • Commonality – Parnas et al. referred to this section as the Assumption List • Variability –Documents the possible variations • Parameters of variation–Quantifies the variabilities • Issues • Appendices

  7. Stages in the Analysis process PLAN Define purpose and scope of the family • ANALYZE • Define Terms • Identify Commonalities • Identify Variabilities QUANTIFY Define parameters of variation EXTERNAL REVIEW

  8. Cited Paper 2 Structuring formal control systems specifications for reuse: Surviving hardware changesJ. Thompson, M. Heimdahl and D. EricksonIn Proc. 5th NASA Langley Formal Methods Workshop - 2000 • Problem To design software control system for members of a family that displays the same high level behavior and survives changes in replaceable hardware devices • Proposed Solution Obtain a high-level software specification of the requirements

  9. 4 Variables Model for Control Systems &Module Decomposition CON MON REQ Controlled Variables Monitored variables IN OUT Software Input Software Output INPUT OUTPUT SOFT 4 Variables Model was proposed by D. Parnas and Jan Madey

  10. Conclusion • The proposed decomposition of the software system results in a module ( ) that represents the system requirements reusable over control systems exhibiting same high level behavior • The sensors related information is confined to the module representing • The actuators related information is confined to the module representing

  11. Uncited Paper 1 Device Independent Navigation and Interaction in Virtual EnvironmentsC. Faisstnauer, D. Schmalstieg, Z. Szalavari Proceedings of the 1998 VRST Adjunct Workshop on Computer Graphics, Taipei, Taiwan • Objective: • Achieving independence of virtual environment applications from particular available input devices • Mapper vs.DIM of Parnas’ paper • Major extensions • Integrate Different set of input devices • Layered interfaces • Automatic configuration (selection of input devices)

  12. Uncited Paper 1 Device Independent Navigation and Interaction in Virtual Environments (Cont’) Device independence by Mapper Structure of Mapper

  13. Uncited Paper 1 Device Independent Navigation and Interaction in Virtual Environments (Cont’) • Why it should cite Parna’s paper? • Mapper is similar to DIM for separating device independent components from device dependent components • Also discussed the issues of data transformation and emulation • Parna’s Procedure and principles can be suitably applied here • Natural extension of DIM

  14. Uncited Paper 2 An Abstract-Device Interface for Implementing Portable Parallel –I/O InterfacesR. Thakur, W. Gropp, and E. LuskProc. of the 6th Symposium on the Frontiers of Massively Parallel Computation, October 1996 • Objective: • Portable and efficient Parallel-I/O Interface • Facilitate implementation of any parallel I/O API on any file systems Many File systems: Unix, PFS, PIOFS, NFS…. Many Parallel I/O API systems: IBM PIOFS, IntelPFS, RIO… • Approach: • ADIO: Abstract –device interface for parallel I/O • Similar to DIM, Mapper • Difference • Not used directly by application programs but by higher layer API

  15. An Abstract-Device Interface for Implementing Portable Parallel –I/O Interfaces (Cont’) • Limitations • this paper doesn’t provide some guidelines and procedure for how to design interfaces. • doesn’t discuss the trade-off of the levels of exposing the details of underlying file systems • Why should cite Parnas’ paper? • ADIO similar to DIM • Similar issues concerned • Parnas’ procedure can be applied to support the design of ADIO ADIO concept

  16. Cited Paper 3 Hints for computer system design B. W. Lampson,ACMOperating Systems Rev. 15, 5, 1983. Reprinted in IEEE Software 1, 1984. • Problem: Computer system design • Functionality • Speed • Faulty tolerance • Functionality design & Interface Design Interfaces are agreements on the functionalities that system should provide.

  17. Hints for computer system design (Cont’) • Interface Design in Computer System • Simplicity, not generality Predictable cost. • Completeness • Don’t hide power ×Sacrifice power to generality Concept of Transparency of Hierarchical System [Parnas. 1975] • Flexibility by procedure parameter

More Related