OOAD

V SEMESTER
OBJECT
• An object is a real world element in an object – oriented environment
that may have a physical or a conceptual existence
• Eg: car, customer, book etc.,
CLASS
• A class represent a templet collection of object having same
characteristic properties that exhibit common behaviour
ENCAPSULATION :
• The process of binding both attributes and method together within
class
• Attributes: Data of an object. ,Properties of an object.
• Methods: Procedures of an object. or Behavior of an object.
• The term object was for formal utilized in the similar language. The
term object means a combination or data and logic that represent
some real-world entity.
• When developing an object oriented applications, two basic questions
arise,
• What objects does the application need?
• What functionality should those objects have?
Car
Cost
Make
Color
Model Attributes of object
• Object Behavior and Methods:
• We can describe the set of things that an object can do on its own (or)
we can do with it.
For example: Consider an object car, We can drive the car. We can
stop the car.
• A method is a function or procedures that is defined in a class and
typically can access to perform some operation.
• Behavior denotes the collection of methods that abstractly describes
what an object is capable of doing.
• Objects Respond to Messages: The capability of an object’s is
determined by the methods defined for it.
• To do an operation, a message is sent to an object. Objects
represented to messages according to the methods defined in its class
• For example:
• When we press on the brake pedal of a car, we send a stop message
to the car object. The car object knows how to respond to the stop
message since brake have been designed with specialized parts such
as brake pads and drums precisely respond to that message.

car
Class Hierarchy

• An object-oriented system organizes classes into a subclass super class

hierarchy.

• The properties and behaviors are used as the basis for making distinctions
between classes are at the top and more specific are at the bottom of the class
hierarchy
Inheritance
• It is the property of object-oriented systems that allow objects to be
built from other objects.
• Inheritance allows explicitly taking advantage of the commonality of
objects when constructing new classes.
• Inheritance is a relationship between classes where one class is the
parent class of another (derived) class.
• The derived class holds the properties and behavior of base class in
addition to the properties and behavior of derived class.
Dynamic Inheritance

• Dynamic inheritance allows objects to change and evolve over time.

Since base classes provide properties and attributes for objects,
hanging base classes changes the properties and attributes of a class.
Example: A window objects change to icon and back again. When we
double click the folder the contents will be displayed in a window and
when close it, changes back to icon. It involves changing a base class
between a windows class and icon class.
Multiple Inheritances

• Some object-oriented systems permit a class to inherit its state

(attributes) and behavior from more than one super class. This kind or
inheritance is referred to as multiple inheritances.
• For example: Utility vehicle inherits the attributes from the Car and
Truck classes.
•
Encapsulation and Information Hiding
• Example: A car engine is an example of encapsulation. Although
engines may differ in implementation, the interface between the
driver and car is through a common protocol.
• Information hiding is the principle of concealing the internal data and
procedures of an object
• Polymorphism
• It means objects that can take on or assume many different forms.
• Polymorphism means that the same operations may behave
differently on different classes.
• The relationship of objects many different classes by some common
super class
• Polymorphism allows us to write generic, reusable code more easily,
because we can specify general instructions and delegate the
implementation detail to the objects involved.
• Example: In a pay roll system, manager, office worker and production
worker objects all will respond to the compute payroll message, but
the actual operations performed are object specific.
Object Relationship and Associations

• Association represents the relationships between objects and classes.

Associations are bi- directional. The directions implied by the name
are the forward direction and the opposite is the inverse direction.

Can fly

pilot planes
Flown
by
Aggregation
• Since each object has an identity, one object can refer to other
objects. This is known as aggregation. The car object is an aggregation
of other objects such as engine, seat and wheel objects.
• Static and Dynamic Binding:
• Determining which function has to be involved at compile time is
called static binding. Static binding optimized the calls. (Ex) function
call.
• The process of determining at run time which functions to involve is
termed dynamic binding.
• Dynamic binding occurs when polymorphic call is issued. It allows
some method invocation decision to be deferred until the information
is known.
• Object Persistence:
• Objects have a lifetime. They are explicitly created and can exist for a
period of time that has been the duration of the process in which they
were created.
• A file or database can provide support for objects having a longer
lifeline, longer than the duration of the process for which they are
created. This characteristic is called object persistence.
•
Define a Domain Model

• There is an identification of the concepts, attributes, and associations

that are considered important. The result can be expressed in a
domain model that shows the important. domain concepts or objects.
• Partial domain model of the dice game

• This model illustrates the important concepts Player, Die, and Dice
Game, with their associations and attributes.
• It is a visualization of the concepts or mental models of a real- world
domain. Thus, it has also been called a conceptual object model.
Assign Object Responsibilities and Draw Interaction Diagrams

• Object-oriented design is concerned with defining software objects

their responsibilities and collaborations. It shows the flow of
messages between software objects, and thus the invocation of
methods.
:dice game D1:die D2:die
Play()
Roll()
Fv1:getfacevalue()

Roll()

Fv2:getfacevalue()
• Define Design Class Diagrams: a static view of the class definitions is
usefully shown with a design class diagram. This illustrates the
attributes and methods of the classes.
• example: in the dice game, an inspection of the sequence diagram
leads to the partial design class diagram .Since a play message is sent
to a DiceGame object, the DiceGame class requires a play method,
while class Die requires a roll and get FaceValue method.
UML DIAGRAMS
• There are two main categories; structure diagrams and behavioral
diagrams.
• Structure diagrams show the things in the modelled system. In a
more technical term, they show different objects in a system
• Behavioural diagrams show what should happen in a system. They
describe how the objects interact with each other to create a
functioning system.
Class Diagram

• Class diagrams are the main building block of any object-oriented

solution. It shows the classes in a system, attributes, and operations
of each class and the relationship between each class.
• modeling tools, a class has three parts.
• Name at the top, attributes in the middle and operations or methods
at the bottom
• Different relationships between classes are shown by different types
of arrows.
• Component Diagram
• A component diagram displays the structural relationship of
components of a software system. These are mostly used when
working with complex systems with many components. Components
communicate with each other using interfaces. The interfaces are
linked using connectors.
• Deployment Diagram
• A deployment diagram shows the hardware of your system and the
software in that hardware.
• Deployment diagrams are useful when your software solution is
deployed across multiple machines with each having a unique
configuration.
• Object Diagram
• Object Diagrams, sometimes referred to as Instance diagrams are very
similar to class diagrams. Like class diagrams, they also show the
relationship between objects but they use real-world examples.
• They show what a system will look like at a given time. Because there
is data available in the objects, they are used to explain complex
relationships between objects.
• Package Diagram
• As the name suggests, a package diagram shows the dependencies
between different packages in a system.
Use Case Diagram

• Use case diagrams give a graphic overview of the actors involved in a

system, different functions needed by those actors and how these
different functions interact.
• starting point for any project you can easily identify the main actors
involved and the main processes of the system.
Activity Diagram

• Activity diagrams represent workflows in a graphical way. They can be

used to describe the business workflow or the operational workflow
of any component in a system.
State Machine Diagram

• State machine diagrams are similar to activity diagrams, although

notations and usage change a bit.
• They are sometimes known as state diagrams or state chart diagrams
as well.These are very useful to describe the behaviour of objects
that act differently according to the state they are in at the moment
Sequence Diagram

• Sequence diagrams in UML show how objects interact with each

other and the order those interactions occur.
• It’s important to note that they show the interactions for a particular
scenario.
• The processes are represented vertically and interactions are shown
as arrows
Communication Diagram

• in UML 1 they were called collaboration diagrams. Communication

diagrams are similar to sequence diagrams, but the focus is on
messages passed between objects.
• The same information can be represented using a sequence diagram
and different objects
• interaction Overview Diagram
• Interaction overview diagrams are very similar to activity diagrams.
While activity diagrams show a sequence of processes, Interaction
overview diagrams show a sequence of interaction diagrams.
• They are a collection of interaction diagrams and the order they
happen. As mentioned before, there are seven types of interaction
diagrams, so any one of them can be a node in an
interaction overview diagram.
• Three Perspectives to Apply UML
• The same UML class diagram notation can be used to draw pictures of
concepts in the real world or software classes in Java.
• Conceptual perspective - the diagrams are interpreted as describing
things in a situation of the real world or domain of interest.
• Specification (software) perspective - the diagrams (using the same
notation as in the conceptual perspective) describe software
abstractions or components with specifications and interfaces, but no
commitment to a particular implementation (for example, not
specifically a class in C# or Java).
• Implementation (software) perspective - the diagrams describe
software implementations in a particular technology (such as Java).
The Meaning of "Class" in Different Perspectives

• Conceptual class real-world concept or thing. A conceptual or

essential perspective. The UP Domain Model contains conceptual
classes.
• Software class a class representing a specification or implementation
perspective of a software component, regardless of the process or
method.
• Implementation class a class implemented in a specific OO language
such as Java.
UNIFIED PROCESS (UP)

• What is the UP?

A software development process describes an approach to building,
deploying, and possibly maintaining software
• the Rational Unified Process or RUP a detailed refinement of the
Unified Process, has been widely adopted.
• UP for three reasons
1. The UP is an iterative process.
2. UP practices provide an example structure for how to do and thus
how to explain OOA/D.
3. The UP is flexible, and can be applied in a lightweight and agile
approach that includes practices from other agile methods
Iterative and Evolutionary Development

• In this lifecycle approach, development is organized into a series of

short, fixed- length (for example, three-week) mini-projects called
iterations.
• the outcome of each is a tested, integrated, and executable partial
system. Each iteration includes its own requirements analysis, design,
implementation, and testing activities.
• The system grows incrementally over time, iteration by iteration, and
thus this approach is also known as iterative and incremental
development . Because feedback and adaptation evolve the
specifications and design, it is also known as iterative and
evolutionary development.
To Handle Change on an Iterative Project
• Each iteration involves choosing a small subset of the requirements,
and quickly designing, implementing, and testing
• In addition to requirements clarification, activities such as load testing
will prove if the partial design and implementation are on the right
path, or if in the next iteration, a change in the core architecture is
required.
 Benefits of Iterative Development

 less project failure, better productivity, and lower defect rates; shown
by research into iterative and evolutionary methods
 early rather than late mitigation of high risks (technical, requirements,
objectives, usability, and so forth)
 early visible progress
 early feedback, user engagement, and adaptation, leading to a refined
system that more closely meets the real needs of the stakeholders
 managed complexity; the team is not overwhelmed by "analysis
paralysis" or very long and complex steps
 the learning within an iteration can be methodically used to improve the
development process itself, iteration by iteration
 Key Ideas and Best Practices will manifest in elaboration:
Table -Sample elaboration artifacts, excluding those started in inception.
Artifact Comment
Domain Model This is a visualization of the domain concepts; it is similar to a static information model
of the domain entities.

This is the set of diagrams that describes the logical design. This includes software class
Design Model diagrams, object interaction diagrams, package diagrams, and so forth.

Software A learning aid that summarizes the key architectural issues and their resolution in the
Architecture design. It is a summary of the outstanding design ideas and their motivation in the
Document system.

Data Model This includes the database schemas, and the mapping strategies between object and
non-object representations.

Use-Case A description of the user interface, paths of navigation, usability models, and so forth.
Storyboards, UI
Prototypes
What is a Domain Model?
• A domain model is a visual representation of conceptual classes or
real- situation objects in a domain . Domain models have also been
called conceptual models domain object models, and analysis object
models.
• Definition: In the UP, the term "Domain Model" means a
representation of real-situation conceptual classes, not of software
objects. The term does not mean a set of diagrams describing
software classes, the domain layer of a software architecture, or
software objects with responsibilities.
• A domain model is illustrated with a set of class diagrams in which no
operations (method signatures) are defined. It provides a conceptual
perspective. It may show:
1. domain objects or conceptual classes
2. associations between conceptual classes
3. attributes of conceptual classes
Why Call a Domain Model a "Visual Dictionary"?
• Domain Model visualizes and relates words or concepts in the domain.
It also shows an abstraction of the conceptual classes, because there
are many other things one could communicate about registers, sales,
and so forth.
• The domain model is a visual dictionary of the noteworthy abstractions,
domain vocabulary, and information content of the domain
• A UP Domain Model is a visualization of things in a real-situation domain of
interest, not of software objects such as Java or C# classes, or software objects
with responsibilities.
Therefore, the following elements are not suitable in a domain model:
• Software artifacts, such as a window or a database, unless the domain being
modeled are of software concepts, such as a model of graphical user interfaces.
• Responsibilities or methods
• Two Traditional Meaning of Domain Model

Meaning 1 :"Domain Model" is a conceptual perspective of objects in a real

situation of the world, not a software perspective.

Meaning 2 :"the domain layer of software objects." That is, the layer of software
objects below the presentation or UI layer that is composed of domain objects
software objects that represent things in the problem domain space with related
"business logic" or "domain logic" methods.
DOMAIN MODEL
• The figure shows a partial domain model drawn with UML class
diagram notation. It illustrates that the conceptual classes of Payment
and Sale are significant in this domain, that a Payment is related to a
Sale in a way that is meaningful to note, and that a Sale has a date
and time, information attributes we care about.
CONCEPTUAL CLASSES

• A conceptual class is an idea, thing, or object. It may be considered in

terms of its symbol, intension, and extension (see Figure).
• Symbol words or images representing a conceptual class.
• Intension the definition of a conceptual class.
• Extension the set of examples to which the conceptual class applies.
• For example, consider the conceptual class for the event of a
purchase transaction. I may choose to name it by the (English) symbol
Sale. The intension of a Sale may state that it "represents the event of
a purchase transaction, and has a date and time." The extension of
Sale is all the examples of sales; in other words, the set of all sale
instances in the universe