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 5 Object Identification - 2
2
3
Lesson Objectives
Learn how to identify Associations and
aggregations Attributes Behaviors
Inheritance Understand how to use the following
approaches Use Case CRC Questioning
Techniques Understand how to refine objects and
associations Learn how to define
responsibility collaborations Learn how to
eliminate unnecessary classes, associations, and
attributes
3
4
Automated Teller Machine (ATM)
Stop bothering me! I told you I dont have any
money!
4
5
Actors
Customer
Automated Teller Machine
Bank System
ATM Operator
5

• In Use Cases, Everything that interacts with the
  system will be modeled as an actor, such as
  persons as well as machines.

6
Use Cases in ATM
Automated Teller Machine
Cash Withdrawal
Customer
Transfer Funds
Bank System
Deposit Funds
Balance Inquiry
6
System Start
ATM Operator
7
A Use Case Description Cash Withdrawal

• Use Case Cash Withdrawal
• When a customer inserts a card in the ATM, the
  machine reads the code from the card and checks
  if it is a valid card. If the card is valid then
  the machine queries the customer for a PIN
  number, else the card is ejected.
• When the machine matches customer coded in the
  PIN number, the machine checks the validity of
  the PIN number. If the PIN number is correct and
  matches the card number then the machine asks
  for the desired transaction the customer wishes
  to perform.
• When the customer selects cash withdrawal the
  machine asks for the desired amount with a
  warning indicating only multiple of 10 is
  allowed.
• When ....

7
8
Candidate Objects

• Account
• ATM
• Balance Inquiry
• Bank Card Reader
• Cancel Key
• Cash Dispenser
• Deposit Slot
• Deposit Funds
• Display Screen (Bank System Interface)
• Menu (Graphical User Interface)

• User Message
• Numeric Keypad
• Numeric Input Key
• PIN
• Cash
• Receipt Printer
• Special Input Key
• Transfer Funds
• Cash Withdrawal

8
9
System Responsibilities Collaborations

• Define Responsibilities
• What are the goals of the system
• What must objects know to meet goals
• What steps must each object accomplish
• Determine Collaborations
• Decompose responsibilities into interactions
  among objects
• Define clients and servers
• Where should knowledge be held

9
10
CRC Cards

• General
• Each class is described on a separate 3X5 or 4X6
  card
• The cards are known as CRC card. They have 3
  sections
• Class
• Responsibilities
• Collaborations

ATM (role)
Collaboration
Responsibility
Server Clients
Access modify account balance Account (role)
Balance Inquiry Deposit Transaction
Funds Transfer Withdrawal Transaction
10
11
Other Techniques Help Refine Objects

• Generalize and Specialize objects
• Associate Objects
• Recognize Accidental Objects
• Challenging and Testing Objects
• Ask Questions

11
12
Explore Generalizations and Specializations

• Generalization exposes commonalities
• Exercise helps to identify new classes
• Considerations for generalizations and
  specializations
• Is it in the problem domain?
• Is it within the systems responsibilities?
• Will there be inheritance?

12
13
Avoid Accidental Objects

• Essential objects represent genuine high-level
  abstractions
• Accidental objects represent qualitative judgments

13
14
Challenge Objects

• Needed Remembrance -- attributes
• Needed Behavior -- methods
• Usually Multiple Services per Object
• Usually More than One Object per Class

14
15
Other Object Tests

• Uniformity Test
• Each instance must have the same set of
  characteristics and be subject to the same rules
  - Car license
• More than a Name Test
• Every object has attributes, if not it is
  probably an attribute of another object -- home
  address
• Or Test
• If inclusion criteria should not use OR in any
  significant way -- drivers license number or
  learners permit number
• More Than a List Test
• If inclusion criteria is only a list of instances
  -- decadent foods includes croissant ,
  cappuccino, chocolate pie, ice cream.

15
16
Final Object Checklist

• Something universal and real for reuse
• Should encapsulate some reasonably complex
  behavior to justify existence
• Methods that dont make use of its current
  classs own attributes is probably encapsulated
  in the wrong object.
• Small and simple stable interfaces
• Self sufficient and complete

16
17
Questioning Techniques Help Elicit Domain
Knowledge

• Play Twenty Questions
• Is it animal, vegetable, or mineral?
• Does it have fur or feathers?
• Can it fly?
• Define Boundaries
• What else?
• What about..?
• Quantify Qualities as Attributes
• How fast?
• How hot?

17
18
Eliminating Unnecessary Associations

• Irrelevant Associations
• outside problem domain
• Implementation Associations
• Examples concurrent process, contains a list
• Associations Between Eliminated Classes

18
19
Eliminating Unnecessary Associations (contd)

• Actions or Transient Events
• Examples Interacts with the Robot, ATM
  accepts cash card.
• Ternary Associations
• Decompose as binary associations or rephrase to
  one binary association.
• Derived Associations
• These are redundant
• Examples Younger than .. derived from age

19
20
Refine Association List

• Choose meaningful association names
• Add role names where appropriate
• Add attributes or associations which qualify
  existing associations
• Example Standard Oil of Ohio uses state
  attribute to qualify company name.
• Specify one-to-many and many-to-many associations
  in the class diagram
• Add missing associations
• Not in problem statement
• from knowledge of application domain

20
21
Identifying Attributes

• Attributes can be thought as a simple association
  with a value which is not an object
• Examples name, age, weight
• Usually corresponding to nouns followed by
  possessive phrases
• Examples color of the car, age of the donor
• Less likely to be fully described in the problem
  statement
• Included in the class box diagram
• Not as relevant to the problem structure as
  associations

21
22
Attribute Types

• Descriptive Attributes
• Naming Attributes
• Referential Attributes

22
23
Descriptive Attributes

• Provide facts intrinsic to each instance of the
  object.
• Examples Account.balance, Cat.weight
• If the value of a descriptive attribute changes,
  it means only that some aspect of an instance has
  changed, but the instance is still the same
  instance.

23
24
Naming Attributes

• Are used to name or label instances.
• ExamplesAccount.number, Flight.number
• Names are typically somewhat arbitrary
• Naming attributes are frequently used as an
  identifier or part of an identifier.
• If the vale of a naming attribute changes, it
  means only that a new name has been given to
  exactly the same instance

24
25
Referential Attributes

• Are used to tie an instance of one object to an
  instance of another.
• Examples Cat.owner name indicates which person
  owns this cat.
• If the vale of a referential attribute changes,
  it means that different instances are now being
  associated.

25
26
Rules of Attributes

• First Rule
• One instance of an object or a class has exactly
  one value for each attribute at any given time.

OK Not OK Not OK
26
Shlaer-Mellor 90
27
Rules of Attributes (contd)

• Second Rule
• An attribute must contain no internal structure
• Examples
• Age, balance, size are all OK.
• A name consists of first name, middle initial,
  and last name (Not OK)
• An address contains house number, street name,
  city, state, zip code, and country name (Not OK)

27
28
Rules of Attributes (contd)

• Third Rule
• When an object has a compound identifier -- that
  is, one made up of two or more attributes --
  every attribute that is not part of the
  identifier represents a characteristic of the
  entire object.

Juice Transfer storage Tank ID cooking Tank
ID gallons plannedTime
The juice Transfer.gallons attribute means that
the number of gallons transferred from the
storage tank to the cooking tank and not the
number of gallons in either the storage tank or
the cooking tank.
28
29
Rules of Attributes (contd)

• Fourth Rule
• Each attribute is not part of an identifier that
  represents a characteristic of the instance named
  by the identifier and a characteristic of some
  other non-identifier attribute

Batch batch ID recipe ID gallons cookingTime
The Batch.cookingTime attribute must represent
the actual time the batch was cooked, and not
the cooking time specified by the recipe
29
30
Eliminating Unnecessary Attributes

• Do not keep attributes that have an object as a
  value, they are associations
• Do not keep attributes that depend on a context,
  these are qualifiers for associations
• If an object can have more that one name, then
  the name qualifies an association of that object
  with another

30
31
Eliminating Unnecessary Attributes (contd)

• Do not put attributes of the association in one
  or the other of the objects involved in the
  association, put the attributes in the
  association itself
• Eliminate attributes which are only used
  internally by the object
• Keep initial analysis of attributes at a high
  level
• Eliminate attributes which are too low level
• Attributes which are in some instances of a
  class, but not in others, indicate that the class
  should be split into two or more classes

31
32
Identifying Inheritance

• Identify classes which share common information
• Three basic approaches
• Bottom Up
• Look for classes with repeated associations,
  attributes or behaviors, and group together into
  higher level classes
• This approach is easier for inexperienced
  modelers
• Top Down
• Look for Noun phrases describing different kinds
  of things in the problem statement.
• Examples Family cars, Sports cars, Luxury cars
• Combination of the two approaches works the best.
• Do Top Down when doing initial analysis
• Identify repeated information in the late passes.

32
33
Identifying Inheritance (contd)

• Always use the AKO test
• All inheritance specifications should identify
  one or more classes which are A Kind Of a
  higher level class.
• NEVER use inheritance for Part / Part-of
  relationships
• Use multiple inheritance only when necessary
• Some object-oriented programming languages do not
  even have this feature.

33
34
Identifying Behaviors

• Done in latest stages
• List of behaviors can become large and get
  detailed quickly.
• May correspond to queries about attributes and
  associations
• Operations to read or write attribute or
  association value
• Examples user name, property value, etc.
• May correspond to events or activities
• Examples begin simulation, alert, calculate
  balance, computer distance

34
35
Experience and Domain Knowledge

• Good objects come from language of domain
• If you are not an expert -- consult users
• Experience will tune decisions
• Slowly at first
• Much faster later

Just do it!
35
36
Discussion Questions

• Define with examples CRC cards, associate
  objects, referential attributes.
• Describe the third norm for testing objects
• What are the differences between essential
  objects and accidental objects
• What are questioning techniques and their
  purposes?
• Describe how do you identify associations ,
  aggregations, inheritance, attributes, and
  behaviors
• Describe how to refine objects and associations
• Explain how to define responsibilities and
  collaborations

36
37
Questions for the Next Lecture

• Define
• Type
• Type vs. Class
• Type specifications
• Interface
• Signatures
• Elements of behavior

37
38
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 this week of the semester
  (Final).
• 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.

38