Objects and components
1 / 37

Objects and Components - PowerPoint PPT Presentation

  • Uploaded on

Objects and Components. The adaptive organization. The competitive environment of businesses continuously changing , and the pace of that change is increasing at an accelerating rate.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Objects and Components' - savea

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

The adaptive organization
The adaptive organization

  • The competitive environment of businesses continuously changing , and the pace of that change is increasing at an accelerating rate.

  • Where it was once possible for a company to stake out its marketing turf and defend its position for years, static positioning is now viable only in a few isolated industries.

  • For most companies today, the only constant is change.

Object orientation
Object Orientation

  • Basic building blocks of a system are the OBJECTS

    • black boxes encapsulating data and procedures

    • messages can be send and received by objects

    • object libraries and templates

  • Importance

    • reusability

    • maintainability

    • flexibility

  • But

    • OO languages needed

    • not enough object libraries available

    • training

Why objects
Why objects ?

  • Grady Booch:

    simply because there appears to be no other way to economically produce an enduring and resilient programming system.

  • David A. Taylor

    objects are the enabling technology for adaptive business systems

  • Planning !!!

The waterfall model
The waterfall model

Project proposal report

Functional specifications

Feasibility report

design specifications

program specs


tests of system performance

audit , feed-back








- intermediate reports

- go/nogo intervals

Post Imple-


System reliability evolution
System reliability evolution

Number of



Why oo good reasons
Why OO ? Good reasons

With the increasing complexity of the systems,

the traditional techniques suffer from two illusions:

  • The analyst knows everything and understands the problem completely before implementation starts

  • The users read the system analysis report and approve it

Project management
Project management

  • Iterative style

    develop a series of solutions to a problem ,

    each of them closer to satisfying the requirements

    ( also called : evolutionary development )

  • Incremental style

    Builds system functionality a little at a time.

    The results are not entire solutions.

    Matthew Pittman proposes iterative analysis and design combined with incremental development

Oo life cycle
OO - Life cycle

  • Facts:

    • System requirements are not fully known at the start

    • knowledge of the system grows during development

    • better develop a system incrementally

    • start with some core functions


Life Cycle









coordination and reuse

Database evolution
Database Evolution

File System


OO - system

What is an object
What is an object ?

  • An object is a software package that contains a collection of related procedures ( methods ) and data ( variables )

  • An object is a data abstraction with a state, a behavior and an identity

    whereby operations are encapsulated together with the data structures on which they are defined







1 y comp




The object paradigm
The object paradigm

Five principles:

  • Abstraction

  • Encapsulation

  • Object communication , message passing

  • Inheritance

  • Polymorphism


  • an abstraction is a simplified view of some part of reality, focusing on some aspects , suppressing others

  • good abstraction emphasizes on those details that are important for the actual observer

  • the use of abstraction makes it possible to postpone decisions regarding details

  • an object is an abstraction of both data and functionality, with a focus on the outside view , separating the implementation of the object from the essential


From: Grady Booch

Abstraction focuses upon the essential characteristics of some object,

relative to the perspective of the user


From: Grady Booch

Encapsulation hides the details of the

implementation of an object


  • Encapsulation is the mechanism by which an object is made to look like a black box to an external observer

  • It is the packaging of a set of ideas into one logical unit, which can be referred to as a single unit

  • Good encapsulation hides design decisions .

  • An external observer sees what the object does, not how it does it.

  • It is the basis for reusability


  • A Class is a software template that defines the methods and variables to be included in a particular kind of object.

    • objects of the same structure and behavior belong to the same class

    • an object belongs to a class or is an instance of a class

    • objects only exist at run-time

      classes are set up at design time

    • a class can contain rules that all instances must satisfy

Messages passing
Messages passing

  • A message starts an operation on an object

    • A message is simply the name of an object, followed by the name of the method the object knows how to execute, and eventually followed by parameters

  • Objects can pass messages to other objects

    • Signature: The message signature contains the stipulation of the message format

  • a message consists of the name of a method and the required arguments

  • the set of messages to which an object responds is the behavior of the object

Message passing
Message passing

The task of software development is to engineer the illusion of simplicity.

Message interface
Message Interface

  • Message interface

    The set of messages an object commits to respond to.

  • A class must specify the messages that objects of this type will make available to other objects

  • Interfaces

    • protect objects from being corrupted by other objects

    • protect other objects from depending on its internal structure

  • Interfaces may be segmented by combining them into composite interfaces

Anatomy of a message
Anatomy of a message

  • A message consists of three parts

    1. A receiver object

    2. A method the receiver knows how to execute

    3. An ordered set of parameters that this method requires to carry out this function (optional)

    Vehicle Turn : 90

    receiver method parameter

    Messages conform to signatures



  • the ability of an instance of a class C to use not only the methods and variables defined for C but also those designed for an ancestor of C

  • Inheritance allows new classes to be build incrementally on existing classes

  • Message interfaces are also inherited








students and staff members are sub-classes of person

Composite objects
Composite objects

  • Objects can contain other objects(Composite objects)

  • Collection class is a special kind of class

  • Benefits of Composition

    • even a deeply nested structure can be treated as a single, unified object

    • this helps manage complexity

  • Delegation

    • when an object assigns a task to another object

Method overriding
Method overriding


it is possible to

override methods

Give area




Give area

Give area





This is not inheritance (but Aggregation)


  • The ability of different objects to respond differently to the same message is called POLYMORPHISM

    e.g. DRAW


  • A variable can point to an object whose class is not absolutely known

Oo system reliability

Number of



OO-System Reliability

  • With OO development techniques

    • A system is never replaced entirely

    • continuous evolution

    • lower implementation risk


  • Connecting objects through interfaces

    • OMG: Object Management Group

    • IDL: Interface Definition Language

    • CORBA: Common Object Request Broker Architecture

      The IDL specification allows objects from different vendors, written in different languages to interact without any knowledge of one another's classes.

      The use of interfaces can eliminate most class dependencies.

      Exception made for inheritance where class references remain unavoidable.

      Microsoft COM technology for ActiveX objects does not includes inheritance.

Distributing objects
Distributing Objects

Object Request Broker

  • channel of communications between remote objects

  • message bus

  • CORBA industry standard

  • IIOP

    • Internet Interoperability ORB protocol

  • DCOM Microsoft

    • Distributed Component Object Model

  • RMI Sunsoft

    • Remote Method Invocation

    • JAVA

  • Message


    Messaging services
    Messaging Services

    • Location transparency

      • location service with ORB

    • Remoteness transparency

      • hides the fact that an object is located on another machine

      • PROXY objects

        • local representative of a remote object

        • the proxy presents the object’s interface to other objects on the local machine

        • it forwards requests for services to the real object

        • proxies allow objects to be moved without affecting any of the systems since they can be replaced by a new proxy

        • Proxies can talk to other proxies

    Mobile objects
    Mobile Objects

    • The ideal solution for distributed object systems is to allow objects to move themselves freely from machine to machine within a virtual object space.

    • JAVA offers the ability to define objects that can move themselves over a network.

    • Mobile objects support load balancing

    • Mobile objects permit flexible architectures.

    Mobile Objects

    Remoteness Transparency

    Location Transparency

    Remote Messaging

    The need for rules
    The Need for Rules

    • Objects contain methods for executing procedures and they have variables to hold the inputs and outputs of those procedures

    • Objects lack a good mechanism for capturing rules that determine when and how these procedures should be carried out.

    • Policies can be hard-coded into objects but that makes them rigid and hard to modify and not adaptive.

    • Apart from procedures and data, objects need rules to make them adaptive and intelligent.

    • Rules address the “when” and “whether” questions.

    Design business rules
    Design Business Rules

    • Business rules should remain visible and modifiable to managers instead of hiding them in the code of a method.

    • The business rules should be encapsulated within the objects and not be stored in a separate rule base.

    • This facilitates the integration of knowledge from different human experts (rules from marketing and from production)

    • Rules can also be designed as separate objects invoked from other object methods.

    Rule objects
    Rule Objects

    • Simplest form of a Rule class

      1. Condition: variable or method that evaluates to true or false

      2. Action: method defined within the class that contains the rule

    • Composite rules can be useful

      • they can be made dynamic because they can manage lists of other rules

      • it is possible to build rule classes that perform automatic code generation (facilitated by dynamic languages like Smalltalk or JAVA)

    Objects as agents
    Objects as Agents

    • If objects are mobile and use rules to guide their actions, they can take on a great deal of responsibility within a business system.

    • An object becomes an active agent, representing and guiding the actions of its real-world object.

    • Agent objects can :

      • monitor the information systems

      • watch for changes

      • scan the internet for useful information

      • carry out routine business transactions

      • ….

    • Agent technology can be seen as an alternative for object technology, but it is better seen as an extension