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

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

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

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

Object-Oriented Software Engineering

Important Software Engineering Activities

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.).

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)

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

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.

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

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

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

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