Concept of Object Oriented Modeling

Document Sample
Concept of Object Oriented Modeling Powered By Docstoc
					Concept of Object Oriented Modeling
Object-Oriented Modeling, or OOM, is a modeling paradigm mainly used in computer
programming. Prior to the rise of OOM, the dominant paradigm was procedural
programming, which emphasized the use of discreet reusable code blocks that could
stand on their own, take variables, perform a function on them, and return values.

The Object-Oriented paradigm assists the programmer to address the complexity of a
problem domain by considering the problem not as a set of functions that can be
performed but primarily as a set of related, interacting Objects. The modeling task then is
specifying, for a specific context, those Objects (or the Class the Objects belongs to),
their respective set of Properties and Methods, shared by all Objects members of the
Class. For more discussion, see Object-oriented analysis and design and Object-oriented
programming. The description of these Objects is a Schema.

As an example, in a model of a Payroll System, a Company is an Object. An Employee
is another Object. Employment is a Relationship or Association. An Employee Class (or
Object for simplicity) has Attributes like Name, Birthdate, etc. The Association itself
may be considered as an Object, having Attributes, or Qualifiers like Position, etc. An
Employee Method may be Promote, Raise, etc.

The Model description or Schema may grow in complexity to require a Notation. Many
notations have been proposed, based on different paradigms, diverged, and converged in
a more popular one known as UML.

An informal description or a Schema notation is translated by the programmer or a CASE
tool in the case of Schema notation (created using a Module specific to the CASE tool
application) into a specific programming language that supports object-oriented
programming (or a Class Type), a declarative language or into a database schema.
The Object-Oriented Model

  1. The object-oriented model is based on a collection of objects, like the E-R model.
        o An object contains values stored in instance variables within the object.
        o Unlike the record-oriented models, these values are themselves objects.
        o Thus objects contain objects to an arbitrarily deep level of nesting.
        o An object also contains bodies of code that operate on the the object.
        o These bodies of code are called methods.
        o Objects that contain the same types of values and the same methods are
            grouped into classes.
        o A class may be viewed as a type definition for objects.
        o Analogy: the programming language concept of an abstract data type.
        o The only way in which one object can access the data of another object is
            by invoking the method of that other object.
        o This is called sending a message to the object.
        o Internal parts of the object, the instance variables and method code, are not
            visible externally.
        o Result is two levels of data abstraction.

     For example, consider an object representing a bank account.

         o  The object contains instance variables number and balance.
         o  The object contains a method pay-interest which adds interest to the
         o Under most data models, changing the interest rate entails changing code
            in application programs.
         o In the object-oriented model, this only entails a change within the pay-
            interest method.
  2. Unlike entities in the E-R model, each object has its own unique identity,
     independent of the values it contains:
         o Two objects containing the same values are distinct.
         o Distinction is created and maintained in physical level by assigning
            distinct object identifiers.
Temporal Modeling

State Diagrams

State diagrams are used to describe the behavior of a system. State diagrams describe all of the
possible states of an object as events occur. Each diagram usually represents objects of a single
class and track the different states of its objects through the system.

When to Use: State Diagrams
Use state diagrams to demonstrate the behavior of an object through many use cases of the
system. Only use state diagrams for classes where it is necessary to understand the behavior of
the object through the entire system. Not all classes will require a state diagram and state
diagrams are not useful for describing the collaboration of all objects in a use case. State
diagrams are other combined with other diagrams such as interaction diagrams and activity

How to Draw: State Diagrams
State diagrams have very few elements. The basic elements are rounded boxes representing the
state of the object and arrows indicting the transition to the next state. The activity section of the
state symbol depicts what activities the object will be doing while it is in that state.

All state diagrams being with an initial state of the object. This is the state of the object when it is
created. After the initial state the object begins changing states. Conditions based on the
activities can determine what the next state the object transitions to.
Below is an example of a state diagram might look like for an Order object. When the object
enters the Checking state it performs the activity "check items." After the activity is completed the
object transitions to the next state based on the conditions [all items available] or [an item is not
available]. If an item is not available the order is canceled. If all items are available then the
order is dispatched. When the object transitions to the Dispatching state the activity "initiate
delivery" is performed. After this activity is complete the object transitions again to the Delivered

State diagrams can also show a super-state for the object. A super-state is used when many
transitions lead to the a certain state. Instead of showing all of the transitions from each state to
the redundant state a super-state can be used to show that all of the states inside of the super-
state can transition to the redundant state. This helps make the state diagram easier to read.

The diagram below shows a super-state. Both the Checking and Dispatching states can
transition into the Canceled state, so a transition is shown from a super-state named Active to
the state Cancel. By contrast, the state Dispatching can only transition to the Delivered state, so
we show an arrow only from the Dispatching state to the Delivered state.