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.

1. Briefly explain the following:

b) Define classes, abstract classes and interfaces and explain their utility. [4]

A class defines constituent members which enable class instances to have stateand 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 runtimeonly. 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 methodcalls 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 Associationrepresents 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
Database Design	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 programmingcan 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 paradigmusing "objects" – data structuresconsisting of data fieldsand methodstogether 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 languagesnow 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 classeswith 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.