1.
Overview of Object Oriented Concepts
2.a) What
distinguishes an ADT from a class? [2]
Answer: ADT
stands for abstract data type. It is basically a set of data values
and associated operations that are specifically independent in
nature. Examples of adt are stacks,trees,lists(doubly,circular,etc)
and so on. Class is a user defined data type which the user can use
in implementing a stack ADT or tree ADT. Class is used for
implementation as it provides data hiding and encapsulation which are
the features of ADT in object oriented programming.
b)
Define classes, abstract classes and interfaces and explain their
utility. [4]
A
class defines constituent members which enable class instances to
have state
and behavior.
Data field members (member
variables or
instance
variables) enable
a class object to maintain state. Other kinds of members, especially
methods,
enable a class object's behavior. Class instances are of the type of
the associated class. For example, an instance of the class "Fruit"
(a "Fruit" object) would be of the type "Fruit".
A class usually represents a noun, such as a person, place or
(possibly quite abstract) thing. Programming languages that include
classes as a programming construct subtly differ in their support for
various class-related features. Most support various forms of class
inheritance. Many languages also support advanced encapsulation
control features, such as access specifiers.
Choosing
interfaces and abstract classes is not an either/or proposition. If
you need to change your design, make it an interface. However, you
may have abstract classes that provide some default behavior.
Abstract classes are excellent candidates inside of application
frameworks.
Abstract
classes let you define some behaviors; they force your subclasses to
provide others. For example, if you have an application framework, an
abstract class may provide default services such as event and message
handling. Those services allow your application to plug in to your
application framework. However, there is some application-specific
functionality that only your application can perform. Such
functionality might include startup and shutdown tasks, which are
often application-dependent. So instead of trying to define that
behavior itself, the abstract base class can declare abstract
shutdown and startup methods. The base class knows that it needs
those methods, but an abstract class lets your class admit that it
doesn't know how to perform those actions; it only knows that it must
initiate the actions. When it is time to start up, the abstract class
can call the startup method. When the base class calls this method,
Java calls the method defined by the child class.
g)
Explain static and dynamic binding. [4]
Dynamic
Binding refers to the case where compiler is not able to resolve the
call and the binding is done at runtime
only. Let's try to understand this. Suppose we have a class named
'SuperClass' and another class named 'SubClass' extends it. Now a
'SuperClass' reference can be assigned to an object of the type
'SubClass' as well. If we have a method (say 'someMethod()') in the
'SuperClass' which we override in the 'SubClass' then a call of that
method on a 'SuperClass' reference can only be resolved at runtime as
the compiler can't be sure of what type of object this reference
would be pointing to at runtime.
If
the compiler can resolve the binding at the compile time only then
such a binding is called Static Binding or Early Binding. All the
instance method calls are always resolved at runtime, but all the
static
method
calls are resolved at compile time itself and hence we have static
binding for static method calls. Because static methods are class
methods and hence they can be accessed using the class name itself
(in fact they are encourgaed to be used using their corresponding
class names only and not by using the object references) and
therefore access to them is required to be resolved during compile
time only using the compile time type information. That's the reason
why static methods can not actually be overriden.
2.
Object Oriented Analysis and Design (OOAD)
1.d) How
are relationships are represented in Object Oriented (OO) data model?
Discuss also the importance of inverse references in Object Oriented
(OO) data model. [4]
``For
data to be useful in providing information, they need to be organized
so that they can be processed effectively.
In
data modeling we try to organize data so that they represent as
closely as possible the real world they are amenable to
representation by computers.''
Components
of a data model
Data
models (Figure 2.1) have been introduced to help software developers
to achieve these two potentially conflicting requirements. As stated
by E.F. Codd in his 1981 Turing Award Lecture,
``A
data model is a combination of at least three components:
a
set of data structure types,
a
collection of operators which can be applied to any instance of the
data types, to retrieve, derive or modify data from any part of those
structures in any combination desired,
a
set of integrity rules, which define the consistent database states -
these rules are general in the sense that they apply to any database
using the model.''
Design
advantage
A
data model provides the designer and the programmer with substantial
advantages: the detailed data design makes use of a few building
blocks, and the manipulation of data is performed by a few operators
that are the same for all data structures.
The
Entity-Relationship (ER) model views the world as consisting of
entities and relationships between them, where an entity is a
``thing'' that can be distinctly identified, e.g. a chamber, a wire,
a point, a track, a vertex, etc., a relationship is an association
between entities, e.g. point belongs to track is an association
between a point and a track.
Entity
sets: The information about an entity is expressed by several
(Attribute, Value) pairs. For example a single point could be:
(
X, 0.56 )
(
Y, 10.75 )
(
Z, 29.14 )
where
X is the attribute and 0.569 is its value, etc. An Entity Set (ESet)
is a set of entities defined by the same attributes. Figure 2.2 shows
an example of an ESet called Point with four entities and with
attributes X, Y, Z.
The
complete data model for a high energy physics experiment is large,
containing many entity sets. In designing such a model it is useful
to display it pictorially, particularly the entity sets and the
relationships between them. Such a picture is called an Entity
Relationship Diagram.
Small
ER diagram
Figure
2.3 presents a small section of such an ER diagram showing the entity
sets Point and Track.The ESet Point is the same as in Figure 2.2.
Track has 8 attributes: the 3 components of the momentum and their
errors and the rank and file coordinates (Rhit and Fhit) of the point
at which the track strikes the calorimeter.
The
relationship between these two ESets is expressed by the arrow
joining the two entity sets: the double headed arrow shows a
many-to-one relationship (many points may lie on one track), while
the vertical bar shows that not all points are related to a track
(some points may not lie on a track).
Representing
one-to-one relationships and partiality
A
one-to-one relationship is represented by a single-headed arrow.
Partiality, i.e. having at least one entity in an ESet not related to
another entity via the relationship, is represented by a vertical bar
on the end of the arrow corresponding to the ESet in question.
Types
of relationships
The
cardinality of an ESet with respect to a relationship is the range of
the number of entities that a single entity in the ESet can be
related to. The lower bound of the range is called the minimum
cardinality and the upper bound is called the maximum cardinality.
These will be referred to as CardMin and CardMax respectively.
Examples
of cardinalities
In
ER diagrams, only 3 cases are generally of interest: 0, 1 or *
(many). Example: Consider ESets Track and Cluster.
The
cardinality of Track with respect to the relationship is [0,1]:
CardMin is 0 because some tracks do not contribute to any cluster.
CardMax is 1 because a given track may only contribute to one
cluster.
The
cardinality of Cluster with respect to the relationship is [0,*]:
CardMin is 0 because some clusters are not associated to known
tracks. CardMax is * because a cluster generally results from several
tracks.
Possible
cardinality values
The
possible cardinalities of an ESet with respect to a relationship are
[0,1], [1,1], [0,*] and [1,*]. Since ADAMO allows one-to-one and
many-to-one but neither one-to-many nor many-to-many relationships
only one of any two ESets may have CardMax = * with respect to the
same relationship. This implies 8 possible types of relationships,
which are shown in Figure 2.4.
Many-to-many
relationships
By
symmetry, a one-to-many relationship may always be modelled as a
many-to-one relationship. Sometimes relationships can be
many-to-many. An example would be if a single point could lie on more
than one track, e.g. in a region where tracks cross. Such
many-to-many relationships are not explicitly supported in ADAMO but
must be broken down into two many-to-one relationships and an
intermediate entity set.
Intermediate
ESet
The
intermediate ESet need not have any attributes, its only purpose is
to support the two relationships.
Example
Figure
2.8 shows the ER diagram and corresponding tables of a simple
many-to-many relationship. The case modelled is that of having the
point with ID 5 being also the intersection point of tracks with ID 1
and 2. Note that since the point with ID 4 does not lie on any track
there is no reference to it in the table TrackPt
A
complete ER diagram
Shown
in Figure 2.5 is the complete ER diagram of the example used in this
guide. Included in the model is a calorimeter consisting of cells
that are capable of making energy measurements. An algorithm may
group adjacent cells with energy deposits above given thresholds into
clusters. Tracks may originate from secondary vertices. More than one
track may hit a given cluster but a track need not produce a cluster
(it could miss the calorimeter). A track may not produce more than
one cluster and a cluster need not have a track pointing to it (a
neutral cluster).
Attribute
of a relationship
A
further algorithm associates tracks and clusters according to the
calculated quantity Chisq which is a measure of how well the two
match. Thus Chisq is an attribute of the relationship between Track
and Cluster and not of either one individually: it is shown hanging
from the relationship arrow.
Convenience
considerations
The
attributes Rhit and Fhit of Track are really attributes of a
relationship between Track and some other ESet called perhaps
Calorimeter. While this is strictly true it illustrates the point
that frequently we produce a model that is convenient to use rather
than one which is more logically correct.
Representing
a key of an entity set
Finally,
the * character on the attributes Rank and File in the ESet Cell
indicate that a key is to be defined on these. ESet keys are used to
identify individual entities in an ESet . The Data Definition
Language (DDL) description of a data structure is a number of plain
text DDL files written by the programmer. Experience suggests that it
is wise to divide the model into sections known as subschemas
(Section 2.6) of approximately 10 ESets in each and to have a
separate DDL file for each subschema. This way, the ER diagram
corresponding to a subschema will fit nicely on an A4 sheet of paper.
The whole is known as the schema.
Calorimeter
subschema
The
subschema corresponding to the ER diagram of Section 2.5 is stored in
the file calori.ddl and is shown in its entirety in Figure 3.2 to
Figure 3.4. It contains the definitions of the entity sets,
attributes, relationship sets, and dataflows that constitute the
model. The order of definition is not important.
Definition
of ESets
Each
box in the ER diagram corresponds to an entry in DEFINE ESET, e.g.
Cluster. The definition of Cluster's four attributes is local to
Cluster. Note that, in addition to the information contained in the
ER diagram, the DDL also specifies data types and ranges of validity
and allows the inclusion of comments.
Definition
of attributes types
Attribute
types may also be defined globally in a DEFINE ATTRIBUTE section. In
this example, Coord is such an attribute type. The attributes X, Y
and Z in both ESets Point and Vertex are then each defined as Coord.
Definition
of identifier keys
The
identifier Number in the ESet Cell is defined in the KEY ... END KEY
block and it corresponds to the *s on the attributes in the ER
diagram. This enables any entity in Cell to be uniquely identified by
the values of the two attributes Rank and File. The key Number is
also used to create an index (Figure 7.9) on Rank and File which will
allow the table Cell to be accessed according to the values of these
two attributes.
f) What
Is versioning? Why Is It Important? [4]
Information,
in whatever form: documents, spreadsheets, web pages, or source code,
changes over time. Tracking changes of a document over time is what a
versioning system does.
In
particular a versioning system records who made a specific change, it
allows backing-out undesirable changes, it gives the ability to
record why a specific change was made and to know what the document
contents were at a specific point in time.
Versioning
content is basically archiving important document versions, to have
control on changes over time.
1.a) Under
what circumstances a relationship is its own inverse? Explain.
[4]
An
inverse or negative relationship is a mathematical relationship in
which one variable decreases as another increase. For example, there
is an inverse relationship between education and unemployment —
that is, as education increases, the rate of unemployment decreases
5.b) Explain
the differences between triggers and integrity constraints.
[6]
A
declarative integrity constraint is a statement about the database
that is always true. A constraint applies to existing data in the
table and any statement that manipulates the table.
A
trigger does not apply to data loaded before the definition of the
trigger, therefore, it does not guarantee all data in a table
conforms to the rules established by an associated trigger.
A
trigger can be used to enforce transitional constraints where as a
declarative integrity constraint cannot be used.
A
trigger is a piece of code which gets automatically executed upon
occurrence of an event. It may not be meant for enforcing integrity.
For example you may want to save the user info as soon as he makes an
entry into a particular table. This will be achieved by means of a
trigger.
An
integrity constraint defines basic rules for a table's columns. It
will always be enforced, for all data which was there in the table
before the rule was added and to the new data which will be added to
the table in future
An
integrity constraint defines a business rule for a table column which
automatically takes care by Oracle internally.
Integrity
Constraints are NOT NULL, UNIQUE, CHECK, PRIMARY KEY, and FOREIGN
KEY.
A
database trigger is a procedure written in PL/SQL and Will run
implicitly when data is modified or when some user or system actions
occur. Triggers are database objects which gets stored in database
and get fires when INSERT or UPDATE statement attempts to violate the
integrity rule, Oracle must roll back the statement and return an
error if trigger exists. Database triggers are BEFOR/AFTER/
{BEFORE|AFTER} {row | statement etc.
Integrity
constraints are Proactive-- Like they take the columns into
consideration before sitting on it like if you leave a primary key on
a column having duplicate or null values it will not obey to sit on
that column.
Triggers
are reactive-- Triggers react only when a DML occurs. When it comes
and sit on a table then its starts working and never considers what
happened before it arrival
e) What
is an association relationship? Give one example of one-to-many
association. [4]
An
Association
represents a family of links. Binary associations (with two ends) are
normally represented as a line, with each end connected to a class
box. Higher order associations can be drawn with more than two ends.
In such cases, the ends are connected to a central diamond.
An
association can be named, and the ends of an association can be
adorned with role names, ownership indicators, multiplicity,
visibility, and other properties. There are five different types of
association. Bi-directional and unidirectional associations are the
most common ones. For instance, a flight class is associated with a
plane class bi-directionally. Associations can only be shown on class
diagrams. Association represents the static relationship shared among
the objects of two classes. Example: "department offers
courses", is an association relation.
OLTP
vs. OLAP
OLTP
(On-line Transaction Processing)
is characterized by a large number of short on-line transactions
(INSERT, UPDATE, DELETE). The main emphasis for OLTP systems is put
on very fast query processing, maintaining data integrity in
multi-access environments and an effectiveness measured by number of
transactions per second. In OLTP database there is detailed and
current data, and schema used to store transactional databases is the
entity model (usually 3NF).
-
OLAP
(On-line Analytical Processing)
is characterized by relatively low volume of transactions. Queries
are often very complex and involve aggregations. For OLAP systems a
response time is an effectiveness measure. OLAP applications are
widely used by Data Mining techniques. In OLAP database there is
aggregated, historical data, stored in multi-dimensional schemas
(usually star schema).
The
following table summarizes the major differences between OLTP and
OLAP system design.
|
|
OLTP
System
Online Transaction Processing (Operational System) |
OLAP
System
Online Analytical Processing (Data Warehouse) |
|
Source
of data
|
Operational
data; OLTPs are the original source of the data.
|
Consolidation
data; OLAP data comes from the various OLTP Databases
|
|
Purpose
of data
|
To
control and run fundamental business tasks
|
To
help with planning, problem solving, and decision support
|
|
What
the data
|
Reveals
a snapshot of ongoing business processes
|
Multi-dimensional
views of various kinds of business activities
|
|
Inserts
and Updates
|
Short
and fast inserts and updates initiated by end users
|
Periodic
long-running batch jobs refresh the data
|
|
Queries
|
Relatively
standardized and simple queries Returning relatively few records
|
Often
complex queries involving aggregations
|
|
Processing
Speed
|
Typically
very fast
|
Depends
on the amount of data involved; batch data refreshes and complex
queries may take many hours; query speed can be improved by
creating indexes
|
|
Space
Requirements
|
Can
be relatively small if historical data is archived
|
Larger
due to the existence of aggregation structures and history data;
requires more indexes than OLTP
|
|
Highly
normalized with many tables
|
Typically
de-normalized with fewer tables; use of star and/or snowflake
schemas
|
|
|
Backup
and Recovery
|
Backup
religiously; operational data is critical to run the business,
data loss is likely to entail significant monetary loss and legal
liability
|
Instead
of regular backups, some environments may consider simply
reloading the OLTP data as a recovery method
|
Procedural
programming
can sometimes be used as a synonym for imperative
programming
(specifying the steps the program must take to reach the desired
state), but can also refer (as in this article) to a programming
paradigm,
derived from structured
programming,
based upon the concept of the procedure
call. Procedures,
also known as routines, subroutines,
methods, or functions (not to be confused with mathematical
functions, but similar to those used in functional
programming)
simply contain a series of computational steps to be carried out. Any
given procedure might be called at any point during a program's
execution, including by other procedures or itself.
Object-oriented
programming
(OOP)
is a programming
paradigm
using "objects"
– data
structures
consisting of data
fields
and methods
together with their interactions – to design applications and
computer programs. Programming techniques may include features such
as data
abstraction,
encapsulation,
messaging,
modularity,
polymorphism,
and inheritance.
Many modern programming
languages
now support OOP, at least as an option.
Comparison
with object-oriented programming
The
focus of procedural programming is to break down a programming task
into a collection of variables,
data
structures, and subroutines,
whereas in object-oriented
programming it is to break down a programming task into classes
with each "class" encapsulating its own methods
(subroutines). The most important distinction is whereas procedural
programming uses procedures to operate on data structures,
object-oriented programming bundles the two together so an "object",
which is an instance of a class, operates on its "own" data
structure.
|
Procedural
|
Object-oriented
|
|
Procedure
|
method
|
|
module
|
object
|
|
procedure
call
|
message
|
|
variable
|
attribute
|
Advantages
of OOP
Object-Oriented
Programming has the following advantages over conventional
approaches:
- OOP provides a clear modular structure for programs which makes it good for defining abstract datatypes where implementation details are hidden and the unit has a clearly defined interface.
- OOP makes it easy to maintain and modify existing code as new objects can be created with small differences to existing ones.
- OOP provides a good framework for code libraries where supplied software components can be easily adapted and modified by the programmer. This is particularly useful for developing graphical user interfaces.
Concepts
of OOP:
- Objects
- Classes
- Data Abstraction and Encapsulation
- Inheritance
- Polymorphism
Objects: Objects
are the basic run-time entities in an object-oriented system.
Programming problem is analyzed in terms of objects and nature of
communication between them. When a program is executed, objects
interact with each other by sending messages. Different objects can
also interact with each other without knowing the details of their
data or code.
Classes: A
class is a collection of objects of similar type. Once a class is
defined, any number of objects can be created which belong to that
class.
Data
Abstraction and Encapsulation: Abstraction
refers to the act of representing essential features without
including the background details or explanations. Classes use the
concept of abstraction and are defined as a list of abstract
attributes. Storing data and functions in a single unit (class) is
encapsulation. Data cannot be accessible to the outside world and
only those functions which are stored in the class can access it.
Inheritance: Inheritance
is the process by which objects can acquire the properties of objects
of other class. In OOP, inheritance provides reusability, like,
adding additional features to an existing class without modifying it.
This is achieved by deriving a new class from the existing one. The
new class will have combined features of both the classes.
Polymorphism: Polymorphism
means the ability to take more than one form. An operation may
exhibit different behaviors in different instances. The behavior
depends on the data types used in the operation. Polymorphism is
extensively used in implementing Inheritance.
Does
procedural programming have any advantages over OOP?
Earlier
I asked this as a perhaps poorly-framed question about when to use
OOP versus when to use procedural programming - some responses
implied I was asking for help understanding OOP. On the contrary, I
have used OOP a lot but want to know when to use a procedural
approach. Judging by the responses, I take it that there is a fairly
strong consensus that OOP is usually a better all-round approach but
that a procedural language should be used if the OOP architecture
will not provide any reuse benefits in the long term.
However
my experience as a Java programmer has been otherwise. I saw a
massive Java program that I architected rewritten by a Perl guru in
1/10 of the code that I had written and seemingly just as robust as
my model of OOP perfection. My architecture saw a significant amount
of reuse and yet a more concise procedural approach had produced a
superior solution.
So,
at the risk of repeating myself, I'm wondering in what situations
should I choose a procedural over an object-oriented approach. How
would you identify in advance a situation in which an OOP
architecture is likely to be overkill and a procedural approach more
concise and efficient.
No comments:
Post a Comment