IST 311 ObjectOriented Design

1
IST 311 Object-Oriented Design Software

• Steven Haynes
• IST 311 Class 2
• 12 January 2006
• shaynes_at_ist.psu.edu

2
The Waterfall Model
Problem Definition
Requirements
Design
Code
Is this really how systems development works?
Test
Implementation
3
The Iterative Waterfall Model
Problem Definition
Requirements
Design
Code
Is this it?
Test
Implementation
4
The Systems Development Funnel
Code
Or is this?
Requirements
Implementation
Test
Design
Design
Problem Definition
Problem Definition
Code
Code
Implementation
Design
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
• Dont 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
• Dont 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 shaynes_at_ist.psu.edu

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