object oriented analysis and design l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Object-Oriented Analysis and Design PowerPoint Presentation
Download Presentation
Object-Oriented Analysis and Design

Loading in 2 Seconds...

play fullscreen
1 / 58

Object-Oriented Analysis and Design - PowerPoint PPT Presentation


  • 296 Views
  • Uploaded on

Object-Oriented Analysis and Design. Lecture 2 Requirements and Specification. Last Time. Functional vs. nonfunctional requirements Eliciting requirements Examples. This Time. More detail on functional and nonfunctional requirements Some ideas on quality requirements

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Object-Oriented Analysis and Design' - finley


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
object oriented analysis and design

Object-Oriented Analysis and Design

Lecture 2

Requirements and Specification

last time
Last Time
  • Functional vs. nonfunctional requirements
  • Eliciting requirements
  • Examples
this time
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
functional requirements
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?
functional requirements5
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)
structured systems analysis
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
modeling the current system
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.
abstracting a logical model
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
identifying deficiencies
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.
data flow diagrams
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

sally s software shop from schach
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.
an initial dfd
An Initial DFD

package data

package details

order

process

orders

Customer

invoice

customer status

customer data

a stepwise refinement
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

fragment of next refinement
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

more ssa steps gane sarsen
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
comments
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!).
essential systems analysis
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
information engineering
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.
object oriented analysis
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!
petri nets schach guha et al
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
a simple petri net
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

petri net with tokens
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

after firing t 1 and t 2
After Firing t1 and t2

p2

Marking: (2,0,2,0)

t1

p1

t2

p3

p4

petri net with inhibitor
Petri Net With Inhibitor

t1 can fire, since p2

is empty, and p3

has a token

p2

t1

p1

p3

the elevator problem
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
elevator problem w petri nets
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
first constraint elevator buttons
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

second constraint floor buttons
Second Constraint: Floor Buttons

FBUf

Ff

Elevator in action

FBUf pressed

Fg

FBDf

Ff

FBDf pressed

Elevator in action

third constraint
Third Constraint
  • If no buttons are illuminated, no transition can fire
documenting functional requirements
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
documenting functional requirements cont
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?
quality requirements
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?
measured conformance
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
conformance cont
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.
meeting user expectations
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
quality metrics assessment
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
measurement of quality
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
shrink wrapped products
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?
textual specifications
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.
textual specs cont
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?
ieee 830
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...
ieee 830 cont
IEEE 830 (cont.)
  • Intro
  • General Description
  • Specific Requirements
    • Functional Requirements
    • External Interface Requirements
    • Performance Requirements
    • Design Constraints
    • Attributes
    • Other Requirements
a requirements template
A Requirements Template
  • A nice outline, provided by Philip Johnson of U. Hawaii
  • Here is a little bit of it...
use cases
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.
what good are use cases
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
how to find use cases
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.
example american factfinder
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.
use case cont
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.
use case cont49
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.
alternate courses of events
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.
american factfinder
American FactFinder
  • Alternate course:
    • If the user is not registered, ask if she would like to register. If so, send the registration page.
    • If the query doesn’t pass pre-processing, return a page giving the bad news.
    • If the query will take more than 15 minutes to process, advise the user, and ask whether to continue.
    • If the query results don’t pass the post-processing filters, return a page with the bad news.
use case notation
Use Case Notation
  • A simple diagram, like this:
  • Pretty stupid, eh?

Request tabulation

Web user

use case dependencies
Use Case Dependencies
  • Pre-conditions may force some use cases to be performed before others are legal.
  • This should be apparent from the textual descriptions, but if you love diagrams:

Register

Request tabulation

use case hierarchies
Use Case Hierarchies
  • If there is commonality among several use cases, the common parts can be extracted.
  • Looking the other way `round, one use case can extend another.
  • Reminiscent of abstract classes and subclasses.
finding potential objects
Finding Potential Objects
  • A use case may suggest objects that are relevant to the system.
  • These will be “analysis-level” objects, not all that will eventually be written.
  • Look for nouns in the use case description; these are “potential” objects.
  • Screen these for
    • Relevance
    • Attribute?
    • Out of scope?
  • Keep the rest for design time.
when are you done
When are you done?
  • When you have named all actors
  • When you have captured all the user goals with respect to the system
  • When each use case is clear enough that:
    • the customer can understand them and agree on the behaviour
    • the developers can understand them and agree that they can design against the behaviour specified
  • Remember that is is an incremental process
sources for this lecture
Sources For This Lecture
  • P.O. Flaatten, D.J. McCubbrey, P.D. O’Riordan, K. Burgess, Foundations of Business Systems, 2nd ed., The Dryden Press, 1992.
  • S. Schach, Object-Oriented and Classical Software Engineering, McGraw-Hill, 2002.
  • C. Gane and T. Sarson, Structured Systems Analysis, Prentice Hall, 1979
  • J. Martin and J.J. Odell, Object-Oriented Methods: A Foundation, Prentice Hall, 1995.
more sources
More Sources
  • Jacobson, I., Object-Oriented Software Engineering, Addison-Wesley 1992.
  • Booch, G., Object-Oriented Analysis and Design, 2nd ed., Addison-Wesley 1994.
  • Whitten, J.L. and L.D. Bentley, Systems Analysis and Design Methods, McGraw-Hill, 1998.
  • R. Guha, S. Lang, M. Bassiouni, “Software specification and design using Petri nets,” Proc. Fourth Int. Workshop on Software Specification and Design, pp. 225-30.