Software Design Methodologies

1
Software Design Methodologies

• Dr. Mohamed Fayad, Associate Professor
• Department of Computer Science Engineering
• University of Nebraska, Lincoln
• Ferguson Hall, P.O. Box 880115
• Lincoln, NE 68588-0115
• http//www.cse.unl.edu/fayad

2
Lesson 4 Object Identification - 1
2
3
Lesson Objectives

• Understand object identification class
  classification
• Learn how to identify
• Objects and classes
• Textual Specification Analysis
• Data Analysis
• Behavior Analysis
• Use Case Analysis
• Associations and aggregations using Abbott's
  approach
• Understand how to use the following approaches
• Data Analysis
• Use Case

3
4
Classification Involves Ordering Knowledge

• Finding Similarities
• Common Attributes
• Common Behaviors
• OO Classifies Software
• Exposes existing commonalities
• Invents stable abstractions
• Goal is a simple natural design

4
5
No Single Best Classification Structure

• Depends upon
• Domain
• Application
• Experience
• Creativity

Water Animals
?
5
Air Animals
Land Animals
6
Same Object Can Be Perceived from Several
Perspectives
Responsibility-Driven carry things,
communicate, maintain its living system
Data-Driven head, tail, body, leg
6
Behavior-Driven walk, run, eat
7
Object/Class Identification Techniques

• Textual Specification Analysis
• Data Analysis
• Behavior Analysis
• Use-Case Analysis
• Responsibility Analysis

7
8
Textual Analysis Approach

• Abbotts Noun Approach
• Use noun, pronoun, and noun phrases to identify
  abstract objects and classes.
• Use singular proper nouns (e.g., sensor number 5)
  and nouns of direct reference (e.g., the fifth
  sensor) to identify abstract objects.
• Use plural and common (e.g., sensor) nouns to
  identify classes.
• Use verbs and predicate phrases (e.g., are
  simultaneously activated) to identify the
  associated operations.
• Comments
• This approach is the oldest approach

8
9
Textual Analysis Approach

• Benefits
• Easy for beginners to use
• Abbotts mapping should usually work
• Can be used with pre-existing textual
  requirements specifications
• Does not require a complete paradigm shift
• Risks
• Indirect
• Many software engineers are weak in grammar
• English is vague, Examples
• Some nouns can be used as verbs and vis versa
• Some words (e.g., purchase, record) can be used
  as both nouns and verbs
• Assumes users requirements are coherent,
  complete and correct
• No tool support

10
10
Selecting Good Classes

• Classes should make sense in the problem domain.
• Good classes classify the objects which need to
  be modeled in the system.
• Classes often correspond to NOUNS.
• Avoid redundant or irrelevant classes which add
  no value in the problem domain.
• Remove classes which have no attributes.

12
11
Elimination of Inappropriate Classes

• After initial pass, discard classes which are
• Redundant
• Irrelevant to the problem domain
• Vague
• Attributes
• If class name has no attributes of its own, it is
  probably an attribute.

11
12
Example 1 Simple Cash Register

• The Problem Statement
• A simple cash register has a display, an
  electronic wire with a plug, and a numeric
  keypad which has keys for subtotal, tax, and
  total. This cash storage device has a total key
  which triggers the release on the drawer. The
  numeric buttons simply place a number on the
  display screen, the subtotal displays the
  current total, the tax key computes the tax, and
  the total key adds the subtotal to the tax.
• Identify all the classes in this problem
  statement
• Use the class elimination rules to eliminate the
  unnecessary classes.

12
13
Classes in the initial pass

• We are going to use nouns to find classes
• Nouns (initial)
• Register Display Wire
• Plug Keypad Keys
• Devices Release Drawer
• Buttons Screen Number
• Total Tax
• Nouns (General Knowledge)
• 0-9 keys
• Money
• Subtotal Key
• Tax Key
• Total Key

13
14
Eliminating Unnecessary Nouns

• Screen --- Redundant
• Number --- Attribute
• Total --- Attribute
• Tax --- Attribute
• 0-9 Key
• Value --- Attribute
• Money
• Subtotal Key
• Tax Key
• Total Key

• Register
• Display
• Wire --- Irrelevant
• Plug --- Irrelevant
• Keypad
• Keys
• Devices --- Vague
• Release --- Irrelevant
• Drawer
• Buttons --- Redundant

14
15
Data Analysis Approach
1. Identify abstract objects as table
3. Identify relationships between objects
Dog
Name Breed Owner Name
Happy Poodle Joe Tasha Pit Bull
Eric King, Jr. Shepherd Carol
Dog Owner
Name Address
2. Identify instances as rows in table
Carol 2601 Lake St.
15
But how do you find your abstract objects?
16
Analyzing the Domain for Abstract Objects

• Tangible things -- airplane, book, table
• Roles -- doctor, professor
• Incidents -- accident, flight
• Interactions -- purchase, marriage
• Specifications -- insurance policy
• People -- humans who carry out some function
• Places -- areas set aside for people or things
• Organizations -- formally organized collections
  of people, resources. and facilities

16
17
Identifying Associations/Aggregations

• Associations often refer to verbs of verb phrases
  
• Examples next to, contains, part of, works for,
  married to, downstream from, connected to, etc.
• These may be explicit in the problem statement or
  implicit in the knowledge of the problem domain
• Write down all candidates, then eliminate
  unnecessary ones and add others
• Aggregation is just a common type of association

17
18
Behavior Analysis

• Data Flow Diagrams (DFDs)
• State-Transition Diagrams (STDs)
• Semantic Nets or Object-Interaction Diagrams
  (OIDs)
• Message or communication Diagrams

18
19
Looking for Behavior

• Examine required Processing or behavior of system
  components
• Objectify common behavior
• Use inheritance
• DFDs may help identify processes

Swimmers
19
Flyers
Runners
20
Data Flow Diagrams (DFDs)

• DFD Approach
• Use each data store on a DFD to identify an
  abstract object or class
• Use (all or part of) the transforms associated
  with data store to identify associated operations
• Candidate Objects
• external entities
• data stores
• control transformations
• Candidate Classes
• data flows

20
21
Data Flow Diagrams (DFDs) (contd)

• Benefits
• Very well-known approach
• Many requirements analysis methods are based on
  DFDs.
• Tool support exists
• Does not require paradigm shift
• Risks
• Data abstraction
• Indirect
• Traditional DFDs have the wrong scope

21
22
State-Transition Diagrams (STDs)

• State Approach
• Identify an object or a class for each entity
  that has a state
• Benefits
• Can be used at any time that an object or a class
  has a finite number of obvious states
• Risks
• The state can belong to the entire subsystem or
  an operation
• An object or a class may have an infinite number
  of states.
• An object or a class may have states that are not
  all obvious.
• An object or a class may have only a small number
  of trivial states.

22
23
Use Case Analysis Baseball System
1
Pitch a Ball
Pitcher
1
Hit a Home Run
1
Batter
Run the Bases
23
1
Runner on First Base
Scored a Run
24
Some Use Cases in Baseball Game

• Base hit
• Single base hit
• In field base hit
• Outfield base hit
• Double base hit
• Triple base hit
• Home run
• A home run
• Two home runs
• Three home runs
• Grand Slam

24
25
A Use Case Description

• Use Case Hit a Home Run
• When a batter hits a home run, the runners run
  the bases and reach home plate and score
• When a batter hits a home run, the batter runs
  the bases until reaching the home plate and
  scores
• When the runners score, the score board updates
  the score board, the game announcer is going
  crazy and saying a big home run ... holy cow
  ... holy cow and the fans are going wild and
  screaming a lot.
• When ..

25
26
Discussion Questions

• 1. Define use case model, use case,
  specification objects, incident objects,
  organization objects.
• 2. List all the object identification techniques
• 3. What are the benefits and risks of each of
  these techniques?
• 4. Describe how do you identify associations
  and aggregations
• 5. Explain
• a. The same object can be perceived from several
  perspectives.
• b. No single best classification structure.
• c. Classification involves ordering knowledge.
• d. How to select good classes
• e. How to eliminate inappropriate classes

26
27
Questions for the Next Lecture

• Check the definition of Classes, Objects,
  Attributes, Interfaces, Abstraction, Behavior,
  Responsibility, Roles, Associations, Aggregation.
  
• Describe the following Models Use Case Model,
  DFD, STD, OID, OCD.

27
28
Tasks for Next Lecture

• Task 1 Problem Statement for team assignments
  are needed (see sample problems on the course web
  site). This is due on the second week of the
  semester.
• Task 2 Think About a problem statement for your
  team Project (see sample problems on the course
  web site). This is due on the fourth week of the
  semester.

28