Transcript Object Modeling OMT

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.

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

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 ?

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
Project proposal
report
project
definition
Functional
specifications
Feasibility report
system
study
design
specifications
design
program specs
code
programming
- intermediate reports
- go/nogo intervals
Installation
tests of system
performance
Post Imple- audit , feed-back
mentation
System reliability evolution
Number of
problems
time
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

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

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
OMG
Life Cycle
analysis
object
modeling
design
construction
coordination and reuse
full
system
definition
Database Evolution
File System
Database
OO - system
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
B0923C7
change
address
12403
Peters
Brussels
1 y comp
give
grade
enroll
The object paradigm
Five principles:

Abstraction

Encapsulation

Object communication , message passing

Inheritance

Polymorphism
Abstraction

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
Abstraction
From: Grady Booch
Abstraction focuses upon the essential characteristics of some object,
relative to the perspective of the user
Encapsulation
From: Grady Booch
Encapsulation hides the details of the
implementation of an object
Encapsulation

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
Classes

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

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
The task of software development is to engineer the illusion of simplicity.
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

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 :
receiver
method
90
parameter
Messages conform to signatures
Inheritance



Person
the ability of an instance
of a class C to use not
change
address
only the methods and
variables defined for C
but also those designed
for an ancestor of C
Inheritance allows new
Staff
student
member
classes to be build
incrementally on existing grade
pay
classes
Message interfaces are
also inherited
students and staff members
are sub-classes of person
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
it is possible to
override methods
Polygon
Give area
Triangle
Rectangle
Give area
Give area
Hexagon
Attention
Person
Head
Leg
This is not inheritance (but Aggregation)
Polymorphism

The ability of different objects to respond
differently to the same message is called
POLYMORPHISM
e.g.

DRAW
NEW
A variable can point to an object whose class
is not absolutely known
OO-System Reliability
Number
of
problems

With OO development techniques
 A system is never replaced entirely
 continuous evolution
 lower implementation risk
time
More about objects
Components

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
Object Request Broker
 channel of communications
between remote objects
 message bus
 CORBA industry standard
Message

IIOP
 Internet Interoperability ORB
protocol
ORB

DCOM Microsoft
 Distributed Component
Object Model

RMI Sunsoft
 Remote Method Invocation
 JAVA
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




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





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

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

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



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