So let's look at the object-oriented analysis in a
little more detail. As I said earlier, traditional analysis
and design techniques were functionally oriented. What that means
is that they concentrated on the functions to be performed,
whereas the data upon which the functions operated were
secondary to the functions themselves. Conversely, object oriented analysis, is
primarily concerned that with a data objects, so we
went from a functional oriented view to a data oriented
view, what that means is that during the analysis phase,
we define a system first in terms of the data
types and their relationships, and the functions or methods are
defined only later and associated with specific objects which are sets
of data. So let's see how we can perform object
orientated analysis in practice, so the basic idea is to be
focused on the objects of the real world. So to
go from a real world objects to a set of requirements.
And we can describe this as a four-step process. The first
step is to obtain or prepare a textual description of the
problem to be solved. So obviously, we need to start from
some description of the system that we need to build. And
this is a very practical oriented approach, so that the next
thing we do is that we take the description and we
underline nouns. In this description. And the nouns that we underline
will become classes in my analysis. We then look at adjectives in
the document. We underline those, and we use that
information to identify the attributes of the classes that we've
previously identified. At this point we focus on active
verbs in the description, and the analysis of the active
verbs will give us the operations that we'll need
to define for our classes. So, again, underline nouns, and
those will become the classes in my system. Then,
objectives. And, those will be the attributes of the classes.
And, finally, active verbs that will become the operations of my classes. And
of course, this is a high level view to take this with a
grain of salt. But we will see that it's a very good pragmatic
approach to identifying requirements, starting from a
description of the system to be built.