OODE Introduction

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.

Modeling

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

UML

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