ECSECS-503: Object Oriented Techniques Unit - I The Meaning Of Object Orientation :

The object orientation is a computer programming methodology. The term Object oriented means we organize software as a collection of discrete objects that incorporates both the data structure and behaviors. It is a contrast to conventional programming in which data structure and behaviors are loosely connected. It promotes understanding of the real world and provides a practical basis for computer implementation. In software development, object oriented approach mainly focuses/emphasis on data structure rather than on procedures/behavior/algorithm. Object orientation is a new way of thinking about problem using model organized around real-world concept. The fundamental idea behind object orientation is to combine both the data and behavior into a single unit, such unit is called an object. object. Advantages Advantages Of Object Orientation: Complex software systems become easier to understand. Object orientation methodology reduces the overall maintenance cost. Software quality is improved. Enhance the extensibility of products. Provides the concept of re-usability. Provides the striking features like inheritance, polymorphism, data abstraction, data hiding etc. Achieves a modularity approach in products. The benefit of Object Orientation only realizes on large scale. Requires intensive testing techniques. OO approach is more time taken than structured programming approach. Limitation Of Object Orientation:

Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 1

Object Identity:
The fundamental construct of object orientation is objects. objects Object can be any run time entity that have attribute/properties, behavior/method, unique identity and must exist in real world. Identity means that data is quantized into discrete, distinguishable entities called object. Each object has its own inherent and unique identity. identity Two objects are distinct even if all their attributes values are identical. In the real world an object simply exists, but within programming language each object has unique identity by which it can be uniquely referenced. The unique identity(id) of object may be implemented in various ways, such as an address of memory, an index of array, or unique value of an attribute. Example : Bi-Cycle is not an Object, but Mukeshs bi-cycle is an Object.

Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 2

Encapsulation:
Encapsulation is a process of wrapping the data and methods into a single unit. The encapsulated data is not accessed outside the world, only those methods which are wrapped together with data can access that, this thing is sometime referred as information-hiding/data-hiding. information-hiding/data hiding. /data Encapsulation consists of separating the external aspect of an object, which are accessible to other object from internal implementation details of the object. Encapsulation makes it possible for objects to be treated as black box, each perform a specific task without concern for internal implementation. Encapsulation provides two features : o Modularity : The source code for an object can be written and maintained independent of the source code for other object. o Data Hiding : The object can have private or public information that can be used as per requirement or situation without affecting other object that depends on it. Data hiding prevents direct access to internal data from client or outside world. To access internal data, client must use getter and setter methods. Encapsulation is a mechanism that binds together the code and the data it manipulates, and keeps both safe from outside interference and misuse. Information hiding restricts direct exposure of data, data is accessed indirectly using safe mechanism (in programming context i.e. methods). Taking bike as an example, we have no access to piston directly, we can use start-button to run the piston. If a bike manufacturer allows direct access to piston, it would be very difficult to control actions on the piston. A common use of information hiding is to hide the physical storage layout for data so that if it is changed, the change should be restricted. Example: Suppose we have class named Student that have an attribute named age that is taken as an byte type, if age is direct accessible to all then client can assign any valid byte value(-128 to 127) to age attribute, but using information hiding we can apply restriction to value for age that is the valid values for age ranges from 5-90 years only.
Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 3

Polymorphism:
The term Polymorphism derived from the Greek word, meaning many form. Polymorphism is a mechanism by which a single object can exhibit multiple behaviors in different instance/situation. Polymorphism is a feature that allows one interface to be used for a general class of action, the specific action is determined by the exact nature of the situation. Polymorphism allows one interface to be used for a set of actions that is one name may refer to many functionality. Polymorphism allows an object to accept different request for same task from client and perform task differently as per input passed by client to perform task. Types Of Polymorphism : o Compile Time Polymorphism. Method, Constructor and Operator Overloading is an example of Compile Time Polymorphism.(Discuss Later in Detail) Note: Java does not allow to overload the Operators. o Run Time Polymorphism. Method Overriding is an example of Runtime Polymorphism. (Discuss Later in Detail)

Generosity: Generosity:
Generosity is a technique for defining a software component that has more than one interpretation depending on the data type of parameter. It provides an abstraction of data items without specifying their exact type. These unknown data type are resolved at the time of their usage. o In case of classes, at the time of object construction. o In case of methods, at the time of method call. The Generosity introduced in java from JDK1.5 version as GENERICS in JAVA In Java, we can create Generic classes, interfaces and methods.

Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 4

Importance Of Modeling:
A model is a simplification of reality, we make model for better understanding of the system. A model omits non essential details. Engineers, artist and craftsmen have built model for thousands of year to tryout design before executing them. Each model has the following elements : o Notation : The language for expressing each model o Process The activities leading to the construction of the systems model. Process: o Tools : To help in model building Modeling Purpose : Testing a physical entity before building it Modeling is important due to the following reason: o Model helps us to visualize a system. o Model permits us to specify the structure and behavior of system. o Model gives us a template that helps in constructing a system. o Model helps in documenting the decision. A model is an abstraction of something for the purpose of better understanding of the system before building it. ABSTRACTION : o Abstraction is a selective examination of certain aspects of a problem. The goal of abstraction is to isolate those aspects that are important for some purpose and suppress that aspect that is unimportant. o Abstraction must always be for some purpose because purpose determines what is and what is not important. o A good model captures the crucial aspects of the problem and omits the other ones. or o A good abstraction is one that emphasizes details that are significant to the reader or user and suppress the details that are, at least for the moment, immaterial or the diversionary.

Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 5

Modeling: Principle Of Modeling:

There are four basic principles of Modeling:

The model which is created to show,

o o

How a problem is identified and How solution is created.

Every model may be expressed at different level of precision. The best models are connected to reality. No single model is sufficient.

FIRST PRINCIPLE :

The choice of model is important because the wrong model

misleads you. The right model illuminate the most difficult development problems, offering insight that you could not gain otherwise. PRINCIPLE SECOND PRINCIPLE :

Level of precision may differ, all the models having different level
or reality such as when we developing Graphical User Interface (GUI) system a quick executable model of user interface having high level of precision. THIRD PRINCIPLE :

The best models are connected to reality, a physical model of a

building that does not respond the same way as the real materials has limited value. Its the best to have model that have clear connection to reality. FORTH PRINCIPLE :

No single model is sufficient, each model may have structural and

behavioral aspect. Together they represent the blueprint of a software system. Use Case : view exposing the requirement of the system. Logical View: capturing the vocabulary of the problem & solution space. Process View: modeling the distribution of systems process and threads. Implementation View: addressing the physical realization of the system Deployment View: focusing on system engineering issues.
Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 6

Object Oriented Modeling:

The Object Oriented Modeling is methodology that combines these three views of modeling system. The Object Model represents the static structural, data aspects of a system. The Dynamic Model represents the temporal, behavior, control aspect of a system. The Functional Model represents the transformational, function aspect of a system. These models separate s system into orthogonal views that can be represented and manipulated with a uniform notation. The different model are not completely independent a system is more than a collection of independent parts but each model can be examined and understood by itself to a large extend. The interconnection between the different models is limited and explicit. Object Model : The object model describes the structure of object in a system. It describes objects Identity, Attribute, Operation, and Relationship to other object. An object model provides the essential framework into which the dynamic and functional model can be placed. The goal of constructing object model to capture those concept from the real world that are important to an application. The Object model is represented graphically with class and object diagrams containing diagrams objects and classes. Classes are arranged into hierarchies, and associated with other classes. Class defines the attributes and operations carried by each object instance. Dynamic Model : The dynamic model describes those aspect of a system concerned with time and sequencing of operationsEvents that marks changes, Sequence of events. State that define the context for event. and
Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 7

Organization of events and state. The dynamic model is represented graphically with state diagrams diagrams. Functional Model : The functional model describes those aspects of a system concerned with transformations of valuesFunctions, Mappings, Constraints, and Functional dependencies The functional model is represented graphically with data flow diagram (DFD). The data flow diagram shows the dependencies between values and the computation of output values from input values and function.

Requirement Of Object Oriented Modeling : 1) User Friendly : The OO Modeling should be sufficiently user friendly to all kind
of users, all the relevant part of modeling must be understandable and must be clear also.

2) Expressive : The model are must be expressive, precise and clear, these are the
required properties for any model.

3) Correctness : The model must be precise that leads model towards correctness,
reliability and robustness.

4) Separation & Concerns : It means the components of a model can be formed

each with having certain role.

5) Tool Support : Effective tool support can really improve the software
engineering process.

6) Standardization : The standardization of object oriented modeling language is

absolutely necessary in context to globalization of modeling language.

Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 8

Introduction to UML :
Stands for Unified Modeling Language Unified: make the same standard, rules Modeling: means to create a simplified representation of something Language: is medium of communication. UML was created by Object Management Group(OMG) UML 1.0 specification draft was proposed to the OMG in January 1997. The OMG is a non-profit organization with about 700 members that sets standards for distributed object oriented computing. The UML is an international industry standard graphical notation for describing software analysis and designs. It is a graphical(pictorial) language used to make software blue prints Before physical implementation of a system It allow you to create blue print of all the aspects of the system UML is generally used to model software systems but it is not limited within this boundary. It is also used to model non software systems as well like process flow in a manufacturing unit etc. UML is not a programming language but tools can be used to generate code in various languages using UML diagrams It is not a programming language, it a modeling language from which programs can be derived. It can be described as a general purpose visual modeling language to specify ,visualize, construct and document software system. Specification:A. Specification:- What are the requirements of a system Visualization:B. Visualization:-UML allows the visualization of systems before they are implemented. Construction:C. Construction:-UML helps in implementation of a complicated system. Documentation: D. Documentation:-documentation of requirements, Functional specification, and test plans Goals of UML: To define some general purpose modeling language which all modelers can use and also it needs to be made simple to understand and use. UML diagrams are not only made for developers but also for business users, common people and anybody interested to understand the system. The system can be a software or non software.
Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 9

Models of UML 1. Business process modeling with Use Case 2. Class and Object Modeling 3. Behaviour Modeling 4. Component Modeling 5. Distribution and deployment modeling Each model is designed according to analyst, developers and customer view. These views can be describe as: 1. User Model View 2. The Structural Model View 3. The Behavioural Model View 4. The Implementation Model View 5. The Environment Model View 1. User Model View: Include the models which define a solution to a problem as understood by user or client. It uses Use case Diagram 2. The Structural Model View: Include the models which provides defines structure of a model .it uses - Class Diagram

- Object Diagram
3. The Behavioural Model View: Describe the behavioural and dynamic features and methods of modeled system . It Uses - Sequence diagram

- Collaboration Diagram - State diagram - Activity Diagram

4. The Implementation Model View: Combines the structural and behavioural model of solution .It uses Component Diagram 5. The Environment Model View: Describe both the structural and behavioural view of the system in which solution is implemented. It Uses Deployment Diagram
Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 10

Conceptual model of UML

A conceptual model can be defined as a model which is made of concepts and their relationships. A conceptual model is the first step before drawing a UML diagram. It helps to understand the entities in the real world and how they interact with each other. Conceptual model of UML can be mastered by learning the following three major elements: 1. UML building blocks 2. Rules to connect the building blocks 3. Common mechanisms of UML 1. UML building block can be define as A. Things B. Relationships C. Diagrams (A) Things: Things are the most important building blocks of UML. Things can be: 1. Structural 3. Grouping 1. Structural things: The Structural things define the static part of the model. They represent physical and conceptual elements. Following are the brief descriptions of the structural things. a. Class: Class represents set of objects having similar responsibilities. 2. Behavioral 4. Annotation

b. Interface: Interface defines a set of operations which specify the responsibility of a . Interface: class.

b. Collaboration: Collaboration defines interaction between elements.

c. Use case: Use case represents a set of actions performed by a system for a specific goal.

Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 11

d.Component: Component describes physical part of a system.

f. Node: A node can be defined as a physical element that exists at run time

2. Behavioural Things: Behavioral things are the dynamic parts of UML models .Representing behavior over time and space. Following are the brief descriptions of the behavioural things. a. Interaction: Interaction is defined as a behavior that consist of a group of messages exchanged among elements to accomplish a specific task

b. State Machine:

State Machine is a behavior that specifies the sequences of states an object goes
through during its lifetime in response to events

3. Grouping Things: It can be defined as a mechanism to group elements of a UML model together . There is only one grouping thing available a. Package: used to organize structural and behavioural things. 4. Annotational Things: These are the comments you may apply to describe, and remark about any element in a model. There is one primary kind of annotational thing, called a note. a. Note: A note is simply a symbol for rendering constraints and comments attached to an element or a collection of elements

Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 12

(B). Relationship is UML: There are four kinds of relationships in the UML: 1. Dependency 2. Association 3. Generalization 4. Realization 1. Dependency: a dependency is a relationship between two things in which a change to one element also affects the other element .

2. Association: Association is a set of links that connects elements(objects) of an UML model. It also describes how many objects are taking part in that relationship.

3. Generalization: it can be defined as a relationship which connects a specialized element with a generalized element .it basically describes inheritance relationship in the word of objects

Realization: It 4. Realization: I can be defined as a relationship in which two elements are connected . One element describes some responsibility which is not implemented and the other one implements them. This relationship exists in case of interface.

C. Diagrams in UML: A Diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and paths (relationships). You draw diagrams to visualize a system from different perspectives, so a diagram is a projection into a system 1. Class diagram 3. Component diagram 5. Use case diagram 7. Communication diagram 9. Activity diagram 2. Object diagram 4. Composite structure diagram 6. Sequence diagram 8. State diagram 10. Deployment diagram

Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 13

11. Package diagram 13. Interaction overview diagram

12. Timing diagram

A class diagram shows a set of classes, interfaces, and collaborations and their relationships. These diagrams are the most common diagram found in modeling object-oriented systems. Class diagrams address the static design view of a system. Class diagrams that include active classes address the static process view of a system. Component diagrams are variants of class diagrams. An object diagram shows a set of objects and their relationships. Object diagrams represent static snapshots of instances of the things found in class diagrams. These diagrams address the static design view or static process view of a system as do class diagrams, but from the perspective of real or prototypical cases. A component diagram is shows an encapsulated class and its interfaces, ports, and internal structure consisting of nested components and connectors. Component diagrams address the static design implementation view of a system. They are important for building large systems from smaller parts. (UML distinguishes a composite structure diagram, applicable to any class, from a component diagram, but we combine the discussion because the distinction between a component and a structured class is unnecessarily subtle.) A use case diagram shows a set of use cases and actors (a special kind of class) and their relationships. Use case diagrams address the static use case view of a system. These diagrams are especially important in organizing and modeling the behaviors of a system. Both sequence diagrams and communication diagrams are kinds of interaction diagrams. An

interaction diagram shows an interaction, consisting of a set of objects or roles, including the
messages that may be dispatched among them. Interaction diagrams address the dynamic view of a system. A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages; a communication diagram is an interaction diagram that emphasizes the structural organization of the objects or roles that send and receive messages. Sequence diagrams and communication diagrams represent similar basic concepts, but each diagram emphasizes a different view of the concepts. Sequence diagrams emphasize temporal ordering, and communication diagrams emphasize the data structure through which messages flow. A timing diagram (not covered in this book) shows the actual times at which messages are exchanged.

Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 14

A state diagram shows a state machine, consisting of states, transitions, events, and activities. A state diagrams shows the dynamic view of an object. They are especially important in modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered behavior of an object, which is especially useful in modeling reactive systems An activity diagram shows the structure of a process or other computation as the flow of control and data from step to step within the computation. Activity diagrams address the dynamic view of a system. They are especially important in modeling the function of a system and emphasize the flow of control among objects. A deployment diagram shows the configuration of run-time processing nodes and the components that live on them. Deployment diagrams address the static deployment view of an architecture. A node typically hosts one or more artifacts. An artifact diagram shows the physical constituents of a system on the computer. Artifacts include files, databases, and similar physical collections of bits. Artifacts are often used in conjunction with deployment diagrams. Artifacts also show the classes and components that they implement. (UML treats artifact diagrams as a variety of deployment diagram, but we discuss them separately.) A package diagram shows the decomposition of the model itself into organization units and their dependencies. A timing diagram is an interaction diagram that shows actual times across different objects or roles, as opposed to just relative sequences of messages. An interaction overview diagram is a hybrid of an activity diagram and a sequence diagram. These diagrams have specialized uses and so are not discussed in this book. See the UML Reference Manual for more details. This is not a closed list of diagrams. Tools may use the UML to provide other kinds of diagrams, although these are the most common ones that you will encounter in practice.

Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 15

Rules of the UML The UML's building blocks can't simply be thrown together in a random fashion. Like any language, the UML has a number of rules that specify what a well-formed model should look like. A well-formed model is one that is semantically self-consistent and in harmony with all its related models. The UML has syntactic and semantic rules for Names Scope Visibility Integrity What you can call things, relationships, and diagrams The context that gives specific meaning to a name How those names can be seen and used by others How things properly and consistently relate to one another

Execution What it means to run or simulate a dynamic model

Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 16

UML Architecture :
Any real world system is used by different users. The users can be developers, testers, business people, analysts and many more. So before designing a system the architecture is made with different perspectives in mind. The better we understand the better we make the system. UML plays an important role in defining different perspectives of a system. These perspectives are: a) b) c) d) e) Design Implementation Process Deployment The centre is the Use Case UML Architecture

Design of a system consists of classes, interfaces and collaboration. UML provides class diagram, object diagram to support this. Implementation defines the components assembled together to make a complete physical system. UML component diagram is used to support implementation perspective.

Process defines the flow of the system. So the same elements as used in Design are also used to support this perspective. Deployment represents the physical nodes of the system that forms the hardware. UML deployment diagram is used to support this perspective. Use Case view which connects all these four. A Use case represents the functionality of the system. So the other perspectives are connected with use case.
Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 17