1. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 1 The SCR/A7E Specification Technique — An Example

2. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 2 A Simple Stop Watch  Four Digit Display, Seven Segments Each  Display Is Min Min Sec Sec  Roll Over To Zero At 99:59  Two Buttons: Start/Stop And Lap/Reset  High-Precision Internal Counter Operating At 10 KHz  Need Complete Semi-formal Specification

3. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 3 A Simple Stop Watch Give me a break, how hard can this be?  What Issues Arise In Specifying Something This Simple? Action On Button Down Or Button Up? Any Action On The "Other" Transition? What If You Push Both Buttons Together? What If You Push The Start/Stop Button When In Lap Display? What If You Push The Lap/Reset Button When Its Reset?

4. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 4 When Has Software Failed? Software has failed when it no longer does what the stakeholders want it to do. If you don’t specify what a software system is supposed to do under certain circumstances, then anything that it does is correct in a sense. There is no "wrong" software, just software you do not want. READ HENINGER’S PAPER CAREFULLY. ASK QUESTIONS.

5. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 5 Example vs. Approach This Is An Example, Don’t Follow "Blindly" Apply Ideas At The Abstract Level To Your Problem Discuss, Think, Investigate, Ask Questions

6. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 6 The Easy Stuff  Symbolic Constants: $maxminutesdisplayed$=99 $processorused$="Intel xyz" $counterfrequency$=10000 Hz  Text Macro: !pushbutton!-Depressing one of the two control buttons for sufficient time that the debounce circuit stabilizes and a single open/close/open sequence is detected. !buttonup!-The event that occurs when a button changes from being down to being up.

7. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 7 Hardware Device Input & Output  Hardware Specification: Seven Segment Displays Buttons  Seven Segment Displays: Output data item:seven segment digit display tens of min //min-10// hardware:LCD description:display tens of minutes count up to 9 interface:i/o port 4  Button: input data item:start/stop push button /start-stop/ hardware:momentary switch, normally open interface:i/o port 1, bit 3

8. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 8 Functionality (Functions?)  Periodic vs. Demand  Basic Difference In Real-time Processing  Time Display Update Is A Periodic Function Every Second  Lap Display Setting Is Demand When Button Is Pushed

9. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 9 Functionality (Functions?)  Display Is Shared—Virtual Displays Explain What Each Display Is To Look Like Separately Explain When And How Each Is To Be Displayed Displays Include: Elapsed Time, Lap Time, Perhaps Others  From Heninger (Paraphrased): "Events specify instants in time, conditions specify intervals of time." "Events provide a convenient way to describe functions where something is done when a button is pushed but not if the pilot continues to hold it down."  Periodic And Demand Functions Defined By Tables That Relate Modes, Events, And Actions

10. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 10 Conditions And Events  Very Important Conditions: /start-stop/=open /start-stop/=closed /lap-reset/=open /lap-reset/=closed  Very Important Events: @T(/start-stop/=open) @T(/start-stop/=closed) @T(/lap-reset/=open) @T(/lap-reset/=closed)

11. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 11 Basic Approach  Assume A Hardware-Incremented Counter  Interrupt Raised For Every Second Passing  Time-State Variables: $time$: $seconds$An integer counter. $minutes$An integer counter. Comments: $seconds$ used to contain elapsed seconds since reset. $minutes$ used to contain elapsed minutes since reset. Both $seconds$ & $minutes$ separate from displ. values. //display//: Four-digit seven segment display. //sec-10////sec-1// //min-10////min-1//

12. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 12 Modes  Modes Of Operations—Collected Into A Table: *initial* *running* *stopped* *lapdisplay*  Mode Transitions (Are These Correct?): *initial* to *running*-@T(/start-stop/=open) *stopped* to *running*-@T(/start-stop/=open) *running* to *stopped*-@T(/start-stop/=open) *lapdisplay* to *running*-@T(/lap-reset/=open) *running* to *lapdisplay*-@T(/lap-reset/=open) *stopped* to *initial*-@T(/lap-reset/=open)  Would A Picture Work?

13. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 13 Event Tables  Note That The Syntax Is Not Entirely Correct Here...

14. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 14 Condition Table  Think About Possible Modes, Conditions, And Outputs For A Robot System

15. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 15 Major Benefits Of This Approach  Simple Formalisms  Not Hard To Understand  Nevertheless Formal  Several Visual Formalisms, Easy To Work With  Does Not Require Elaborate Tool Support Although Very Sophisticated Tools Do Exist

16. University of Virginia SCR/A7E Specification Example (CS340 John Knight 2005) 16 Major Benefits Of This Approach  Amenable To Simple Human Checking, E.g. Completeness: Are All Modes Listed In Event Table? Do Set Of Modes Cover All Possible Operating Conditions? Is Mode Transition Table Complete? Are Actions Associated With Mode Transitions Correct?  Provides Structure To Our Specification & The Process By Which It Is Created: Modes Mode Transitions Events And Conditions Function Tables