Propuestas de Mejora

In a nutshell

We always seem to extend the scope of our systems, and even the object models are frequently too complex to be comprehended by our limited brain capacity. The OOram technology provides abstractions that help us to divide and conquer, enabling us to handle complex phenomena in a controlled manner. We analyze different parts of a phenomenon to create simple role models, and understand each of these models separately.

Complex models are constructed from simple ones in a controlled and consistent manner. This construction, called synthesis, permits us to reuse proven models in a variety of contexts. The advantages of reuse are threefold. First, reuse reduces development cost and lead time. Second, the reuse of tested models in a controlled environment increases total quality. Third, critical phenomena can be protected by the mandatory access through validated models; thus ensuring system integrity. The main disadvantage is probably the danger of blindly building on old models, thereby loosing the fresh outlook and creativity needed to discover new insights.

As we have stressed earlier, our first approach to a new problem is to focus on its essential aspects and postpone all the trivial parts to later stages in the development. The principle of minimizing risk

(FOOTNOTE: See section 4.3) suggests that we start with the parts we expect will be the hardest to get right, and continue with other parts as the harder ones get resolved. We might begin by sketching out the work flow in the organization, or creating a high-level model of the information requirements, or making a small user interface prototype, or studying high-level state machine models showing essential states and transitions in critical processes.

We may create solution islands

Many authorities recommend an orderly progression from the abstract to the concrete; create the first models on a high level of abstraction and then fill in details as work progresses. We find this excellent advice not always easy to follow, because we often have to start with some low level problem due to its high risk.

29 March 1995 23:05 3.2 The synthesis operation

Whatever our work process, we will end up with many different models describing different aspects of the problem and its solution. There will be overview models on a high level of abstraction, and low level models showing the details of a bounded part of the problem. We do not want to extend an overview model with more and more details until we get a huge model containing everything; we want to retain the overview model and to supplant it with auxiliary

descriptions of the various details.

We think in a number of distinct models, each having its own unique area of concern and representing a part of the whole.

We need many models

All our different models show different aspects of the same overall phenomenon; they are strongly linked to this common phenomenon. The models are not orthogonal, but are highly dependent because the same objects often appears in several models. We support the ideas of traceability and seamless descriptions, so that whenever we observe some information in one model, we will be able to link it to any other description of the same thing -- whether in a different model on the same level of abstraction; or in another model on a different

abstraction level.

We need seamless model interdependencies

Subclassing used for concept building and for code sharing

Inheritance is used in object-oriented programming for two different purposes: concept building and code sharing.

When concept building, we subclass a given superclass because the concept represented by the subclass is a specialization of the concept represented by the superclass. Instances of the subclass will have all the attributes of the superclass and understand all the messages understood by the superclass in addition to possible attributes and messages defined in the subclass.

In Objectworks\Smalltalk for example, class VisualComponent defines objects which can be made visible on the computer screen. The VisualComponent subclass TextLines represent lines of stylized text; instances of TextLines understand all the VisualComponent messages, in addition to messages which manage their text attributes. When code sharing, we subclass a given superclass quite simply because it contains useful code. All the messages defined in the superclass need not be meaningful in the context of the subclass. For example, the Objectworks\Smalltalk class Collection defines a message (at: index) which gives indexed access to its contents. Class

3.2 The synthesis operation 29 March 1995 23:05

Set is a subclass of Collection. An instance of class Set contains an unordered collection of elements that are not duplicated. Indexed access to sets is meaningless and therefore prohibited. Most of the Collection code is useful in Set, and the decision to make class Set subclass of Collection was one of expedience rather than a

consideration of abstract concepts. We regard code sharing as a useful and legitimate use of class inheritance in programming, as long as we make it quite clear what we are doing.

We could similarly synthesize an OOram base model into a derived model because the base model contained useful constructs. But the purpose of OOram models is to enhance our understanding of a phenomenon, and we insist that synthesis is used for the synthesis of concepts.

Synthesis only used for concept building

Role modeling and synthesis apply common sense to objects

An object model is a simulation of the phenomenon it represents; its objects enact the phenomenon. It is common sense that if we want to isolate certain aspects of the phenomenon, we correspondingly isolate the relevant aspects of the objects which enact them, and we describe their role in the context of the studied aspects.

It is also common sense that if we want a structure of objects to simulate several phenomena simultaneously, we let its objects play the roles which describe these phenomena.

Analysis and synthesis are the two operations which enable us to zoom in and out in our study of the complex world around us. The separation of concern and object playing multiple roles by synthesis makes it possible to describe systems of any size with OOram role models.

Consider an extremely complex system with an enormous number of objects, such as the total system of an enterprise integrated with the systems of all its suppliers and customers. We can still isolate any phenomenon and study it as a role model, and we can still describe any composite phenomenon by creating a role model synthesized from the models of its parts.

OOram models describe systems of any size

We might be tempted to consider all our interdependent models as being parts of a single, global model. We could create this global model by starting with any model and recursively adding all models that are related to it. The global model would in many ways resemble the global conceptual schema used in database technology, and the individual models would be similar to the external schemas.

No global model needed

3.2 The synthesis operation 29 March 1995 23:05

©Taskon 1992. Page 117 Role model synthesis

We do not believe the idea of a global model is a fruitful one. We believe that everything in the real world somehow depends on everything else, so that a truly global model would be very large indeed and impossible to create or manage. Our definition of a system on page 61?? reflected this: a system is something we choose to consider as a whole during some period of observation, and a system has an environment which links it with the rest of the world without including the rest of the world in the system. Remember that we could not include the environment objects in our system, because we then ended up modeling the whole universe.

Finding the models We end this introduction to synthesis with the $64,000 question: How

do we find the models, i.e., how do we determine that we should factor out a base model or merge several models into a larger one? There are no hard and fast rules, but we will endeavor to give a few loosely formulated guidelines. Behind these guidelines is the fortunate fact that this is an area where the good systems analyst can

demonstrate his or her excellence.

It is commonly believed that our short term memory can manage 7 ± 2 notions at the same time. So we suggest the guideline that a role model should consist of 7 ± 2 roles. We should search for

subphenomena to be factored out from models that are substantially larger than this. We should also search for common base models that can be synthesized into several derived models, or several times into the same model.

Conversely, we should consider merging models which contain less than five roles. Models that are used several times are exceptions to this rule -- such as the client-server models which contain just two roles in their basic form but which may be synthesized into many different derived models.

A model may depend on other models in many different ways.

Generalization-specialization is an important model relationship: one

model describes a general phenomenon, while other models describe its specializations. A general model could, for example, describe how we make important decisions in our organization. Two different specializations of this model could describe how we create a budget or how we establish a major project. (FOOTNOTE: The creation of different kinds of reusable components will be discussed in chapter 5:

Creating reusable components.) Many different model

relationships

29 March 1995 23:05 3.2 The synthesis operation

Role model synthesis ©Taskon 1992. Page 118

Another important model relationship is aggregation: what is

described as a single role on one level of abstraction is expanded into a model with several roles on the next level of detailing.

A third, very interesting model relationship is the object-subject

relationship: the universe of discourse (object attributes and message

parameters) in a role model may be specified as the roles of another role model.

OOram synthesis The Webster dictionary defines synthesis: "synthesis 1a: the composition or combination of parts or elements so as to form a whole c: the combination of often diverse conceptions into a coherent whole" [Webster 77].

We represent model relationships with the very general notion of role

model synthesis, where we specify that individual objects shall play

several roles, possibly from different role models.

We say that the base model is synthesized into the derived model. This is achieved by synthesizing every base role in the base model into a corresponding derived role in the derived model.

The concept of synthesis is as important to OOram role modeling as the concept of inheritance is to object oriented programming. In both cases, we specify that some objects shall, in some sense, be similar other objects. The main difference is that while object-oriented programming focuses on the relationship between individual classes of objects; OOram synthesis focuses on the relationships between complete patterns of objects.

The idea of objects playing multiple roles has a clear parallel in the theory of organizations: a person typically plays multiple roles such as a subordinate in a department, a member of a project, a traveler in the context of travel expenses.

Consider the file transfer protocol example of figure 2.17 on page 78??. The figure describes two models: a Client-Server model and a Source-Destination model.

We are now in the position to design three different systems by using these two models as base models and synthesizing them into three different derived models. Figure 3.16 shows a system where the Client can send files to the Server; figure 3.17 shows a system where the Client can retrieve files from the Server; and figure 3.18 shows a system where the Client can send and retrieve files to and from the Server.

Objects play multiple roles

29 March 1995 23:05 3.2 The synthesis operation

©Taskon 1992. Page 119 Role model synthesis

dst src dst src rsp int Source Client Destination Server Client Server Source Destination

Client-Server base model

File transmit derived model

Source-Destination source model

Figure 3.16 A system where the Client can send files to the Server dst src rsp int rsp int Destination Client Source Server Client Server Source Destination

Client-Server base model

File retrieve derived model

Source-Destination source model

Figure 3.17 A system where the Client can retrieve files from the Server

29 March 1995 23:05 3.2 The synthesis operation

Role model synthesis ©Taskon 1992. Page 120

Figure 3.18 A system where the Client can send and retrieve files dst src dst dst rsp int Send/receive Client Send/receive Server Client Server Source Destination

Client-Server base model

Source-Destination base model File send/receive derived model

A base model may be repeatedly synthesized into a derived model. Figure 3.19 shows a role model for a tree structure. The base model marked (a) describes a basic tree consisting of a Mother role and a Child role. A Child has one and only one Mother, while a Mother can have any number of Child objects, even none.

The Mother may ask her Child to execute a block of code recursively, either executing the code before traversing the subtree (

preorderTraverse) or after (postorderTraverse). The Mother may also ask her Child for all tree leaves (getLeaves). The Daughter may ask her Mother for the root of the tree, in this case it is the Mother herself. Figure 3.19 (b) shows a three level tree with roles Root, Node and Leaf. This is a derived role model; it was created by synthesizing the basic tree model twice. First, the Root and Node roles are specified to play the Mother and Child roles respectively. Second, the Node and Leaf roles are specified to play the Mother and Child roles. A Root object will now play the Mother role; a Node object will play both the Child and the Mother role; and a Leaf object will play the Daughter role.

We see that the interfaces of the derived model are simply inherited from the base model, and it is not necessary to repeat the specification in the derived model. Further, if the base model had been

implemented as the classes Mother1 and Child1, the implementation of the derived model could exploit this by deriving its classes from the base classes.

Base models may be applied repeatedly

29 March 1995 23:05 3.2 The synthesis operation

©Taskon 1992. Page 121 Role model synthesis

Figure 3.19 The creation of a composite tree dw up dw up dw up Child<Mother getLeaves postorderTraverse: preorderTraverse: Child<Mother getLeaves postorderTraverse: preorderTraverse: Child<Mother getLeaves postorderTraverse: preorderTraverse: Root Mother<Child getRoot Mother<Child getRoot Mother<Child getRoot Node Leaf Mother Child (a) Base model (b) Derived model Synthesis applies to whole role models

Synthesis is an operation on role models, not single roles. The argument is that if we extend the services offered of one object, we must also extend some other object to make it utilize the new functionality. We do not know the exact nature of these objects; but we do know that they will play the appropriate roles. So when we specify that Root plays the role of Mother, we immediately ask: Who plays the corresponding role of Child? Figure 3.19 shows two

synthesis operations, not four.

The notation for synthesis is a set of bordered arrows connecting base roles to corresponding derived roles. The first synthesis operation is marked with white arrows in figure 3.19, the second with colored arrows.

The ideas of role model analysis and role model synthesis give us two independent dimensions in the description of systems of interacting objects. This is illustrated abstractly in figure 3.20.

Two-dimensional modeling

Integration within a role model is achieved through collaborator interaction.

1.

Integration between role models is achieved by letting an object play several roles. An interdependency between two roles played by the same object is described in a method. The method is triggered when the object receives a message in the context of one role; it may send messages and thus trigger activities in the context of another role. The method could also change an attribute which is defined in the context of another role.

2.

29 March 1995 23:05 3.2 The synthesis operation

Role model synthesis ©Taskon 1992. Page 122

Horizontal integration (Analysis):

Collaborator interaction within Role Model.

Vertical Integration (Synthesis):

Message

triggers Method

which sends (stimulus) Message or changes Attribute

Figure 3.20 Two- dimensional modeling

The purpose of role model analysis is to understand a phenomenon and specify its possible implementation. We spend considerable effort to persuade ourselves and others that the model is a faithful and correct representation of the phenomenon, and that the

implementation will fill our needs and be without serious flaws.

We want to retain base model correctness in the derived model

Assuming that a base model is correct in all the aspects we care to consider, we would like this correctness to be retained in a model that is derived from it by synthesis so that we do not need to repeat the correctness considerations. We will distinguish between three kinds of correctness:

That the derived model conserves the static correctness of the base model.

1.

That the derived model conserves the dynamic correctness of the base model.

2.

That the derived model correctly reflects the semantics of the base model.

3.

Static correctness can be retained automatically

It is fairly easy to create an OOram tool that conserves static correctness through a synthesis operation. Specifically:

All roles in a base model are mapped onto corresponding roles in the derived model.

1.

The attributes of the base roles are retained as attributes of the corresponding derived roles.

2.

3.2 The synthesis operation 29 March 1995 23:05

All ports in a base model are mapped onto corresponding ports in the derived model. The cardinalities of the ports in the derived model must be consistent with the cardinalities of the

corresponding ports in the base model: the minimum cardinality of a derived port may be equal to or greater than the minimum cardinality of the corresponding base port, and the maximum cardinality of a derived port may be equal to or less than the maximum cardinality of the corresponding base port.

3.

4. All interfaces defining the messages that are permitted to be sent from a base port are retained as identical interfaces defining