CS6502 Unit 5 OOAD
CS6502 Unit 5 OOAD
At the very least, DCDs depict the class or interface name, superclasses, operation signatures,
and attributes of a class. This is sufficient to create a basic class definition in an OO language. If
the DCD was drawn in a UML tool, it can generate the basic class definition from the diagrams.
From the DCD, a mapping to the attribute definitions (Java fields) and method signatures for the
Java definition of SalesLineItem is straightforward, as shown in Figure below.
1
4) Explain in detail using an example how methods can be created from interaction
diagrams?
Creating Methods from Interaction Diagrams
The sequence of the messages in an interaction diagram translates to a series of statements in the
method definitions. The enterItem interaction diagram in Figure 20.2 illustrates the Java
definition of the enterItem method. For this example, we will explore the implementation of the
Register and its enterItem method. A Java
2
The enterItem message is sent to a Register instance; therefore, the enterItem method is
defined in class
Register.
currentSale.makeLineItem(desc, qty);
In summary, each sequenced message within a method, as shown on the interaction diagram, is
mapped to a statement in the Java method.
The complete enterItem method and its relationship to the interaction diagram is shown in Figure
20.4
3
5) What are collection classes? Give examples.
Collection Classes in Code
One-to-many relationships are common. For example, a Sale must maintain visibility to a group of
many SalesLineItem instances, as shown in Figure 20.5. In OO programming languages, these
relationships are usually implemented with the introduction of a collection object, such as a List or
Map, or even a simple array.
For example, the Java libraries contain collection classes such as ArrayList and HashMap, which
implement the List and Map interfaces, respectively. Using ArrayList, the Sale class can define
an attribute that maintains an ordered list of SalesLineItem instances.
4
The choice of collection class is of course influenced by the requirements; key-based lookup
requires the use of a Map, a growing ordered list requires a List, and so on.
As a small point, note that the lineItems attribute is declared in terms of its interface.
For example, in Figure 20.5 the definition for the lineItems attribute demonstrates this
guideline:
Example :
An excellent practice promoted by the Extreme Programming (XP) method [Beck00], and
applicable to the UP and other iterative methods (as most XP practices are), is test-driven
development (TDD) or test-first development. In this practice, unit testing code is written before
the code to be tested, and the developer writes unit testing code for all production code. The
basic rhythm is to write a little test code, then write a little production code, make it pass the test,
then write some more test code, and so forth.
5
Class Payment
// something like:
package com.foo.nextgen.domain;
Class ProductCatalog
public ProductCatalog()
// sample data
ProductDescription desc;
6
descriptions.put( id2, desc );
return descriptions.get( id );
Class Register
this.catalog = catalog;
currentSale.becomeComplete();
7
public void makeNewSale()
currentSale.makePayment( cashTendered );
Class ProductDescription
public ProductDescription
this.id = id;
this.price = price;
this.description = description;
8
}
Class Sale
new ArrayList()<SalesLineItem>;
9
{
subtotal = lineItem.getSubtotal();
total.add( subtotal );
return total;
Class SalesLineItem
this.description = desc;
this.quantity = quantity;
10
}
Class Store
Unit is more difficult to define when inheritance is involved - Suggestion is to use the flat
definition
Becomes complicated with multiple inheritance - Flattening solves inheritance problem
Flattened classes are not a part of the system - Cannot be certain properly tested
Complication in Polymorphism
11
Flattened classes are not a part of the system - Cannot be certain properly tested
May not have necessary methods for testing - Can add test methods
Should they be a part of the delivered system?
Analogous to having instrumented program text
Levels of testing – 2
Classes are units
Three levels
Class
Unit testing
Integration
Interclass testing
System
At port level
Eventhough , a class is considered as unit of testing as a natural choice, the role of Inheritance
complicates the matter. If a given class inherits attributes and/or operations from super classes , the stand
alone compilation criterion of a unit is sacrificed. However, the “flattened classes” concept alleviates
this problem. A flattened class is an original class expanded to include all the attributes and operations it
inherits.
12
Unit Testing on a flattened class solves the inheritance problem , but it raises another. A flattened class
will not be part of a final system, so some uncertainty remains. Also the methods in a flattened class
might not be sufficient to test the class. This leads to unending chain of methods testing other methods.
EXAMPLE
The LHS Fig. shows a UML inheritance diagram of a part of a simple automated teller machine. The fig.
on the RHS shows the “flattened” checkingAccount and savingsAccount classes. Here we need to test
the getbalance and setBalance operations twice resulting in losing some of the benefits of Object
Orientation.
Class Testing
Class test cases are created by examining the specification of the class.
o This is more difficult if the class is a subclass and inherits data and behavior from a
super class. A complicated class hierarchy can be pose significant testing problems.
If you have a state model for the class, test each transition - devise a driver that sets an object
of the class in the source state of the transition and generates the transition event.
Class Constraints/Invariants should be incorporated into the class test.
13
All class methods should be tested, but testing a method in isolation from the rest of the class is
usually meaningless
o Method Testing
A public method in a class is typically tested using a black-box approach.
o Start from the specification, no need to look at the method body.
o Consider each parameter in the method signature, and identify its equivalence classes.
o Incorporate pre-conditions and post-conditions in your test of a method.
o Test exceptions.
For complex logic, also use white-box testing or static testing.
17) Discuss the merits and demerits of a) Methods as Units b) Classes as Units in OO unit
testing?
(a) Methods as Units.
A method implements a single function, and it would not be assigned to more than one
person, so methods might ideally be considered as units. The smallest compilation is
problematic.
Also if we are using fully flattened classes , we will need to unflatten them to their original form
when unit testing is complete.
14
• Interclass Testing
• The first level of integration testing for object-oriented software
– Focus on interactions between classes
• Bottom-up integration according to “depends” relation
– A depends on B: Build and test B, then A
• Start from use/include hierarchy
– Implementation-level parallel to logical “depends” relation
• Class A makes method calls on class B
• Class A objects include references to class B methods
– but only if reference means “is part of”
18) Compare unit testing and Integration testing in OO Testing.
OO definitions of unit and integration testing
• Procedural software
– unit = single program, function, or procedure
more often: a unit of work that may correspond to one or more intertwined functions or
programs
• Object oriented software
– unit = class or (small) cluster of strongly related classes
(e.g., sets of Java classes that correspond to exceptions)
– unit testing = intra-class testing
– integration testing = inter-class testing (cluster of classes)
– dealing with single methods separately is usually too expensive (complex scaffolding), so
methods are usually tested in the context of the class they belong to
19) Explain in detail about OO Integration testing.
15
16
A sequence diagram traces ana execution-time path through a collaboraton diagram. Thick vertical lines
represent either a class or an instance of a class, and the arrows are labelled with the messsages sent by
(instances of) classes in their time order. The portion of oocalendar application that prints out the new
date is shown as sequence diagram as in Fig below :
17
20) What are MM-Paths for OO Software? Give an example.
An MM-Path starts with a method and ends when it reaches a method that does not issue any
message of its own; this is the point of quiescence.
The figure below is an example of MM-Path for the collaboration diagram of OO Calendar
example shown above. With this formulation we can view object oriented integration testing
independently of whether the units were chosen as methods or classes.
18
19