Study Experiment – Object Oriented Concepts

Aim:
To study about the object-oriented concepts.

Description:
Basic OO Concepts

Introduction:

Goal of OO: Reduce complexity of software development by keeping details, and

especially changes to details, from spreading throughout the entire program.

This presentation assumes "Basic Class Design" presentation.

Definitions

 Client Code - the code that uses the classes under discussion.

 Coupling - code in one module depends on code in another module

Change in one forces rewrite (horrible!), or recompile (annoying), of code in the

other. Four key concepts of OOP

1. Abstraction - responsibilities (interface) is different from implementation

  Distinguish between interface and its behavior vs. the implementation
and its details

 A class provides some services, takes on some responsibilities, that are

defined by the public interface. How it works inside doesn't matter.

 Client should be able to use just the public interface, and not care about
the implementation.

2. Encapsulation - guarantee responsibilities by protecting implementation from

interference

 Developer of a class can guarantee behavior of a class only if the

internals are protected from outside interference. Specifying private
access for the internals puts a wall around the internals, making a clear
distinction between which code the class developer is responsible for,
and what the client developers are responsible for.

3. Inheritance - share interface and/or implementation in related classes

 Express commonalities between classes of objects by arranging them

into an inheritance hierarchy. Allows functionality shared between
classes to be written/debugged/maintained in one place, the base class,
and then reused in descendant classes (shared implementation).

 More importantly, allows client code to interact with classes in the

hierarchy through an interface specified in the base class of the
hierarchy (shared interface).

4. Polymorphism - decouple client from exact class structure

 Allows client code to use classes in an class hierarchy in a way that

depends only on the public interface of the base class. Derived classes
will implement this interface differently, but in ways compatible with
the shared public interface.

General Approach for Designing Classes:

Do the class design work at the level of the public interfaces, not the private
implementations.

I. Don’t get bogged down in implementation details like “I can do with this with
a map container and a deque!”
II. Think only about what the class responsibilities are and what they do in their
 public interfaces:

 Class X is responsible for …., class Y for ….

 When an X object needs … it calls the public member function … of

the appropriate Y object with … as parameters, which returns …

III. Try writing pseudo code just for the interactions between class objects through
their public interfaces.

IV. Keep this up until you can’t stand it any more, then make implementation
choices and write the code.

Continue design thinking until you have thought of at least two reasonable ways to
solve each design problem.

I. “Reasonable” here means “not obviously stupid.”

II. Don’t just jump on the first design you think of and hack it out.

III. All designs are imperfect - they all involve trade-offs. They are good in some
ways, bad in others.

IV. A good design is good in the most important ways, and bad in the less
important ways.

V. But there might be more than one good design - just different in the specific
tradeoffs.

VI. You can’t make an intelligent choice if you have only thought of one design -
there could be another, better, simpler one.
 Study of UML Diagrams – Aim and Scope of Diagrams

AIM:
General study of UML

DESCRIPTION:
Why is UML important?
Let's look at this question from the point of view of the construction trade. Architects
design buildings. Builders use the designs to create buildings. The more complicated the
building, the more critical the communication between architect and builder. Blueprints are
the standard graphical language that both architects and builders must learn as part of their
trade.
Writing software is not unlike constructing a building. The more complicated the
underlying system, the more critical the communication among everyone involved in creating
and deploying the software. In the past decade, the UML has emerged as the software
blueprint language for analysts, designers, and programmers alike. It is now part of the
software trade. The UML gives everyone from business analyst to designer to programmer a
common vocabulary to talk about software design.
The UML is applicable to object-oriented problem solving. Anyone interested in
learning UML must be familiar with the underlying tenet of object-oriented problem solving
-- it all begins with the construction of a model. A model is an abstraction of the underlying
problem. The domain is the actual world from which the problem comes. Models consist of
objects that interact by sending each other messages. Think of an object as "alive." Objects
have things they know (attributes) and things they can do (behaviors or operations). The
values of an object's attributes determine its state.
Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors
(methods or functions) into a single distinct entity. Objects are instances of classes.

UML NOTATION
 Unified Modeling Language.
 Set of notations and conventions used to describe and model an application.
 Universal language for modeling systems.
 Standard notation for OO modeling systems.
 Does not specify methodology to develop an application.
 UML DIAGRAMS

The heart of object-oriented problem solving is the construction of a model. The

model abstracts the essential details of the underlying problem from its usually complicated
real world. Several modeling tools are wrapped under the heading of the UML™, which
stands for Unified Modeling Language™. The purpose of this course is to present important
highlights of the UML.
At the center of the UML are its nine kinds of modeling diagrams, which we describe
here.
 Class Diagram
 Use Case Diagram
 Behavioral Diagram
 Interaction Diagram
 Sequence Diagram
 Collaboration Diagram
 State Chart Diagram
 Activity Diagram
 Implementation Diagram
 Component Diagram
 Deployment Diagram
Some of the sections of this course contain links to pages with more detailed
information. And every section has short questions. Use them to test your understanding of
the section topic.

CLASS DIAGRAM
 Shows the static structure of the model.
 Collection of static modeling elements such as classes and their
relationships connected as a graph.
 Provides visual representation of objects, relationships and their structures.
 Class:-
 A class is a set of objects that share a common structure and common behavior.

<Class Name>
<Attributes>
<Operations>

Interface:-
 Specifies the externally-visible operations of a class and/or component.

Association:-
 Model properties of associations.
 The properties are stored in a class and linked to the association relationship.
 Example,

Bank Account Person

Generalization:-
 A generalize relationship is a relationship between a more general class or use case
and a more specific class or use case.
 Example,

Vehicle

Bus Truck Car

USE CASE DIAGRAM

 Set of use cases enclosed by system boundary, communication association between
actors and use cases, and generalization among use cases.
Actors:-
 External factors that interacts with the system from the user's perspective.
Use Cases:-
 Set of scenarios that describe how actor uses the system.
 Represented as,

Relationship:-
 Communication – communications with the use case normally.
 Uses – Shown by generalization arrow from the use cases.
 Extends – Used when one case does more than another that is similar to it.

BEHAVIOR DIAGRAM INTERACTION

DIAGRAM

 Diagrams that describes how group of objects are collaborated.

SEQUENCE DIAGRAM:
 Describes the behavior of the system through interaction between the system and the
environment in time sequence.
 Two dimensions:
 Vertical dimension – represents time.
 Horizontal dimension – represents objects.
 Life line – Object's existence during the interaction.

Object 1 Object 2

<Event>
COLLABORATION DIAGRAM:
 An interaction diagram that shows the order of messages that implement an operation
or a transaction.
 Collaboration diagrams show objects, their links, and their messages.

Object 1 Object 2
1. <Event>

Object:-
 An object has state, behavior, and identity.
 Objects interact through their links to other objects.
Link:-
 A link is an instance of an association, analogous to an object.
Message:-
 A message is the communication carried between two objects that trigger an event.

STATECHART DIAGRAM
 Models the dynamic behavior of individual classes or any other kind of object.
 Shows the sequences of states, events, and actions.
State:-
 Represents a condition or situation during the life of an object during which it satisfies
some condition or waits for some event.

<State>

Start State:-
 Shows the beginning of workflow.

End state::-
 Represents the final or terminal state.
ACTIVITY DIAGRAM
 Used for modeling the sequence of activities in a process
 Special case of a state machine in which most of the states are activities and most of
the transitions are implicitly triggered by completion of the actions in the source
activities.
Activity:-
 Represents the performance of task or duty in a workflow.

<Activity>

Swim lanes:-
 Represents organizational units or roles within a business model.
IMPLEMENTATION DIAGRAM
 Shows the implementation phase of system development.
 Two types of implementation diagrams:
 Component diagram
 Deployment diagram

COMPONENT DIAGRAM
 Models the physical components in the design.
 A graph of the design’s components connected by dependency relationships.
 Includes concept of packages.
 Package is used to show how classes are grouped together.

DEPLOYMENT DIAGRAM
 Shows the configuration of runtime processing elements and software components.
 It is a graph of nodes connected by communication association.
 Nodes are the components that are connected to other components through
dependencies.
 Used in conjunction with component diagrams to show the distribution of physical
modules.