Designing Abstract Interfaces for Designing Abstract Interfaces for

Device IndependencyDevice 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

Naval Research Lab's redesign of the flight SW for A-7 aircraft

A Procedure for Designing Abstract A Procedure for Designing Abstract Interfaces for Device Interface ModulesInterfaces for Device Interface Modules

Heninger, K. Parker, R. Parnas, D.L.IEEE Fifth International Conference on Software Engineering - 1981

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

Designing Abstract InterfacesDesigning Abstract Interfaces … is to obtain its dual descriptionAssumption ListAssumption List: List of all the assumptions about the characteristics of the hardware devices the user programs are allowed to make Functional Description: 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

Some Problems and Tradeoffs'Some Problems and Tradeoffs'

Characteristics that change independently should be contained in sub-modules

Certain variable parameters can be specified either at system generation time 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

Commonality Analysis: A Systematic Commonality Analysis: A Systematic Process for Defining FamiliesProcess for Defining Families

David 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

Cited Paper 1

Contents of a Commonality Analysis documentContents of a Commonality Analysis document

IntroductionIntroduction OverviewOverview

Dictionary of Terms Dictionary of Terms - Standard set of terms used for the description of the family

Commonality Commonality – Parnas et al. referred to this section as

the Assumption ListAssumption List

Variability Variability – Documents the possible variations

Parameters of variationParameters of variation – Quantifies the variabilities IssuesIssues AppendicesAppendices

Stages in the Analysis processStages in the Analysis process

PLANPLAN

Define purpose and scope of the family

ANALYZEANALYZE•Define Terms •Identify Commonalities •Identify Variabilities

QUANTIFYQUANTIFYDefine parameters of variation

EXTERNAL EXTERNAL REVIEWREVIEW

Structuring formal control systems Structuring formal control systems specifications for reuse: Surviving hardware specifications for reuse: Surviving hardware

changeschangesJ. Thompson, M. Heimdahl and D. Erickson

In Proc. 5th NASA Langley Formal Methods Workshop - 2000

ProblemTo design software control system for members of a family that displays the same high level behavior and survives changes in replaceable hardware devices

Proposed SolutionObtain a high-level software specification of the requirements

Cited Paper 2

4 Variables Model was proposed by D. Parnas and Jan Madey

4 Variables Model for Control Systems &4 Variables Model for Control Systems &Module DecompositionModule Decomposition

MON CON

INPUT OUTPUT

REQREQ

ININ

SOFTSOFT

OUTOUT1IN

REQSOFT

1OUT

Monitoredvariables

ControlledVariables

SoftwareInput

SoftwareOutput

ConclusionConclusion

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

1IN

1OUT

REQSOFT

Device Independent Navigation and Device Independent Navigation and Interaction in Virtual EnvironmentsInteraction in Virtual Environments

C. 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)

Uncited Paper 1

Device Independent Navigation and Device Independent Navigation and

Interaction in Virtual Environments (Cont’)Interaction in Virtual Environments (Cont’)

Device independence by Mapper Structure of Mapper

Uncited Paper 1

Device Independent Navigation and Device Independent Navigation and

Interaction in Virtual Environments (Cont’)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

Uncited Paper 1

An Abstract-Device Interface for Implementing An Abstract-Device Interface for Implementing Portable Parallel –I/O InterfacesPortable Parallel –I/O Interfaces

R. Thakur, W. Gropp, and E. Lusk Proc. 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

Uncited Paper 2

An Abstract-Device Interface for Implementing An Abstract-Device Interface for Implementing

Portable Parallel –I/O Interfaces (Cont’)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 ADIOADIO concept

Hints for computer system design Hints for computer system design B. W. Lampson, ACM Operating Systems Rev. 15, 5, 1983.

Reprinted in IEEE Software 1, 1984.

Problem: Computer system design– Functionality– Speed– Faulty tolerance

Functionality design & Interface DesignInterfaces are agreements on the functionalities

that system should provide.

Cited Paper 3

Hints for computer system design (Cont’)Hints for computer system design (Cont’)

Interface Design in Computer System– Simplicity, not generality

Predictable cost.– Completeness– Don’t hide power

×Sacrifice power to generalityConcept of Transparency of Hierarchical System [Parnas. 1975]

– Flexibility by procedure parameter