Object-Oriented Analysis and Design

1. Object-Oriented Analysis and Design Lecture 2 Requirements and Specification

2. Last Time • Functional vs. nonfunctional requirements • Eliciting requirements • Examples

3. This Time • More detail on functional and nonfunctional requirements • Some ideas on quality requirements • Comments on textual specifications • A little on IEEE 830 • Use cases

4. Functional Requirements • “What the system is supposed to do, but not how to do it.” • Basic problems: • How do we go about determining requirements? • How do we go about documenting requirements?

5. Functional Requirements • We hope for a foolproof (?) way of specifying a system. • Natural language may be too vague. • Over the years, we have seen various methods • data oriented • process oriented • behavior oriented • Formal techniques (Petri nets, Z)

6. Structured Systems Analysis • Oriented toward automating existing procedures. • Initiated when we discovered that ½ of all business systems never completed, other ½ cost 3estimate. • Abstract a “logical system” from the current physical system by removing implementation details. • Look for inadequacies. • Find solutions to them. • Implement

7. Modeling the Current System • Look for “data flows” - information coming in, leaving, or passed from one worker to another. • Look for “processes” - places where data are transformed. • Look for “data stores.” • Try to diagram all this. • Look for inconsistencies.

8. Abstracting a Logical Model • Ignore how things are done; eliminate • who performs what • the data medium • duplication of data • temporary data storage • technology dependencies • processes that could be changed without affecting the overall outcome • Document

9. Identifying Deficiencies • Where are the bottlenecks in the current system? • Where can inconsistencies occur? • Are there better processing schemes? • What new features? • Drop old features? • Document again. • Design new system.

10. Data Flow Diagrams Process Data Flow Transforms inputs to outputs Movement of data External Entity Data Store Disk, tape, voice mail... Person or organization providing data

11. Sally’s Software Shop (from Schach) • Sally buys software from vendors & sells to the public. • Sally stocks popular software packages, and special orders others. • Sally extends credit to businesses and some individuals. • Sally has been doing well, but has been advised to computerize.

12. An Initial DFD package data package details order process orders Customer invoice customer status customer data

13. A Stepwise Refinement Software Suplier package data details of package to be ordered package details address place order at software supplier order verify order is valid Customer pending orders credit status customer data details of package on hand assemble orders invoice

14. Fragment of Next Refinement package data package details details of package to be ordered verify order is valid order Customer credit status details of package on hand customer data address delivery note assemble orders details of package received from software agency delivery details invoice create invoice payment apply payment to invoice invoice details payment details accounts rec’v

15. More SSA Steps (Gane & Sarsen) • Decide what sections to computerize • Determine the details of the data flows • Define the logic of the processes • Define the data stores • Define the physical resources (e.g., DBMS) • Determine the I/O spec (user interface) • Determine the sizing • Determine the hardware requirements

16. Comments • This is a tedious, time-consuming process. Stepwise refinement helps. • Following it blindly (as many have done) ignores many opportunities for innovation. • For existing automated systems, it may involve reverse engineering (ugh!).

17. Essential Systems Analysis • A reaction to shortcomings of earlier methods. • A cleaner approach: • identify the system’s purpose in terms of events and responses • identify essential activities comprising the responses • identify data flows necessary for the responses

18. Information Engineering • A greater focus on data structures. • E-R models and process models. • Diagrams, diagrams, diagrams! • A combination of top-down and bottom-up. • CASE support exists.

19. Object-Oriented Analysis • Objects, messages, methods. • Data and process combined into objects. • Objects grouped into classes; classes arranged hierarchically. • A fusion of earlier methods. • We’ll have lots more to say about this!

20. Petri Nets (Schach, Guha et al.) • Invented in 1962 by Carl Petri • Used lots of places in computer science • Good for describing synchronization of concurrent activities • First, a description, then • specify the elevator problem

21. A Simple Petri Net p2 Places P = {p1,…,p4} Transitions T = {t1, t2} Input functions I(t1) = {p2, p4} I(t2) = {p2} Output functions O(t1) = {p1} O(t2) = {p3, p3} t1 p1 t2 p3 p4

22. Petri Net With Tokens Marking: (1,2,0,1) t1 and t2 can fire p2 t1 p1 t2 p3 If t1 fires, the marking becomes (2,1,0,0) p4

23. After Firing t1 and t2 p2 Marking: (2,0,2,0) t1 p1 t2 p3 p4

24. Petri Net With Inhibitor t1 can fire, since p2 is empty, and p3 has a token p2 t1 p1 p3

25. The Elevator Problem • n elevators in a building with m floors • Each elevator has m buttons • light on when pressed, light off when elevator gets there • Each floor (except 1st and mth) has 2 buttons (up and down) • light on when pressed, light off when elevator gets there, going in correct direction • If no requests, an elevator remains at the current floor with doors closed

26. Elevator Problem w/ Petri Nets • Each floor represented by a place Ff, 1<f<m • An elevator is represented by a token • A token in Ff means that an elevator is at floor f

27. First Constraint: Elevator Buttons • We need more “places”: EBf,e with 1  f  m, 1  e  n • To keep things simpler, just use EBf with 1  f  m EBf Ff Elevator in action EBf pressed Fg

28. Second Constraint: Floor Buttons FBUf Ff Elevator in action FBUf pressed Fg FBDf Ff FBDf pressed Elevator in action

29. Third Constraint • If no buttons are illuminated, no transition can fire

30. Documenting Functional Requirements • Prose, obviously, but this can be ambiguous. • Diagrams of every sort: • DFDs • E-R diagrams • Process diagrams • State diagrams • Context diagrams • Petri nets

31. Documenting Functional Requirements (cont.) • CASE tools; often built around one methodology. • Make drawing and storing diagrams easier. • Are they user-friendly, as well as analyst-friendly? • Can they integrate various views (data, process, behavior)? • Do they compile?

32. Quality Requirements • Defining quality: • Measured conformance with specs • Quality as satisfied users • What does the user expect? • Expectations vs. specifications. • How can we measure quality in advance of implementation?

33. Measured Conformance • The old days: • You made a gear • Someone measured it • Kept it, scrapped it, or reworked it • Then: notion of process defect • Later: • Feedback • Quality circles

34. Conformance (cont.) • Continuous process improvement requires statistical quality control: the process is stable. • Manufacturing is different than IS: • Objective measures harder to come by • How to tie dissatisfaction with the development process? • Quality improvement is not usually institutionalized.

35. Meeting User Expectations • Expectations include • meeting contractual agreements • meeting functional specs • quantified and unquantified goals for usability, reliability, availability, performance, security, maintainability • “no surprises” • benefits justify cost

36. Quality Metrics & Assessment • Budget and schedule: easy • Performance (response times, hardware resources, throughput): fairly easy to “design in,” if realistic • Reliability (accurate & complete, available, bug-free, fast recovery): hard to measure at design-time • Usability (ease of learning, ease of use): relies on an “architectural metaphor”; prototypes can help • Flexibility: modern design ideas (O-O) help

37. Measurement of Quality • Quality requirements are either met or not met (just like any other). • Metrics are necessary, otherwise the requirement is academic. • Some metrics are easy to come by • “response time less than 2 seconds for 95% of transactions” • Some aren’t so easy • 4 hours training, then novice can do transaction X in 30 seconds

38. Shrink-Wrapped Products • No client + no sponsor = no rules? • Developers need to think like upper management: what’s the “Technology Plan”? • Think in terms of multiple releases. • What is the competition doing? • McCarthy speaks of these features: strategic, competitive, customer satisfaction, investment, and paradigmatic. • Wouldn’t this attitude work everywhere?

39. Textual Specifications • The requirements document may be the most important thing you write. • Define exactly what the software will do; if it “shall” have some property, how will you determine if it does? • There are many “standards” for SRS, and your organization may have one of its own.

40. Textual Specs (cont.) • Questions: • What is the function of the spec? • What is the uncertainty in the project? • What is the management view of the spec? • Who are the readers? • Are there local conventions?

41. IEEE 830 • A standard devised by volunteers (good ones!) • 1983, but many revisions. • See http://standards.ieee.org for the details • Basically, it looks like...

42. IEEE 830 (cont.) • Intro • General Description • Specific Requirements • Functional Requirements • External Interface Requirements • Performance Requirements • Design Constraints • Attributes • Other Requirements

43. A Requirements Template • A nice outline, provided by Philip Johnson of U. Hawaii • Here is a little bit of it...

44. Use Cases • One way to describe a system is by defining its intended uses. • A “use case” is a sequence of steps (a scenario) for completing a required task. • A use case is initiated by an “actor” • Course enrollment: an actor might be a student • Nightly report: the actor is the system itself • Banking: an actor is an ATM • An actor is anything that needs to interact with the system.

45. What Good Are Use Cases? • Validate requirements, make sure nothing is missed • View system from an external viewpoint • Help identify system objects • Basis for test plan • Basis for user manual

46. How to Find Use Cases? • Any of the methods described previously • Interviews • JAD • System context model • Examining current systems & practice • Prototypes • A “user” may have many roles, i.e., be many different actors. Identify roles and activities.

47. Example: American FactFinder • Use case name: Request tabulation • Actor: Web user • Description: Describes the process of submitting a request, processing it, and responding to the actor. • Normal course: • This use case is initiated when the user clicks the Request Tabulation button on our Web site.

48. Use Case (cont.) • The user selects the base table (census, business, health, etc.), then selects attributes. • The user submits the request by clicking OK. • The query is checked by the pre-processing filters. • The query is submitted to the database. • The result is checked by the post-processing filters. • The result is returned to the user.

49. Use Case (cont.) • Precondition: The user has registered. • Post-condition: The query details have been logged. • Assumptions: The user has cookies enabled; session remains open during processing.

50. Alternate Courses of Events • Things don’t always go smoothly! • Exceptional conditions are recorded in one or more “Alternate Course” blocks. • These describe reasons why the normal course isn’t followed, and what alternate actions are performed.