IST 311 – Object-Oriented Design & Software

1. IST 311 – Object-Oriented Design & Software Steven Haynes IST 311 – Class 2 12 January 2006 shaynes@ist.psu.edu

2. The ‘Waterfall’ Model 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 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 shaynes@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