OBJECT

We define an object as a concept, abs ration or thin g with crisp boundaries and meaning

for the problem at hand. Object serve two purpose: They promote understanding of the real world

and provide a practical basis for computer implementation. Decomposition of a problem into

objects depend on judgment and the nature of the problem.

All objects have identity and are distinguishable. Twins are two identical persons, even

though they may look the same. The term identity means that objects are distinguished by their

inherent existent and not by descriptive properties that they may have.

The word object is often vaguely used in the literature. Sometime object means a single times it refers to a group of Similar things. Usually the context resolves any ambiguity.

CLASSES

An objects class describes a group of objects with similar properties , common behavior,

common relationship to other objects and common semantics. The abbrevation class is often used

instead of objects classes. Objects in a class have the Same attributes and behavior patterns.

Most objects derive their individuality from difference in there attribute values and relationship to

another.

The objects in a class shares a common semantic purpose, above and beyond there

equipment of common attributes and behavior. Each object "knows" its class. Most object

oriented programming languages can determine an objects class at run time.

If objects are the focus of object modeling why both wit h classes? The notation of

abstraction at the heart of t e matter. By grouping into objects into classes, we abstract a problem

. Abstraction gives modeling its power and ability to generalize from a few specific case to a host

of similar cases. Operations can be written once per instances. Operation s can be written on e

for each class, so that all the objects in the class benefits from code reuse. Even special cases, such

as circles and squares, can use the general procedure, though more efficient procedures are

possible.

ADVANCED LINK AND ASSOCIATION CONCEPTS

1.Link Attributes

An attribute IS a property of the objects in a class. Similarly, a link attribute is a property

of the Iinks in an association Access permits $1 on Is an attribute of Accessible by. Each Iink

attribute has a value for each , as illustrated by the sample data at the bottom of the figure The OMT notation for a link attribute is a box attached to the association by a loop one or more link attributes may appear In the Second region of the box. This notation emphasizes the similarity between attributes for links.

Many -to -many associations pro vi de the most compelling rati Dante for link attributes. Such an attribute is a property of the link and cannot be attached to either object. Access

permission is a property of Yd e and User, and cannot b e attached to either File or User alone

without I o sing Information

Generalization and inheritance

Generalization and inheritance are abstractions for sharing similarities among classes while preserving their differences . Generalization is the relation between a class an done or more refined version s of it. The class being refined is called the super class and each refined version is called a subclass attributes and operation common to a group of sub classes are attached to the super class an d shared by e ach subclass. Each subclass is said to inherit the features of its superclass. Generalization is sometime called " is a" :relationship because each Instance of subclass is an instance of superclass as well.

Generalization and inheritance are transitive across an arbitrary number of levels. The term

ancestor and descendent refer to generalization of classes across the multiple Ievels. An instance of a subclass is simultaneously an instance of its ancestor classes. Each subclass not only Inherits all the features of its ancestors but adds its on specific attributes and operations as well.

The notation for generalization Is a triangle connecting a super class to its subclasses . The super class is connected by a line to the apex of the triangle. The subclasses are connected by Iines to a horizontal bar attached to the base of the triangle .

Use of generalization

Generalization is a useful constructor both modeling and implementation Generalization facilitates

modeling by structuring classes and capturing what is similar and what is different about classes.

Inheritance of operations is help full during implementation as a vehicle for reusing code. Object connected languages provide strong support for the notion of inheritance In contrast, Current database systems provide Iittle or no support for inheritance . Object connected database programming languages and extended relational database systems show promise of connecting this

situations. After modeling a system the developed at the resulting classes and these to group simliar classes and reuse common code.

Aggregation

Aggregation is a strong form of association. An aggregaton is a complex object, which is made up of component objects. The individual parts may or may not exist independently. Semantically it is an extended object that is treated as a unit. It adds semantic connotation in some cases. If objects are tightly bound in a part hole relationship it might be usefuI to model the relationships as an aggregation. If not they shod be mode/led as normal relationships. The choice between using aggregation or not is one of judgement more then one of rules.

Aggregation is not the same thing as generalization. In aggrega6on individual distinct objects is combined, one is part of the other. Generalization models the relationship subclass super-class. An object is simultaneously part of the both the subclass and the super-class. Both sub-class and super-class refer to the same object. Aggregation is seen as an part hole relationship and generalization is called "a kind of" or "is a". An aggregate can be fixed, variable or recursive. A fixed aggregate means that the number of subparts is predefined. In a variable aggregate the number of parts may vary. A recursive aggregate has directly or indirectly an instance of the same kind of aggregate. Propagation or triggering is a good indicator of aggregation. The trigger leads to the application of a network of operations. When moving an aggregate of its parts moves.

Abstract classes

An abstract class is a class that has no Instances but whose

descendent classes have direct instances. A concrete class is a class that Is instantiable

that is can Ieave direct instances. A concrete class may have abstrct classes. A concrete

class may be a Ieaf class in the Inheritance tree only concrete classes may be the Ieaf

class In the inheritance tree. The figure shows the definition o f abstract class an d concrete

class . the dotted line IS the objct modeling notation for Instantiation.

Abstract classes organize features to several classes. It is open useful to create an abstract

Super class to encapsulate classes that participate In the association or aggregation . Zorne

abstract classes appear naturally In the application domain . Other abstract classes are

artificially introduced as a mechanism for promoting code rense.

GENERA

LIZATION AS EXTENSION AND RESTRICTION

An instance of a class is an instance of all ancestors of that class.

Generalization implies that subclasses must bee an instantiation of all its ancestors.

A subclass can not omit any inherited features and all ancestor operations must

apply. However a subclass may implement operations, add new features, place

constraints on ancestor attributes and rename inherited features.

Class membership is either ruled by rules or explicit by enumeration. In

ruled govern memberships defined the conditions for being a class member it is a

ruled based membership. If the condition determining class membership is explicit

by enumeration an attribute value determines class membership.

A subclass may add new features. This is called extension. A subclass may

also constrain ancestor attributes. This is called restriction because it restrict the values that

instances can assume. Inherited features can be renamed in a restriction.

The inherited major and minor axes of a circle must be equal and could be renamed

the diameter. Changing an operation is called overriding. Overriding is done for:

* extention in which case some extra behavior is added

* restriction when the types of possible arguments is limited

Overriding for extension: The new operation is same as the inherited operation,

except adds some behavior, usually affecting new attributes of the subclass.

Overriding for restriction: The new operation restricts the protocol such astightening the type

of arguments. This may necessary to keep the inherited operation closed with in the subclass.

METADATA

Meta data is data that describes other data. Models are inherently metadata, since they describe the things being modelled.

Patterns and Metadata

Real world things may be metadata. There are real world things that describe other real-

world things, Iike a blueprint describes a house.

Object Design

During object design, developers define solution domain objects to bridge the gap between the analysis model and the hardware/software platform defined during system design. This includes precisely describing object and subsystem interfaces, selecting off-the-shelf components, restructuring the object model to attain design goals such' as extensibility or understandability, and optimizing the object model for performance. The result of the object design activity is a detailed object model annotated with constraints and precise descriptions for each clement.

Object design includes

• reuse, during which we identify off-the-shelf components and design patterns to make use of existing solutions

• service specification, during which we precisely describe each class interface

• object model restructuring, during which we transform the object design model to improve its understandability and extensibility

• object model optimization, during which we transform the object design model to address performance criteria such as response time or memory utilization.

Object design like system design is not algorithmic. Object design is not sequential.

The interface specification activities of object design include

• identifying missing attributes and operations

• specifying type signatures and visibility

• specifying invariants

• specifying preconditions and postconditions.

Dynamic modeling

Events and states

An object model describes the possible patterns of objects, attributes and links

that can exist in a system. The attribute values and links held by an object are

called its state. Over time, the objects stimulate each other, resulting in a series of

changes to their states. An individual stimulus from one objet to another is called

an event. The pattern of events, states and state transitions for a given class can

be abstracted and represented as a state diagram. The dynamic model consists of

multiple state diagrams, one state diagram for each class with important dynamic

behavior.

Events

An event is a something that happens at a point of time. An event has no

duration. One event may logically precede or follow another, or the two events

may be unrelated. Two events that are causally unrelated are said to be

concurrent, they have no effect on each other. An event is one way transmission

of information from one object to another. An object sending an event to another

object may expect a reply, but the reply is a separate event under control of the

second object, which may or may not choose to send it. An event conveys

information from one object to another. Some classes of events may be simply

signals that something has occurred, while other classes of events convey data

values. The data values of an event are its attributes.

Example of event classes and attributes

airplane flight departs (airline, flight num, city)

mouse button pushed (button, location)

input string entered(text)

phone receiver lifted digit

dialed(digit) engine

speed enters danger zone

Scenarios and event traces

A scenario is a sequence of events that occurs during one particular execution of a

system. The scope of scenario can vary; it may include all events in a system, or it

may include only those events impinging on or generated by certain objects in a

system.

A scenario for a phone call

Caller lifts receiver Dial

tone begins Caller

dials digit (5) Dial

tone ends

Caller dials digit (5)

Caller dials digit (5)

Caller dials digit (1)

Caller dials digit (2)

Caller dials digit (3)

Caller dials digit (4)

Called phone begins ringing

Ringing tone appears in calling phone

Called party answers

Called phone stops ringing

Ringing tone disappears in calling phone

Phones are connected

Called party hangs up

Phones are disconnected

Caller hangs up

Each event transmits information from one object to another. The next after

writing a scenario is to identify the sender and receiver objects of each event. The

sequence of events and the objects exchanging events can both be in an

augmented scenario called an event trace diagram

Event trace for a phone call

Caller lifts receiver

Dial tone begins

Caller dials digit (5)

Dial tone ends

Caller dials digit (5)

Caller dials digit (5)

Caller dials digit (1)

Caller dials digit (2)

Caller dials digit (3)

Caller dials digit (4)

Ringing tone phone rings

Answers phone

Tone stops ringing stops

Phones connected Phones connected

Callee hangs up

Connection broken Connection broken

Caller hangs up

Caller phone line callee

States

A state is an abstraction of the attributes values and links of an object. Sets of

values are grouped together into a state according to properties that affect the

gross behavior of the object. A state specifies the response of the object to input

events. The response to an event received by an object may vary quantitatively

depending on the exact values of its attributes, but the responses are

quantitatively the same for all values within the same state, and may be

quantitatively different for values in different states. A state has duration it

occupies an interval of time. A state is associated with a continuous activity. In

defining state we ignore those attributes that do not affect the behavior of the

object, and we lump together in a single state all combinations of attribute values

and links that have the same responses to events.

State diagrams

A state diagram relates events and states. When an event is received the next

state depends on the current state as well as event, a change of state caused by

an event is called a transition. A state diagram is a graph whose nodes are states

and whose directed arcs are transitions labeled by an event names. A state is

drawn in rounded box containing an optional name. a transition is drawn as an

arrow from the receiving state to the target state; the label on the arrow is the

name of the events causing the transition. All the transitions leaving a state must

correspond to different events. The state diagram specifies the state sequence

caused by an event sequence. It also represent one shot life cycles or continuous

loops.

OPERATIONS

Controlling Operations

An activity is a operation that take time to complete. An activity is associated with a state. Activities include continuous operations as sequential operations that terminate by themselves after an interval of time. The notation "do: A" within a state box indicates that activity A starts on entry to the state and stop on exit. The same notation "do: A" indicates that sequential activity A begins on entry to the state and stop when complete.

An action is an instantaneous operation. An action is associated with an event. An action represent an operation whose duration is insignificant compared to the resolution of the state diagram. A real-world operation is not really instantaneous. Actions can also represent internal control operations, such as getting attributes or generating other events.The notations for an action on a transition is a slash ('/') and the name of the action , following the name of the event causes it.

Fig. Action for pop-up menu

Fig. Summary of notation for unstructured state diagrams

state diagram for phone line

NESTED STATE DIAGRAMS

State diagrams can be structured to permit concise descriptions of complex

systems. The ways of structuring state machines are similar to the ways of structuring

objects: generalization and aggregation. Generalization is equivalent to expanding nested

activities. It allows an activity to be described at a high level, then expanding at lower

level by adding details, similar to a nested procedure call. In addition, generalization

allows state and events to be arranged in to generalization beer archies with inheritance of

common structure and behavior, similar to inheritance of attributes and operations in

classes. Aggregation allows a state to be broken in to orthogonal components, with limited

interaction among them . Aggregation is equivalent to co n currency of states.

Problems with Flat State Diagrams:

State diagrams have often been criticized because they allegedly lack expensive

power and impractical for large problems. These problems are true of flat, unstructured

state diagrams. Consider an object with n in dependent Boolean attributes that affect

control. Representing such an object with a single flat diagram require 2^n states.

partitioning the state in to n independent state machines, however, only 2n states are

required. Consider the state diagram shown in figure in which n^2 transitions are ne e de d to

connect ever y state to every other state. If this model can be reformulated using structure,

the number of transitions could be reduced as low as n.