Divide and conquer Systems consisting of relatively few objects may often be described in
a single role model, but many practical object structures will be too large and complex to be comprehended as a single model. We then identify different concerns, which are covered by the system, and analyze each of them separately. We divide the whole into
manageable parts and conquer each part with an appropriate model. If the whole is simply the sum of its parts, we have also conquered the whole. If not, we may use OOram synthesis to create derived models which describe the dependencies. OOram synthesis will be the theme of chapter 3. For now, we will continue our studies of the use of isolated role models.
29 March 1995 23:05 2.3 Modeling with roles
The Internet as a huge structure of objects
We will use the Internet as an example of a large object structure. The Internet connects several million computers. Its is typical of the distributed nature of Internet that nobody knows the exact number. As seen from the Internet, the connected computers appear as objects: they have identity, they are encapsulated, and only interact by sending messages to each other.
The Internet is used for a wide variety of purposes. Some are well known and some are only known within their user community. We believe it is an early example of the information systems of the future; it is not a designed system, but has evolved as many different people have made their contributions. The whole is not known to anybody, and would exceed our mental capacity even if we had access to all relevant information. We can, however, select any activities we may be interested in; identify the objects that take part in the activities; idealize them into roles; and describe the activities to any desired detail.
Concern: The FTP As an example, let us select the wellknown network File Transfer
Program, FTP. The interaction between the FTP participants is based on the Arpanet standard File Transfer Protocol, which allows the transfer of files between two remote computers. Two objects are involved as indicated in the top model of figure 2.17. The first takes the initiative and controls the activities; this object plays the Client role. The other is a provider of services; this object plays the Server role. Some objects (computers) are only able to play the Client role; other objects are only able to play the Server role; and some objects are able to play both roles. The abstraction from object to role permits us to ignore these complications and create a "pure" model where each role has a single purpose. The role model is illustrated in figure 2.17 (a).
2.3 Modeling with roles 29 March 1995 23:05
Given the Client and Server roles, we can now study how they perform various activities. In one activity, the Client identifies itself by name and password to the Server so that the Server can establish the appropriate privileges. Another activity permits the Client to navigate in the Server's file directory hierarchy. A third activity permits the Client to specify operations on the "current file directory". The FTP standards for these activities do not interest us here. The point is that we can describe each activity as an interaction process involving the Client and Server roles. Each activity will start with a stimulus message from the Client, and will result in a response in the form of appropriate changes in object attributes or some final
termination message. A change directory stimulus message results in a change in the Server's currentDirectory attribute. A list directory stimulus message results in a termination message to the Client that contains the list.
Client-Server activities
Figure 2.17 Two independent role models describe the FTP file transfer service
dst src
rsp int
Source Destination
Client Server (a) FTP Client-Server model
(b) Data transfer model
The main purpose of FTP is to transfer files between the connected parties. Files may be transferred from the Client to the Server or from the Server to the Client. We combine these two cases by defining file transfer as being the transfer of a file from an object playing the Source role to an object playing the Destination role. This is illustrated in figure 2.17 (b).
We normally want to be able to transfer files in both directions; the Client and Server objects then need to be able to play both the Source and the Destination roles. We could alternatively define a system of objects that only permitted file transfer in one direction; a Client which could only play the role of Destination would be more secure than the general Client, since it would be unable to export files to other destinations.
The initiative for a file transfer is taken by the object playing the Client role, and the choice of roles actually played at any given time by that object depends on the direction of the desired transfer.
Concern: Transferring a file
29 March 1995 23:05 2.3 Modeling with roles
The transfer of a file causes a fairly complex interaction between Source and Destination. The Source has to split the file into
transferable chunks that have to be reassembled in correct sequence in the Destination. The Source has to add redundant data to the chunks so that the Destination can check that the chunk has been transferred correctly. Protocols have to be established between Source and Destination to control the flow of data and to ensure retransmission of incorrect chunks. All this can be studied in the role model
independently of which objects play the roles of Client and Server; and which objects play the roles of Source and Destination.
File transfer activity fairly complex
The above example illustrates two points about role modeling. The first is that we need to see the involved objects if we want to describe how a structure of objects performs its duties. The second is that separation of concern is a powerful way of separating a complex situation into simple components. We could have created an object model with two objects: one playing the roles of Client, Source and Destination, the other playing the roles of Server, Source and
Destination. This derived model would be more complex and harder to understand than the two simple models of figure 2.17, and the combination of the two essentially separate functionalities would not in any way add to the value of the model.
Separation of concern a powerful simplifying device