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.

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

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

[How will you model systems which are written in non OO languages then ?]

• Coherent Interfaces Rule
  • A class and its interfaces should represent a coherent view of some concept in the problem or solution domain. 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.
• Open-Closed principle
  • Class should be open i.e. easily extensible and it should be closed to allow usage (well-encapsulated).

UML

• A family of visual languages to describe systems (not necessarily but usually software systems).
• UML is not a research project - it is a collection of practices gained through industry usage.
• A system can be viewed through different perspectives. E.g. a house can be viewed differently by the landlord, tenant, plumber, architect, tax officials view.
• In UML, different kind of diagrams allow us to have views about the system in different ways.
  • e.g. use case diagram represent system functions from the user perspective, sequence diagram is representation of objects and their temporal interactions etc.

Classes

• A class is an intentional description ( a blueprint) of set of objects.
• A description can be thought of as : 1) a specification and 2) a realization. In UML practice, these are usually combined.
• Class diagrams represent a set of classes, interfaces, collaborations and their relationships.
• They offer a static conceptual view of the system.

Relations between classes

• Association : Represents a connection between instances of the classes. (not between the classes themselves). By default an association is bidirectional.
• As in a representation of the references to other instances that an instance has.
• A role is attached to the end of an association. The role also has a multiplicity. Make sure both of these are represented.
• For e.g. a Manager and an Employee's association role can be "manager" with multiplicity of 1 on the Manager end (each Employee has 1 manager) can and 1..* (each manager has 1 or more employees) on the Employee end.
• Navigability: A direction can be imposed on an association. This means that the destination object will have a direct reference from the source object, but not the other way around.
• for e.g. a User object can have references to Password objects, but not the other way around, since it will be a security risk.

• Aggregation : Represents asymmetric bidirectional semantic connections.
• Represents a stronger coupling between classes. for e.g. a company is made up of a number of departments.
• Generally for relations as whole and part, master and slave, composed and composing.
• Notation : a white diamond at the aggregation point. for e.g the white diamond will be at the end of the company.

• Composition : Maximum multiplicity of 1 on the aggregate side and automatic propagation of destruction.
• For e.g. a relation between a Engine and Pistons. If the engine is destroyed, so are the pistons.
• Represented by a filled in diamond at the end of the aggregation.