The document provides an overview of software design concepts and artifacts including finite state machines (FSM), sequence diagrams, and flow charts. It outlines the goals and requirements of an assignment to design, implement, and test a bridge control system simulation using these artifacts and the RobotC programming language. Key aspects are to demonstrate the relationship between design and implementation through traceability between artifacts and clear expression of control and data flow.

1. Software Tutorial (unplugged) Check out Moodle for Design Assignment 1 ! GOAL: validate a good DESIGN, then map your DESIGN into CODE…

2. Before FRIDAY NIGHT… Please fill in this survey! Tutorial Overview: http://spreadsheets.google.com/viewform?formkey=dE1yNW10UVRSMWNGUTZ5dHRKOEplVUE6MA

3. 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

4. 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!

5. 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

6. 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…

7. 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

8. Finishing Touches? Might be questionable! Proof-reading: putting on finishing touches … could be implementation and testing… BUT THOSE AREN’T FINISHING TOUCHES!!!

9. WaterFall Model Not real… [picture http://en.wikipedia.org/wiki/Waterfall_model]

10. 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

11. Sashimi Model greater overlap between phases difficulty in determining milestones? [picture http://www.acidaes.com/SWM.htm]

12. Cool, but not what you are doing! 3 artefacts FSM Sequence diagram Flow charts 3 people! How perfect is that?

13. 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

14. 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

15. Draw the FSM diagram core structure in the system

16. Sequence Diagrams each function has a “lifeline” parameters and return values marked

17. Call diagram for Sample Program getName getAstrologicalSign getHoroscope sign horoscope name sign getBirthMonth getBirthDay main month day

18. Flow Charts conditional execution branching looping algorithm is revealed in this form diamonds are decisions rectangles are statements

19. Flow Charts

20. Greencard?

21. User Interfaces?

22. 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

23. 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.

24. What? When? Where? first draft of design artefacts must be ready at the beginning of lab the week of January 11 th beginning of lab the week of January 18 th hard copies of all artefacts electronic submission of RobotC program after your lab instructor has signed off Jan 11 th the rest of the lab time will be spent on this assignment get it done!

25. 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

26. 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

27. 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

28. 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

29. 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!

30. 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!!! } }

31. 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!

32. Enumerated types and structs! Want them to build robust software… //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. 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

34. 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; }

35. Environment is GREAT!

36. CHANGE VALUES ON THE FLY!!!

37. Best line ever…

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