OBJECT-ORIENTED DESIGN JEAN SIMILIEN. WHAT IS OBJECT-ORIENTED DESIGN? Object-oriented design is the…
Object-Oriented Analysis and Design Lecture 2 Requirements and Specification.
-
date post
20-Dec-2015 -
Category
Documents
-
view
215 -
download
3
Transcript of Object-Oriented Analysis and Design Lecture 2 Requirements and Specification.
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
Comments on textual specifications A little on IEEE 830 Use cases
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 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 Oriented toward automating existing
procedures. Initiated when we discovered that ½ of all
business systems never completed, other ½ cost 3estimate.
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 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
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
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
Data StoreExternalEntity
Transformsinputs to outputs
Movementof data
Disk, tape,voice mail...
Person or organizationproviding data
Process
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
Customer
customer data
package data
processorders
order
invoicecustomer status
package details
A Stepwise Refinement
Customer
package data
verifyorder isvalid
order
customer data
credit status
packagedetails
assembleorders
invoice
details ofpackageon hand
pending orders
details ofpackage tobe ordered
place orderat softwaresupplier
SoftwareSuplier
address
Fragment of Next Refinement
verifyorder isvalid
package data
customer data
credit status
package details
Customer order
assembleorders
createinvoice
applypayment toinvoice accounts rec’v
address
delivery details
invoice details
delivery note
invoice
payment details
payment
details of packageto be ordered
details of packageon hand
details of packagereceived fromsoftware agency
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
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
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
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
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.)
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
p1
p2
p3
p4
Places P = {p1,…,p4}Transitions T = {t1, t2}Input functions I(t1) = {p2, p4}
I(t2) = {p2}
Output functionsO(t1) = {p1}O(t2) = {p3, p3}
t1t2
Petri Net With Tokens
p1
p2
p3
p4
t1t2
Marking: (1,2,0,1)t1 and t2 can fire
If t1 fires, themarking becomes(2,1,0,0)
After Firing t1 and t2
p1
p2
p3
p4
t1t2
Marking: (2,0,2,0)
Petri Net With Inhibitor
p1
p3
t1
t1 can fire, since p2
is empty, and p3
has a token
p2
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 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 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
Fg
Elevator in actionEBf pressed
Second Constraint: Floor Buttons
FBDf Ff
Elevator in action
FBDf pressed
FBUf Ff
Fg
Elevator in actionFBUf pressed
Third Constraint If no buttons are illuminated, no
transition can fire
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.)
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
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
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.)
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
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 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 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
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
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.)
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
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.) Intro General Description Specific Requirements
Functional Requirements External Interface Requirements Performance Requirements Design Constraints Attributes Other Requirements
A Requirements Template
A nice outline, provided by Philip Johnson of U. Hawaii
Here is a little bit of it...
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? 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? 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 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:1. This use case is initiated when the user
clicks the Request Tabulation button on our Web site.
Use Case (cont.)2. The user selects the base table (census,
business, health, etc.), then selects attributes.
3. The user submits the request by clicking OK.4. The query is checked by the pre-processing
filters.5. The query is submitted to the database.6. The result is checked by the post-processing
filters.7. The result is returned to the user.
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 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 Alternate course:
1. If the user is not registered, ask if she would like to register. If so, send the registration page.
2. If the query doesn’t pass pre-processing, return a page giving the bad news.
3. If the query will take more than 15 minutes to process, advise the user, and ask whether to continue.
4. If the query results don’t pass the post-processing filters, return a page with the bad news.
Use Case Notation A simple diagram, like this:
Pretty stupid, eh?
Request tabulationWeb user
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:
Request tabulationRegister
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 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 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
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 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.