2. 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
3. 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."
4. • 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
5. 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.
6. 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
7. 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
8. 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
9. 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.
10. 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,
11. 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,"
