Requirements -> OOA -> OOD -> Implement / test

analysis

Conceptual model

Concepts


Conceptual model - attributes

(chapter 11)

Concepts

real world entity, not software component

Attributes

remembered information implied by use case

e.g. date and time of Sale





UML notation


Attributes

Simple attributes or pure data types



Attributes in POST model

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

conceptual model with attributes

Larman fig 11.9


Glossary

Definitions of terms

Define all terms that require clarification

POST glossary

Term

Category

Comments

Buy Items

use case

Description of a process of a customer buying items in a store

ProductSpecn.
description : Text

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.
price: Quantity

attribute

Price of an item in a sale and its ProductSpecification.

SaleLineItem.
quantity: Integer

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.
upc : UPC

attribute

Universal product code of the Item and its ProductSpecification.


Relationships in analysis (Review)

  1. Generalization-specialization / Classification - "is-a"
    a kestrel is a bird
    commodore is a car
  2. Association Named relationship - "uses-a" (often)
    a ship uses a port
    a company employs an employee

    sometimes called "acquaintance"

  3. Aggregation - "has-a" "consists-of"
    a car has an engine

    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


    Inheritance

    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

    Should only have to make changes in one place

    Localisation of change is the key to the ease of change of software

    Inheritance

    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.

    Implementing in Java

    public class Employee {
    
        protected String name;
        protected Address address;
    }
    
    To inherit, use the keyword inherits
    public class Academic inherits Employee {
    
        protected Subjects subjects;
    }
    

    Open Closed Principle

    (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.


    Abstract classes

    (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.

    Example

    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 interfaces

    Java does not support multiple inheritance
    (one of its main weaknesses as an OO language)

    Java goes part of the way with Interfaces

    Interface

    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:


    The Enumeration interface

    Part of the Java class libraries.

    Provides a way of stepping through a collection.

    Has methods

    hasMoreElements()

    are there any more elements in the enumeration?

    nextElement()

    retrieves the next element in the enumeration.
    (and moves the pointer along one in the enumeration)

    Used in Hashtable, Vector, StringTokenizer,

    Hashtable class has methods

    elements()

    returns an enumeration of all of the elements in a hash table

    keys()

    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.