EEEGEF 492.03 Module Interface Specification MIS Module Internal Design MID

1
EEE/GEF 492.03Module Interface Specification
(MIS)Module Internal Design (MID)
Royal Military College of Canada Electrical and
Computer Engineering

• Professor Colin Wortley
• wortley_at_rmc.ca
• 613-541-6000 ext. 6493

Dr. Terry Shepard shepard_at_rmc.ca 613-541-6000
ext. 6031
2
Module Interface Specification (MIS)The Four
Roles of the MIS

• Designer
• Determines behaviour records it in MIS
• Developer
• Creates Module Implementation (MI) to meet MIS
• Verifier
• Determines if the MI meets the MIS
• User
• Reads MIS writes programs that use the MI

3
The Need for a Precise MIS

• To support the four roles
• Why not use the source code as an MIS?
• parallel implementation difficult
• No record of implementers assumptions
• Tester has no basis for correctness
• Complex implementation hard to use as MIS
• Source unavailable in proprietary systems
• In large complex systems, these five issues can
  cause serious problems, including schedule
  slippage, wasted effort, and high defect rates.
• On the other hand, use of MIS style of
  development is relatively rare fix and
  integrate on the fly too much math?

4
MIS Work Product Definition

• A module interface is the set of assumptions
• the module user may make about module behaviour
• the module developer may make about user
  behaviour
• second one is not part of syntax and semantics
  outlined below
• Interface syntax
• access routine input parameter types
• return (output) value types
• names of exceptions that may be signaled
• may include values of defined constants
• Interface semantics
• based on MSMs, with additions
• local functions, types and constants

5
Interface Design

• Design as a series of decisions
• you must first see the available alternatives
• you must then record your decisions
• Service and secret
• found in the module guide
• Access routine idioms for set, sequence and tuple
• eg. access by absolute position vs. sequential
  access to a sequence
• eg. access by field for a tuple, or access by
  whole tuple
• Quality heuristics consistent, essential,
  general, minimal, opaque following slides
• starting point for design
• guide for design reviews

6
Module Interface Design/Quality Goals

• The engineering goal best product at lowest cost
• Minimize cost of development and maintenance
• good interface design is a major contributor
• Maximize run-time performance
• can be affected by poor interface design
• Maximize interface quality
• largely ignored
• hard to pin down, but worth trying
• Design for integration with other modules

7
Module Interface Quality Heuristics

• Consistent
• with partial knowledge the rest can be
  predicted
• underlies all principles of quality
• Essential
• do not provide unnecessary features
• do not offer the same service in two ways
• Minimal
• Keep independent features separate
• Many set-get calls violate minimality

8
Module Interface Quality Heuristics

• General
• the ability to use a function for many purposes
• user will do things never imagined by the
  designer
• in the absence of knowledge, preserve freedom
• Opaque
• the module secret is hidden
• if expected change occurs, interface need not
  change

9
A Module Interface Design Procedure

• Choose the state
• end result is often simple
• takes time to get it right
• worthwhile specifying it precisely
• Access routine design
• choose the set of access routines
• determine the interface syntax
• establish the specification trichotomy
• specify the normal and exception case behaviours

10
Exception Signaling

• MIS says when to signal an exception
• need to decide how to signal
• Three principal approaches
• idiomatic use of data
• idiomatic use of control flow
• built in language constructs
• 2nd approach is used for symtbl as implemented
• for each exception E, there is a C function
  called E in an exceptions file, symtbl_e.c
• E is invoked as needed from symtbl.c, following
  the rules in the MIS
• exception handling is specific to the context of
  use, so the C function for a given E may change

11
The symtbl MIS design

• Choose the module state
• stores a set of symbol/location pairs
• symbols must be unique locations need not
• A software-decision hiding module
• hides the implementation data structure and
  algorithms
• What are the remaining design steps?
• set of access routines
• interface syntax
• specification trichotomy
• assumptions
• normal cases
• exception cases

12
symtbl MIS Syntax
define ST_MAXSYMS 50 define ST_MAXSYMLEN 20
13
symtbl MIS - Semantics

• state variables
• tbl set of tuple of ( sym string, loc
  integer )
• assumptions
• st_s_init is called before any other access
  routine
• All string parameters are legal C strings
• any unstated assumptions ?

14
(No Transcript)
15
(No Transcript)
16
External interaction three cases

• Standalone modules
• specified interaction is with caller only
• provide service without requiring assistance
• do not interact with the environment
• calls on other modules are hidden, if they exist
• eg. memory management may be static or may use
  malloc
• Interaction with the environment
• add environment variables to the MIS
• provide a physical interpretation, often in prose
• Explicit interaction with other modules
• eg. a module may initialize a large data
  structure that is manipulated by other modules

17
Interaction with the environment

• Environment variables
• new MIS section
• name, type, interpretation for each variable
• Example
• using a two dimensional array to specify a
  position on a monitor
• scnrc is the character at screen row r and
  column c, with the numbering zero-relative and
  beginning in the upper-left corner

18
MIS Work Product Criteria

• Audience
• designer, implementer, verifier, user
• Prerequisites
• a reading knowledge of the MIS notations
• Purpose
• to specify the module interface
• Well-formed
• follows a defined format
• Comprehensible
• by the intended audience

19
MIS Work Product Criteria ( contd )

• complete
• Every call in every state covered by assumption,
  exception or normal case
• Sufficient
• Provides required service
• Feasible
• Can be implemented, verified affordably
• High quality
• No unnecessary violations of quality heuristics

20
Module Internal Design (MID)
21
Role of The MID

• Two main differences between the MIS and the
  Module Implementation (MI)
• different state space
• different expression language
• Separate into two steps
• MID deals with the first difference
• MIS abstract state
• MID concrete state

22
Abstract State versus Concrete State

• Abstract state chosen for clarity and simplicity
• Concrete state required because
• abstract state unavailable in MI language
• abstract state insufficient
• MID can be omitted when
• abstract state and concrete state are the same
• there is no concrete state

23
MID - Definition

• Similar to MIS
• interface syntax omitted same as MIS
• semantics again based on MSM
• add state invariant and abstraction function
• State invariant
• predicate on state space
• restricts and indicates legal states
• holds on completion of every access routine call
• Abstraction function
• function A from concrete states to abstract
  states
• The meaning of a state
• Let C be a call on a set type access routine.
  Then it should always be true that A?CMIS CMID?A

24
symtbl MID abstract and concrete states

• Abstract state
• tbl set of tuple of ( sym string, loc
  integer )
• Concrete state
• struct

char symST_MAXSYMLEN 1 int loc
tblST_MAXSYMS int tblcnt
other choices for concrete state ?
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
symtbl a second version of the state invariant

• ( for all t in tbl)( t.sym lt ST_MAXSYMLEN )
  and
• ( for all t1, t2 in tbl )( t1 not equal to t2 -gt
  t1.sym not equal to t2.sym ) and
• tbl lt ST_MAXSYMS

29
MID Work product criteria

• Audience
• module designer and implementer
• Prerequisites
• understanding of the MIS
• understanding of the C constructs for
  declarations
• Purpose
• specify access routine behaviour in terms of
  concrete state
• Well formed
• obeys the MID format

30
MID Work product criteria

• Comprehensible
• by the intended audience
• Correct
• with respect to the MIS
• Feasible
• can be implemented affordably