1. From the customer’s perspective the SRS is: How smart people are going to solve the problem that was stated in the System Spec. A “contract”, more or less Is it doable?  Technically  On time  Under budget Modified from Buckley

2. Remember, Reality is NOT what we might wish it to be! Economic Political Technical Where is the BEST Solution?

3. Now the team has to decide: Software Architecture  Object Oriented?  Structured?  Database Oriented (Informational Flow)? Major Modules including utilities Modified from Buckley

4. Phase II – What happens next! Documenting the development approach  Top Level Design Document  Detailed Design Documents per module  Test Procedure  User and Technical Manuals (C) Buckley

5. What happens next! Top-Level Design is possible TLDD – Top Level Design Document Structure Charts / Object Charts Major Module Interfaces  module-to-module  hardware to software  drivers to control Modified from Buckley

6. The “Approach” Software Development Methodology  Waterfall  Staged / Evolutionary Integration Thread – what gets built and tested first  Development order  Parallel development explored What can or should be Prototyped Delivery Schedule

7. Integration Thread Approach “Big Bang Approach – Design everything at once. – Then code everything. – Then try to integrate and debug. – A gazillion errors – No adaptation to changing requirements – Some errors require re-design, not just recode © Buckley

8. Integration Thread Design and develop a single function “core” Must represent fairly the entire known system Must be capable of driving…. © Buckley

9. Structured Design

11. Supervisory Requirement

12. Programming for Structured Design Single-context – only one thing runs at a time If multiple context is needed (6 joints), each must be tracked and kept separately Supervision must jump between them on an adaptable schedule Re-use is limited to duplicate / redundant code All code is created at once, persists until the end Communication between modules does not exist – info is passed, held, then accessed in three steps

13. Programming for Structured Design Well used modules require a high-degree of customization (control coupling) A structured approach to designing software involves breaking the problem at hand into algorithms, formulas, and procedures that sufficiently describe the designer’s view of a system It depends upon the designer’s ability to cover the problem with a solution based on computer storage, mathematical operations, and the correct sequence and timing of calls to subroutines that each perform smaller steps.

14. Programming for Structured Design In structured programming, the designer has at his disposal only four operations, or algorithms:  concatenation (the serial execution of lines of code in order)  iteration (repeated execution of small steps in order to accomplish a larger task, as in a for-loop)  alternation (a yes/no decision, as in an “if” statement)  transfer of control (a supervisory decision to jump to a subroutine based on conditions). Data structures – records and arrays – help in organizing the storage and presentation of data. Memory and I/O ports query the environment and deliver results to users.

15. The Shoulder Joint

16. Consolidate Effort Across 6

17. 6 “States” must be kept

18. Object Oriented Design

19. Looks Like the Problem Space

20. Object Oriented Design Those tasks are objects, and they exist concurrently and are simultaneously persistent. They each operate independently of the system, yet have access to the system’s collective resources. They have a known, dependable interface – or contract – with the system to provide responses to stimuli in a dependable form.

21. Object Oriented Design Their creation and destruction, activation and sleep are, at the control of the designer. They have a capability that no structured module can approach: their exact form, their behavior, the domain in which they operate, and their use of system resources can be customized at run-time. They are perfectly suited to model complex, large, real world problems and systems.

22. Object Oriented Philosophy  Object Oriented design represents a philosophical difference from structured design.  OO Design is one of independence of function rather than supervisory control. Objects operate as small, independent computers; each with a specific job to do when the environment in which they operate presents the proper stimulus.  The major design task in an object-oriented architecture is inter-object communication and the coordination of independently running “computers” to collectively perform a coherent function. It more closely resembles the real world.

23. The Robot Joint Class

24. A Reduced Programming Task All of the effort goes into a well-designed Joint Class Reduced programming time Extended utility of each Joint The maintainability of a program is related to its complexity.  Complexity is not dependent on size but is based on the decision structure of the program.  One of the reasons that maintenance costs are high is that the structure of the system, which has to be modified, is non- existent, either through lack of design, indirect implementation, or the effects of continuing changes.

25. OO is a Run-Time Philosophy OO extends beyond the use of Inheritance, Polymorphism, and Encapsulation during programming. OO involves the run-time advantages of concurrency, persistence, selective activation and deactivation, and independence of instances.