23 September

1
23 September

• Presentations
• Design

2
Demo 1 Purpose

• You dont understand something until youve
  taught it
• Clarification of your thought process and
  understanding
• Sharpen your understanding of the project
• Facilitate sharing
• Learn from each other
• Practice presenting

3
Logistics

• 15 minute presentations (excluding set up)
• Copies of charts to be posted on website
• Email me attachment or link
• Full attendance is expected

4
The Basics

• Speak loudly and clearly
• Stand up
• No chewing gum when speaking
• Speak, dont read you ARE the experts
• Practice, practice, practice
• Set up and test demos and laptops early and
  again the day you present

5
Presentations Hints

• Cover all topics, but they dont need equal time!
• Focus on whats special about your project
• Dont try to cover too much
• Keep it light
• Give the audience something to look at

6
Death by PowerPoint

• Google it and you can waste many hours
• One that I like
• http//www.slideshare.net/thecroaker/death-by-powe
  rpoint
• PowerPoint is Evil (Edward Tufte)

7
Presentations Grading

• Content and style count
• Single grade for group
• Everyone does need to present but not equally

8
Presentation Content

• Motivation
• Introduction to the area and project
• Key domain problems to be addressed
• Users
• Who are they
• What do they need to do
• Design
• Architecture
• Key technical problems to be addressed
• Technologies being used (and why)
• Demo
• Any interesting whys

9
Examples of Architecture Pictures
10
Design

• A Little Structure

11
Software Engineering Elaborated Steps

• Concept (contract, intro on web site)
• Requirements (use cases, requirements)
• Architecture
• Design
• Implementation
• Unit test
• Integration
• System test
• Maintenance

12
Documenting Your Design

• Two types of documentation
• How the system fits together
• Critical to understanding
• Not easily captured in the code
• External documentation required
• The details of the implementation
• Captured in the code
• Components
• Inline comments
• Doxygen

13
Design Overview

• Start with a picture of your architecture
• What other models are needed?
• Data flow?
• Data model?
• State transition?
• Key considerations
• What are the hard parts of the work?
• What are the critical areas?

14
Detailed Design

• Build on well understood patterns from the system
  design
• Goal is to prepare the project for implementation
• Includes
• Module definitions
• Processes (if relevant)
• Data definitions
• Design decisions

15
From System Design to Detailed Design

• A Little Structure

16
Use Cases, System Detailed Design
17
Domain Classes

• Object-oriented paradigm, not implementation
• Domain application specific
• Classes defined in natural language
• Used to explain the architecture and design
• Classes derived from the requirements
• Need not match the implementation
• Hard to not fall into that trap

18
Domain Classes Matching Implementation Classes

• Benefits
• Simplicity of mapping
• Drawbacks
• Later changes
• No worse off then if not matched
• May be too early for implementation decisions

19
Defining Domain Classes

• Begin with Use Cases
• Identify nouns
• External agents are not domain classes
• Are these key classes for the application?
• Are there others?
• Identify attributes and functionality for each
  class
• Validate
• Walkthrough use cases
• Try changes and extensions
• Look for
• Missing attributes or functions
• Changes that reach every where

20
Bridge Example
Cars should be able to travel from the top of
Smith Hill at 65 mph, travel in a straight line,
and arrive at Jones Hollow within 3 minutes.
Auto
Road
21
Class exercise teacher portal

• Want to identify
• Classes
• Attributes
• Functions

22
Use Cases for a Teacher Portal

• teacher presented with view with his content
• read messages from other teachers and
  administrators
• schedule an assessment
• selects class
• selects test based on difficulty and subject
• create new test
• create new question
• type of question
• introductory text
• possible answers
• correct answer
• edit existing question
• edit full test
• post message
• content
• recipient
• view class content

Classes Attributes Functions
23
Use Cases for a Teacher Portal

• teacher presented with view with his content
• read messages from other teachers and
  administrators
• schedule an assessment
• selects class
• selects test based on difficulty and subject
• create new test
• create new question
• type of question
• introductory text
• possible answers
• correct answer
• edit existing question
• edit full test
• post message
• content
• recipient
• view class content

Classes Attributes Functions
24
Use Cases for a Teacher Portal

• teacher presented with view with his content
• read messages from other teachers and
  administrators
• schedule an assessment
• selects class
• selects test based on difficulty and subject
• create new test
• create new question
• type of question
• introductory text
• possible answers
• correct answer
• edit existing question
• edit full test
• post message
• content
• recipient
• view class content

Classes Attributes Functions
25
Use Cases for a Teacher Portal

• teacher presented with view with his content
• read messages from other teachers and
  administrators
• schedule an assessment
• selects class
• selects test based on difficulty and subject
• create new test
• create new question
• type of question
• introductory text
• possible answers
• correct answer
• edit existing question
• edit full test
• post message
• content
• recipient
• view class content

Classes Attributes Functions
26
Back to Detailed Design

• What are we starting with?
• Domain classes
• System design models
• Use cases
• What do we need to do?
• Define implementation classes that
• realize the domain classes
• within the architecture framework
• and implement the functions defined in the use
  cases

27
Bridge Example Completed
2. Domain classes
3. System Design
1. Use case Cars should be able to travel from
the top of Smith Hill at 65 mph, travel in a
straight line, and arrive at Jones Hollow within
3 minutes.
Auto
Road
4. Detailed Design
Auto
Cable
Guardrail
Road
Smith Hill
Pylon
Jones Hollow
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
28
Design Principles

• Correctness
• Robustness
• Flexibility
• Reusability
• Efficiency

29
Correctness

• Always a goal. Others may be negotiable.
• Definition satisfies all of the applications
  requirements
• How do we know the requirements are correct?
• Approaches
• Inspections
• Readable (I didnt have time to write a short
  letter, so I wrote a long one instead.)
• Modular
• Formal verification
• Invariants, pre- and post-conditions
• Usually used only in critical components

30
Robustness

• Ability to handle anomalous situations
• Techniques
• Verifying input
• Initialization
• Parameter checking
• Range
• Constraints
• Husk and kernel

31
Importance of Robustness USS Yorktown (1998)

• Guided missile cruiser that suffered widespread
  system failure off the coast of Virginia
• Dead in the water for more than two hours
• Crew member mistakenly entered a zero in a data
  field of an application
• Divide by zero
• Buffer overflow
• Shut down the propulsion system