CSCE 431 Lecture 9

« previous | Tuesday, February 11, 2014 | next »

System Design

• Subsystem decomposition
• Abstraction of the machines
  • middleware
  • frameworks
  • class libraries
  • database engines
• Application domain components
  • Off-the-shelf application domain components for select domain functionality
• Object design fills in the rest
  • Adapt reusable components
  • Idetnify new solutions
  • Specify subsystem interfaces precisely

Object Design

Purpose:

• prepare for implementation
• transform system for better implementability, extensibility, performance, etc.

Once again, reuse and adapt existing solutions!

• off-the-shelf components
• libraries
• design patterns

Specify all interfaces and subsystem APIs

Modularity

Parnas; On the Criteria to be Used in Decomposing Systems into Modules (1972)

• every module should be known to the outside world through an official "public" interface
• Rest of properties are "secret" (so it can change without stepping on anyone's toes)
• Should be impossible to access the secrets from the outside
• Language should not matter, design matters

Inheritance, encapsulation, polymorphism, and related features in object-oriented languages aimed at supporting information hiding.

Characteristics of good modularization: low coupling and high cohesion

• minimize dependencies (changes are localized)
• maximize unity (modules should work well together)

Encapsulation

The process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation Booch

Casual definition: bundling data and methods with access protection.

Enables enforcement of object invariants (provable correctness)

Inheritance

Used in

1. organization (analysis)
   • express generalization / specialization in taxonomies that deal with application domain
2. reuse (object design)
   • helps to reuse models and code to deal with solution domain
   • goal is to reduce redundancy and obtain extensibility

Meyer has 13 types of inheritance

Implementation Inheritance

(class inheritance)

extend application's functionality by using functionality of superclass

Some or all operations already implemented

Interface Inheritance

(subtyping)

Inherit specification.

Extensibility: Open-Closed Principle (OCP)

A module should be open for extension but closed for modification B. Meyer (OOSC98)

In other words, defining new subclasses should suffice to evolve code.

• maybe in Eiffel, type system gives considerable freedom

This is nice if it works, but requires guessing/knowing the variation points and obeying Liskov Substitution Principle

Inheritance vs. Delegation

Consider

class HashTable {
    void put(Object key, Object element);
    Object get(Object key);
    boolean containsKey(Object);
    boolean containsValue(Object);
}

Delegation is generally preferred; inheritance should only be used if taxonomies exist.

Inheritance Example

class MySet extends HashTable {
    void put(Object element) {
        if (!containsKey(element))
            put(element, this);
    }

    boolean containsValue(Object element) {
        return containsKey(element);
    }
}

Delegation Example

class MySet {
    private HashTable table;

    MySet() {
        table = new HashTable();
    }

    void put(Object element) {
        if (!containsValue(element))
            table.put(element, this);
    }

    boolean containsValue(Object element) {
        return table.containsKey(element);
    }
}

(Object Oriented) Design Patterns

Motivation:

• Not every problem should be solved wiht a solution developed "from scratch"
• Desireable to reuse solutions
• at the time, recording and cataloging experience in software design was not done systematically (or at all)
• Learning how to design starts by studying other designs

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of he solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Visually pleasing and practical structures for an application and/or setting could be described by a pattern language. Christopher Alexander