Modular Programming
and
Use Case Models
Session 3
LBSC 790 / INFM 718B
Building the Human-Computer Interface
Agenda
•	Coping with complexity

•	Modular programming

•	Modeling use cases
Sources of Complexity
•	Java syntax
–	Learn to read past the syntax to see the ideas
–	Copy working examples to get the same effect
•	Object structure
–	Practice modeling object structures using UML
–	Our focus next week
•	Interaction of data and control structures
–	Our focus last week (“structured programming”)
•	Modularity
–	Our focus this week
Why Modularity?
•	Limit complexity
–	Extent
–	Interaction
–	Abstraction

•	Minimize duplication

Defensive Programming
•	Goal of software is to create desired output

•	Programs transform input into output
–	Some inputs may yield undesired output

•	Methods should enforce input assumptions
–	Guards against the user and the programmer!

•	Everything should be done inside methods
Passing Arguments in Java
•	Call by value
–	Primitive data types
–	Object references
•	The two meanings of “equal”

•	Overloaded method names
–	Depends on parameter type, number, and order

Returning Values in Java
•	Return type declaration
–	No return statement for “void”

•	Return statement causes early termination
–	Multiple return statements can be present
•	First one executed causes termination
–	Type must match declaration
–	Objects encapsulate complex return types
Uses of Methods in Java
•	Constructor

•	Set and get

•	Helper

•	Event handler
–	Stay tuned until we get to GUI’s
The Exercise from Session 2
•	Read the Book class
–	Available on the session 2 notes page

•	Create the Library class

•	Test the two together
From Last Time:
Some Things to Pay Attention To
Syntax
•	How layout helps reading
•	How variables are named
•	How strings are used
•	How output is created
•	How applications are invoked
Structured Programming
•	How arrays are used
•	How boolean flags are used
Modular Programming
•	Modularity of methods
•	How methods are invoked
•	How arguments work
•	How scope is managed
•	How errors are handled
•	How results are passed
Object Structure
•	How classes are defined
Lessons from Homework 1
•	Goal:  Get past the startup difficulties
•	Lessons?
–	Work in groups – it is easier to see past other people’s roadblocks than your own!
–	“Cut and paste” beats “read and reproduce”
–	Start early - unforseen details cost unforseen time
–	Use the mailing list
Show and Tell
•	What cool resources have you found?
–	Books and Web sites?

•	What new Java tricks have you learned?

•	What do you need to know to make progress?
Use Case Design
•	Use Case Diagram
–	Input-output behavior

•	Use Case Narrative
–	Explains  each use case

•	Use Case Scenario
–	Activity diagram shows how the use cases are used together (we’ll save this one for 2 weeks)
Use Case Diagram
•	External “actors”
–	Roles of people
–	Types of systems
•	Use cases 
–	Top-level functions (solid arrows to/from actors)
•	Relationships among use cases
–	Always-depends-on (dashed <<include>>)
–	Sometimes-is-depended-on (dashed <<extend>>)
–	Inherits-from (solid triangle-arrow)
Flight Finder Exercise
Example Use Case Diagram
Use Case Narrative
•	Assumptions
•	Pre-conditions
•	Initiation
•	Dialog
•	Termination
•	Post-conditions
•	Other requirements
–	Open issues, security, audit, …
Exercise Background
•	Search
–	Find every potentially suitable route (a sequence of legs that satisfy traveler-specified criteria and other fixed constraints) and display a summary of each such sequence to the traveler.
•	Select
–	Display the route map, timeline, and text summary for a single sequence of legs selected by the traveler from the search result list. 
Exercise Background
•	Parse Sched
–	Obtain schedule data from the Joint Operational Support Airlift Command (JOSAC) and identify the data for each leg of each flight that is needed to find and display suitable routes.
Exercise Background
•	The traveler or a system adminstrator will first obtain schedule data from JOSAC using their Web browser and store it on their hard drive in the received format.  Upon program initiation, the Parse Sched use case will run automatically.  Once that completes, the traveler may specify the origin, destination, radii around each, and a connection radius (or leave any of the default values set) and then initiate the search.  Once the search completes, the traveler may step through the interesting routes one at a time, viewing information on which their decision might be based.  Once one or more acceptable routes have been identified, the traveler can then contact the appropriate facilities directly to make travel arrangements. 
Project
•	Time to start forming project teams
–	Need to choose a project in the next month

•	Shoot for three-person teams
–	Pay attention to skill balance, not just interests

•	Discuss your project ideas with me
Muddiest Point
On a blank sheet of paper, write a
single sentence that will convey
to me what you found to be the
most confusing thing that was
discussed during today’s class.