The document discusses object-oriented approaches to software development. It covers the history of object-oriented programming from the 1950s to modern languages like C++ and Java. It then outlines key concepts of the object-oriented model like abstraction, encapsulation, and modularity. The document also discusses object-oriented programming, the software development life cycle, object-oriented analysis using tools like UML, and object-oriented design.

1. Object-OrientedObject-Oriented
Approach/DevelopmentApproach/Development
of Softwareof Software
Presented by: Raja PrasadPresented by: Raja Prasad
Mca (IV sem) AGIMca (IV sem) AGI

2. OutlinesOutlines
 Historical ProspectiveHistorical Prospective
 MotivationsMotivations
 Object-Oriented ModelObject-Oriented Model
 Object-Oriented programmingObject-Oriented programming
 Life CycleLife Cycle
 Object-Oriented AnalysisObject-Oriented Analysis
 UmlUml
 Object-Oriented DesignObject-Oriented Design

3. Historical PerspectiveHistorical Perspective
 Was initially thought of as a “research curiosity”Was initially thought of as a “research curiosity”
 Object-oriented programming is today whatObject-oriented programming is today what
structured programming was in the 1970’sstructured programming was in the 1970’s
 The Object and object attribute idea firstThe Object and object attribute idea first
conceived in the 1950’s for A.I.conceived in the 1950’s for A.I.
 The real movement began in 1966 with theThe real movement began in 1966 with the
introduction of theintroduction of the SimulaSimula languagelanguage

4. Historical PerspectiveHistorical Perspective
 Palo Alto Research Center (PARC) developedPalo Alto Research Center (PARC) developed
SmalltalkSmalltalk in the early 1970’sin the early 1970’s
 SmalltalkSmalltalk is considered the first truly object-orientedis considered the first truly object-oriented
languagelanguage
 Led other languages to support object-orientedLed other languages to support object-oriented
programmingprogramming
 examples:examples: Objective-C, C++, Self, Eiffel,Objective-C, C++, Self, Eiffel, andand FlavorsFlavors
 1980 Booch pioneered the concept of object-1980 Booch pioneered the concept of object-
oriented design (OOD)oriented design (OOD)

5. MotivationMotivation
 Benefits are Greater:Benefits are Greater:
 ProductivityProductivity
 ReliabilityReliability
 MaintainabilityMaintainability
 ManageabilityManageability

6. MotivationMotivation
 Direct mapping of concepts in the problemDirect mapping of concepts in the problem
domain to software units and their interfacesdomain to software units and their interfaces
 Viewing the world as objects is more naturalViewing the world as objects is more natural
since it is closer to the way humans thinksince it is closer to the way humans think
 Objects are more stable than functions…Objects are more stable than functions…
 Supports information hiding, data abstraction,Supports information hiding, data abstraction,
and encapsulationand encapsulation
 Easily modified, extended, and maintained…Easily modified, extended, and maintained…
 if your product was designed correctlyif your product was designed correctly

7. Object-Oriented ModelObject-Oriented Model
 A “new” way of thinking about what it means toA “new” way of thinking about what it means to
compute and how information can be structuredcompute and how information can be structured
 Systems are viewed as cooperating objects thatSystems are viewed as cooperating objects that
encapsulate structure and behavior in aencapsulate structure and behavior in a
hierarchical constructionhierarchical construction
 Functionality achieved by messages passingFunctionality achieved by messages passing
between objectsbetween objects

8. Object-Oriented ModelObject-Oriented Model
 Object-oriented model can be viewed as the frameworkObject-oriented model can be viewed as the framework
containing:containing:
 AbstractionAbstraction
 EncapsulationEncapsulation
 ModularityModularity
 HierarchyHierarchy
 ConcurrenceConcurrence
 ReusabilityReusability
 ExtensibilityExtensibility

9. Object-Oriented ModelObject-Oriented Model
 The integration ofThe integration of
procedural and data-procedural and data-
driven approachesdriven approaches

10. Object Oriented ProgrammingObject Oriented Programming
 Concepts:Concepts:
 Programs are organized into cooperating collectionsPrograms are organized into cooperating collections
of objectsof objects
 Object: entity that encapsulates state and behavior.Object: entity that encapsulates state and behavior.
An instance of a classAn instance of a class
 Interface or protocol: set of messages to which it willInterface or protocol: set of messages to which it will
respondrespond
 Response can be a message or routine, or delegationResponse can be a message or routine, or delegation
of the message to another objectof the message to another object

11. Object Oriented ProgrammingObject Oriented Programming

12. Life CycleLife Cycle
 If it is accepted that object-oriented is more thanIf it is accepted that object-oriented is more than
object-oriented coding, then a whole newobject-oriented coding, then a whole new
approach, including life cycle, must be adoptedapproach, including life cycle, must be adopted
(Booch, 1994)(Booch, 1994)

13. Life CycleLife Cycle
 Waterfall consists of aWaterfall consists of a
sequential process,sequential process,
primarily in oneprimarily in one
directiondirection
 Does notDoes not
accommodate realaccommodate real
iterationiteration
 Criticized for placingCriticized for placing
no emphasis on reuseno emphasis on reuse
and having noand having no
unifying model tounifying model to
integrate the phasesintegrate the phases

14. Life CycleLife Cycle
 Water fountain lifeWater fountain life
cycle describes thecycle describes the
inherent iterative andinherent iterative and
incremental qualitiesincremental qualities
of object-orientedof object-oriented
developmentdevelopment
 Prototyping andPrototyping and
feedback loops arefeedback loops are
standardstandard

15. Object-Oriented AnalysisObject-Oriented Analysis
 Examines requirements from the perspective ofExamines requirements from the perspective of
the classes and objects found in the vocabularythe classes and objects found in the vocabulary
of the problem domainof the problem domain
 Yields black-box objects that are derived fromYields black-box objects that are derived from
the problem domainthe problem domain
 Scenarios can be used to determine necessaryScenarios can be used to determine necessary
object behaviorobject behavior

16. Analysis exampleAnalysis example
 Problem: Drawing shapesProblem: Drawing shapes
 Scenarios:Scenarios:
 Draw a pointDraw a point
 Draw a lineDraw a line
 Draw a circleDraw a circle
 Draw a squareDraw a square
 Draw a rectangleDraw a rectangle
 Draw a polygonDraw a polygon

17. UMLUML
 UML is a standard language for specifying,UML is a standard language for specifying,
visualizing, constructing, and documenting thevisualizing, constructing, and documenting the
artifacts of software systems.artifacts of software systems.
 UML was created by Object ManagementUML was created by Object Management
Group (OMG) and UML 1.0 specification draftGroup (OMG) and UML 1.0 specification draft
was proposed to the OMG in January 1997.was proposed to the OMG in January 1997.
 UML stands forUML stands for UUnifiednified MModelingodeling LLanguage.anguage.
 UML is a pictorial language used to makeUML is a pictorial language used to make
software blue prints.software blue prints.

18. UML Building-BlocksUML Building-Blocks
There three building blocks of UML
Building-Blocks
Relationships Diagrams
Structural
Behavioral
Grouping
Annotational

19. ThingsThings
Structural things: Structural things define the static part of the model.
They represent physical and conceptual elements

20. Continue thingsContinue things

21. Behavioral thingsBehavioral things
A behavioral thing consists of the dynamic parts of UML models.

22. Grouping thingsGrouping things
Grouping things can be defined as a mechanism to group elements
of a UML model together.

23. Annotational thingsAnnotational things
Annotational things can be defined as a mechanism to capture
remarks, descriptions, and comments of UML model elements.
Note is the only one Annotational thing available.

24. RelationshipRelationship
Relationship is another most important building block of UML. It
shows how elements are associated with each other and this association
describes the functionality of an application.

25. RelationshipRelationship

26. Structural NotationStructural Notationclass
Object

27. Structural NotationStructural Notation

28. Class diagramClass diagram
Defn:-The class diagram is a static diagram. It represents the
static view of an application.
Purpose:-The purpose of the class diagram is to model the static
view of an application.

29. Object diagramObject diagram
Defn:-Object diagrams are derived from class diagrams so object
diagrams are dependent upon class diagrams.
Object diagrams represent an instance of a class diagram.
Purpose:-The purpose of a diagram should be understood clearly
to implement it practically.

30. Component diagramComponent diagram
Defn:-Component diagrams are used to model physical aspects
of a system.
Purpose:-It does not describe the functionality of the system but
it describes the components used to make those functionalities.

31. Deployment diagramDeployment diagram
Defn:-deployment diagrams are used to describe the static
deployment view of a system. Deployment diagrams consist of
nodes and their relationships.
Purpose:-Deployment diagrams are used for describing the
hardware components where software components are deployed.

32. Use caseUse case
Defn:-deployment diagrams are used to describe the static
deployment view of a system. Deployment diagrams consist of
nodes and their relationships.
Purpose:-Deployment diagrams are used for describing the
hardware components where software components are deployed.

33. Sequence diagramSequence diagram

34. Collaboration diagramCollaboration diagram

35. Structure chart diagramStructure chart diagram

36. Activity diagramActivity diagram

37. Object-Oriented DesignObject-Oriented Design
 Object focus shifts to the solution domainObject focus shifts to the solution domain
 Objects, their semantics, and relationships areObjects, their semantics, and relationships are
identifiedidentified
 Implementation and iteration occurImplementation and iteration occur
 Jacobsen says “when details of theJacobsen says “when details of the
implementation begin to show, it’s OOD”implementation begin to show, it’s OOD”
 In my practice: OOA is preliminary design, andIn my practice: OOA is preliminary design, and
OOD is detailed designOOD is detailed design

38. Management IssuesManagement Issues
 Object-oriented development requires aObject-oriented development requires a
commitment to change processes, resources, andcommitment to change processes, resources, and
organizational structure.organizational structure.
 LOC measurements are less valuable, # ofLOC measurements are less valuable, # of
classes reused, inheritance depth, number ofclasses reused, inheritance depth, number of
class-to-class relationships, object coupling, totalclass-to-class relationships, object coupling, total
# of classes, and class sizes are more valuable# of classes, and class sizes are more valuable
and meaningfuland meaningful

39. Management IssuesManagement Issues
 Booch suggests smaller development teams, andBooch suggests smaller development teams, and
cultivation of reuse expertscultivation of reuse experts
 Reward reuse, not LOC: build libraries andReward reuse, not LOC: build libraries and
application frameworksapplication frameworks
 QA: review and testing activities still essential,QA: review and testing activities still essential,
but timing and definition are differentbut timing and definition are different
 Tools: everything described exists in visualTools: everything described exists in visual
studiostudio

40. The FutureThe Future
 The future is now… object-orientedThe future is now… object-oriented
development is pretty standarddevelopment is pretty standard
 Class libraries and application frameworks (exist)Class libraries and application frameworks (exist)
 Transparent information access across applicationsTransparent information access across applications
and environments (exists)and environments (exists)
 Movement will gain popularity (did)Movement will gain popularity (did)

42. Questions? Comments?Questions? Comments?
 Feel free to speak up!Feel free to speak up!