Object-Oriented Systems Analaysis and Design

Chapter 1:
Object-Oriented System Development
Alamirew Gedif
Learning Objectives
 At the completion of this chapter, you are able to understand
– The Object-Oriented philosophy and why we need to study it
– The Unified Approach
– Objects and Classes, and their differences
– Class Attributes and Methods
– The concept of Messages
– Class hierarchy inheritance and multiple inheritance
– Encapsulation and Information hiding
– Polymorphism
– Advantages of OO approach
– Aggregation and composition
CT-4221: Chapter 1 - Overview of Object-Oriented System Development 2

Overview of Object-Oriented Analysis and Design
 Object-Orientation
• The OO paradigm is currently the most popular way of analyzing,
designing, and developing application systems, especially large ones.
• To obtain an understanding of this paradigm, we could begin by
asking: What exactly does the phrase ‘object-oriented’ mean? ‘object-
oriented’ implies that objects play a central role, and we elaborate this
further as a perspective that views the elements of a given situation by
decomposing them into objects and object relationships.
• Object-oriented methodology is about how to:
– analyze the problem domain in terms of objects and their
interactions,
– discover classes from this analysis,
– refine classes into a conceptual model of the product,
– discover and define design objects that must manage the working
of the solution, and so on.

Overview of OO Analysis and Design…cont’d
 Analysis
• The analysis phase answers the questions of who will use the system,
what the system will do, and where and when it will be used. During
analysis, the project team investigates any current system, identifies
opportunities for improvement, and develops a concept for the new
system. This phase has 3 steps:
– An analysis strategy is developed to guide the project team’s efforts. It
usually includes an analysis of the current system (called the as-is
system) and its problems and then ways to design a new system
(called the to-be system).
– The next step is requirements gathering. The analysis of this
information—in conjunction with input from the project sponsor and
many other people—leads to the development of a concept for a new
system. The system concept is then used as a basis to develop a set of
business analysis models, which describe how the business will
operate if the new system is developed.

– The analyses, system concept, and models are combined into a
document called the system proposal, which is presented to the project
sponsor and other key decision makers (e.g., members of the approval
committee) who decide whether the project should continue to move
forward.
 Design
• The design phase decides how the system will operate, in terms of the
hardware, software, and network infrastructure; the user interface, forms,
and reports; and the specific programs, databases, and files that will be
needed.
• Although most of the strategic decisions about the system were made in the
development of the system concept during the analysis phase, the steps in
the design phase determine exactly how the system will operate. The design
phase has 4 steps:
– The design strategy is first developed. It clarifies whether the system will
be developed in house, outsourced, or buy an existing software package.

– The design strategy is first developed. It clarifies whether the system
will be developed in house, outsourced, or buy an existing software
package.
– This leads to the development of the basic architectural design for the
system, which describes the hardware, software, and network
infrastructure to be used. In most cases, the system will add or change
the infrastructure that already exists in the organization. The interface
design specifies how the users will move through the system and the
forms and reports that the system will use and generate.
– The database and file specifications are developed. These define
exactly what data will be stored and where they will be stored.
– The analyst team develops the detailed design, which defines the
programs that need to be written and exactly what each program will
do.
 OOD- emphasizes on defining software objects and how they
collaborate to fulfill the requirements.

 Object-Oriented Analysis
• OOA is an iterative stage of analysis, which takes place during the SDLC,
that aims to model the functional requirements of the software while
remaining completely independent of any potential implementation
requirements.
• It is the procedure of identifying software engineering requirements and
developing software specifications in terms of a software system’s
object model, which comprises of interacting objects.
• The main difference between object-oriented analysis and other forms
of analysis is that in object-oriented approach, requirements are
organized around objects, which integrate both data and functions. They
are modelled after real-world objects that the system interacts with. In
traditional analysis methodologies, the two aspects - functions and data
- are considered separately.
• 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”.
• The primary tasks in object-oriented analysis (OOA) are:
– Identifying objects
– Organizing the objects by creating object model diagram
– Defining the internals of the objects, or object attributes
– Defining the behavior of the objects, i.e., object actions
– Describing how the objects interact
• The common models used in OOA are use cases and object models.
 Object-Oriented Design
• Object–Oriented Design (OOD) involves implementation of the
conceptual model produced during object-oriented analysis. It is
really just an extension of the object-oriented analysis process that
preceded it. In OOD, concepts in the analysis model, which are
technology−independent, are mapped onto implementing classes,
constraints are identified and interfaces are designed, resulting in a
model for the solution domain, i.e., a detailed description of how the
system CT-4221:
is to beChapter
built1 on concrete technologies.
- Overview of Object-Oriented System Development 8
• Grady Booch has defined object-oriented design as “a method of
design encompassing the process of object-oriented decomposition
and a notation for depicting both logical and physical as well as static
and dynamic models of the system under design”.
• The implementation details generally include:
– Restructuring the class data (if necessary),
– Implementation of methods, i.e., internal data structures and
algorithms,
– Implementation of control, and
– Implementation of associations.

 Software development is dynamic and always undergoing major
change. The methods and tools will differ significantly from time to
time. Today, a vast number of tools and methodologies are available
for systems development.
 Systems development refers to all activities that go into producing an
information systems solution as system: analysis, modeling, design,
implementation, testing, and maintenance
 Object-Oriented methods enable us to create sets of objects that
work together synergistically to produce software that better module
their problem domains than similar systems produced by traditional
techniques.
 A software development methodology is a series of processes that
lead to the development of an application. Each process consists of
number of steps and rules that should be performed during
development.
 The software development process will continue to exist as long as
the development system is in operation.
Two Orthogonal Views of Software
(Two Approaches to System Development)
• There are two orthogonal view of software development:
− Traditional Paradigm
− Object-Oriented Paradigm
• The two basic building blocks of an Information System are the
operations performed by that Information System and the data on which
the operations are performed.
• The Traditional Paradigm essentially ignores the data in favour of the
operations. In contrast, the Object-Oriented paradigm pays equal
attention to both operations and data.
• OO views system dev’t as a collection of object, which combines data
and functionality together, and interact and collaborate each other; while
the traditional techniques view software as a collection of programs (or
functions) and isolated data.
• The heart of the distinction between the two lies in their primary focus:
the traditional approach focuses on the function of the system, and OO
focuses on the object, which combines data and functions.

The Need of Object-Orientation
 An object orientation produces systems that are easier to evolve, more
flexible, more robust, and more reusable than a top-down approach. An
object orientation
• Allows higher level of abstraction
− The object-oriented approach supports abstraction at the object
level. Since objects encapsulate both data (attributes) and functions
(methods), they work at a higher level of abstraction.
− The development can proceed at the object level and ignore the rest
of the system as long as necessary. This makes designing, coding,
testing, and maintaining the system much simpler.
• Provides Seamless transition among different phases of software
development
− The object-oriented approach essentially uses the same language to
talk about analysis, design, programming, and database design. This
seamless approach reduces the level of complexity and redundancy,
and Makes for clearer, more robust system development.
The Need of Object-Orientation…cont’d
• Encourage good development techniques
– helps us to exploit the expressive power of object-based and
object-oriented programming languages.
– Significant improvements in productivity and code quality have
consistently been achieved using C++ as ‘a better C’ with a bit of
data abstraction thrown in where it is clearly useful.
– In a properly designed system, the routines and attributes within a
class are held together tightly, the classes will be grouped into
subsystems but remain independently and therefore, changing one
class has no impact on other classes and so, the impact is
minimized.
• Promotes of reusability
– Objects are reusable because they are modeled directly out of a
real-world problem domain. Here classes are designed, with reuse
as a constant background goal. All the previous functionality
remains and can be reused without changed.
Overview of the Unified Approach
• The unified approach (UA) is a methodology for software development that is
proposed by Booch, Rumbaugh, and Jacobson, which tries to combine the best
practices, processes, and guidelines along with the Object Management
Group's unified modeling language.
• The unified modeling language (UML) is a set of notations and conventions
used to describe and model an application. But, the UML does not specify a
methodology or what steps to follow to develop an application; that would be
the task of the UA.
• The heart of the UA is Jacobson's use case that represents a typical interaction
between users and a computer system to capture the users' goals and needs.
• The main advantage of an object-oriented system is that the class tree is
dynamic and can grow. Developers in an object-oriented environment fosters
the growth of the class tree by defining new, more specialized classes to
perform the tasks that the required applications supposed to perform. Creating
additional applications will require no more than assembling classes from the
class library.

Overview of the Unified Approach …cont’d
• UA, also uses the layered architecture, which is an approach to software dev’t
that allows developers to create objects that represent tangible elements of the
business independent of how they are represented to the user through an
interface or physically stored in the database.
• The layered architecture consists of view or user interfaces, business and access
layers. It reduces the interdependence of the user interface, the business control
and the database access. Therefore, it allows for a more robust and flexible
system
 Recapping: Generally, the UA consists of the following concepts:
– Use-case driven development.
– Utilizing the Unified Modeling Language for modeling.
– Object-oriented analysis and Object-oriented design.
– Repositories of reusable classes, and hence, maximum reuse.
– The layered approach
– Incremental development and prototyping.
– Continuous testing.

Overview of The Unified Approach …cont’d
 Object-Oriented Analysis
− OOA is a process that is responsible for extracting the user needs
towards an OO system.
− It is a core process that must be carried out in order to produce
system which can satisfy user needs. In the analysis phase, the
domain problem is identified.
− The outcome of the OOA phase will be a list of models that describe
what the system will do. However, these models will not explain how
the system will function. Besides that, it is being conducted from the
user’s perspective not from the technology perspective.
− Basically, there are five steps to perform in OOA phase:
• Actors of the system are identified, and use case are developed
• Business process models-UML activity diagrams- are created
• UML Interaction diagram are deloped
• Classes of objects are identifies.
 Object-Oriented Design
− The OOD phase introduced in UML has combined Jacobson’s use case
analysis and interaction diagram, Booch’s object diagram and Rumbaugh’s
domain models. Therefore, with the best practices extracted from three of
them, all the processes involved in the system development are traceable.
− In this phase, the design of classes, attributes, methods, association
structure and protocols will be produced.
− The three object layers- view layer, business layer and access layer-need to
be developed.
− As soon as the design of objects is completed, user satisfaction and
usability tests can be carried out in order to verify and validate the system.
− Testing must be done by referring to the use-case diagram, which is
prepared during the analysis phase. Iterative testing can refine the quality
of the design. Thus, the outcome of the system development process will
be able to fulfill users’ needs.

 Iterative Development and Continuous Testing
− The process of an OO system dev’t is described as an iterative
process where the system is tested until the users are satisfied
with it. The purpose of this continuous testing is to identify as
many weaknesses in the system as possible. With this process of
identifying, the end-users will find the system beneficial to their
work and hence improve their quality and quantity of work.
 Repository of reusable classes and maximum reuse.
− The UA has proposed a repository that should be able to store any
objects from previous projects that might be useful in future
system development. All definitions of the data elements belong
to an object have to be accessible and searchable. Hence, a faster
and shorter time of dev’t process can be reached. All the
components object model developed are made available and can
be referred easily.

 Layered Approach to Software Development
• A better approach to systems architecture is one that isolates the
functions of the interface from the functions of the business.
• This approach also isolates the business from the details of the data
access.
• Using the three layered approach, you are able to create objects that
represent tangible elements of your business yet are completely
independent of how they are represented to the user (through an
interface) or how they are physically stored (in a database).
• The three-layered approach consists of
– view or user interface layer,
– business layer, and an
– access layer

 The Business Layer
• The business layer contains all the objects that represent the business (both data
and behavior). This is where the real objects such as Order, Customer, Line item,
Inventory, and Invoice exist.
• The responsibilities of the business layer are very straightforward: Model the
objects of the business and how they interact to accomplish the business
processes.
• When creating the business layer, however, it is important to keep in mind a
couple of things.
• These objects should not be responsible for the following:
– Displaying details. Business objects should have no special knowledge of how
they are being displayed and by whom.
– Data access details. Business objects also should have no special knowledge
of "where they come from." It does not matter to the business model
whether the data are stored and retrieved via SQL or file I/O. The business
objects need to know only to whom to talk about being stored or retrieved.
20
 The User Interface (View) Layer
• The user interface layer consists of objects with which the user
interacts as well as the objects needed to manage or control the
interface.
• The user interface layer also is called the view layer.
• This layer typically is responsible for two major aspects of the
applications:
– Responding to user interaction. The user interface layer objects
must be designed to translate actions by the user, such as
clicking on a button or selecting from a menu, into an
appropriate response
– Displaying business objects. This layer must paint the best
possible picture of the business objects for the user.

 The Access Layer
• The access layer contains objects that know how to communicate
with the place where the data actually reside, whether it be a
relational database, mainframe, Internet, or file.
• Regardless of where the data actually reside, the access layer has
two major responsibilities:
– Translate request. The access layer must be able to translate any
data-related requests from the business layer into the
appropriate protocol for data access
– Translate results. The access layer also must be able to translate
the data retrieved back into the appropriate business objects and
pass those objects back up into the business layer.
CT-4221: Chapter 2 - Object-Oriented System Development Life Cycle 22

 Unified Modeling Language
• Until 1995, object concepts were popular but implemented in many
different ways by different developers. Each developer had his or her
own methodology and notation. Then in 1995, Rational Software
brought three industry leaders together to create a single approach to
object-oriented systems development.
• Grady Booch, Ivar Jacobson, and James Rumbaugh worked with others
to create a standard set of diagramming techniques known as the
Unified Modeling Language (UML).
• The objective of UML was to provide a common vocabulary of object-
oriented terms and diagramming techniques rich enough to model any
systems development project from analysis through implementation.
• In November 1997, the Object Management Group (OMG) formally
accepted UML as the standard for all object developers. During the
following years, the UML has gone through multiple minor revisions.

 Unified Modeling Language
• UML defines a set of fourteen diagramming techniques used to model
a system. The diagrams are broken into two major groupings: one for
modeling the structure of a system and one for modeling behavior.
• Structure diagrams provide a way to represent the data and static
relationships in an information system. The structure diagrams include
class, object, package, deployment, component, and composite
structure diagrams.
• Behavior diagrams provide the analyst with a way to depict the
dynamic relationships among the instances or objects that represent
the business information system.
• The behavior modeling diagrams include activity, sequence,
communication, interaction overview, behavior state machine, and
use-case diagrams.

Basic Elements of Object Orientation
 Objects and Classes
• The concepts of objects and classes are intrinsically linked with each
other and form the foundation of object–oriented paradigm.
 Object
• An object is a real-world element in an object–oriented environment
that may have a physical or a conceptual existence. Each object has:
– Identity that distinguishes it from other objects in the system.
– State that determines the characteristic properties of an object as
well as the values of the properties that the object holds.
– Behavior that represents externally visible activities performed by an
object in terms of changes in its state.
• Objects can be modeled according to the needs of the application. An
object may have a physical existence, like a customer, a car, etc.; or an
intangible conceptual existence, like a project, a process, etc.

Basic Elements of Object Model…cont’d
 Class
• A class represents a collection of objects having same characteristic
properties that exhibit common behavior. All objects in a class have the
same set of attributes and the same set of operations; they differe only in
the value of their respective attributes
• It gives the blueprint or description of the objects that can be created from
it. Creation of an object as a member of a class is called instantiation. Thus,
object is an instance of a class.
• The constituents of a class are:
– A name of class.
– A set of attributes for the objects that are to be instantiated from the
class. Generally, different objects of a class have some difference in the
values of the attributes. Attributes are often referred as class data.
– A set of operations that portray the behavior of the objects of the class.
Operations are also referred as functions or methods.

 Attributes
• Attributes are the properties of a class; on the whole they are things
that can be measured or observed.
• An attribute of an object is a property that has a name, a value and a
type. The name and type must be identical for all instances of a class,
but the value may be different.
• Two objects are not equal, or identical, just because they have identical
attributes.
 Operations
• Operations are also referred as functions or methods. They are what a
class does (or can have done to it). When you have fully specified the
attributes and operations of a class, then you have specified that class
completely (some experts would say that one must specify the class's
constraints as well, but that is largely beyond the scope of this course).

 Message
• All of a class's operations are accessible to other classes, that is, classes
can communicate by invoking each others operations. This is called
“message passing”.
• Some operations are private to that class, because they are only
concerned with internal operation of the class. Remember that classes
should be self-contained, and should expose as little as possible of
their internal workings.
• An operation has a name, a parameter list, and a return value, much
like a function. The parameter list is (essentially) the data elements
that will be supplied to the operation. The return value is a piece of
data that can be returned to the object that invoked the operation.

Examples of Classes and Objects

Example Messages and Methods

Principles of Object-Oriented Systems
 Abstraction
• Abstraction means focusing on the essential features of an element or
object, and ignoring the unnecessary details or properties for the time
being. The essential features are relative to the context in which the object
is being used. Grady Booch has defined abstraction as follows:
– “An abstraction denotes the essential characteristics of an object that
distinguish it from all other kinds of objects and thus provide crisply
defined conceptual boundaries, relative to the perspective of the
viewer.”
• An abstraction focuses on the outside view of an object and so serves to
separate an object’s essential behavior from its implementation.
• Example : When a class Student is designed, the attributes
registration_number, name, course_code, course_title and credit_hour are
included while characteristics like pulse_rate and size_of_shoe are
eliminated, as they are irrelevant in the educational institution perspective.

Principles of Object-Oriented Systems…cont’d
 Encapsulation and Information Hiding
 Encapsulation
• Encapsulation is the process of binding both attributes and methods
together within a class. Through encapsulation, the internal details of
a class can be hidden from outside. It permits the elements of the
class to be accessed from outside only through the interface
provided by the class.
 Data Hiding
• Typically, a class is designed such that its data (attributes) can be
accessed only by its class methods and insulated from direct outside
access. This process of insulating an object’s data is called data
hiding or information hiding.

 Modularity
• Modularity is the process of decomposing a problem into a set of
modules so as to reduce the overall complexity of the problem.
• Booch has defined modularity as:
– “The property of a system that has been decomposed into a set
of cohesive and loosely coupled modules.”
• Modularity is intrinsically linked with encapsulation.
• Modularity can be visualized as a way of mapping encapsulated
abstractions into real, physical modules having high cohesion within
the modules and their inter–module interaction or coupling is low.

 Class Hierarchy
• An OO system organizes classes into a subclass–superclass or child class–parent
class or derived class-base class hierarchy.
• At the top of the class hierarchy are the most general classes and at the bottom
are the most specific.
• A subclass inherits all of the properties and methods defined in its superclasses.
• Subclasses are generally add new properties and methods specific to the class.
• Subclasses may refine or constrain the state and behavior inherited from its
superclasses.
• Superclasses generalize behavior. It follows that a more general state and
behavior is modeled as one moves up the class hierarchy and a more specific
state is modeled as one moves down.
• A class may simultaneously be the subclass to some class and a superclass to
other class(es).

 Inheritance
• Inheritance allows developers to define classes incrementally by reusing classes
defined previously as the basis for new classes. Inheritance makes it simpler to
define classes.
• The data modeling literature suggests using inheritance to identify higher-level, or
more general, classes of objects.
• Common sets of attributes and methods can be organized into super classes.
Typically, classes are arranged in a hierarchy whereby the super classes, or general
classes, are at the top and the subclasses, or specific classes, are at the bottom.
• It permits new classes to be created from existing classes by extending and refining
its capabilities. The existing classes are called the base classes/parent classes/super-
classes, and the new classes are called the derived classes/child classes/subclasses.
• The subclass can inherit or derive the attributes and methods of the super-class(es)
provided that the super-class allows so. Besides, the subclass may add its own
attributes and methods and may modify any of the super-class methods.
35
An inheritance relationship can be identified:
“IS–A” Or “A-KIND-OF”inheritance: It defines the hierarchical relationship in
inheritance, whereby from a super-class, a number of subclasses may be derived
which may again have subclasses and so on. Ex., if we derive a class Rose from a
class Flower, we can say that a rose is a flower.
“PART–OF” inheritance: It defines the hierarchical relationship in aggregation by
which a class may be composed of other classes. Ex., a flower is composed of
sepals, petals, stamens, and carpel. It can be said that a petal is a part of flower.

• Most classes throughout a hierarchy lead to instances; any class that

has instances is called a concrete class.
• Some classes do not produce instances because they are used merely
as templates for other, more-specific classes (especially classes
located high up in a hierarchy). The classes are referred to as abstract
classes.
CT-4221: Chapter 1 - Overview of Object-Oriented System Development
37
 Types of Inheritance
– Single Inheritance : A subclass derives from a single super-class.
– Multiple Inheritance : Some object-oriented systems permit a class to inherit its state
(attributes) and behaviors from more than one super class. This kind of inheritance is
referred to as multiple inheritance. Multiple inheritance can pose some difficulties. For
example, several distinct parent classes can declare a member within a multiple
inheritance hierarchy. This then can become an issue of choice, particularly when
several super classes define the same method. It also is more difficult to understand
programs. One way of achieving the benefits of multiple inheritance in a language with
single inheritance is to inherit from the most appropriate class and then add an object
of another class as an attribute.
– Multilevel Inheritance : A subclass derives from a super-class which in turn is derived
from another class and so on.
– Hierarchical Inheritance : A class has a number of subclasses each of which may have
subsequent subclasses, continuing for a number of levels, so as to form a tree structure.
– Hybrid Inheritance : A combination of multiple and multilevel inheritance so as to form
a lattice structure.
38
 Dynamic Inheritance
• Dynamic inheritance allows objects to change and evolve over time.
Since base classes provide properties and attributes for objects,
changing base classes changes the properties and attributes of a class.
A Windows object can be changed into an Icon and then back again,
which involves changing a base class between a Windows class and an
Icon class.
• Dynamic inheritance refers to the ability to add, delete, or change
parents from objects (or classes) at run time.
• In object-oriented programming languages, variables can be declared
to hold or reference objects of a particular class.
– For example, a variable declared to reference a motor vehicle is
capable of referencing a car or a truck or any subclass of motor
vehicle.
39
 Polymorphism
• Poly means “many” and morph means “form”, and Polymorphism means
that the same message or operation can be interpreted differently by
different classes of objects.
• Polymorphic operations are used in the context of an inheritance
hierarchy where the same operation may be implemented differently in
each subclass. A single message will produce a different response
depending on the class of the object to which it is sent.
• Different pieces of information need to be collected and stored. We do
not have to be concerned with how something is done when using
objects. We can simply send a message to an object, and that object will
be responsible for interpreting the message appropriately.
• For example, if we sent the message “Draw yourself ” to a square object, a
circle object, and a triangle object, the results would be very different,
even though the message is the same.


Object-Oriented Systems Analaysis and Design

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object-Oriented Systems Analaysis and Design

Uploaded by

Copyright:

Available Formats

Chapter 1:

Object-Oriented System Development

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 2

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 3

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 4

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 5

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 6

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 9

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 11

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 14

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 15

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 17

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 18

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 19

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 21

CT-4221: Chapter 2 - Object-Oriented System Development Life Cycle 22

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 23

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 24

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 25

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 26

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 27

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 28

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 29

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 30

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 31

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 32

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 33

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 34

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 36

• Most classes throughout a hierarchy lead to instances; any class that

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 40

CT-4221: Chapter 1 - Overview of Object-Oriented System Development 41

You might also like