Software Tutorial (unplugged)Check out Moodle for Design Assignment 1!

GOAL: validate a good DESIGN, then map your DESIGN into CODE…

Before FRIDAY NIGHT…

• Please fill in this survey!

• Tutorial Overview:– http://spreadsheets.google.com/viewform?

formkey=dE1yNW10UVRSMWNGUTZ5dHRKOEplVUE6MA

Objectives

• Communicate software design using three different schematic artefacts

• Map software design to implementation using explicit control and data flow

• Create software that has qualities of readability, maintainability and evolvability

The Mythical Man Month• Many good lessons, including– Brooke’s Law• “Adding manpower to a late software project makes it

later”

– Second system effect…• The general tendency is to over-design the second

system– using all the ideas and frills that were cautiously sidetracked

on the first one. The result, as Ovid says, is a “big pile.”

– Unintentional interaction• As time went on, the number of modules that needed

modifications per change task kept increasing!

Design Artifacts

• Finite State Machines– States and transitions

• Verify system behaviour

• Sequence Diagrams– Functions and data flow

• Divide and conquer the implementation…• High level, system as functions

• Flow Charts– Logic

• Lower level, control flow within functions

Land traffic

Sea traffic

Boat waiting

Boat through

In your Communication’s Text…

• 5 stages of communication– Predrafting: determining requirements of the

overall task

– Drafting: roughing out basic components

– Revision: refining organization of components

– Editing: refining flow within components

– Proof-reading: putting on finishing touches

• Makes sense!

• Systematic…

ROUGHLY mapping these steps…• FSM– Predrafting: determining requirements of the

overall task

• Sequence Diagram– Drafting: roughing out basic components

• Sequence Diagram/Flow Chart– Revision: refining organization of components

• Flow Chart– Editing: refining flow within components

Finishing Touches?

• Might be questionable!– Proof-reading: putting on finishing touches

– … could be implementation and testing…

• BUT THOSE AREN’T FINISHING TOUCHES!!!

WaterFall Model

• Not real…

[picture http://en.wikipedia.org/wiki/Waterfall_model]

WICKED!

• Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall model) – refers to design as a "wicked problem" — a

problem whose requirements and limitations cannot be entirely known before completion

– it is impossible to perfect one phase of software development, thus it is impossible if using the waterfall model to move on to the next phase

Sashimi Model

• greater overlap between phases

• difficulty in determining milestones?

[picture http://www.acidaes.com/SWM.htm]

Cool, but not what you are doing!

• 3 artefacts– FSM

– Sequence diagram

– Flow charts

• 3 people!– How perfect is that?

Finite State Machines

• a model of behavior composed of a finite number of states, transitions between those states, and actions

• captures important data that must be maintained in the implementation

• similar to a "flow graph" – can verify the logic when certain conditions are

met

Eg., Describe the System and Data• an elevator– can be at one of two floors• Ground or First

– one button that controls the elevator• Up or Down

– two lights that indicate the current floor• Red for Ground, and Green for First

– at each time step, the controller checks• the current floor and current input, changes floors and

lights in the obvious way

Draw the FSM diagram

• core structure in the system

Sequence Diagrams

• each function has a “lifeline”

• parameters and return values marked

Call diagram for Sample Program

getNamegetAstrologicalSign

getHoroscope

signhoroscope

name

sign

getBirthMonthgetBirthDay

main

month

day

Flow Charts

• conditional execution– branching

– looping

• algorithm is revealed in this form– diamonds are decisions

– rectangles are statements

Flow Charts

Greencard?

User Interfaces?

Overview

• bridge control system– ensure safe passage of both land and sea traffic

– software simulation• demonstrate the relationship between design and

implementation of a simplified control system

• RobotC program – will not require I/O to include any sensors,

motors, or lights

What to hand in?

• A fully labelled Finite State Machine showing the states and transitions in the system.

• A Sequence Diagram showing both control and data flow at the level of functional decomposition.

• A Flow Chart of the logic within key functions of the system.

• A fully tested implementation of the proposed design as a RobotC program.

What? When? Where?

• first draft of design artefacts must be ready at the beginning of lab the week of January 11th

• beginning of lab the week of January 18th

– hard copies of all artefacts

– electronic submission of RobotC program

• after your lab instructor has signed off Jan 11th the rest of the lab time will be spent on this assignment– get it done!

Details

• in the default state, the bridge is down, services one way car traffic only

• if a tall boat is waiting, cars should be stopped and the bridge should be raised (when safe!)

• once the boat is through, we can return to the default state

car traffic

boat traffic

boat waiting

boat through

Step 1

• Design a more detailed FSM for your system – clearly label the states and transitions between

these states

– note this will be data managed by your system

– remember that any details that appear at this level must be traceable in the implementation of your design!

• http://www.cs.princeton.edu/courses/archive/spr06/cos116/FSM_Tutorial.pdf

Step 2

• decompose the system – this core FSM, which will eventually be

implemented in your main task,

– functionality consisting of helper functions

• captured in a Sequence Diagram

• http://www.agilemodeling.com/artifacts/sequenceDiagram.htm

Step 3

• helper functions contain key logical structures of the system

• they may require abstraction of tasks into further helper functions– such as state manipulation with conditional

execution

• http://www.agilemodeling.com/artifacts/flowChart.htm

Bridge Simulator Software

• No sensor/motor I/O in the simulation– HOW?!– Debugger!

• No global variables– Why?– Can have constants!

• No GOTOs– WHAT???– Loads of all the necessary control structures!

FSM

• Core of the main function (task!)while(true) {

switch( <current state> ) { case( <state 1> ): //more here… break;

case( <state 2> ): //more here…

break; //more cases?

default: //invalid state!!! } }

Debug Mode: Step and Modify Data

• infinite loop!?

• state transitions– modifying actual data values while stepping

through the execution of the program in debug mode

• control flow should be handled by appropriate mechanisms that are common to high level programming languages– no GOTOs!

Enumerated types and structs!

• Want them to build robust software…

//FSM statestypedef enum {

CARS = 0, BOATS = 1 } T_bridge_state;

//Positions for gates/bridgestypedef enum {

DOWN = 0, UP = 1 } T_position;

//States and transitions for a bridge system typedef struct {

T_position gate; T_position bridge;

//system state T_bridge_state system_state;

//… more here!!!} T_bridge system;

Data Types and Structures

• RobotC allows you to organize data – enumerated data types and structures

• accomplish traceability between design and implementation

• naming convention – identifier name for an enum or a struct starts with

“T_” to signify the definition of a new “Type”

– the compiler will leverage to ensure compatibility

Functional Decomposition

• Might be an issue with structs and params…

• Reference type parameters DO work though!

• Note that these data types should be global– other than that, all other data that is not constant

(const) should be local

void init_controls(T_position &gate, T_position &bridge, T_bridge_state &state) {gate = UP;bridge = DOWN;state = CARS;

}

Environment is GREAT!

CHANGE VALUES ON THE FLY!!!

Best line ever…

Marking…Criteria

Fail(1-3)

Below Expectations(4-5)

Meets Expectations(6-7)

Exceeds Expectations(8-10)

Design artefacts (FSM, sequence diagrams, and flow charts) are well laid out, easily followed?

Artefacts are incomplete, inaccurate, or hard to follow.No clear relationships between artefacts.

Completeness and accuracy are somewhat clear, but compromised in some way.Relationships need to be clarified.

Requirements are met by design artefacts.Relationships between them are traceable.

Design is thoughtful and extensible. Good use of abstraction and separation of concerns.Relationships are conveyed in a clear and concise manner.

Does the implementation match the design?

No traceability between design and code.

Somewhat traceable, could be improved.

Sufficiently traceable throughout.

Clearly traceable through all artefacts.

Is data flow clear (data structures, parameters)?

No clear data flow or structures.

Data structures and data flow are managed, but could be clarified further.

Sufficient use of data structures, and data flow.

Clear and well documented, extensible data structures and thoughtful use parameters for data flow.

Is the implementation clear (functional decomposition, documentation, identifier names)?

The RobotC program lacks clarity.

Decomposition could be improved.

Clear, and sufficient use of abstraction.

Clear and well documented, highly extensible with platform specific details abstracted appropriately