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 balance. 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 1 diagrams. 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. 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.