(chapter 11)
real world entity, not software component
remembered information implied by use case
e.g. date and time of Sale
POST Item Store address: Address name: Text Sale date: Date time: Time Payment amount: Quantity ProductCatalog ProductSpecification description: Text price: Quantity upc: UPC SalesLineItem quantity: Integer Cashier Customer Manager
Larman fig 11.9
Definitions of terms
Define all terms that require clarification
Term |
Category |
Comments |
---|---|---|
Buy Items |
use case |
Description of a process of a customer buying items in a store |
ProductSpecn. |
attribute |
Short description of an item in a sale and its ProductSpecification. |
Item |
type |
Item for sale in a store. |
Payment |
type |
A cash payment. |
ProductSpecn. |
attribute |
Price of an item in a sale and its ProductSpecification. |
SaleLineItem. |
attribute |
Quantity of one king of Item bought. |
Sale |
type |
A sales transaction |
SaleLineItem |
type |
Line item for a particular item bought in a Sale. |
Store |
type |
Place where sales occur. |
Sale.total : Quantity |
attribute |
Grand total of sale. |
Payment.amount: Quantity |
attribute |
Amount of cash tendered by customer for payment. |
ProductSpecn. |
attribute |
Universal product code of the Item and its ProductSpecification. |
sometimes called "acquaintance"
Aside 1:
Sometimes difficult to decide between association
and aggregation
a country has a capital
determined more by intent than explicit language mechanism
Aside 2:
aggregation or attributes?
In some models, an engine may just be an attribute of a car,
in
others it will be a separate entity (object).
Transition from analysis to design (OO)
Analysis | Design |
---|---|
Generalization | Inheritance |
Association | Reference |
Aggregation | Reference Value |
Suppose you have an Employee class.
It has features such as
name address phone id position leaveRemaining setAddress(newAddress) takeLeave(days)
Now you find that you need an Academic class which has everything in an employee class plus some extra features
subjects studentsSupervising
You could create a new class which is distinct from Employee. You would duplicate all that is in Employee and add the extra features.
Not much extra work in the duplication (cut and paste).
But consider maintenance: If you had to add an email feature, with methods setEmail and getEmail. You would have to do it in 2 places.
Extra work (not a great deal), plus opportunity for mistakes
Localisation of change is the key to the ease of change of software |
Make Academic a special type of Employee.
Then Academic contains all of the features in Employee + any extra that have been added.
Any changes to Employee are also propagated to Academic.
public class Employee { protected String name; protected Address address; }To inherit, use the keyword
inherits
public class Academic inherits Employee { protected Subjects subjects; }
(OOSC, chapter 3)
A module is open if it is available for extension.
A module is closed if it is available for use by other modules.
Software should be open. It is impossible to foresee all of the features it will need in its lifetime.
Software should be
closed. Other modules will need to use it.
Software should be both open and closed |
Inheritance allows an elegant way of allowing software to be open and closed. Consider if a module 'nearly' does everything required. Without inheritance, the only options are change or copy. With inheritance, leave the existing module as it is, and the new one inherits from it.
(Read OOSC on behaviour classes, particularly 684-688, 848-850.)
Classes in which
one or more features are abstract.
These features will be defined
in a descendant.
abstract class Employee { String name; public abstract int getWeeklyEarnings(); }
Every employee can be queried for their weekly earnings,
but they will be calculated differently.
So the getWeeklyEarnings()
function can't be implemented. It has
to be implemented for each descendent.
Staff have an annual salary, so
public class Staff inherits Employee { int weeklyEarnings; public int getWeeklyEarnings() { return weeklyEarnings; } }
Sales people get paid by commission, so
public class Salesperson inherits Employee { int sales, commission; // commission is in percent public int getWeeklyEarnings() { return (sales *commission)/100; } }
There can be no objects of type EMPLOYEE. They wouldn't know how to calculate weeklyEarnings.
But abstract classes are an important and powerful design technique in OO. They can significantly improve the ease of maintenance of OO software.
Java does not
support multiple inheritance
(one of its main weaknesses as an OO
language)
Java goes part of the way with Interfaces
Interfaces allow class methods to be given at the pure specification level with no implementation at all.
all methods are abstract
(but they have signatures)
any variables must be
Interfaces are skeletons of classes showing what form the class will take when it is implemented.
Writing an interface
interface X { public void a(int b); public int c(); public static final int D = 4; }
Implementing an interface
public class A implements B {...}
Differences:
Part of the Java class libraries.
Provides a way of stepping through a collection.
Has methods
|
are there any more elements in the enumeration? |
|
retrieves the next element in the
enumeration. |
Used in Hashtable, Vector, StringTokenizer,
Hashtable class has methods
|
returns an enumeration of all of the elements in a hash table |
|
returns an enumeration of all of the keys in a hash table |
to print all of the elements in a hash table
for (Enumeration elts = table.elements(); elts.hasMoreElements(); ) { System.out.println(elts.nextElement()); }
to print all of the keys in a hash table
for (Enumeration keys = table.keys(); key.hasMoreElements(); ) { System.out.println(keys.nextElement()); }
What has this gained us?
Once we know how to step through the elements in a Hashtable, we know how to step through the elements in a Vector, a StringTokenizer, etc.
If we write our own collection class, we can implement Enumeration and iterate through it in exactly the same way.
The biggest learning task in an OO language is not learning the
language syntax, but learning the class libraries. Well designed
class libraries can reduce this cognitive load.
The Enumeration
interface in the Java libraries is an example.