Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Software Tutorial (unplugged) Check out Moodle for  Design Assignment 1 ! GOAL: validate a good DESIGN, then map your DESI...
Before FRIDAY NIGHT… <ul><li>Please fill in this survey! </li></ul><ul><li>Tutorial Overview: </li></ul><ul><ul><li>http:/...
Objectives <ul><li>Communicate software design using three different schematic artefacts </li></ul><ul><li>Map software de...
The Mythical Man Month <ul><li>Many good lessons, including </li></ul><ul><ul><li>Brooke’s Law </li></ul></ul><ul><ul><ul>...
Design Artifacts  <ul><li>Finite State Machines </li></ul><ul><ul><li>States and transitions </li></ul></ul><ul><ul><ul><l...
In your Communication’s Text… <ul><li>5 stages of communication </li></ul><ul><ul><li>Predrafting: determining requirement...
ROUGHLY mapping these steps… <ul><li>FSM </li></ul><ul><ul><li>Predrafting: determining requirements of the overall task <...
Finishing Touches? <ul><li>Might be questionable! </li></ul><ul><ul><li>Proof-reading: putting on finishing touches </li><...
WaterFall Model <ul><li>Not real… </li></ul><ul><li>[picture http://en.wikipedia.org/wiki/Waterfall_model] </li></ul>
WICKED! <ul><li>Steve McConnell in  Code Complete  (a book which criticizes the widespread use of the waterfall model)  </...
Sashimi Model <ul><li>greater overlap between phases </li></ul><ul><li>difficulty in determining milestones? </li></ul><ul...
Cool, but not what you are doing! <ul><li>3 artefacts </li></ul><ul><ul><li>FSM </li></ul></ul><ul><ul><li>Sequence diagra...
Finite State Machines <ul><li>a model of behavior composed of a finite number of  states ,  transitions  between those sta...
Eg., Describe the System and Data <ul><li>an elevator </li></ul><ul><ul><li>can be at one of two floors </li></ul></ul><ul...
Draw the FSM diagram  <ul><li>core structure in the system </li></ul>
Sequence Diagrams <ul><li>each function has a “lifeline” </li></ul><ul><li>parameters and return values marked </li></ul>
Call diagram for Sample Program getName getAstrologicalSign getHoroscope sign horoscope name sign getBirthMonth getBirthDa...
Flow Charts <ul><li>conditional execution </li></ul><ul><ul><li>branching </li></ul></ul><ul><ul><li>looping </li></ul></u...
Flow Charts
Greencard?
User Interfaces?
Overview <ul><li>bridge control system </li></ul><ul><ul><li>ensure safe passage of both land and sea traffic </li></ul></...
What to hand in? <ul><li>A fully labelled  Finite State Machine  showing the states and transitions in the system. </li></...
What? When? Where? <ul><li>first draft of design artefacts must be ready at the beginning of lab the week of  January 11 t...
Details <ul><li>in the default state, the bridge is down, services one way car traffic only  </li></ul><ul><li>if a tall b...
Step 1 <ul><li>Design a more detailed FSM for your system  </li></ul><ul><ul><li>clearly label the states and transitions ...
Step 2 <ul><li>decompose the system  </li></ul><ul><ul><li>this core FSM, which will eventually be implemented in your mai...
Step 3 <ul><li>helper functions contain key logical structures of the system </li></ul><ul><li>they may require abstractio...
Bridge Simulator Software <ul><li>No sensor/motor I/O in the simulation </li></ul><ul><ul><li>HOW?! </li></ul></ul><ul><ul...
FSM <ul><li>Core of the main function (task!) </li></ul>while(true) {              switch(  <current state>  ) {          ...
Debug Mode:  Step and Modify Data <ul><li>infinite loop!?  </li></ul><ul><li>state transitions </li></ul><ul><ul><li>modif...
Enumerated types and structs! <ul><li>Want them to build robust software… </li></ul>//FSM states typedef enum {          C...
Data Types and Structures <ul><li>RobotC allows you to organize data  </li></ul><ul><ul><li>enumerated data types and stru...
Functional Decomposition <ul><li>Might be an issue with structs and params… </li></ul><ul><li>Reference type parameters DO...
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 artefact...
Upcoming SlideShare
Loading in …5
×

Software Tutorial Week1 Online 1

1,044 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Software Tutorial Week1 Online 1

  1. 1. Software Tutorial (unplugged) Check out Moodle for Design Assignment 1 ! GOAL: validate a good DESIGN, then map your DESIGN into CODE…
  2. 2. Before FRIDAY NIGHT… <ul><li>Please fill in this survey! </li></ul><ul><li>Tutorial Overview: </li></ul><ul><ul><li>http://spreadsheets.google.com/viewform?formkey=dE1yNW10UVRSMWNGUTZ5dHRKOEplVUE6MA </li></ul></ul>
  3. 3. Objectives <ul><li>Communicate software design using three different schematic artefacts </li></ul><ul><li>Map software design to implementation using explicit control and data flow </li></ul><ul><li>Create software that has qualities of readability, maintainability and evolvability </li></ul>
  4. 4. The Mythical Man Month <ul><li>Many good lessons, including </li></ul><ul><ul><li>Brooke’s Law </li></ul></ul><ul><ul><ul><li>“ Adding manpower to a late software project makes it later” </li></ul></ul></ul><ul><ul><li>Second system effect… </li></ul></ul><ul><ul><ul><li>The general tendency is to over-design the second system </li></ul></ul></ul><ul><ul><ul><ul><li>using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a “big pile.” </li></ul></ul></ul></ul><ul><ul><li>Unintentional interaction </li></ul></ul><ul><ul><ul><li>As time went on, the number of modules that needed modifications per change task kept increasing! </li></ul></ul></ul>
  5. 5. Design Artifacts <ul><li>Finite State Machines </li></ul><ul><ul><li>States and transitions </li></ul></ul><ul><ul><ul><li>Verify system behaviour </li></ul></ul></ul><ul><li>Sequence Diagrams </li></ul><ul><ul><li>Functions and data flow </li></ul></ul><ul><ul><ul><li>Divide and conquer the implementation… </li></ul></ul></ul><ul><ul><ul><li>High level, system as functions </li></ul></ul></ul><ul><li>Flow Charts </li></ul><ul><ul><li>Logic </li></ul></ul><ul><ul><ul><li>Lower level, control flow within functions </li></ul></ul></ul>Land traffic Sea traffic Boat waiting Boat through
  6. 6. In your Communication’s Text… <ul><li>5 stages of communication </li></ul><ul><ul><li>Predrafting: determining requirements of the overall task </li></ul></ul><ul><ul><li>Drafting: roughing out basic components </li></ul></ul><ul><ul><li>Revision: refining organization of components </li></ul></ul><ul><ul><li>Editing: refining flow within components </li></ul></ul><ul><ul><li>Proof-reading: putting on finishing touches </li></ul></ul><ul><li>Makes sense! </li></ul><ul><li>Systematic… </li></ul>
  7. 7. ROUGHLY mapping these steps… <ul><li>FSM </li></ul><ul><ul><li>Predrafting: determining requirements of the overall task </li></ul></ul><ul><li>Sequence Diagram </li></ul><ul><ul><li>Drafting: roughing out basic components </li></ul></ul><ul><li>Sequence Diagram/Flow Chart </li></ul><ul><ul><li>Revision: refining organization of components </li></ul></ul><ul><li>Flow Chart </li></ul><ul><ul><li>Editing: refining flow within components </li></ul></ul>
  8. 8. Finishing Touches? <ul><li>Might be questionable! </li></ul><ul><ul><li>Proof-reading: putting on finishing touches </li></ul></ul><ul><ul><li>… could be implementation and testing… </li></ul></ul><ul><li>BUT THOSE AREN’T FINISHING TOUCHES!!! </li></ul>
  9. 9. WaterFall Model <ul><li>Not real… </li></ul><ul><li>[picture http://en.wikipedia.org/wiki/Waterfall_model] </li></ul>
  10. 10. WICKED! <ul><li>Steve McConnell in  Code Complete  (a book which criticizes the widespread use of the waterfall model) </li></ul><ul><ul><li>refers to design as a &quot;wicked problem&quot; — a problem whose requirements and limitations cannot be entirely known before completion </li></ul></ul><ul><ul><li>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 </li></ul></ul>
  11. 11. Sashimi Model <ul><li>greater overlap between phases </li></ul><ul><li>difficulty in determining milestones? </li></ul><ul><li>[picture http://www.acidaes.com/SWM.htm] </li></ul>
  12. 12. Cool, but not what you are doing! <ul><li>3 artefacts </li></ul><ul><ul><li>FSM </li></ul></ul><ul><ul><li>Sequence diagram </li></ul></ul><ul><ul><li>Flow charts </li></ul></ul><ul><li>3 people! </li></ul><ul><ul><li>How perfect is that? </li></ul></ul>
  13. 13. Finite State Machines <ul><li>a model of behavior composed of a finite number of states , transitions between those states, and actions </li></ul><ul><li>captures important data that must be maintained in the implementation </li></ul><ul><li>similar to a &quot;flow graph&quot; </li></ul><ul><ul><li>can verify the logic when certain conditions are met </li></ul></ul>
  14. 14. Eg., Describe the System and Data <ul><li>an elevator </li></ul><ul><ul><li>can be at one of two floors </li></ul></ul><ul><ul><ul><li>Ground or First </li></ul></ul></ul><ul><ul><li>one button that controls the elevator </li></ul></ul><ul><ul><ul><li>Up or Down </li></ul></ul></ul><ul><ul><li>two lights that indicate the current floor </li></ul></ul><ul><ul><ul><li>Red for Ground, and Green for First </li></ul></ul></ul><ul><ul><li>at each time step, the controller checks </li></ul></ul><ul><ul><ul><li>the current floor and current input, changes floors and lights in the obvious way </li></ul></ul></ul>
  15. 15. Draw the FSM diagram <ul><li>core structure in the system </li></ul>
  16. 16. Sequence Diagrams <ul><li>each function has a “lifeline” </li></ul><ul><li>parameters and return values marked </li></ul>
  17. 17. Call diagram for Sample Program getName getAstrologicalSign getHoroscope sign horoscope name sign getBirthMonth getBirthDay main month day
  18. 18. Flow Charts <ul><li>conditional execution </li></ul><ul><ul><li>branching </li></ul></ul><ul><ul><li>looping </li></ul></ul><ul><li>algorithm is revealed in this form </li></ul><ul><ul><li>diamonds are decisions </li></ul></ul><ul><ul><li>rectangles are statements </li></ul></ul>
  19. 19. Flow Charts
  20. 20. Greencard?
  21. 21. User Interfaces?
  22. 22. Overview <ul><li>bridge control system </li></ul><ul><ul><li>ensure safe passage of both land and sea traffic </li></ul></ul><ul><ul><li>software simulation </li></ul></ul><ul><ul><ul><li>demonstrate the relationship between design and implementation of a simplified control system </li></ul></ul></ul><ul><li>RobotC program </li></ul><ul><ul><li>will not require I/O to include any sensors, motors, or lights </li></ul></ul>
  23. 23. What to hand in? <ul><li>A fully labelled Finite State Machine showing the states and transitions in the system. </li></ul><ul><li>A Sequence Diagram showing both control and data flow at the level of functional decomposition. </li></ul><ul><li>A Flow Chart of the logic within key functions of the system. </li></ul><ul><li>A fully tested implementation of the proposed design as a RobotC program. </li></ul>
  24. 24. What? When? Where? <ul><li>first draft of design artefacts must be ready at the beginning of lab the week of January 11 th </li></ul><ul><li>beginning of lab the week of January 18 th </li></ul><ul><ul><li>hard copies of all artefacts </li></ul></ul><ul><ul><li>electronic submission of RobotC program </li></ul></ul><ul><li>after your lab instructor has signed off Jan 11 th the rest of the lab time will be spent on this assignment </li></ul><ul><ul><li>get it done! </li></ul></ul>
  25. 25. Details <ul><li>in the default state, the bridge is down, services one way car traffic only </li></ul><ul><li>if a tall boat is waiting, cars should be stopped and the bridge should be raised (when safe!) </li></ul><ul><li>once the boat is through, we can return to the default state </li></ul>car traffic boat traffic boat waiting boat through
  26. 26. Step 1 <ul><li>Design a more detailed FSM for your system </li></ul><ul><ul><li>clearly label the states and transitions between these states </li></ul></ul><ul><ul><li>note this will be data managed by your system </li></ul></ul><ul><ul><li>remember that any details that appear at this level must be traceable in the implementation of your design! </li></ul></ul><ul><li>http://www.cs.princeton.edu/courses/archive/spr06/cos116/FSM_Tutorial.pdf </li></ul>
  27. 27. Step 2 <ul><li>decompose the system </li></ul><ul><ul><li>this core FSM, which will eventually be implemented in your main task, </li></ul></ul><ul><ul><li>functionality consisting of helper functions </li></ul></ul><ul><li>captured in a Sequence Diagram </li></ul><ul><li>http://www.agilemodeling.com/artifacts/sequenceDiagram.htm </li></ul>
  28. 28. Step 3 <ul><li>helper functions contain key logical structures of the system </li></ul><ul><li>they may require abstraction of tasks into further helper functions </li></ul><ul><ul><li>such as state manipulation with conditional execution </li></ul></ul><ul><li>http://www.agilemodeling.com/artifacts/flowChart.htm </li></ul><ul><li>  </li></ul>
  29. 29. Bridge Simulator Software <ul><li>No sensor/motor I/O in the simulation </li></ul><ul><ul><li>HOW?! </li></ul></ul><ul><ul><li>Debugger! </li></ul></ul><ul><li>No global variables </li></ul><ul><ul><li>Why? </li></ul></ul><ul><ul><li>Can have constants! </li></ul></ul><ul><li>No GOTOs </li></ul><ul><ul><li>WHAT??? </li></ul></ul><ul><ul><li>Loads of all the necessary control structures! </li></ul></ul>
  30. 30. FSM <ul><li>Core of the main function (task!) </li></ul>while(true) {              switch( <current state> ) {                case( <state 1> ):                        //more here…                        break;             case( <state 2> ):                        //more here…                         break; //more cases?                default:                      //invalid state!!!              }               }
  31. 31. Debug Mode: Step and Modify Data <ul><li>infinite loop!? </li></ul><ul><li>state transitions </li></ul><ul><ul><li>modifying actual data values while stepping through the execution of the program in debug mode </li></ul></ul><ul><li>control flow should be handled by appropriate mechanisms that are common to high level programming languages </li></ul><ul><ul><li>no GOTOs! </li></ul></ul>
  32. 32. Enumerated types and structs! <ul><li>Want them to build robust software… </li></ul>//FSM states typedef enum {         CARS = 0,         BOATS = 1 } T_bridge_state; //Positions for gates/bridges typedef 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;
  33. 33. Data Types and Structures <ul><li>RobotC allows you to organize data </li></ul><ul><ul><li>enumerated data types and structures </li></ul></ul><ul><li>accomplish traceability between design and implementation </li></ul><ul><li>naming convention </li></ul><ul><ul><li>identifier name for an enum or a struct starts with “T_” to signify the definition of a new “Type” </li></ul></ul><ul><ul><li>the compiler will leverage to ensure compatibility </li></ul></ul>
  34. 34. Functional Decomposition <ul><li>Might be an issue with structs and params… </li></ul><ul><li>Reference type parameters DO work though! </li></ul><ul><li>Note that these data types should be global </li></ul><ul><ul><li>other than that, all other data that is not constant (const) should be local </li></ul></ul>void init_controls(T_position &gate, T_position &bridge, T_bridge_state &state) { gate = UP; bridge = DOWN; state = CARS; }
  35. 35. Environment is GREAT!
  36. 36. CHANGE VALUES ON THE FLY!!!
  37. 37. Best line ever…
  38. 38. 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

×