Designing User Interfaces Spring 1999

1
SE 746-NT Embedded Software Systems
Development Robert Oshana Lecture
11 For more information, please
contact NTU Tape Orders NTU Media
Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu
2
Lecture 11Sequence EnumerationA technique for
specifying embedded systems
3
Specifying a System
If the systems planners and customer do
not Specify what is expected in all types of
interactions with the system, i.e. the behavior
of the system, someone else will. That someone
else is most likely the programmer when he or she
is coding the ELSE option of some IF statement.
There is a very low probability that the
programmers guesses as to the expected behavior
will be what The customer expects. -- James
Kowal, Behavior Models Specifying Users
Expectations
4
Software design is deductive
Progressive reasoning from the general (user
requirements to the specific (software design)
5
What is a good requirement?

• Correct what is being stated has to be right and
  the requirement should, where applicable, contain
  precise information
• Clear the objective of the requirement should be
  obvious and free from wordiness. You shouldn't
  have to think too hard about what the requirement
  is trying to say. Is it understood by everyone?
• Unambiguous the requirement should not be
  interpretable in more than one way

6
What is a good requirement?

• Complete individual requirements should be free
  from any obvious omissions. If a group of
  requirements make up a complete picture of some
  functionality - is everything there? Have all
  cases be clearly stated?
• Consistent the requirement should make sense in
  its current context. Is the requirement
  conflicting with or contradicting any other
  requirements? Is the requirement free of
  unnecessary jargon, homonyms and synonyms?

7
What is a good requirement?

• Reasonable what is being described must be
  achievable and practical
• Clear Dependencies if the requirement has any
  dependencies they should be identified. Examples
  include other requirements, project dependencies
  and technological dependencies
• Traceable your requirement is uniquely identified

8
What is a good requirement?

• Unique each requirement should be the only one
  that says the same thing. Why say it twice and
  give yourself a maintenance hassle or risk of
  contradiction?
• Relevant The requirement should actually be
  mandatory. Is the requirement in fact merely
  narrative that has no bearing on the
  functionality of the system? Is the requirement
  something that is outside of the systems control
  and just not desirable as a requirement?

9
What is a good requirement?

• Testable the requirement must be specific rather
  than vague. Has it been quantified? Have
  tolerances and ranges been expressed? Can you
  think of a reasonable way to test it? Will the
  effects of this requirement be visible?
• Clear Usage can you identify a use or a user for
  the requirement? Does it have a reason for living?

10
What is a good requirement?

• Design-free there should not be too much detail.
  Has the requirement started to infringe on the
  design process by describing how things will be
  done, rather than what should be done?
• No Assumptions all assumptions should be clearly
  stated. An unstated element in a requirement can
  take on different meaning for each individual
  that reads it. This is ambiguity by stealth and
  can just as easily lead to incorrect
  implementation and dispute

11
What is a good requirement?

• Prioritized the importance of a requirement
  should be obvious. Some will be more important
  than others
• Modifiable The document needs to be structured
  in such a way that a change to an individual
  requirement does not cause excessive impact on
  other items
• Complete Everything that is going to be in the
  system is described in the specification. Avoid
  gaps and unnecessary duplication

12
What is a good requirement?

• Verifiable The specification can only be
  considered as verifiable if every requirement
  within the specification can be verified
• Traceable The source of all the requirements in
  the specification should be known and all
  requirements within the specification should be
  traceable to subsequent documents
• Usable The specification is a tool. It is
  essential that it is usable to all parties that
  will rely on its content

13
Complete, consistent, correct

• Complete All possible stimulus histories have
  been mapped to their corresponding responses.
• Consistent No history has been mapped to more
  than one response or one set of responses.
• Correct The domain, range, and mapping have
  been properly specified in the judgement of the
  domain experts.

14
A Quick Overview of Function Theory
15
Two Sets
B
A
b
w
x
d
a
c
z
y
e
A X B lta,bgt a ? A, b ? B lta,xgt, lta,wgt,
lta,ygt, lta,zgt, ltb,xgt, ltb,wgt, ltb,ygt, ltb,zgt, ltc,xgt,
ltc,wgt, ltc,ygt, ltc,zgt, ltd,xgt, ltd,wgt, ltd,ygt, ltd,zgt,
lte,xgt, lte,wgt, lte,ygt, lte,zgt
16
A relation between two sets
B
A
b
w
x
d
a
c
z
y
e
17
A relation between two sets that qualifies as a
function
B
A
b
x
d
a
w
c
z
y
x
18
A complete function
B
A
b
x
d
a
w
c
z
y
e
19
A partition of the domain set
b
a
d
c
e
20
A Mapping Rule
mapping rule
All possible results (co-domain)
All possible scenarios of use (domain)
Correct results (range)
21
Specification Steps

• Behavior
• Shows relationship between input and output
• State
• Shows how stimulus history affects the output
• Implementation
• Shows how the state box information is implemented

22
Behavior view

• Defines required external behavior for all
  possible circumstances of use
• Receives stimulus, S, from environment and
  produces response, R to environment
• Response depends on current stimuli and history
  of stimuli received so far
• No knowledge of internal behavior
• State free and procedure free
• Mathematically, SH ? R

23
The Black Box Behavior view
Description may be mathematical or a Natural
language Description of functionality
SH
R
SH ? R
24
A calculator example

• What is the effect of pressing 6 ?
• It depends
• Stimulus history 1
• SH Clear 7 1 3
• S 6
• Response Display 7136

25
A calculator example

• What is the effect of pressing 6 ?
• It depends
• Stimulus history 2
• SH Clear 7 1 3
• S 6
• Response Display 6

26
State view

• Defines the state space
• Encapsulate stimulus history as state data
  (procedure free)
• (old state, stimulus) ? (new state, response)
• Preserves black box specification
• Several possible state implementations of the
  black box

27
Invent State Data data view
state machine
S
R
black box
( OS, S ) ? ( NS, R )
28
State machine description of the Calculator
0..9/add digit to display
0..9/add digit to display
clear
,-,,/ store operand1 store op clear display
store operand 2 display operand1 op operand2
29
The Clear Box view

• Defines processing required to implement the
  defined state behavior
• Computer program that accepts stimulus, S, and,
  using the state data defined, produces response,
  R
• Several possible implementations
• (old state, stimulus) ? (new state, response), by
  procedure

30
Implementation A Clear box view
state machine
S
R
( OS, S ) ? ( NS, R ) by procedure
31
Sequence-based Specification Process

• Stepwise construction of complete, consistent,
  correct specifications
• All possible sequences of stimuli are enumerated
  systematically in strict order
• Stimulus sequences of length zero, length one,
  length two, etc
• Each sequence mapped to its correct response

32
Sequence-based Specification Process

• Equivalent sequences identified by applying a
  reduction rule
• Enumeration process terminates when the system
  has been defined completely and consistently
• Makes a tractable problem of the large number of
  use cases arising from the combinatorial use of
  S/W

33
Sequence-based Specification Process

• A sequence represents a scenario of use
• Sequence enumeration reveals
• Possible scenarios
• Impossible scenarios
• Intended uses
• Erroneous use
• Reducible sequences
• Irreducible sequences

34
Irreducible Sequences

• Canonical sequences basis for precise
  specification of software behavior
• Mathematically correct literal enumeration of
  sequences all combinations mapped to response
• Consistent orderly enumeration of sequences
  ensures that a given scenario of use only appears
  once
• Traceable correct every element of sequence
  based specification traced to requirements origin

35
Steps to Defining Behavior

• Tagged requirements
• System boundary definition
• Sequence enumeration
• Canonical sequence
• analysis

36
Tagged requirements

• Requirements are tagged for use in verifying the
  correctness of each element of subsequent work
  products
• Methodical consideration of sequences in the
  enumeration process forces exposure of
  ambiguities and omissions in the requirements

37
System Boundary Definition

• Determines which components are inside and
  outside the system
• Entities outside are sources of stimuli and
  destination of responses
• Identification begins are the atomic level
• Abstractions invented to simplify the enumeration
  process
• Used to hide well-known details
• Reflect natural partitions in the product
• Reduce a large set of elements to a smaller set

38
Sequence Enumeration

• Sequences are enumerated in order of length and
  evaluated
• Sequences that are impossible are marked
  illegal, not considered further
• Correct response traced to requirement or a
  derived requirement formed
• Two sequences are equivalent if their responses
  to further stimuli are identical (only extend the
  shorter)

39
Sequence Enumeration

• Enumeration stops when all sequences of a given
  length are illegal or equivalent to a shorter
  sequence
• Completed enumeration is mathematically complete
  (all sequences mapped to a response) and
  consistent (each sequence mapped to only one
  response)

40
Canonical Sequence Analysis

• Legal sequences in the enumeration that are not
  equivalent to any previous sequence are canonical
• Represent unique conditions of system usage
• Analysis reveals the state space for the system
  (at current level of abstraction)
• Variables invented to encapsulate conditions in
  each sequence of stimuli
• Can represent state data for the system

41
SE 746-NT Embedded Software Systems
Development Robert Oshana 10 minute
break For more information, please
contact NTU Tape Orders NTU Media
Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu