发信人: wjanry()
整理人: majorsun(2000-03-08 14:00:35), 站内信件
|
Object-Oriented Technology
by Josie Lam
HISTORY
Object-Oriented(OO) technology is not a new topic as most people assum
e. It is certainly a hot topic today but its inception began in the la
te 1960抯 with the simulation programming language called Simula by O.
J. Dahl and Kristen Nygaard (Taylor p. 15). Simula introduced the idea
of objects to simulate real-world entities. Then in the early 1970抯,
another programming language, SmallTalk by Alan Kay, furthered the id
ea of using software objects simulating real-world objects to using so
ftware objects for prototyping and developing applications. In the mid
1980抯, other OO programming language, such as C++ and Eiffel, emerge
d.
WHY OO?
To understand why OO technology is popular after more than a decade of
obscurity, we have to understand the problems corporations were facin
g. First, software is difficult to develop, modify, and maintain. Seco
nd, most software are delivered late and over budget. Third, programme
rs are still having to create software from the ground-up because of n
o code reuse. With these issues, corporations are willing to try to fi
nd another approach towards developing a more cost-effective, efficien
t software that will be delivered on time. Corporations need to have a
competitive advantage over their competitions by delivering the produ
cts faster. They also needed to be able to adapt quickly to new change
s.
The approach corporate America has been using for years is structured
programming. Structured programming is a top-down approach, which brea
ks a program down into components until the components cannot be decom
posed anymore. The top-down approach made a vast improvement over the
quality of software, but with large systems, this approach could cause
potential problems. Structured programming can seldom design what the
completed system would be without actually implementing the system. I
f design is found to be incorrect after programming has started, then
the design would have to be entirely restructured. And that would cost
corporations time and money. The difference between structured progra
mming and OO programming is how the data and functions are kept. In st
ructured programming, data and functions are kept separately. Usually
all of the data are placed before any of the functions are written. So
metimes, it is not intuitively known which data works with which funct
ion. But in OO programming, the related data and functions of an objec
t are placed together within one unit (Montlick p. 1).
With the object-oriented approach, the design of the whole system coul
d be modeled at a higher level. Any potential problems with the design
can be fixed at this level without having to start any programming. A
lso, people can easily understand the system as objects rather than pr
ocedures since people think in objects. For example, people see a car
as a system with an engine, gas tank, wheels, etc. But most people wou
ld not see a car as a series of procedures that makes it run. Since it
抯 more natural to think of a system in objects, it is understandable
why OO technology is gaining popularity.
KEY CONCEPTS
OO concepts is important in learning and understanding OO technology.
The key concepts are object, class, message, encapsulation, inheritanc
e, and polymorphism.
Objects directly relate to the real-world entities. Objects can be a p
erson, thing, or concept. An object is like a "black box", therefore a
ll the implementation is hidden (Montlick p. 1). An object has a state
, behavior. The state of an object is one of the possible conditions i
n which an object may exist. For example, if a light bulb is the objec
t, then one of the possible conditions for it would be "on"(Berard). T
he state is represented by the values of the properties(attributes) of
an object. State changes are reflected by behavior of an object. The
behavior of an object defines how an object acts and reacts. The behav
ior is determined by the set of operations the object can perform on i
tself. The behaviors of an object is also known as its interface, func
tions, and methods. For example, if a printer is an object, then its b
ehavior or function is to print whatever it receives.
Class is a generic definition for a set of similar objects. Classes pr
ovides the specifications for the objects? behaviors and attributes. C
lass is an abstraction of a real world entity. Objects are instances o
f a class. For example, the attributes for the class animal is having
four legs and a tail. Its behaviors is sleeping and eating(Render, 1-2
0). Then possible instances or objects of the class animal are cat, el
ephant, and horse.
Messages are requests for the receiver objects to carry out the indica
ted method or behavior and return the result of that action to the sen
der objects. For example, a person object sends the light bulb object
a message to turn on(Berard). The light bulb object has a behavior tha
t will change its state from off to on. Then the light bulb object tur
ns itself on and indicates to the person object that its new state is
on.
Encapsulation is the process of hiding the implementation details of a
n object. The only access to manipulate the object data is through its
interface. It protects an object抯 internal state from being corrupte
d by other programs. Also, other programs are protected from changes i
n the object implementation, therefore reducing the ripple effect (Men
s p. 3). Program maintenance is easier and less expensive because chan
ges in the object data or implementation is only modified in one place
. Programs using this object抯 functions only cares that the object do
es what it is supposed to do because encapsulation allows objects to b
e viewed as black boxes.
Inheritance is a code reuse mechanism to build new objects out of old
ones. Inheritance defines a relationship among classes where one class
shares the structure and/or behavior on one or more classes. For exam
ple, the class feline inherits all the behavior and attributes of the
class animal (Render, 1-20). And the class feline also has a meow beha
vior that was not in the class animal. So all instances of the class f
eline has four legs, a tail, sleeps, eats, and meows while instances o
f the class animal has only four legs, a tail, sleeps, and eats. It al
so provides a more flexible and adaptable system and enables polymorph
ism.
Polymorphism means having many forms. It provides the ability to use a
single message to invoke many different kinds of behavior. For exampl
e you have a class shape with a draw behavior(Taylor, 46-47). The draw
behavior will draw any instances of shape. If classes triangle, recta
ngle, and circle are inheritances of the shape object, all of them hav
e behavior of the shape. Within the inherited classes of triangle, rec
tangle, and circle, the draw behavior is rewritten to draw a triangle,
rectangle, and circle respectively. So if a triangle object calls the
draw behavior, a triangle will be drawn. For the rectangle, a rectang
le is drawn. And a circle is drawn for the circle object. Therefore th
e individual implementation of each different shape is hidden behind a
single interface or behavior, draw. Other programs can generically in
voke an object抯 operation without knowing the object抯 type.
METHODOLOGY
Currently there are several methodologies available to use in object-o
riented analysis and design. Why is an OO methodology so important? It
抯 a systematic way to do analysis and design. It enables planning and
repeatable development. It provides a basis for developer experience.
Also it avoids misunderstanding and avoid different notations for the
same thing because everyone is speaking the same language. The most w
idely used methodologies are Rumbaugh抯 Object Modeling Technique(OMT)
, Shlaer-Mellor (Object-Oriented Analysis/Design(OOA/D), Booch Method,
Wirfs-Brock (Responsibility-Driven Design/Class/Responsibility/Collab
oration)RDD/CRC, Coad/Yourdon Methodology, and Jacobson Object-Oriente
d Software Engineering(OOSE).
To decide which method is best, you have to look at some selection cri
teria. First, the method should be suitable for the application requir
ements, cover the software lifecycle phases, and also fit the programm
ing language. Second, developers?experience with the method affect how
well they use the method. Third, the amount of support the method has
. The support could be tools for creating models, technical help, or a
mentor. Finally, the method should be easy to use and understand.
Rumbaugh OMT is based on elements of structured analysis and entity-re
lationship modeling. The primary phases to iterate through are analysi
s, system design, and object design, and implementation. In the analys
is phase, there are three models to build . In the system and object d
esign the models are refined. The object model provides the class and
object diagrams that detail the classes, objects, attributes, and rela
tionships in a system. The dynamic model deals with the behavioral asp
ects of the system. Detailed descriptions of use cases and scenarios a
re created, including the event diagram for each class. The functional
model uses data flow diagrams to look at the data flow among the beha
viors. Most often the functional model is not created since it duplica
tes much of the dynamic model. The Implementation phase describes how
to translate the design into code. Some of its strengths is in its not
ations which supports all major OO concept. A weaknesses is that Analy
sis phase has more support than the design (Render, 4-12).
Shlaer-Mellor method uses the traditional information modeling techniq
ues to represent the entities in a system, state diagrams to model the
states of the entities, data-flow diagrams to model the flow of data
through a system. This method produces three models, information model
, state model, and process model. The information model identifies the
objects, attributes, and the relationships between objects in the pro
blem. The state model describes the lifecycle of each object using sta
te-transition diagrams. The process model creates an action data flow
diagram to show process within an action and the communication between
actions. This method is primarily concerned with OO analysis Some str
engths of Shlaer-Mellor method is that it provides different views of
the problem, easy conversion from structured methods. It also is widel
y used since it is one of the oldest OO methods (Render, 4-15).
Booch抯 method is a very popular OO design method. It decomposes the a
nalysis and design process into 4 iterative phases. They are identific
ation of classes and objects, their semantics and their relationships,
and specification of interfaces and implementations. Each of the phas
es creates one or more diagrams of class and object, module and proces
s, state-transition, and interaction. The Booch method is very detaile
d and has a great deal of commercial use. It has a rich set of notatio
n and incorporates elements of other methods (Render, 4-19).
Wirfs-Brock抯 RDD/CRC is geared toward design, but it may be useful fo
r brainstorming during the analysis phase. It follows a simple, intuit
ive process. It involves creating a CRC(Class/Responsibility/Collabora
tion) card for each object in the system. This method finds the object
s in the system and identifies its class. It determines the responsibi
lities(behaviors) of each object/class. It also determines the collabo
rations between the objects. Collaborations are the connections betwee
n objects and the sequence of messages sent while the objects do their
responsibilities. Its strengths are the ease of use and understanding
, inexpensive tools of index cards, and it is being used commercially.
It identifies the class hierarchies and the subsystems (Render, 4-24)
.
Coad/Yourdon method is based on OO and entity-relationship modeling. I
t breaks the problem down to 5 layers, which are identified by separat
e activities. These activities are class and object layer, structure l
ayer, subject layer, attribute layer, and service layer. In the class
and object layer, classes and objects are found in the problem stateme
nt and requirements documents. The structure layer analyzes the previo
us layer to find inheritance relationships among the classes and objec
ts. Then the subject layer separates the system into layers and identi
fies the class and objects in each layer. The attribute layer identifi
es the attributes of each class and objects. This layer will also chec
k for any special cases of the class and objects. The service layer id
entifies the states, behaviors, and message connections for each class
and objects. Some of its strengths is that it is a simple, intuitive
approach and it抯 also easy to understand and use. But it is not widel
y used, not supported enough, and it includes some non OO features, su
ch as a key attribute to identify objects (Render, 4-27).
Although Jacobson抯 method OO Software Engineering(OOSE) contains elem
ents of other OO methods, it places more emphasis on use cases. OOSE h
as 3 phrases that creates one or two of the requirements and analysis
models, design and implementation, and the test model. The requirement
model identifies the users or other systems this system interacts wit
h, the use cases, the interfaces, and briefly describes the objects in
the problem domain that is part of the use cases. The analysis modeli
ng identifies the interfaces objects, identify the entity objects, and
identifies the control objects which directs the sequences of actions
and connects interface and entity object s. the design modeling descr
ibes the objects in the system and how they interact. This modeling pr
oduces block specification, interaction diagrams, and state-transition
diagrams. The implementation modeling describes the implementation of
the system and produces annotated source code. The test model describ
es how to test the system and produces the test specifications and tes
t results. Some of its strength is the ease of learning because of the
simple notation. It covers all development phases with a good support
for the analysis phase (Render, 4-32).
The need for standardization of methods is needed for many reasons. Th
ere are many methods and notations competing with each other that user
s are distracted by the decisions they need to make. Existing methods
are already converging since these methods pick up ideas from other so
urces. A single, common language is desirable because it can be used f
or all development methods, used throughout the project lifecycle, and
used for different application technologies.
Since standardizing methodologies is an issue, the Object Management G
roup(OMG) sent out a Request for Proposal(RFP) in June 1996. Submissio
n was due in January 1997 and they hope to adopt a standard by June 19
97. The RFP asked for an open repository for analysis and design model
s, including a meta-model and CORBA IDL interfaces to access the model
s. There has been several submissions by several different groups to a
ccomplish standardization. Some contending standards are Rational抯 Un
ified Modeling Language(UML) and the OPEN consortium抯 Open Modeling L
anguage (Fowler, "Standardization and the UML" p. 2).
UML combines the best of Booch, Rumbaugh, and Jacobson抯 methods into
one. UML is supported by several companies including Microsoft, Hewlet
t-Packard, Oracle, and Texas Instruments. UML claim to have an "open"
process to encourage other methodologists to join.
OML is led by Don Firesmith, Brian Henderson-Sellers, and Ian Graham.
They came up with this method because they claim that UML is too groun
ded in old-fashioned data modeling techniques which are inappropriate
for object modeling.
Other proposals from OPEN Object Alliance, IBM, and Objecttime were su
bmitted, but they are supporting UML or OML with some extensions. It s
eems that UML will become the standard since they are backed by the le
ading methodologists and major companies. With UML抯 open process, new
techniques added will be treated as extensions to UML. This approach
makes it easier for UML to be used.
There are many Computer Aided Software Engineering(CASE) tools availab
le to people to use with the methods. Some tools are specifically desi
gn for a specific method, but other tools can support more than one me
thod. Use of CASE tools make frequent revisions of the models much eas
ier, even though the white-board is much easier to draw and erase. CAS
E tools are also useful for proper documentation.
Testing OO is a little different from testing structural code. In OO,
you test the model, class, cluster, system, integration, regression, a
nd stress tests. Also you test iteratively and incrementally. As a res
ult, testing activities start earlier, errors are found earlier, deadl
ines are handled more gracefully, and testing is more integrated in de
velopment.
LANGUAGES
Although, many OO programming languages exist today, the 2 leading lan
guages are SmallTalk and C++. SmallTalk is considered to be the pure f
orm of OO since it strictly follows the OO methodology. On the other h
and, C++ is a hybrid since it is an existing language, C, mixed with O
O features. C++ does not strictly adhere to the OO methodology which t
o some people is an improvement and to others a disadvantage. It is an
improvement because programmers can choose to use any or none of the
OO features in C++. It is a disadvantage for the same reasons. A begin
ner might think that because he is coding using C++, he is using OO. B
ut he does not realize that he is not using any of the OO features. So
me other OO languages that are currently gaining popularity are Visual
Basic and Java.
STRENGHS
One of the reasons why OO is beneficial is that programmers can design
programs in the context of the kinds of objects and their relationshi
ps to be modeled in the real-world system. OO models mirror the busine
ss systems. Another benefit is faster development because software is
built from standard objects, reusable existing models of corporate pro
cesses, and rapid prototyping of models from the methodologies. Also h
igher quality is achieved because programs are created out of existing
, tested components. Easier maintenance is also achieved since code ne
eds only to be changed in one place. Scalability is also a benefit. La
rger systems are easier to build and maintain because its subsystems c
an be developed and tested independently. Changes to existing systems
can be made without rebuilding the system.
WEAKNESSES
Technology is still evolving. There is a lack of established standards
, lack of portability from one environment to another. Also it is hard
to mix classes from different vendors/languages. Conversion to OO env
ironment requires education and training since the technology is devel
oping. New software and hardware may be required as part of the cost o
f conversion. Lack of structure can lead to bad coding. Also people wi
ll need time to shift from the structured paradigm to the OO paradigm.
Another problem is that people do not want to shift because they stil
l believe that the current paradigm is the best one for solving their
problems or they are afraid to venture into unknown areas, even if the
OO paradigm is the best solution.
In an article in Computer World by Martin A. Goetz, the author suggest
s that code reuse will "never become widespread" (Goetz, pg 33). Part
of his reasoning is that object-oriented programming is hard to learn.
Unlike COBOL with its English-like syntax that is "straight-forward,
easily understood, and easily maintainable" , OOP requires that progra
mmers and designers learn an "unnatural way" to deal with applications
. OOP is not the problem. The problem lies in the way people have been
taught to think when programming. OO technology requires a paradigm s
hift in their way of thinking about programming. And that is the diffi
culty. In the real world people think in objects and how objects inter
act with each other. People identify every object in their life with c
ertain features and functions. For example, a phone is an object. Its
features may include a speaker, a built-in answering machine, a number
pad, and a handset. Its function is to be able to receive incoming ca
lls and to make outgoing calls. But when doing structured programming,
the phone attributes and its functions are separated. Now anyone can
invoke the phone functions and change the way the phone should work.
Goetz mentions that although OO has been available for awhile, studies
has shown that most companies who tried OO have abandoned it. The one
s who succeed have not developed much reusable objects. The time spent
on finding and maintaining reusable code is not "cost-effective nor p
ractical". The reason may be that the unsuccessful companies did not f
ully understand what the OO paradigm is and how to correctly apply the
m. Another reason may be that OO technology is still emerging and has
not fully developed enough to present a significant number of reusable
objects. Most of these problems could be solved through education to
learn the paradigm and training to enforce what was learnt. And only t
ime and wider usage of OO technology will prove if objects are reused.
FUTURE
OO is not the perfect solution for everyone but it is the best solutio
n to the rapidly changing problems in almost every industry, especiall
y in Graphical User Interface(GUI) applications. Anticipating the chan
ges, OMG is making a concentrated effort to standardize OO methodology
. Open systems is possible when more mix-and-match software are availa
ble . Client-Server Applications are more easier to develop. Enterpris
e modeling allows companies to concentrate on developing and maintaini
ng a working model of its corporate processes, instead of constructing
an on-going series of separate application programs. A Object-Oriente
d Database Management System(OODBMS) will also be available.
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.96.184.41]
|
|