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