Object-oriented real-world modeling revisited
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
The Journal of Systems and Software 59 (2001) 153±162
www.elsevier.com/locate/jss
Object-oriented real-world modeling revisited
Sadahiro Isoda *
Toyohashi University of Technology, Toyohashi-shi, Aichi-ken, Japan
Received 1 September 2000; received in revised form 31 December 2000; accepted 21 February 2001
Abstract
When applied to real-world problems, object-oriented modeling maps an entity in the real world to a class as it is. This seemingly
natural ``genuine'' real-world modeling can be rightly applied to cases when the purpose of modeling is merely to represent a
problem in a class diagram and thus to facilitate its understanding. Business process reengineering is a good example of this.
Genuine real-world modeling can also be applied to the development of a program that simulates the real world on a computer.
Contrary to these cases, however, ``pseudo'' real-world modeling has instead to be applied when a business assistance application is
to be developed. It maps an entity whose information is dealt with by the business to be automated to a class that represents the
information about the entity. These two modeling methods have to be appropriately applied according to the type of their target
problems. This point, however, has not been suciently recognized. Many authors of the literature on object-oriented methodol-
ogies and techniques teach us ``naive'' real-world modeling, whose real nature is a mixture of genuine and pseudo real-world
modeling methods. Naive analyzers who believe the literature are lured into severe modeling errors when they develop business
assistance applications. Ó 2001 Elsevier Science Inc. All rights reserved.
Keywords: Object-oriented methodology; Object-oriented analysis; Real-world modeling; OOSE; OMT; UML
1. Introduction real-world modeling plays a fundamental role in the
methodologies and techniques.
Many authors state that object-orientation allows us As real-world modeling is a technique to model the
to intuitively and naturally model the real world. Borg- real world as it is, it identi®es a class corresponding to
ida et al. (1985) say ``the chief advantage of object-ori- an entity in the real world that can be easily observed.
ented frameworks is that they make possible a direct and Therefore, real-world modeling is usually used for
natural correspondence between the world and its making initial models in the early stage of the require-
model''. Martin and Odell (1992) say ``the models we ments analysis phase of software development. It cannot
build in OO analysis re¯ect reality more naturally than be used for identifying the deep structure of the target
the models in traditional systems analysis'' McGinnes world, which usually happens during the latter part of
(1992) says ``the object-oriented approach is often de- requirements analysis phase.
scribed as `natural' and `intuitive' because it attempts to We can see an example of real-world modeling in
represent the application domain more closely than Ambler (1998). He performs object-oriented modeling
conventional ways of structuring information systems''. based on Wirfs-Brock's responsibility-driven approach
Based on this recognition, ``real-world modeling'' or the (Wirfs-Brock and Wilkerson, 1989) and Beck's CRC
representation of the real world as it is in the frameworks modeling technique (Beck and Cunningham, 1989). The
of object-orientation seems to be generally accepted. example problem he uses is a university information
This paper discusses real-world modeling itself. Al- system. He identi®es classes representing real-world en-
though it mentions several object-oriented methodolo- tities such as students, professors, seminars and courses.
gies and techniques, it never intends to directly evaluate Then he assigns operations ``enroll in a seminar'' and
nor criticize any one of them. It does so just because ``drop a seminar'' to the student class, and ``add
student'' and ``drop student'' to the seminar class. His
policy of assigning operations to classes can be described
*
Tel.: +81-532-44-6893; fax: +81-532-44-6893. as follows: give a class, possibly a personi®ed one, every
E-mail address: isoda@tutkie.tut.ac.jp (S. Isoda). operation it may have in the real world, without
0164-1212/01/$ - see front matter Ó 2001 Elsevier Science Inc. All rights reserved.
PII: S 0 1 6 4 - 1 2 1 2 ( 0 1 ) 0 0 0 5 9 - 0154 S. Isoda / The Journal of Systems and Software 59 (2001) 153±162 considering how the system will be implemented. We world modeling. Section 3 deduces the rules for pseudo can see another example in Rosenberg (1999). He ap- real-world modeling. Then we apply it to simple exam- plies a ``grammatical approach'' to a portfolio trading ple problems. Section 4 shows that the real nature of and accounting system, i.e., he identi®es classes and naive real-world modeling is a mixture of genuine and their operations according to the noun phrases and verb pseudo real-world modeling methods and discusses phrases extracted from a problem statement. This ap- possible modeling errors due to naive real-world mod- proach is equivalent to identifying classes corresponding eling when applied to business assistance applications. to entities in the real world, and hence he practically Section 5 discusses related topics. applies real-world modeling. For the notation of class diagrams, this paper uses Contrary to these seemingly natural understandings, UML, which has become an international standard for real-world modeling that models the world as it is can- object-oriented modeling language (Booch et al., 1998; not be applied to ``business assistance applications'', i.e., OMG, 1999; Rumbaugh et al., 1999). applications that automate business in the real world like the systems above. What is to be used for business assistance applications is ``pseudo'' real-world modeling. 2. Two object-oriented modeling methods This point, however, has not been suciently recog- nized. In the literature on object-oriented methodologies In the previous section, we started with the simple and techniques, many authors teach us to model the real understanding that real-world modeling is a technique world as it is without considering the type of target that models the real world as it is. Here, we de®ne it problems (Ambler, 1998; Beck and Cunningham, 1989; more precisely. Real-world modeling identi®es classes Rumbaugh et al., 1991; Wirfs-Brock and Wilkerson, according to entities in the real world and associations 1989; Wirfs-Brock et al., 1990). They apply a wrong according to relationships between them. It assigns modeling technique to those problems instead of pseudo attributes and operations to classes according to the real-world modeling. In this paper, we call the technique attributes and functions of the entities. Thus, we de®ne ``naive real-world modeling'' because it results from real-world modeling as shown below (in fact this de®- naive understanding of object-oriented modeling. Ana- nition is that of genuine real-world modeling). lyzers who believe the literature apply it for developing business assistance applications. The result is severe De®nition 1. Real-world modeling represents the real modeling errors such as mixing up actors in the real world in a class diagram by way of: world and classes in the system, identifying irrelevant (1) identifying classes according to relevant entities classes, and assigning irrelevant operations to classes. in the real world, Here, an actor is an entity that exists just outside of the (2) assigning operations to the classes according to system and communicates with it. the functions of the entities, Some authors point out that those errors are often (3) assigning attributes to the classes according to observed in the literature. McGinnes (1992) says that the data of the entities, and ``Objects in an information system are distinct from (4) identifying associations between classes accord- objects in the real world, and can never be more than a ing to the static relationships between the entities. representation or model of the real thing. . . the failure to distinguish between system objects and real world ob- In this paper, an entity is de®ned to include not only a jects is very much in evidence in the object-oriented lit- physical thing but an idea that can be treated in the erature''. Gossain (1998) says ``if we take the phrase same way as a physical thing. The target of object-ori- `model the real world' too literally, as many people do, ented modeling is either the real world or ``cyber'' we run into trouble''. These two statements, however, worlds built on computers. We ®rst discuss the former are insucient in that they do not analyze why people case. The purpose of object-oriented real-world model- are liable to make such errors of mixing up real-world ing, or, in other words, the usage of class diagrams made entities and system objects, nor show what other kinds by real-world modeling, can be classi®ed into the three of errors might accompany them, nor present any cases, namely measures to prevent them. The result is that there still Usage 1. To facilitate understanding of a problem in exist many researchers, practitioners and lecturers who the real world without any intention of developing believe naive real-world modeling and that the misun- an application based on the diagram. derstanding is persistently handed over to many novices. Usage 2. To develop an application that simulates This paper tries to solve this problem by showing a the real world. total view of real-world modeling. Section 2 explains Usage 3. To develop an application that automates that there are three kinds of usages for real-world business in the real world. modeling, and two of them require genuine real-world A good example of Usage 1 is business process re- modeling, and the remaining one requires pseudo real- engineering, whereby we ®rst represent an organiza-
S. Isoda / The Journal of Systems and Software 59 (2001) 153±162 155
tion's business process, possibly together with its envi- being. In fact, it describes the example problem used
ronment, in a class diagram and then analyze the pro- later.) Let us assume that in the ``original'' real world
cess in order to make improvements (OMG, 1999). (a), a certain business is operated manually, and now we
Another example is representing the structure of a dis- are going to develop an application that automates it.
tributed computing system as a network of computers As the application to be developed is a business assis-
and devices. Usage 1 may also happen in the require- tance application, it will eventually be embedded in the
ments elicitation step of software development, whereby original real world, and then the original world changes
a target problem, together with its environment, is rep- into the ``automated'' real world (c).
resented in a class diagram to facilitate understanding of The application embedded is an entity belonging to
the problem itself. An example of Usage 2 is an aircraft the automated real world just as other entities such as
¯ight simulator. This kind of software simulates a cyber books and users are; and hence, it would be mapped to a
world constructed on a computer that is a copy or model class if the automated real world were to be modeled.
of the real world. What is common between Usage 1 and Also, modules of the application (implemented classes,
Usage 2 is that the real world is modeled as it is. That is, i.e., data structures or functions) are entities within the
each class in the class diagram represents its corre- application and hence, if the internal structure of the
sponding entity in the real world. In order to obtain application were to be modeled, they would be mapped
such class diagrams, we can simply apply real-world to classes. One thing to be noted here is that the appli-
modeling (Fig. 1). cation and its modules belong to worlds of dierent
In Usage 3, however, things are quite complicated. levels because the application is an entity of the auto-
Fig. 2 shows how the real world, the class diagram, and mated real world whereas modules are entities of the
the application are related. (Do not be concerned with cyber world within the application. (In fact, the lack of
the names of the elements in this ®gure for the time this recognition can lead to naive real-world modeling.)
Fig. 1. Genuine real-world modeling: (a) Usage 1; (b) Usage 2.
Fig. 2. Mechanism of pseudo real-world modeling.156 S. Isoda / The Journal of Systems and Software 59 (2001) 153±162
Now, let us con®rm the relationship between the class entities whose information is not dealt with by the
diagram (b) and the application that is a part of the business include the system itself, actors of the system (if
automated real world (c). As the application is devel- the system does not deal with actor's information), and
oped based on the class diagram, the class diagram is a other entities unrelated to the business. Here, the term
model of the application (this holds with any software ``system'' includes aliases of a system, such as the com-
and its model). That is, if the application exists, we puter on which a system is installed.
could obtain the class diagram by applying genuine real- Modeling rule 1: In applying pseudo real-world
world modeling to the internal structure of the appli- modeling, we should identify only the classes that cor-
cation. (Here, genuine real-world modeling is applied to respond to the entities whose information is dealt with
a cyber world.) This means that we can make class di- by the business to be automated. We should not include
agram (b) if we do what is equivalent to modeling the entities whose information is not dealt with by the
internal structure of the application. business.
Starting from this fact, let us ®nd out what the
modeling method for Usage 3 should look like. First, it 3.2. Operations assigned to classes
is the original real world that can be the target of
modeling because it has the same structure (and be- In pseudo real-world modeling we model entities in
havior) as the application; the automated real world is the original real-world to obtain a model of the infor-
not appropriate because it contains the application in it mation about them. Then, attributes can be straight-
and therefore has dierent structure from the applica- forwardly dealt with: we can simply assign attribute of
tion itself. Next, just as each module in the application an entity to the class corresponding to it because the
represents information about an entity, each class rep- attributes are nothing but the information about it. As
resents information about an entity (Douglass, 2000; for operations, however, the situation is rather compli-
Rumbaugh, 1995). Thus, we have to map information cated. Note that ``information about an entity'' does not
about an entity to a class. have any functions of itself because it is merely infor-
In the case of Usages 1 and 2, each class is a model of mation. Thus, even when an entity has a function, we do
its corresponding entity itself and therefore we can re- not necessarily have to assign it to the class corre-
gard a class and the entity to be the same. In the case of sponding to the entity. This point is often neglected,
Usage 3, however, we cannot. It follows that the mod- however.
eling method used in Usage 3 must be a dierent one Then, what operations does a class corresponding to
from the natural real-world modeling method de®ned at the information about an entity have? The answer is that
the start of this section and used in Usages 1 and 2. it depends on the design. First, the encapsulation prin-
As the modeling method used in Usage 3 models the ciple guides us to assign an operation to the class whose
real world although in a ®ctitious way, it is a kind of attribute is handled by the operation. Other operations
real-world modeling. If we regard the modeling method that cannot be decided by the principle wholly depend
used in Usages 1 and 2 as genuine, the one used in Usage on the designer. That is, while a designer makes an
3 may be pseudo. This is the reason for the naming analysis model and then polishes it up to make a design
of the two modeling methods. They should be appro- model, he or she assigns to classes operations that are
priately chosen according to the type of their target necessary for realizing the functions prescribed by the
problems. problem statement. Thus, we have to follow the next
rule:
Modeling rule 2: In applying pseudo real-world
3. Rules of pseudo real-world modeling modeling, we can assign attributes of an entity to its
corresponding class, but do not necessarily have to as-
We study pseudo real-world modeling in more detail sign functions to it. What operations a class has depends
to ®nd its rules and de®nition. on design, speci®cally guided by the encapsulation
principle.
3.1. Scope of modeling
3.3. De®nition
In Usage 3 the class diagram is used to develop an
application that automates business performed in the Below is the de®nition of pseudo real-world model-
original real world manually. Therefore, we should ing, incorporating the two modeling rules. Compared
model information about the entities that are dealt with with that of genuine real-world modeling, (1) and (2) are
by the business to be automated. That is, we should not changed.
model the whole real world in which the business is
being performed, but we should select only the entities De®nition 2. Pseudo real-world modeling represents the
whose information is dealt with by the business. Those real world in a class diagram by way of:S. Isoda / The Journal of Systems and Software 59 (2001) 153±162 157
(1) identifying classes according to entities whose
information is dealt with by the business to be
automated,
(2) assigning operations to the classes guided by the
encapsulation principle,
(3) assigning attributes to the classes according to
the data of the entities, and
(4) identifying associations between classes accord-
ing to the static relationships between the entities. Fig. 3. Class diagram for a simple library system.
3.4. Applying pseudo real-world modeling to examples outside of the system and then performs its operation
register to register itself. This implementation is the re-
Let us con®rm the modeling rules of pseudo real- sult of design based on the second sentence of Modeling
world modeling by way of applying it to two small rule 2. Note that we do not consider the creation of
examples. objects because we are discussing how to make initial
analysis models in the early stage of requirements
3.4.1. Example 1 analysis phase.
(1) Problem description. We need a library manage- Next, we consider the borrowing function (b). A
ment system with functions: natural implementation of the borrowing function is to
(a) To register books. Library clerks perform regis- assign operation ``borrow'' to the book class. This is
tration. because each book object may have a Boolean attribute
(b) To borrow and return books. Library users do ``isBorrowed'' that indicates whether it is borrowed or
the job themselves. not and the borrow operation will change it. Therefore,
(c) To keep record of current borrowings, i.e., the the book class has the borrow operation due to the en-
system knows the user who is currently borrowing capsulation principle (Modeling rule 2). The operation
a speci®c book. will also set a link (i.e., an instance of an association)
(2) Modeling. As the library system automates a between the user and book objects speci®ed by param-
business in the real world, it is a business assistance eters of message borrow. A similar implementation can
application. Therefore, we apply pseudo real-world be applied to the returning function.
modeling to the original real world to obtain a class Note that we do not need a clerk class in the class
diagram. First, let us identify the entities whose infor- diagram because the problem statement does not state
mation is dealt with by the business. For the bene®t of that the system is to be aware of which clerk has regis-
explanation, we ®rst consider function (c). It deals with tered a particular book, and therefore we do not need
the information about books and users. (Note that the any association between the clerk class (if identi®ed) and
use-case-driven approach (Jacobson et al., 1992; the book class. Furthermore, as there are no functions
Kruchten, 1998) is most suitable for identifying classes that deal with the clerk class, we do not need one.
in this context. That is, we ®rst describe the system's Therefore, we can decide not to identify a clerk class
behavior visible from the outside as a set of use-cases, (Modeling rule 1). If a new function ``to keep record of
and then walk through them to discover entities that which clerk registered a speci®c book'' were added to the
appear in the behavior.) problem description, then we would identify a clerk class
Then, we identify associations. Because there is a and an association registered by between the book class
relationship ``currently borrowed by whom'' between and the clerk class.
the information about books and users, we can identify (3) Class diagrams with actors. In the above modeling
an association ``borrowed by'' between the book class we apply pseudo real-world modeling to the original real
and the user class. Thus we have a partial class diagram world and identify classes by ®nding:
necessary for realizing the function (c) as shown in (A) Entities whose information is dealt with by the
Fig. 3. It consists of the user class, book class and business to be automated.
association borrowed by. In fact, a class diagram made by this modeling rep-
Let's con®rm that the class diagram is sucient to resents only the internal data structure of the system to
implement functions (a) and (b). First, these two func- be developed. In order to make the diagram represent a
tions do not deal with any entity information other than whole system, we should add those classes that handle
those about books and users. To realize the registration interfaces with the outside and control of object col-
function (a), we simply assign operation ``register'' to laboration. Then, it is worthwhile to add actors to the
the book class. Then, we can sketch the behavior like class diagram representing a whole system for clarifying
this: a book object receives a message register came from the system interface. In the following discussion we need158 S. Isoda / The Journal of Systems and Software 59 (2001) 153±162
Fig. 4. Class diagram with actors for a simple library system.
actors in additions to classes representing the internal (b) The system knows the customer name and pass-
data structure of the system. word for each account, and also the issue number
We can identify actors by ®nding: and issue date of cash cards issued to the account.
(B) Entities that enter or receive information into or (c) The system provides cashing service through
from the system ATMs. The system keeps records of the account
while simulating use cases just as we do for identifying number, date, ATM number, card's issue number,
classes. We can identify the clerk actor from the regis- amount of money, and balance for each transaction.
tration use case and the user actor from the borrowing (d) When a cash card is entered into an ATM, the
and returning use cases. Fig. 4 shows the re®ned class system reads the account number and the issue num-
diagram with these actors as well as the boundary ber of the card. It then asks the customer to enter his
classes handling the interface between the system and password, and compares it with the one recorded in
the actors. The symbol consisting of a circle and a the system. When veri®ed, the system again asks the
T-mark represents a boundary class. customer to enter an amount of money he or she re-
quires. The system dispenses cash if the requested
3.4.2. Example 2 amount is within the current balance.
(1) Problem description. Make a class diagram (2) Modeling. Let us make an analysis model of the
(analysis model) for a banking system that ful®lls re- banking system that works on a single virtual computer.
quirements below. Fig. 5 shows a general view of the (The system may consist of a central subsystem on a host
banking system: computer and an ATM subsystem on each of the ATMs.
(a) Customers can open accounts with a bank. The But we defer such architecture issues until design phase.)
bank issues one or a few cash cards for each ac- We apply pseudo real-world modeling to the problem. By
count. Each cash card has an account number and simulating the business of the banking system (it is ap-
an issue number magnetically recorded on it. The propriate to apply the use-case-driven approach as men-
system can tell whether a cash card is the original, tioned above), we easily know that the system handles
family, or reissued card by way of the issue number. information of the entities: customer, cash card, account,
ATM, and transaction. Then we identify classes repre-
senting these entities. We can also easily identify associ-
ations between the classes from the problem description.
We now have a class diagram showing the internal
structure of the banking system (the part of the class
diagram encircled by a dotted line in Fig. 6). Then, we
identify the customer actor and the cash card actor. By
adding these actors and boundary classes corresponding
to the actors, we have a class diagram representing the
whole system. Note that association names are omitted
if they are evident from classes at their both ends. The
``authorized by'' association represents the relationship
between a transaction and the cash card that evoked it.
This is derived from the requirement (c) that says that
the system keeps records of the card's issue number for
each transaction. The association between transaction
class and account class is also derived from (c). In the
execution time, a transaction object will obtain the ob-
Fig. 5. Banking system. ject ID of the target account object via the cash cardS. Isoda / The Journal of Systems and Software 59 (2001) 153±162 159
Fig. 6. Class diagram for a banking system.
object and then establishes a link instance of the asso-
ciation; it will use the link for further processing.
4. Errors due to naive modeling
The two modeling methods, namely genuine and Fig. 7. Erroneous class diagram for the library system.
pseudo real-world modeling, are given by De®nitions 1
and 2, and therefore they are de®nite as such. Naive Let us review the diagram. Among the classes, the
real-world modeling, however, can only be known by book class is appropriately identi®ed. The clerk class,
analyzing modeling examples that appear in the litera- however, is unnecessary. It is actually an actor that has
ture cited in Section 1. By so doing, we ®nd that the real crept into the class diagram (let us call this kind of errors
nature of naive real-world modeling is a mixture of Category 2). The user class is rightly identi®ed, but we
genuine and pseudo modeling methods and that naive should be careful about its operations.
real-world modeling is equivalent to performing the The library system is so small that we cannot see any
following steps: unnecessary classes that correspond to entities unrelated
Step 1. Apply genuine real-world modeling to the to the business. This kind of modeling errors, however,
automated real world. can often be observed in general (let us call them
Step 2. Apply pseudo real-world modeling to the Category 1 errors).
original real world, if necessary.
Step 3. Merge the results of Steps 1 and 2 to obtain a 4.1.2. Operations assigned to classes
single class diagram, assuming that those classes When we apply genuine real-world modeling (again,
that appear in common (if any) are the same. as Step 1 of naive modeling), De®nition 1 guides us to
Note that we do not claim those who believe naive real- assign operation borrow to the user class. It also guides
world modeling consciously perform the steps above. us to identify an association between the user class and
the book class that is the target of the operation, because
4.1. Example 1 users in the real world has the function borrow (let us
call this kind of errors Category 3).
Example 1 is so simple that we only have to apply Let us consider operation borrow of the user class.
Step 1 because all the classes that naive modeling ex- Recall that the book class also has operation borrow
pects are found in Step 1. which is to set attribute isBorrowed as stated in Section
3.4.1. Therefore, the system behaves as shown in the
4.1.1. The scope of modeling collaboration diagram (Fig. 8). That is, a user actor
When we apply genuine real-world modeling (as sends message borrow to the library system (shown as a
Step 1 of naive modeling) to the library problem, we will package), a user object receives it, and then resends it to
think that the user, book, and clerk in the real world are a book object. In this model, the user object in the
relevant entities and then identify classes representing system is resending the message just received, thus
them. Thus we have a class diagram as shown in Fig. 7. merely repeating the action of the real-world user, and160 S. Isoda / The Journal of Systems and Software 59 (2001) 153±162
Fig. 8. Partial confused collaboration diagram of the library system.
hence a queer model (Gossain, 1998). This kind of
modeling errors is very often observed with novice an- Fig. 10. Erroneous class diagram due to naive real-world modeling.
alyzers. Note that these errors only happen when a
business assistance application deals with the informa- ``partial class diagram A''. Note that accounts and
tion about its actors. transactions are not taken into the class diagram because
they exist within the banking system. These classes,
however, are indispensable for developing a banking
4.1.3. Three categories of errors
system. This means that it is necessary to perform Step 2.
Among the three categories of errors due to naive
Step 2. Now, we apply pseudo real-world modeling to
real-world modeling (actually, genuine real-world
the original world. De®nition 2 guides us to identify
modeling), Categories 1 and 2 are less signi®cant in that,
customer, cash card, ATM, account and transaction
when we ®nd some erroneous classes belonging to them
classes because the business to be automated deals with
in the course of analysis and design, we can simply de-
information about the entities corresponding to them.
lete them without giving much in¯uence on other part of
(Apparently, customer, cash card, and ATM classes are
the class diagram. (It is needless to say that a modeling
identi®ed again, but actually these three classes are
technique that allows unnecessary classes to creep into
identi®ed here for the ®rst time; those identi®ed in Step 1
class diagrams should not be adopted.) On the other
are actors.) Then, we identify associations between the
hand, Category 3 errors are more signi®cant in that they
classes. Let us call the class diagram obtained ``partial
give much in¯uence on the structure of class diagrams
class diagram B'' (which is equivalent to the encircled
and that it is less easy to ®nd them.
part of the class diagram in Fig. 6).
Step 3. As partial class diagrams A and B have the
4.2. Example 2 customer, cash card and ATM classes in common, each
of the three classes are united into a single class and we
We need three full steps for this example. obtain the class diagram shown in Fig. 10.
Step 1. The automated real world shown in Fig. 5 Now, let us review the class diagram. Associations
contains customers, cash cards, ATMs, and a banking with italicized names are unnecessary associations de-
system, and we have a class diagram (Fig. 9) consisting rived from the associations between the customer, cash
of classes representing these entities. Let us call it card, and ATM classes in Fig. 9 (Category 3 errors).
These errors originate from genuine real-world model-
ing performed in Step 1. That is, the merging performed
in Step 3 itself is misleading, but it does not add to
modeling errors. This is because Step 2 does pseudo real-
world modeling, which is correctly applied to the ATM
problem. Therefore, what is wrong with naive real-world
modeling resides in Step 1.
5. Discussion
5.1. Modeling a cyber world
We know that class diagrams made by real-world
Fig. 9. Partial class diagram A. modeling may be used to develop simulation or businessS. Isoda / The Journal of Systems and Software 59 (2001) 153±162 161
assistance applications (Usages 2 and 3). Both of these In fact, no small amount of literature on object-ori-
categories of applications deal with the real world; the ented analysis teaches us to perform wider-scope mod-
former simulates entities of the real world, and the latter eling and hence it supports the claim. Shlaer and Mellor
automates business in the real world. In addition to (1988) state an object identi®cation process, telling us to
these, we have other applications that do not directly ``start at the center of the problem domain until you
deal with the real world. Examples of these are utility have objects that are at least one layer outside of the
programs such as text editors, graphic editors, and scope of the system to be built''. Rumbaugh et al. (1991)
compilers. Then, how can we make class diagrams to practically model a system together with its environment
develop these applications? in their bank ATM problem. Hoydalsvik and Sindre
Take a graphic editor as an example. It deals with (1993) propose to draw a boundary line on a class dia-
graphics, icons, windows, ®les, etc. We can assume that gram, encircling the region to be automated to divide
these entities (we de®ned an entity as a real thing or an classes into those in the system and those outside.
idea in Section 2) constitute a cyber world on a com- Before discussing this claim, let's review the process
puter. Then, because the entities are of themselves in- of drawing data ¯ow diagrams based on structured
formation and because each class in a class diagram is a analysis. It consists of the next four steps (Yourdon,
representation of information, we can make a class di- 1989).
agram by simply modeling the cyber world as it is. This Step 1. Model not only the business to be automated
means that we can apply genuine real-world modeling to but its environment to draw an initial data ¯ow
a cyber world. diagram.
To sum up, we can say that genuine real-world Step 2. Classify processes (bubbles) of the initial
modeling is natural in that it does not concern itself with data ¯ow diagram into those to be automated and
whether the target world is real or cyber and that it those performed by people or other systems.
models a target world as it is. Therefore, it is appro- Step 3. Draw a context diagram consisting of a large
priate to rename it ``natural modeling''. Pseudo real- circle and some squares surrounding the circle. The
world modeling, on the contrary, is special in that its circle represents the processes to be automated as a
target is restricted to the real world and is only used for whole, and each square represents an actor.
developing an application that automates business in the Step 4. Re®ne the context diagram stepwise to con-
real world. Table 1 summarizes the dierences of the two struct a hierarchy of data ¯ow diagrams.
modeling methods. That is, the two modeling methods Now go back to Modeling rule 1. The argument
dier in what is the target, what can be identi®ed as a about Modeling rule 1 is dissolved when we notice the
class, what operations can be assigned to a class, and to dierence between the models made by structured
what uses they can be applied. analysis and those made by pseudo real-world modeling.
That is, because each bubble in a data ¯ow diagram
represents a function, a boundary line drawn on the
5.2. Modeling the system together with its environment diagram divides functions into those in the system and
those outside, and outside functions that are directly
Some software engineers who are familiar with the adjacent to the boundary line become the functions of
structured analysis methodology may argue against actors. That is, a boundary line on a data ¯ow diagram
Modeling rule 1, claiming that, in the case of object- de®nes the system interface, and therefore wider-scope
oriented analysis, we should ®rst model a target business modeling allows us to design system interface. This is the
together with its environment and then delete unneces- merit of wider-scope modeling in the case of structured
sary classes, just like we have been doing with the analysis, and therefore it is valid and useful.
structured analysis methodology. Let us call this pro- In the case of pseudo real-world modeling, the situ-
cess, in short, ``wider-scope modeling''. ation is dierent. When we apply pseudo real-world
Table 1
Summary of the two object-oriented modeling methods
Modeling method Target world What can be a class What operations can Usage
be assigned
Genuine real-world Real or cyber Entity Functions of (1) To facilitate understanding of a
modeling world an entity problem in the real world
(Natural modeling) (2) To develop an application that
simulates the real world
(3) To develop an application that deals
with a cyber world
Pseudo real-world Real world Information about (Depends on To develop an application that auto-
modeling an entity design) mates business in the real world162 S. Isoda / The Journal of Systems and Software 59 (2001) 153±162
modeling to the original real world, we select from the plications is naive real-world modeling whose real na-
world those entities that the system to be automated ture is a mixture of genuine and pseudo real-world
deals with and then make classes corresponding to them. modeling methods. This lures naive analyzers who be-
In other words, we model the whole original world se- lieve the literature into severe modeling errors when they
lectively. If we should make a class corresponding to an develop business assistance applications.
entity that the system does not deal with, the class would
be just an unnecessary class contained in the class dia-
gram; it never exists outside of the class diagram. References
Therefore, wider-scope modeling does not provide the
merit of designing system interface, but it rather brings Ambler, S.W., 1998. The Object Primer. Cambridge University Press,
Cambridge, UK.
us the demerit of making unnecessary classes and then Beck, K., Cunningham, W., 1989. A laboratory for teaching object-
deleting them. oriented thinking. In: Proceedings of OOPSLA'89, pp. 1±6.
Further, we have a positive reason for not applying Booch, G., Rumbaugh, J., Jacobson, I., 1998. The Uni®ed Modeling
wider-scope modeling to pseudo real-world modeling. A Language User Guide. Addison-Wesley, Reading, MA.
natural process of identifying classes is ®rst drawing a Borgida, A., Greenspan, S., Mylopoulos, J., 1985. Knowledge repre-
sentation as the basis for requirements speci®cations. IEEE
class diagram consisting of those classes that are clearly Computer 18 (4), 82±91.
necessary, and then incrementally adding ones found Douglass, B.P., 2000. Realtime UML Second Edition: Developing
during the analysis and design process. This is possible Ecient Objects for Embedded Systems. Addison-Wesley, Read-
because adding a class means making its internal ing, MA.
structure more concrete. Gossain, S., 1998. Object Modeling and Design Strategies. Cambridge
University Press, Cambridge, UK.
It is true that, in the requirements elicitation step of Hoydalsvik, G.M., Sindre, G., 1993. On the purpose of object-oriented
developing a business assistance application, we some- analysis. In: Proceedings of OOPSLA 93, pp. 240±255.
times apply wider-scope modeling to make a class Jacobson, I., Christerson, M., Jonsson, P., Oevergaard, G., 1992.
diagram (call it a context class diagram) as stated in Sec- Object-Oriented Software Engineering ± A Use Case Driven
tion 2. The purpose of the context class diagram, however, Approach. Addison-Wesley, Reading, MA.
Kruchten, P., 1998. The Rational Uni®ed Process: An Introduction.
is not to directly serve as a design document for software Addison-Wesley, Reading, MA.
development. Rather, it is to facilitate our understanding Martin, J., Odell, J.J., 1992. Object-Oriented Analysis and Design.
of the problem: context class diagram represents the Prentice-Hall, Englewood Clis, NJ.
world where the business assistance application works McGinnes, S., 1992. How objective is object-oriented analysis?. In:
(i.e., the automated real-world in Fig. 2). Proceedings of CAiSE'92, Manchester, UK, pp. 1±16.
Object Management Group, 1999. OMG Uni®ed Modeling Language
Speci®cation. version 1.3, http://www.rational.com/uml/resources/
index.jtmpl/.
6. Conclusion Rosenberg, D., 1999. Use Case Driven Object Modeling with UML ±
A Practical Approach. Addison-Wesley, Reading, MA.
This paper shows that object-oriented modeling Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W.,
1991. Object-Oriented Modeling and Design. Prentice-Hall, Engle-
consists of two kinds of methods, namely the genuine wood Clis, NJ.
and pseudo real-world modeling methods. Genuine real- Rumbaugh, J., 1995. OMT: The development process. J. Object-
world modeling is used for: (1) representing the real Oriented Programming 8(2), 8±16; 76.
world in a class diagram without any intention of de- Rumbaugh, J., Jacobson, I., Booch, G., 1999. The Uni®ed Modeling
veloping an application based on the diagram, (2) de- Language Reference Manual. Addison-Wesley, Reading, MA.
Shlaer, S., Mellor, S.J., 1988. Object-Oriented Systems Analysis:
veloping a simulation program, and (3) developing an Modeling the World in Data. Yourdon Press, Englewood Clis,
application that deals with entities of a cyber world on a NJ.
computer. Genuine real-world modeling is natural and Wirfs-Brock, R., Wilkerson, B., 1989. Object-oriented design: A
allows us to simply model the target world as it is, be it responsibility-driven approach. In: Proceedings of OOPSLA'89,
real or cyber. Another kind of modeling method is pp. 71±75.
Wirfs-Brock, R., Wilderson, B., Wiener, L., 1990. Designing Object-
pseudo real-world modeling. It is used for developing a Oriented Software. Prentice-Hall, Englewood Clis, NJ.
business assistance application and allows us to make a Yourdon, E., 1989. Modern Structured Analysis. Prentice-Hall,
model of the information about the entities the business Englewood Clis, NJ.
handles by viewing the real world. These two modeling Sadahiro Isoda is a Professor of Toyohashi University of Technology.
methods have to be appropriately applied according to He holds an M.Sci. in Physics and Ph.D. in Information Science both
from The University of Tokyo. From 1978 to 1979 he was a visiting
their target problems. sta member at the Department of Computer Science, University of
This point, however, has not been suciently recog- Illinois, Urbana. His research interests are in the area of software
engineering, especially design methodologies, object-orientation, soft-
nized. In the literature on object-oriented methodologies ware reusability, metrics, project management, and human factors. He
and techniques, many authors teach us to model the chaired the Special Interest Group on Software Engineering of Infor-
mation Processing Society of Japan (IPSJ) from 1993 to 1997. He has
real-world as it is without considering the type of target also played many active roles in the international research activities.
problems. What they apply to business assistance ap- Dr. Isoda is a senior member of IEEE.You can also read
