EDUCATION HOLE PRESENTS

2014

WWW.EDHOLE.COM

Object Modeling ...................................................................................................................... 2 Objects .................................................................................................................................................................. 3 Classes ................................................................................................................................................................... 3

Links and Association .............................................................................................................. 4

Generalization .................................................................................................................................. 4

Inheritance ....................................................................................................................................... 5

Aggregation ..................................................................................................................................... 6

Abstract class ................................................................................................................................... 6

Multiple inheritance ................................................................................................................ 7

Inheritance to Support Polymorphism .............................................................................................. 8

Subclasses and super classes ............................................................................................................ 9

Uninhabitable classes ....................................................................................................................... 9

Meta data ...................................................................................................................................... 10

Axiom ............................................................................................................................................ 10

Candidate keys ............................................................................................................................... 11 Constraints .......................................................................................................................................................... 11

Object Modeling Object oriented modelling is a method of analysis for modelling knowledge & information about a system where the system is divided into elements called objects. An object comprises of variables & methods. Objects of similar type are grouped into classes & objects may comprise other objects also. Modeling a system using object oriented approach several benefits such as understandability, flexibility, maintainability, extensibility, reusability, etc

Objects

Objects are the physical and conceptual things we find in the universe around us. Hardware, software, documents, human beings, and even concepts are all examples of objects. For purposes of modeling his or her company, a chief executive officer could view employees, buildings, divisions, documents, and benefits packages as objects. An automotive engineer would see tires, doors, engines, top speed, and the current fuel level as objects. Atoms, molecules, volumes, and temperatures would all be objects a chemist might consider in creating an object-oriented simulation of a chemical reaction. Finally, a software engineer would consider stacks, queues, windows, and check boxes as objects. Objects are thought of as having state. The state of an object is the condition of the object, or a set of circumstances describing the object. It is not uncommon to hear people talk about the "state information" associated with a particular object. For example, the state of a bank account object would include the current balance, the state of a clock object would be the current time, and the state of an electric light bulb would be “on or off." For complex objects like a human being or an automobile, a complete description of the state might be very complex. Fortunately, when we use objects to model real world or imagined situations, we typically restrict the possible states of the objects to only those that are relevant to our models. We also think of the state of an object as something that is internal to an object. For example, if we place a message in a mailbox, the (internal) state of the mailbox object is changed, whereas the (internal) state of the message object remains unchanged. Sometimes people think of objects as being strictly static. That is, the state of an object will not change unless something outside of the object requests the object to change its state. Indeed, many objects are passive (static). A list of names does not spontaneously add new names to itself, nor would we expect it to spontaneously delete names from itself. However, it is possible for some objects to change their own state. If an object is capable of spontaneously changing its own state, we refer to it as an "object with life." (Objects with life are sometimes also called "active objects" or "actors.") Clocks and timers are common examples of objects with life. If we were modeling a business process, we would recognize that salespeople and customers were also objects with life

Classes

There are two broad categories of objects: classes and instances. Users of object-oriented technology usually think of classes as containing the information necessary to create instances, i.e., the structure and capabilities of an instance is determined by its corresponding class. There are three commonly used (and different) views on the definition for "class":

• A class is a pattern, template, or blueprint for a category of structurally identical items. The items created using the class are called instances. This is often referred to as the "class as a `cookie cutter'" view. As you might guess, the instances are the "cookies."

• A class is a thing that consists of both a pattern and a mechanism for creating items based on that pattern. This is the "class as an `instance factory'" view; instances are the individual items that are "manufactured" (created) using the class's creation mechanism.

• A class is the set of all items created using a specific pattern. Said another way, the class is the set of all instances of that pattern.

•

Links and Association Association defines a relationship between classes of objects that allows one object instance to cause another to perform an action on its behalf. This relationship is structural, because it specifies that objects of one kind are connected to objects of another and does not represent behavior.

A bidirectional association

Unless otherwise specified, navigation across an association is bidirectional, although it may be limited to just one direction by adorning some end with an arrowhead pointing to the direction of traversal. In generic terms, the causation is usually called "sending a message", "invoking a method" or "calling a member function" to the controlled object. Concrete implementation usually requires the requesting object to invoke a method or member function using a reference or pointer to the memory location of the controlled object. The objects that are related via the association are considered to act in a role with respect to the association, if object's current state in the active situation allows the other associated objects to use the object in the manner specified by the role. A role can be used to distinguish two objects of the same class when describing its use in the context of the association. A role describes the public aspects of an object with respect to an association.

Generalization

A generalization shows that one class inherits from another. The inheriting class is called a

descendant. The class inherited from is called the ancestor. Inheritance means that the definition of the ancestor - including any properties such as attributes, relationships, or operations on its objects - is also valid for objects of the descendant. The generalization is drawn from the descendant class to its ancestor class. Generalization can take place in several stages, which lets you model complex, multilevel inheritance hierarchies. General properties are placed in the upper part of the inheritance hierarchy, and special properties lower down. In other words, you can use generalization to model specializations of a more general concept.

Example

In the Recycling Machine System all the classes - Can, Bottle, and Crate - describe different types of deposit items. They have two common properties, besides being of the same type: each has a height and a weight. You can model these properties through attributes and operations in a separate class, Deposit Item. Can, Bottle, and Crate will inherit the properties of this class.

The classes Can, Bottle, and Crate have common properties height and weight. Each is a specialization of the general concept Deposit Item.

Inheritance Inheritance can be defined as the process whereby one object acquires (gets, receives) characteristics from one or more other objects. Some object-oriented systems permit only single inheritance, a situation in which a specialization may only acquire characteristics from a single generalization. Many object-oriented systems, however, allow for multiple inheritance, a situation in which a specialization may acquire characteristics from two or more corresponding generalizations.

Aggregation

Aggregation is either:

• The process of creating a new object from two or more other objects, or • An object that is composed of two or more other objects.

For example, a date object could be fashioned from a month object, a day object, and a year object. A list of names object, for example, can be thought of as containing many name objects. A monolithic object is an object that has no externally-discernible structure. Said another way, a monolithic object does not appear to have been constructed from two or more other objects. Specifically, a monolithic object can only be treated as a cohesive whole. Those outside of a monolithic object cannot directly interact with any (real or imagined) objects within the monolithic object. A radio button in a graphical user interface (GUI) is an example of a monolithic object. Composite objects are objects that have an externally-discernible structure, and the structure can be addressed via the public interface of the composite object. The objects that comprise a composite object are referred to as component objects. Composite objects meet one or both of the following criteria:

• The state of a composite object is directly affected by the presence or absence of one or more of its component objects, and/or

• The component objects can be directly referenced via the public interface of their corresponding composite object.

It is useful to divide composite objects into two subcategories: heterogeneous composite objects and homogeneous composite objects:

• A heterogeneous composite object is a composite object that is conceptually composed of component objects that are not all conceptually the same. For example, a date (made up of a month object, a day object, and a year object) is a heterogeneous composite object.

• A homogeneous composite object is a composite object that is conceptually composed of component objects that are all conceptually the same. For example, a list of addresses is a homogeneous composite object. The rules for designing heterogeneous composite objects are different from the rules for designing homogeneous composite objects.

Abstract class

Abstract classes are classes that embody coherent and cohesive, but incomplete, concepts, and in turn, make these characteristics available to their specializations via inheritance. People

sometimes use the terms "partial type" and "abstract super class" as synonyms for abstract class. While we would never create instances of abstract classes, we most certainly would make their individual characteristics available to more specialized classes via inheritance. For example, consider the concept of an automobile. On one hand, most people know what an automobile is. On the other hand, "automobile" is not a complete definition for any vehicle. It would be quite accurate to describe "automobile" as the set of characteristics that make a thing an automobile, in other words, the "essence of automobile-nests."

Multiple inheritance A class can inherit from several other classes through multiple inheritances, although generally it will inherit from only one.

There are a couple of potential problems you must be aware of if you use multiple inheritance:

• If the class inherits from several classes, you must check how the relationships, operations, and attributes are named in the ancestors. If the same name appears in several ancestors, you must describe what this means to the specific inheriting class, for example, by qualifying the name to indicate its source of declaration.

• If repeated inheritance is used; in this case, the same ancestor is being inherited by a descendant more than once. When this occurs, the inheritance hierarchy will have a "diamond shape" as shown below.

Multiple and repeated inheritance. The Scrolling Window With Dialog Box class is inheriting the Window class more than once. A question that might arise in this context is "How many copies of the attributes of Window are included in instances of Scrolling Window With Dialog Box?" So, if you are using repeated inheritance, you must have a clear definition of its semantics; in most cases this is defined by the programming language supporting the multiple inheritances. In

general, the programming language rules governing multiple inheritances are complex, and often difficult to use correctly.

Inheritance to Support Polymorphism

Sub typing means that the descendant is a subtype that can fill in for all its ancestors in any situation. Sub typing is a special case of polymorphism, and is an important property because it lets you design all the clients (objects that use the ancestor) without taking the ancestor's potential descendants into consideration. This makes the client objects more general and reusable. When the client uses the actual object, it will work in a specific way, and it will always find that the object does its task. Sub typing ensures that the system will tolerate changes in the set of subtypes.

Example

In a Depot-Handling System, the Transporter Interface class defines basic functionality for communication with all types of transport equipment, such as cranes and trucks. The class defines the operation execute Transport, among other things.

Both the Truck Interface and Crane Interface classes inherit from the Transporter Interface; that is, objects of both classes will respond to the message execute Transport. The objects may stand in for Transporter Interface at any time and will offer all its behavior. Thus, other objects (client objects) can send a message to a Transporter Interface object, without knowing if a Truck Interface or Crane Interface object will respond to the message. The Transporter Interface class can even be abstract, never instantiated on its own. In which case, the Transporter Interface might define only the signature of the execute Transport operation, whereas the descendant classes implement it. Some object-oriented languages, such as C++, use the class hierarchy as a type hierarchy, forcing the designer to use inheritance to subtype in the design model. Others, such as Smalltalk-80, have no type checking at compile time. If the objects cannot respond to a received message they will generate an error message. It may be a good idea to use

generalization to indicate subtype relationships even in languages without type checking. In some cases, you should use generalization to make the object model and source code easier to understand and maintain, regardless of whether the language allows it. Whether or not this use of inheritance is good style depends heavily on the conventions of the programming language.

Subclasses and super classes

A Subclass, "derived class", heir class, or child class is a modular, derivative class that inherits one or more language entities from one or more other classes (called super classes, base classes, or parent classes). The semantics of class inheritance vary from language to language, but commonly the subclass automatically inherits the instance variables and member functions of its super classes. Some languages support the inheritance of other construct as well. For example, in Eiffel, contracts which define the specification of a class are also inherited by heirs. The super class establishes a common interface and foundational functionality, which specialized subclasses can inherit, modify, and supplement. The software inherited by a subclass is considered reused in the subclass. A reference to an instance of a class may actually be referring one of its subclasses. The actual class of the object being referenced is impossible to predict at compile-time. A uniform interface is used to invoke the member functions of objects of a number of different classes. Subclass may replace super class functions with entirely new functions that must share the same method signature.

Uninhabitable classes

In some languages a class may be declared as uninhabitable by adding certain class modifiers to the class declaration. Examples include the "final" keyword in Java or the "sealed" keyword in C#. Such modifiers are added to the class declaration before the "class" keyword and the class identifier declaration. Such sealed classes restrict reusability, particularly when developers only have access to precompiled binaries and not source code. The sealed class has no subclasses, so it can be easily deduced at compile time that references or pointers to objects of that class are actually referencing instances of that class and not instances of subclasses (they don't exist) or instances of super classes (up casting a reference type violates the type system). sub type polymorphism. Because the exact type of the object being referenced is known before execution, early binding (or "static dispatch") can be used instead of late binding (also called "dynamic dispatch" or "dynamic binding") which requires one or more virtual method table lookups depending on whether multiple inheritance or only single inheritance are supported in the programming language that is being used.

Meta data

Metadata are data that describe other data. When data are accompanied by such descriptions, they can be integrated into new applications on-the-fly. Indeed, when these descriptions are sufficiently rich and powerful, they can constitute a second-level language. This is distinct from the domain level in that it helps to specify the domain in such a way that it is dynamic and flexible. It makes it so that your domain objects can be reified. Neither metadata nor active object-models are new. Indeed, "meta is beta" was a mantra for database people during the '70s, and the designers of contemporary object-oriented systems build active object-models every day, without knowing they are doing anything special. This workshop brought together practitioners, language theorists, pattern mavens, architects, and academics to look for the patterns that underlie their disparate interests. By identifying the patterns and establishing a common vocabulary, we hope to relieve those who follow of the burden of reinventing these approaches yet again. The phrase "machine understandable" is key. We are talking here about information which software agents can use in order to make life easier for us, ensure we obey our principles, the law, check that we can trust what we are doing, and make everything work more smoothly and rapidly. Metadata has well defined semantics and structure. Metadata was called "Metadata" because it started life, and is currently still chiefly, information about web resources, so data about data. In the future, when the metadata languages and engines are more developed, it should also form a strong basis for a web of machine understandable information about anything: about the people, things, concepts and ideas. We keep this fact in our minds in the design, even though the first step is to make a system for information about information. For an example of metadata, when an object is retrieved using the HTTP protocol, the protocol allows information about its date, its expiry date, its owner, and other arbitrary information to be sent by the server. The world of the World Wide Web is therefore a world of information and some of that information is information about information. In order to have a coherent picture of this, we need a few axioms about metadata. The first axiom is that :

Axiom

One is that metadata can be stored regarded as data, it can be stored in a resource. So, one resource may contain information about itself or about another resource. In current practice on the World Wide Web there are three ways in which one gets metadata. The first is the data about a document contained within the document itself, for example in the HEAD part of an HTML documents or within word processor documents. The second is that during the HTTP transfer the server transfers some metadata to the client about the object which is being transferred. This, during an http GET, is transferred from the server to the client and, during a PUT or a POST, is transferred from the client to the server. One of the things which we have to rationalize in our architecture of the World Wide Web is who exactly is making the statement. Whose statement,

whose property is that metadata. The third way in which metadata is found is when it is looked up in another document. This practice has not been very common until the PICS initiative was to define label formats specifically for representing information about World Wide Web resources. The PICS architecture specifically allows for PICS labels which are resources about other resources to be buried within the resource itself, to be retrieved as separate resources, or to be passed over during the http transaction.

Candidate keys

a candidate key of a relation is a minimal super key for that relation; that is, a set of attributes such that

1. The relation does not have two distinct tulles (i.e. rows or records in common database language) with the same values for these attributes (which means that the set of attributes is a super key)

2. There is no proper subset of these attributes for which (1) holds (which means that the set is minimal).

The constituent attributes are called prime attributes. Conversely, an attribute that does not occur in ANY candidate key is called a non-prime attribute. Since a relation contains no duplicate tulles, the set of all its attributes is a super key if NULL values are not used. It follows that every relation will have at least one candidate key. The candidate keys of a relation tell us all the possible ways we can identify its tulles. As such they are an important concept for the design of database schema.

Constraints

In addition to suffered operations, the public interface of an object can also contain constants. Constants are objects of constant state. Imagine that we want to create a "bounded list of addresses class." A bounded list is a list that has a fixed maximum number of elements. A bounded list can be empty, and it can contain fewer than the maximum number of elements. It can even contain the maximum number of elements, but it can never contain more than the defined maximum number of elements. Assume that we place a constant in the public interface of our bounded list of addresses. This constant represents the maximum number of elements that can be placed in the bounded list. Assume also that there is a suffered operation that will tell us how many elements (addresses, in our example) are currently in the bounded list. We can now determine how much room is available in the bounded list by inquiring how many addresses are already in the list, and then subtracting this from the previously-defined constant. In some cases, as with the bounded list example above, constants are provided more for convenience than necessity. In other cases, such as in the case of encryption algorithms needing a "seed value,"

constants are an absolute requirement.