OODE Introduction

From Suhrid.net Wiki
Jump to navigationJump to search

Why OO

  • Modern systems are large and complex - lots of interconnected components, distributed and heterogeneous.
  • OO is particularly useful to build such systems.
  • Remember OO is not always the best approach, but is useful in the right setting.
  • OO is whats most applied in industry.
  • OO allows engineering of more extensible systems.
    • 90 % of system development is maintenance of which much is "extension".
  • OO is helpful in constructing large scale systems.
    • Lots of interacting parts, lots of complexity. Requirements keep changing.

When to use OO

  • For the systems where the user is in control e.g. decision support systems, CRM's, enterprise systems. OO makes it easier to model such systems.
  • Systems where long term extensibility is important. Again OO's concepts make it easier to incorporate extensibility.

What is OO Development

  • Quite simply, the use of classes and objects in developing software and systems.
  • Classes represent recurring, reusable, extensible concepts that provide services. A class is an informational abstraction, representing a concept, some information, a facility as a type that can be instantiated.
  • Objects are instances of classes and carry out computations in response to messages.
  • e.g. : A Ticket is a class which has a price and a destination. An instance of a Ticket is an object which is needed to carry out a journey.
  • OO Development implies using classes and objects throughout the construction process - requirements analysis, design, coding and testing.

Development Methods

  • Waterfall - doesnt work for large systems
  • Spiral - emphasizes risk and cost
  • RUP - Rational Unified Process from IBM Rational. User stories are constructed from which OO designs will be built.
  • Use cases are a way to write user stories.
  • Model Driven Development
    • Aim to build software using abstract models. RUP is a kind of MDD.
    • Models are at a higher level abstraction than code.
    • UML is a popular modeling language.


  • Create models at each phase, requirements, design etc.
  • Capture the essence of things of interest - not everything.
  • Hence models are easier to change - but is difficult to keep the model in sync with the actual system.


  • A visual language for describing many aspects of system design and requirements.
  • UML is only a language and NOT a method or process. UML is typically used with an agile process, although the process can be used without UML.
  • A method = language + process + tools.
  • UML consists of two parts:
  1. The graphical notation used to draw models.
  2. A metamodel: which specifies the validity of models.
  • The graphical notation consists of various diagrams such as class, communication, state charts, use case diagrams etc.

Agile Development

  • A class of development methods that emphasize developments as a series of small steps.
  • The particular steps are chosen during the enactment of the process rather than being per-determined.
  • Often accompanied by refactoring of current code.
  • Steps occur at fixed dates, rather than fixed functionality.
  • Many agile methods: XP, SCRUM, DSDM.

Software Quality

  • One of the primary goals of SE is to produce quality software.
  • How can quality be measured ?
    • Internal characteristics: Maintainability, flexibility, testability etc
    • External : Correctness, robustness, reliability, usability etc
  • So, again why OO ? OO is one technique improve internal construction and design of a system to improve software quality.

Quality in OO Systems

  • High quality OO systems will be non-monolithic - high cohesion, low coupling.
  • Heuristics exist to build high quality OO systems:

Direct Mapping Rule

  • The class structure in the system must relate (clear mapping) to the structure in the model.
  • The development is seamless, the concepts of class and objects are all pervasive.
  • But in practice, difficult to describe customer requirements, which tend to be goal/event based using classes/objects.
  • So we need modeling things such as use cases and interactions.
  • Consequently using an OO modeling language with an OO programming language is helpful.
  • OO model language with non OO programming language is problematic.

Coherent Interfaces Rule

  • Each class has an interface which declare the services the instances of the classes provide.
  • A class and its interfaces should represent a coherent view of some concept in the problem or solution domain.
  • That abstraction should encapsulate the information about a particular concept: e.g. Bank Account, Flight Plan, Player. This relates to high cohesion.

Small Interfaces Rule

  • When two objects communicate, they should exchange as little information as possible. This relates to weak or low coupling.

Explicit Interfaces Rule

  • When two objects are communicating, this must be obvious from their class definitions. The conversations need to be clearly visible - to facilitate understanding.

Information Hiding Rule

  • AKA Encapsulation. Data must be hidden, kept private so that client objects are kept independent of implementation.
  • Only that information must be exposed which is necessary to use the services provided by each object. The interface of a class is public, everything else must be hidden.

Open-Closed principle

  • Class should be open i.e. easily extensible.
  • Class should be closed to allow usage.
    • Well defined and stable and documented interfaces.