1. IST 311 – Object-Oriented Design & Software
Steven Haynes
IST 311 – Class 2
12 January 2006

2. The ‘Waterfall’ Model Is this really how systems development works?
Problem Definition
Requirements
Design
Is this really how systems development works?
Code
Test
Implementation

3. The Iterative ‘Waterfall’ Model
Problem Definition
Requirements
Design
Is this it?
Code
Test
Implementation

4. The Systems Development ‘Funnel’
Code
Or is this?
Requirements
Implementation
Test
Design
Design
Problem Definition
Problem Definition
Code
Code
Implementation
Design
ISD allows us to convert a mess to:
- No mess
- Less mess
- A better mess
- A different mess
- A bigger mess
Need requirements analysis to judge feasibility, need feasibility to get budget to pay for requirements analysis.
Requirements
Test

5. Object-Oriented Software Engineering

6. Important Software Engineering Activities

7. Software Engineering: Requirements
A functional requirement is a specification of a function that the system must support;
A nonfunctional requirement is a constraint on the operation of the system that is not directly related to system functions (e.g., usability, response time, security requirement, etc.).

8. Software Engineering: Notations
A notation is a set of rules for representing a model graphically or textually. (e.g., UML, Z).
A software development methodology is a collection of methods for solving problems during software process; it specifies how and when each method should be used.
OMT (Object Modeling Technique, Rumbaugh, 1991)
OOSE (Jacobson, 1992)
Booch methodology (Booch, 1994)

9. Scenario-Based Design *
Scenarios are used to explicate and evaluate requirements, evolving designs, and systems in production
Envisioning scenarios – used to imagine what and how interaction support will be delivered by the system being designed
Evaluation scenarios – used to walk through an existing design to ensure that the model supports desired interactions
Scenarios are concrete instances of a use case
* Carroll & Rosson, 1992; Carroll, 1995; Carroll, 2000

10. Scenario Scenario Title – short description of the scenario
Actor – the person or role performing the scenario
Setting – a description of the context in which the scenario takes place
Scenario Goal – the objective of the interaction with the application being designed
Scenario Narrative – a detailed account of how you envision that the scenario actor will interact with the application to achieve the scenario goal
Claims Analysis – statements of what is required to support the interaction scenario. Claims should include explicit consideration of trade-offs, the pros and cons of different approaches to feature design.

11. Use Cases Actors Use Cases Include (Uses) Use Cases Extend Use Cases
Annotations
Pre-conditions
Post-conditions
Constraints
Don’t use actor or use case generalization

12. Guidelines for Use Cases
Actors – specific user roles
Human actors on left
Non-human actors (systems) on right
Use Cases – verb-noun phrase
e.g., Verify Credit Card
Include (uses) link – included use case MUST be completed for the including use case to complete
Extend link – extending use case represents a variant of the extended use case

13. In-Class Work in ad hoc groups
Using your scenarios from the degree audit domain, create a use case diagram showing all the major functionality the system should have
Don’t forget system administration use cases, though these can be on a separate diagram
Make sure all your names are on the diagram
Send the soft copies to me at

14. Homework Assignment This is an individual assignment
Read Bruegge Ch. 2
Review Ambler Ch.4
Using the MS Visio Static Structure (class diagram) template, design six (6) abstractions (classes) for the degree audit application
Hint: Use your scenarios, noun-verb analysis
Each of your classes should have at least 3 attributes and at least 2 operations (methods)
Include Notes in your diagram describing the basic responsibility of each class
Hand in hard copies of your diagrams at the start of class Tuesday, January 17