Unit 1

2. 1. Higher Level of Abstraction
2. Seamless transition among different phases
of software development
3. Encouragement of good programming
techniques
4. Promotion of reusability
5. Easy to adapt and maintain

3.  A system is a collection of elements organized together for a specific purpose and
goal these elements are known as, “system elements”.
 A system elements and their relationships define the “systems structure”.
 The way elements interact and collaborate define the “system behavior”.
 Object oriented development approach encourages software developers to work
and think in terms of the application throughout the software life cycle i.e.
Analysis, Design, Implementation.
 Object oriented development is a conceptual process independent of programming
language until the final stage.
 Object-oriented systems development is a way to develop software by building
self-contained modules or objects that can be easily replaced ,modified & reused.
 System development is the process of defining, designing, testing and
implementing a new system.

4.  Need of OOSD :- To make software development
easier and more natural by raising the level of
abstraction to the point where applications can be
implemented in the same terms that described by
users.
 Phases in Object-Oriented Software Development :-
1. Phase I – Object-Oriented Analysis ( OOA )
2. Phase II – Object-Oriented Design ( OOD )
3. Phase III – Object-Oriented Implementation ( OOI )
or
Object-Oriented Construction ( OOC )
or
Object-Oriented Programming ( OOP )

5.  Grady Booch has defined OOA as, “object-oriented
analysis is a method of analysis that examines
requirements from the perspective of the classes
and objects found in the vocabulary of the
problem domain”.
 In this stage, the problem is formulated, user
requirements are identified, and then a model is
built based upon real-world objects.
 It understands system’s functional requirement.

6.  Primary tasks of OOA :-
1. Finding the objects
2. Organizing the objects
3. Object Interaction
4. Operations on objects
5. Object Implementation
( FOIOI )

7.  Purpose of Analysis :- The main objective of
the analysis is to capture a complete,
unambiguous and consistent picture of the
requirements of the system and what the
system must do the satisfy the user’s
requirements and needs.
OOA is a process by which we can identify
the classes that play a role in achieving the
system goals and requirements.
 Analysis is a difficult activity :-
1. Unclear descriptions of requirements
2. Incomplete requirements
3. Unnecessary future requirements

8.  This begins with the problem statement and ends with a detailed
design that can be transformed into an operational system.
 It includes architecture and system’s constraints which are usually
not considered in analysis phase.
 It asks , “ How do we solve the problem / implement the solution
? ”
 Object-oriented design includes two main stages, system design
and object design.
1. System Design :-In this stage, the complete architecture of the
desired system is designed, composed of a hierarchy of
interacting objects, grouped into classes.
2. Object Design :-In this phase, a design model is developed
based on both the models developed in the system analysis
phase and the architecture designed in the system design phase.
All the classes required are identified.

9.  It is the actual implementation of the design.
 The detailed design is implemented using a object-oriented
programming language or database management system or CASE
tools.
It asks , “ How do we solve the problem / implement the solution ?”
 In this stage, the design model developed in the object design is
translated into code in an appropriate programming language or
software tool. The databases are created and the specific hardware
requirements are ascertained. Once the code is in shape, it is tested
using specialized techniques to identify and remove the errors in the
code.
 It means, we have to transform analysis model into design model
and then in implementation i.e. source code using programming
language. The objects are identified during analysis phase may be
implemented during construction phase.

10.  Advantages of OOSDLC ( Object-Oriented
Software Development Life Cycle ) :-
 More challenging problem domain can be
handled.
 It improved communication among all users,
analyst , designers and programmers.
 Increase consistency among all the models
developed during object-oriented analysis,
design and programming.
 Reusability of analysis, design, programming
results and models.

11.  SDLC is a process used by software industry to
design, develop and test high quality software.
 SDLC aims to produce a high quality software
that meets or exceeds customer expectations,
reaches completion within times and cost
estimates.
 SDLC is a framework defining tasks performed at
each step in the software development process.
 It consists of a detailed plan describing how to
develop, maintain, replace and alter or enhance
specific software.

13.  Stage 1: Planning and Requirement Analysis :- It is performed by senior members of team with inputs from
customer, sales department, market surveys and domain experts in the industry. This information is used to plan
the basic project approach and to conduct product feasibility study in economical, operational, and technical areas.
 Stage 2: Defining Requirements :- To clearly define and document the product requirements and get them
approved from the customer or market analysts. This is done through SRS. Software Requirement Specification
document which consists of all the product requirements to be designed and developed during project life cycle.
 Stage 3: Designing the product architecture :- SRS is the reference for product architects to come out with the
best architecture for product to be developed. Based on requirements specified in SRS, usually more than one
design approach for product architecture is proposed and documented in a DDS - Design Document Specification.
This DDS is reviewed by all important stakeholders and based on various parameters as risk assessment, product
robustness, design modularity , budget and time constraints , the best design approach is selected for the product.
 Stage 4: Building or Developing the Product :- In this stage, the actual development starts and the product is
built. The programming code is generated as per DDS during this stage. The programming language is chosen with
respect to type of software being developed.
 Stage 5: Testing the Product :- This stage refers to the testing only stage of product where products defects are
reported, tracked, fixed and retested, until the product reaches quality standards defined in SRS.
 Stage 6: Deployment in the Market and Maintenance :- Once the product is tested and ready to be deployed it
is released formally in appropriate market. Then based on feedback, the product may be released as it is or with
suggested enhancements in targeting market segment. After the product is released in market, its maintenance is
done for the existing customer base.

14.  Waterfall Model
 Iterative Model
 Spiral Model
 V-Model
 Big Bang Model
 Agile Model
 RAD Model ( Rapid Application Development
) and
 Prototyping Models.

15.  By Winston Royce in 1970.
 Linear-sequential life cycle model.
 In a waterfall model, the outcome of one
phase acts as input for the next phase
sequentially.
 In this, each phase must be completed fully
before the next phase can begin.
 In this model phases do not overlap.
 It is basically used for the project which is
small and there are no uncertain
requirements.

17.  Requirement Specification or Requirement Gathering and analysis:-
All possible requirements of the system to be developed are captured in this phase and
documented in a requirement specification document.
 System Design :-
The requirement specifications from first phase are studied in this phase and system design is
prepared. System Design helps in specifying hardware and system requirements and also helps
in defining overall system architecture.
 Implementation :-
With inputs from system design, the system is first developed in small programs called units,
which are integrated in the next phase. Each unit is developed and tested for its functionality
which is referred to as Unit Testing.
 Integration and Testing :-
All the units developed in the implementation phase are integrated into a system after testing
of each unit. Post integration the entire system is tested for any faults and failures.
 Deployment of system :-
Once the functional and non functional testing is done, the product is deployed in the
customer environment or released into the market.
 Maintenance :-
There are some issues which come up in the client environment. To fix those issues patches
are released. Also to enhance the product some better versions are released. Maintenance is
done to deliver these changes in the customer environment.

18. 1. This model is simple and easy to understand and use.
2. It is easy to manage due to the rigidity of the model – each
phase has specific deliverables and a review process.
3. In this model phases are processed and completed one at a
time. Phases do not overlap.
4. Waterfall model works well for smaller projects where
requirements are very well understood.
5. It allows for departmentalization and control.
6. A schedule can be set with deadlines for each stage of
development and a product can proceed through the
development process model phases one by one.
7. Development moves from concept, through design,
implementation, testing, installation, troubleshooting, and ends
up at operation and maintenance. Each phase of development
proceeds in strict order.
8. Clearly defined stages.
9. Easy to arrange tasks.
10. Process and results are well documented.

19. 1. Once an application is in the testing stage, it is very difficult
to go back and change something that was not well-thought
out in the concept stage.
2. No working software is produced until late during the life cycle.
3. High amounts of risk and uncertainty.
4. Not a good model for complex and object-oriented projects.
5. Poor model for long and ongoing projects.
6. Not suitable for the projects where requirements are at a
moderate to high risk of changing.
7. It does not allow for much reflection or revision.
8. Once the product is developed and if any failure occurs then the
cost of fixing such issues are very high, because we need to
update everywhere from document till the logic.
9. It is difficult to measure progress within stages.
10. Cannot accommodate changing requirements.
11. Adjusting scope during the life cycle can end a project.

20. Some situations where the use of Waterfall
model is most appropriate are :-
1. Requirements are very well documented,
clear and fixed.
2. Product definition is stable.
3. Technology is understood and is not
dynamic.
4. There are no ambiguous requirements.
5. Ample resources with required expertise are
available to support the product.
6. The project is short.

21.  Proposed by Boehm.
 Spiral model is a combination of iterative development process
model and sequential linear development model i.e. waterfall
model.
 It allows for incremental releases of the product, or incremental
refinement through each iteration around the spiral.
 The spiral model describes how a product developers to form
new version and how a version can be incrementally developed
form prototype to completed product.
 In spiral mode, more time is spent on analysis to understand the
system completely.
 Complete project is divided into different activities over time. At
the beginning of project, a small group of people performs
analysis and subsequently design. These activities are worked on
iterative manner.
 The spiral model has four phases. A software project repeatedly
passes through these phases in iterations called Spirals.

23.  Analysis or Identification :-
This phase starts with gathering the requirements in the baseline spiral.
This also includes understanding the system requirements, subsystem requirements, unit
requirements by continuous communication between the customer and the system analyst. At the
end of the spiral the product is deployed in the identified market.
 Design :-
Design phase starts with the conceptual design in the baseline spiral and involves architectural
design, logical design of modules, physical product design and final design in the subsequent spirals.
 Implementation or Construct or Build :-
Implementation or Construct phase refers to production of the actual software product at every
spiral. In the baseline spiral when the product is just thought of and the design is being developed a
POC (Proof of Concept) is developed in this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a working
model of the software called build is produced with a version number. These builds are sent to
customer for feedback.
 Testing or Evaluation and Risk Analysis :-
Testing or Risk Analysis includes identifying errors and faults of the system. It identifying,
estimating, and monitoring technical feasibility and management risks, such as schedule slippage
and cost overrun. After testing the build, at the end of first iteration, the customer evaluates the
software and provides feedback.
 Based on the customer evaluation, software development process enters into the next iteration and
subsequently follows the linear approach to implement the feedback suggested by the customer. The
process of iterations along the spiral continues throughout the life of the software.

24. 1. Changing requirements can be accommodated.
2. Allows for extensive use of prototypes.
3. Requirements can be captured more accurately.
4. Users see the system early.
5. Development can be divided into smaller parts and more
risky parts can be developed earlier which helps better
risk management.
6. It allows for elements of the product to be added in when
they become available or known. This assures that there
is no conflict with previous requirements and design.
7. This method is consistent with approaches that have
multiple software builds and releases and allows for
making an orderly transition to a maintenance activity.
8. The spiral model forces early user involvement in the
system development effort.

25. 1. Management is more complex.
2. End of project may not be known early.
3. Not suitable for small or low risk projects and could
be expensive for small projects.
4. Process is complex .
5. Spiral may go indefinitely.
6. Large number of intermediate stages requires
excessive documentation.
7. It takes very strict management to complete such
products and there is a risk of running the spiral in
indefinite loop. So the discipline of change and the
extent of taking change requests is very important
to develop and deploy the product successfully.

26. 1. When costs there is a budget constraint and risk evaluation
is important.
2. For medium to high-risk projects.
3. Long-term project commitment because of potential
changes to economic priorities as the requirements change
with time.
4. Customer is not sure of their requirements which is usually
the case.
5. Requirements are complex and need evaluation to get
clarity.
6. New product line which should be released in phases to
get enough customer feedback.
7. Significant changes are expected in the product during the
development cycle.

27.  Object diagrams are derived from class
diagrams so object diagrams are
dependent upon class diagrams.
 UML object diagrams use a notation
similar to class diagrams in order to
emphasize the relationship between
instances of classes.
 Object diagrams are useful in easy
understanding of class diagrams.

28.  A class element can have any number of attributes and
operations.
 Object names are underline and may show the name of the class
from which the object is instantiated.
 The colon (:) symbol is used as a separator between object name
and class name.

29. Example:-

30.  Purpose of the object diagram :-
1. Useful in forward and reverse engineering.
2. Defines the object relationships of a system.
3. Gives the static view of an interaction.
4. Easy understanding of object behavior and
their relationship from practical perspective.

31.  A model is an abstract representation of a
system, constructed to understand the system
prior to building and modifying it.
 The object model visualizes the elements in a
software application in terms of objects.
 The object model describes the structure of
object in a system : their identity, relationships to
other objects , attributes, and operations.
 The object model is represented graphically with
an object diagram.
 The object diagram contains classes
interconnected by association lines.
 Each class represents a set of individual objects.

32. Visibility or Modifires
 In object-oriented design, there is a notation of visibility for
attributes and operations.
 UML identifies four types of visibility: public(+),
protected(#), private(-), and package(~).
 The +, -, # and ~ symbols before an attribute and operation name
in a class denote the visibility of the attribute and operation.
+ denotes public attributes or operations
- denotes private attributes or operations
# denotes protected attributes or operations
~ denotes package attributes or operations

33. Class Visibility Example
In the example above:
•attribute1 and op1 of MyClassName are public
•attribute3 and op3 are protected.
•attribute2 and op2 are private.

34. A public member is accessible from anywhere outside the class but
within a program.
A private member variable or function cannot be accessed, or even
viewed from outside the class. Only the class and friend functions
can access private members.
A protected member variable or function is very similar to a private
member but it provided one additional benefit that they can be
accessed in child classes which are called derived classes.
Note:

35. Access for each of these visibility types is shown
below for members of different classes.

36. Ex:-Define the Object “Book” with
possible Attribute & Operations with
visibility?
Ans:-
Book
-bookname:string
-id:int
-no_of_pages:int
-price:float
-author:string
+add()
+delete()
+update()
+view()
Ex:-
1.Passenger
2.Employee
3.Customer pays the Medical Bill
4.Bank Account.
5.Credit Card

37.  Objects can be:
 External entities like other systems, devices, people etc. that
produce or consume information to be used by a computer-
based systems.
 Things like reports displays , letters, signals, etc. that are part
of the information domain for the problem.
 Occurrences or events like a properly transfer or the
completion of a series robot movements that occur within the
context of system operation.
 Roles like manager, engineer , sales person etc. played by
people who interact with the system.
 Organizational units like division , group, team etc. that are
relevant to an application.
 Places like manufacturing floor or loading dock that establish
the context of the problem and the overall function of the
system.
 Structures like sensors, four-wheeled vehicles or computers
etc. that define a class of objects or in the extreme, related
classes or objects.

38.  To find the essential objects. Which are to remain
essential throughout the system’s life cycle.
 Define the classes that model real-world entities.
 Example :- For a banking applications typical
objects would be Customer, Account, Bank and
Clerk.
 Generally, classes will be the nouns that figure in
your problem domain like Bank, Money, Budget,
Credit card etc.
 Classification theory is used to identify classes
and objects.

39.  Classification is the process of checking to
see if an object belongs to a category or a
class.
 Classes are important mechanism for
classifying objects.
 The main role of a class is to define the
attributes, methods and applicability of its
instances ( objects).
 Classes are important because they create
conceptual building blocks for designing
systems.

40. Strategies or Approaches for identifying
objects ( classes ) :-
 Noun Phrase Approach
 Common Class Patterns
 Use Case Driven
 CRC Cards (Class- Responsibility Collaborator
)

41.  This approach was proposed by Rebecca Wirfs-Brock, Brian Wilkerson and Lauran Wiener.
 In this, nouns are considered as candidate classes and verbs are considered as its methods.
 Nouns are converted into singular ( if plural ). Nouns ( candidate classes ) are divided into 3 categories :-
1. Relevant classes
2. Irrelevant ( can be skipped ) classes
3. Fuzzy classes
 Irrelevant classes do not have any purpose or are unnecessary, so it is safe to skip it.
 Candidate classes are then selected only from other 2 categories either by adding or removing some classes as
necessary.
 Guidelines for selecting candidate classes form Relevant and Fuzzy Categories :-
Finding classes is an incremental and iterative approach.
 Redundant Classes :-
Two classes can not have same information. If more than one word is used to define the same data, select the
one that is more meaningful in context of the system.
 Adjective Classes :-
An adjective suggests a different kind of object, different use of same object or it could be utterly irrelevant. If
the use of adjective signals that the behaviors of the object is different then make new class. In this, create new
classes if the classes behave differently with their adjective. Eg. :- Adult members behave differently than
Teenage members , so the two should be classified as different classes.
 Attribute Classes :-
Tentative objects that are used only as values should be defined or restated as attributes and not as class. In
this, eliminate the nouns that are attributes, not classes. Eg. :- Client status and demographic of client are not
classes but attributes of the client class.
 Irrelevant Classes :-
Each class must have a purpose and every class should be clearly defined and necessary. We must formulate a
statement of purpose. Simply eliminate the candidate class.
The purpose of identifying relevant classes and eliminating irrelevant classes is an incremental approach.

42.  The common class patterns approach is based on
knowledge base of the common classes that has been
proposed by researchers.
Pattern Name Description Example
Concept Class Principles or ideas. Are non-tangible. Performance
Events Class Things that happen at a given date and time, or
as steps in an ordered sequence. These are
associated with attributes such as :- who, what
, when, where , how or why.
Landing , Request, Interrupt, Order
Organization
Class
Formally organized collections of people,
resources or facilities having a defined
mission.
Departments.
People Class Different roles that users play in interacting
with the application. Two categories of people
class :- 1) People who use the system 2)
People who do not use the system but about
whom information is kept by the system.
Teachers, Students, Employees.
Places Class Areas set aside for people or things, physical
locations that the system must keep
information about.
Travel Office, Buildings.
Tangible
things and
devices class
Physical objects that are tangible and devices
with which the application interacts.
Cars, Sensors

43. Pattern Name Classes
Concept Class Not Applicable
Events Class Account, Checking Account, Savings Account,
Transaction
Organization Class Bank
People Class Bank Client
Places Class Not Applicable
Tangible things and devices class ATM Machine

44.  Use cases are used to model the scenarios in the system and
specify what external actors interact with the scenarios.
 The scenarios are described through sequence of steps. The
designer then examines the steps of each scenario to determine
what objects are needed for the scenario to occur.
 Each scenario shows different sequence of interaction between
actors and the system.
 Walks through each scenario to identify the objects , the
responsibilities of each object, and how these objects collaborate
with other objects.
 This approach helps us to understand the behavior of the
system’s objects.
 A use case is a list of steps, typically defining interactions
between a role (known in Unified Modeling Language (UML) as an
"actor") and a system, to achieve a goal. The actor can be a
human, an external system, or time.

45.  Both the use-case and sequence diagrams are
used to model scenarios in the systems.
 Only difference is that, use cases offer a
high-level view of a system whereas the
sequence diagram enables to model a specific
analysis and also assists in modeling the
interactions between objects in the system.

46.  Eg. :- Consider the case study of SBI Bank.
Assume a use case scenario , say “Invalid PIN”
 Use-case name :- Invalid PIN
 Step 1: Insert ATM Card
 Step 2 : Request PIN
 Step 3 : Insert PIN
 Step 4 : Verify PIN
 Step 5 : If invalid PIN, display bad message
 Step 6 : Eject ATM Card
 Based on these activities , we find
that the objects that interact are :-
BankClient, ATM Machine and BankOperator.

49.  Introduced in 1989 by Kent Beck and Ward Cunningham, Wilkinson in
1995, Ambler in 1995.
 CRC is an effective way to analyze scenarios and identifies classes based
on the analysis of how objects collaborate to perform business functions
( use cases ).
 It is a collection of standard index cards that have been divided into
three sections- class name, responsibilities and collaborations.
 On top of the card, the class name
 On the left, the responsibilities of the class
 On the right, collaborators (other classes) with which this class interacts
to fulfill its responsibilities.
 A class represents a collection of similar objects, it appears in upper left
corner. A responsibility is something that a class knows or does, and a
collaborator is another class that a class interacts with to fulfill its
responsibilities. Collaboration takes one of two forms: A request for
information or a request to do something.

50.  Student CRC Card. Here, class name is Student which is singular
noun or singular noun phrase. Students have number, name ,
address, phone number. These are the things student knows.
Students also enroll in seminars, drop seminars and request
transcripts. These are the things a student does. The things a
class knows and does constitute responsibilities. Also, a class
can change values of the things it knows, but it is unable to
change the values of what other classes know.

51.  Something that an object known is called as,
“attribute”, which essentially represents data.
 A class defines attributes and an object has
values for those attributes.
 An attribute is a named property of a class, which
describes a range of values.
 A class may have any number of attributes or no
attributes at all.
 An attribute which has some property is shared
by all objects of that class.
 Eg. :- Customer class has a name, address,
phone number and date of birth

52.  Guidelines for defining attributes :-
 Keep the class simple, state only enough attributes to
define object state.
 Attributes are less likely to be fully described in the
problem statement. We must draw on our knowledge
of the application domain and the real world to find
them.
 Omit derived attributes.
 Do not carry discovery of attributes to excess. We can
add more attributes in subsequent iterations.
 The three basic types of attributes are :-
 Single value attributes
 Multiplicity or multivalue atttibutes
 Reference to another object or instance connection

53.  We can also specify the visibility scope and multiplicity of each attribute.
 Visibility we can specify with attributes and even with operations, which specifies whether it
can be used by other classifiers.
 We can specify any of these levels of visibility.
1. Public :-
Any outside classifier with visibility to the given classifier can use the feature. It specified by
preceding the ‘+’ symbol. Eg. :- + name
2. Protected :-
Any descendent of the classifier can use to the feature. It specified by preceding the ‘#’
symbol.
3. Private :-
Only the classifier itself can use the feature. Specified by preceding the ‘-‘ symbol.
During the design phase, to define the class attributes, following presentation suggested :-
Visibility name : type-expression = initial value
Where, visibility is one of the following :-
+ Public visibility ( accessibility to all classes )
# Protected visibility ( accessibility to subclasses and operations of the class)
- Private visibility ( accessibility only to operations of the class )

55.  Something an object can do is called an
operation ( specification) and essentially
represents processing. How an object does the
processing for a given operation is known as,
“operation’s method” or “implementation”.
 An operation is implementation of a service that
can be requested from any object of a class.
 Operation is an abstraction of something that an
object can do and shared by all objects of that
class.
 Operations define the behavior of an object and
change the object’s attributes in some way.
 A class may have any number of operations.

56.  An operation can specify by a stating its signature,
covering name, type and default value of all
parameters and return type.
 We can specify visibility and scope of each operation.
 In operations signature, we may provide zero or more
parameters.
 Syntax :- name : type [ : default-value]
 The operation presentation has been suggested :-
 Visibility name : ( parameter-list) : return type
expression

58.  The intent of object oriented analysis is to define all
classes, their relationships and associated behavior
with them that are relevant to the problem to be
solved. To achieve this, following tasks will occur :-
 Basic user requirements must be communicated
between the customer and software engineer.
 Classes must be identified i.e. its attributes and
methods are defined.
 A class hierarchy is defined.
 Object to object relationships should be represented.
 Object behavior must be modeled.
 Above all steps reapplied repeatedly till the model is
not complete.

60. Q. “Objects cannot be constructed from other
objects”. State true or false and justify in
short. [1 M ] [ Oct. 2010 ]
 True, because objects have their own
identity and are separately distinguishable.
Objects can be constructed form a class not
from another object.

61. 1. Give advantages of object oriented analysis. [1 M ] [ Oct. 2010 ]
2. “Objects cannot be constructed from other objects”. State true or false and justify in
short. [1 M ] [ Oct. 2010 ]
3. How to organize the objects? [ 10 M ] [ April 2011 ]
4. Define limited polymorphism. [ 10 M ] [ April 2011 ]
5. Give the steps of object design process. [10 M ] [ April 2011 ]
6. “Object is an instance of class.” State true or false adjusting in short. [ 1M ] [April
2011] [April 2013]
7. Give the drawback of using a function / data method in system development. [1 M ] [
April 2011]
8. Define the object ‘Bank Account’ with possible attributes and operations with
visibility.
9. [ 1M ] [ Oct. 2011 ]
10. Define the object ‘Book’ with possible attributes and operations with visibility. [1M]
[April 2012]
11. What is meant by object-orientation construction ? [1M ] [ April 2012 ]
12. Define the object “Passenger” with possible attributes and operations with visibility.
[1M] [ Oct. 2012 ]
13. Define the object “Employee” with possible attributes and operations with visibility.
[1M] [Oct. 2013]
14. “A class is object type.” State true/ false and justify. [1M] [April 2015]

62.  Which of the following feature should available in an object ?
a. Encapsulation
b. Inheritance
c. Information hiding
d. All these
 Classes lying below a class in the inheritance hierarchy are called -----------
a. Ancestors
b. Descendants
c. Super class
d. Concrete class
 Which of the following is not a inheritance type
a. Multiple
b. Multilevel
c. Natural
d. Hybrid
 The objects may be implemented using previously developed source code, such a
part are called ---------------------
a. Components
b. Model
c. Operations
d. Inheritance

63. Q. State True or False :-
1.The only part of the object we can see is its operations the
inside is hidden to us.
2.Object can not be constructed from other objects.
3.Classes may called as object type.
4.Due to inheritance modifications/ maintenance of system
become difficult.
5.A system developed using a function / data method often
becomes difficult to maintain.