Dr. Magdy S. Hanna

1
Testing Object-Oriented SystemsHow does it
impact Software Quality and TestingPart 1

• Dr. Magdy S. Hanna
• International Institute for Software Testing
• Software Dimensions
• University of St. Thomas
• [phone], mhanna_at_softdim.com

2
Claimed Benefits of Object-Oriented Development

• To tackle more challenging problem domains
• To explicitly represent commonalties among
  objects in the application domain
• To allow reusability of design and code
  components
• To integrate process modeling, data modeling, and
  dynamic modeling into one model
• To produce highly maintainable software
• To better manage the complexity of the problem
  domain

3
Components of the Object Model

• Objects
• Object identity
• Object types or classes
• Object attributes (instance variables)
• Object behavior (operations, methods, and
  messages)
• Encapsulation
• Inheritance
• Object composition

4
Objects

• Definition An object is a concept, abstraction,
  an event, a physical object, or any thing that
  has crisp boundaries and meaning for the
  application being modeled.
• Examples Joe, 471-67-9867, illegal
  command, The 1996 Olympics, The Radisson
  Metrodome, This seminar, or any one of you.
• Objects have identity and are distinguishable
  based on their inherent existence regardless of
  any of their characteristics.

5
Object types or classes

• Definition An object class or type is a
  collection of objects with similar
  characteristics (attributes, behavior, or
  relationship with other objects)
• Examples person_name, SSN, error_message,
  Olympic_event, hotel, seminar_attendees
• Note these object classes correspond to object
  examples on the previous slide

6
Object Attributes (Instance Variables)

• Attributes are characteristics of all objects
  within a class
• Attribute names are unique within each class not
  across classes

7
Operations

• Operations are actions that might be performed by
  (or to) any of the objects in a class.
• All objects in a class share the same operations.
• Examples close_account, open_account,
  hire_employee, cancel_reservation, etc.
• Operations may have parameters
• In a true object-oriented environment,
  operations are the only means for changing
  objects data

8
Methods

• A method is an implementation of an operation.
• Different operations may have different (more
  specialized) methods for different classes.
• Examples close_checking_account,
• close_saving_account close_normal_window,
  close_project_manager
• Public vs private methods

9
Messages

• Messages are the only means for communication
  between objects.
• A message contains the target class, the name of
  the operation, and any necessary parameters.
• Example account.close 1765345
• Note The right method would be invoked based on
  the account type

10
Object Behavior

• The set of messages to which an object within a
  class can respond is known as the behavior of the
  object.
• As a result of receiving a message, an object
  perform an operation by executing a method.
• The execution of a method may cause the object to
  send messages to other objects or to itself.
• Example cancel_reservation may trigger
  delete_invoice

11
Encapsulation and Information Hiding

• Encapsulation refers to the bundling of an
  objects data and behavior in one programming
  unit.
• Information hiding refers to separating the
  details of an objects implementation (data and
  methods) from its external interface (the set of
  operations available for the users of the
  object).
• Encapsulation makes it possible to change the
  implementation without having to change the
  interface.

12
Encapsulation
External Interface
Internal Implementation
13
Inheritance

• Class are normally organized in the form of a
  graph including subclasses and superclasses
• Class graphs can be strict hierarchy or a lattice

14
Inheritance (Cont.)

• A subclass inherits all attributes and behavior
  of All of its supertypes.
• A subclass may re-define any of its superclass
  methods or attributes.
• Multiple inheritance and conflict resolution

15
Composite Objects(Part-of-relationships)

• Used to model
• Assembly-parts
• Container-contents
• Collection-members
• Very different from subtype/supertype
  relationships

16
Characteristics of Part-Of Relationships

• Transitive relationship A is part-of B and B
  part-of C implies A is part-of C.
• Antisymmetric relationship A is part-of B
  implies b is NOT part-of A.

17
Comparison
OO Modeling Data Modeling Objects/Classes Enti
ties/Entity Sets Instance Variables Attributes C
lass Variables Type discriptors, class
attributes Associations (primitive) Relation
ships Class hierarchy /inheritance ISA
relationships Object Identity Primary key
Abstraction To some degree through
concepts above
18
Relationship of Object-Oriented Modeling to Data
Modeling

• The following concepts currently characterize the
• object-oriented paradigm
• Encapsulation of data and operation
• Object communication via sending messages
• Object composition
• Object identity independent of objects
  characteristicsSome of these will continue to
  move to data modeling

19
Purely Language (Implementation) Concepts

• Encapsulation
• Information hiding
• Polymorphism (overloading)
• Binding
• Distribution

20
Object Orientation and Software Quality
21
What is Quality?
22
Quality is Fitness for Use
User Concerns Quality Factor

• How secure is it? Integrity
• How often will it fail? Reliability
• Can it survive during failure? Survivability
• How easy is it to use? Usability
• How much is needed in way of resources? Efficiency
  
• Does it comply with requirements? Correctness
• Does it prevent hazards? Safety
• Does it import/export data ? Interoperability

23
Quality is Fitness for Use
User Concerns Quality
Factor How easy is it to repair? Maintainabilit
y How easy is it to expand? Expandability How
easy is it to change? Flexibility How easy is
it to transport? Portability Is it reusable
in other systems? Reusability Is it easy to
effectively test the system? Testability Is the
software easily managed? Manageability Do I have
control over how it works? Configurability
24
Which Quality Factors are Impacted

• Maintainability
• Expandability
• Flexibility
• Correctness
• Reusability
• Efficiency
• Testability

25
Correctness

• Correctness of the a software system is a the
  degree to which the software meets its intended
  requirements.
• It is facilitated by how precise, complete, and
  unambiguous requirement definitions are.
• Use Cases are effective ways for refining
  requirements.

26
What Are Use Cases

• A Use Case describes a scenario in which a user
  interacts with the system to accomplish a
  particular task.
• Each Use Case specifies
• The task to be performed
• The user class
• Different actions and corresponding system
  responses
• Estimated frequency of use
• Very useful for deriving test cases early in the
  requirement phase

27
Example

• Use Case 1 of the Telephone Banking System
• Task Making a balance transfer
• User Class Current customer
• Frequency one per week per customer

User Action System Response User dials the
number System plays greeting and ask for account
number User enters invalid account
number System informs user and ask for account
number again User enter a valid account
number System asks for PIN
28
Object Orientation and Reuse

• Facilitated by the black-box concept
• Class libraries
• Components

29
Efficiency

• Performance in terms of response time is
  negatively impacted.
• Back-end relational databases will remain a
  problem for long time
• Object-Oriented databases do not scale up.

30
Testability

• Encapsulation creates the need for testware
  written by programmers
• Inheritance introduces another dimension of
  difficulty
• Polymorphism and dynamic binding require much
  more testing
• OO development is RAD by nature

31
Conclusion

• OO technology is not for all applications
• OO technology has not delivered all promises
• It is just a different way of building systems
• It presents new challenges to testing
  professionals
• No matter what we do, we will always release much
  less reliable systems.

32
Testing Object-Oriented SystemsPart 2

• Dr. Magdy S. Hanna
• Software Dimensions
• University of St. Thomas
• [phone], http//softdim.com