Analysis of Trading Packages in Trading Business

To fully understand this analysis, you will need to read Analysis of Exchange Trading first.

Developing large information systems presents particular challenges. The fundamental way to deal with a large-scale system is to decompose it into smaller systems. This requires some form of architectural modeling.

The first organizing tool of any information system is the layered architecture. This architecture identifies many of the package divisions of the system. In a larger system, however, the domain model becomes too large for a single package. This section looks at how we can split a large domain model. The concepts of package and visibility are again deployed as the basic tool for the division. The trading concepts of Analysis of Exchange Trading provide the examples.

The first pattern looks at how to organize the models of scenarios and portfolios. The main problem is that of multiple access levels to a Package (Section 1). A risk management application uses scenarios to get the information needed to value portfolios. Another application needs to set up and manage scenarios. Both applications need access to the scenario types, but they need very different levels of access. Different clients needing different interfaces is a common problem. Solutions include allowing a package to have multiple protocols and using different packages.

The relationships between contracts and parties raise the problem of Mutual Visibility (Section 2). Three solutions suggest themselves: a one-way visibility between contract and party, putting them both in the same package, or putting them in separate mutually visible packages.
All three solutions have significant disadvantages.

The final pattern explores Sub-typing Packages (Section 3) by considering how to position the derivatives discussed in Analysis of Derivative Contracts onto the package structure. This pattern illustrates that sub-types can be placed in a package separate from their super-types with visibility from the sub-type to the super-type.

1. Multiple Access Levels to a Package

Portfolios are constructed from contracts using market indicators as descriptions. Scenarios are used independently to develop prices for market indicators. Portfolios and contracts need to use scenarios to value themselves, but scenarios do not need any knowledge of portfolios and contracts, as shown in Figure 1.


Figure 1. An initial picture of package visibilities.

To carry out valuations, a portfolio only requires the price of a market indicator. The portfolio package does not need to know how the scenario is set up. Thus, although the scenario element type needs to be visible to the portfolio so the getQuote message can be sent, there is no need to see the sub-types with the definition of how the quote is formed. Indeed we can go further and say that even the scenario element is not useful to the portfolio. A better approach would be to present the interface to the portfolio as shown in Figure 2. This interface has a keyed mapping on the scenario, which takes a market indicator as an argument. Since no other properties of the scenario element are important, the interface for the portfolio package is simple.



Figure 2. An interface for the scenario package that hides scenario elements.
This is the best interface for the portfolio package, which does not need to know about scenario elements.

This approach requires two different types of scenario package: one for the interface to portfolio and another for setting up scenarios. Thus something more than a simple assignment of types to packages is needed. The immediate and obvious approach is to divide the types in the scenario package into public and private types in the package. Public types are those visible to other packages that have a visibility into the scenario package (such as portfolio). Private types are only visible to types within the scenario package. In this case the scenario is a public type and the scenario element is a private type. This logic can be extended to operations. Public operations can be public within a package and public to other packages. Although this represents a fine degree of control, it can be too difficult to maintain. The art of good visibility design is to choose a degree of visibility that is fine enough to be useful but not so fine as to make the portfolio a nightmare to manage. (Things that are difficult to manage tend not to be managed, which leads to out-of-date, useless models.)

One problem with this approach is that users need software to set up and manipulate scenarios. This requires components at the application logic and presentation layers. Thus the model must include a scenario management application package that is separate from the scenario package. Figure 3 shows the addition of a scenario management application package and a risk management application package. This approach would not work with the public/private approach described above, however, because the scenario management application requires the private types of the scenario package. Although both portfolio and scenario management require visibility of the scenario package, they need different types of visibility.

One solution to this problem allows a package to have more than one protocol. (Wirfs-Brock uses the term "contract" which is confusing in this example, so we use "protocol").
In our original pattern, we set up a protocol as a set of operations; however, it is quite reasonable to make it merely a set of types to allow simpler control of visibility. Using separate protocols results in a diagram such as Figure 4, in which the scenario has two protocols: The one used by the portfolio permits only the small protocol, while the scenario management application uses the deeper protocol. The protocols are shown by semicircular ports on the package box. (I'm only showing ports on packages with more than one protocol.)



Figure 3. Adding application packages to Figure 1.
The problem with this is that the scenario management application needs a much larger interface to the scenario package than the portfolio package needs.



Figure 4. The packages of Figure 3 with protocols.
Each protocol implies a separate interface.

Using separate protocols is one way to deal with the multiple visibility issue. Another is to introduce an extra package, as shown in Figure 5. The scenario element and its sub-types are moved from the scenario package into the scenario structure package. The scenario package contains only the scenario type and its simple associations.



Figure 5. Using an extra package for the scenario structure.

The portfolio package has visibility only into the scenario package, while the scenario management application sees both the scenario and the scenario structure package. We can define new scenarios with the extra visibility.

A question that might occur to the attentive reader is whether the scenario needs to have visibility to the scenario structure. Responding to a request for a quote requires use of the internal structure. An intriguing aspect of inheritance and polymorphism manifests itself in these visibilities. The scenario package can contain a scenario class that defines the interface required by all packages with visibility to the scenario. However, this scenario class need not implement all of the interface (and thus is abstract).
We can place a second scenario class in the scenario structure package that implements the interface. This second scenario class has full visibility to the contents of the scenario structure. Any scenario object used by another package is an instance of the scenario structure's scenario class, but those clients of the class do not realize it. All they see is an object that conforms to the interface of the scenario package's scenario class. It may be worth providing a notation to show where this kind of subclassing occurs across package boundaries, although we don't use one.

So when an object in the portfolio package sends a message to a scenario, it is actually sending a message to an instance of the concrete scenario class that lies in the scenario management package. However, the caller thinks it is calling an instance of the abstract scenario class that lies in the scenario package. An object can send a message to an object in a package it cannot see, providing the called object is a subclass of a class in a package the calling object can see.

A consequence of this is that visibilities do not reflect compilation or load dependencies. Although the scenario structure is not visible to the scenario, the scenario needs the scenario structure to function (strictly speaking, it is dependent on some package that implements the interface).
The scenario structure contains the concrete subclasses of the scenario without which the scenario package cannot work.

Although two different scenario classes are needed in this scheme, they may conform to a single scenario type. In this case a new sub-type is provided to allow access to the internal structure of a scenario for applications such as scenario management. It is possible to have a single type, however, when other types do not need to call special features only present on the sub-type.

2. Mutual Visibility

Adding packages for contracts and parties raises more complex issues. With scenarios and portfolios, separate packages were used for two reasons. First, scenarios and portfolios seem to be separate lumps of the model. They are themselves complex sections that seem to make a unit of labor. Second, we do not need any knowledge of portfolios to construct a model of scenarios. The second reason is the strongest because it leads to the visibility relation-ships shown in Figure 1.

It is reasonable to conclude that contracts can be put together and modeled without a knowledge of portfolios. Contracts can be recorded independently of the dynamic structure of the portfolio used to group them together for risk assessment purposes, as shown in Figure 6.


Figure 6. Packages for portfolio and contract.
The risk management application needs both packages, but the pricing application only needs to know about contracts.

The relationships between parties and contracts are a greater problem. We can make an argument for placing a party in its own package. A number of applications might look for information about parties without wanting to know anything about the deals being carried out with them. A common party package might hold common information about parties used by many dealing systems, rather like a contact database. Thus we can conclude that a party package is valuable.

What would be the relationship between the party and contract packages? It would be valuable for a party to tell which contracts were dealt with it, and for a contract to tell who the parties for the contract were. This implies mutual visibility between a party and a contract, as shown in Figure 7. But mutual visibility may cause problems in a package model. On the whole we try to design package models with a layered architecture and simple lines of visibility. Many people believe such an architecture should never have cycles in visibility relationships, because a cycle breaks the rule of clear layers. Mutual visibility is the simplest case of a cycle.


Figure 7. Separate party and contract packages.

Some applications need only one of either the party package or the contract package, but both of these packages need each other. This can imply mutual visibility. If mutual visibilities are unacceptable, we can choose a single direction or combine the packages.

To remove mutual visibility we must either alter the features of party or contract so that only one knows about the other, or combine them into a single package. Each alternative has trade-offs.

The benefit of restricting the visibility between the party and contract types to one direction is that it decreases the coupling between the two types (and their respective packages). If we remove the mappings from party to its contracts (making the association one-way) we can work on the party package without needing to know anything about contracts. This reduces the coupling (the party is no longer coupled to the contract, which is an advantage. However, a user who wants to know which contracts a particular party is the counterparty for must look at every contract and use the mappings to the party to form the set. Thus we have reduced the complexity for the developer of the party package but increased the complexity for the developer of any application that needs to use both types. There is no absolute right answer here; we have to look at the trade-offs in each direction and decide which choice is the lesser burden.

Modeling Principle: The decision between a one-way and two-way association is a trade-off between less work for the developers of the types involved (by reducing their coupling) and convenience for the users of the types.

Assuming we decide in favor of the two-way association, our only route to eliminating the mutual visibility is to combine the party and contract packages. This is not free of disadvantages, however. In Figure 7 we can see the contact management package only needs to know about parties, not contracts. Combining these two packages would remove this information. Contact management would be forced to have greater visibility than it needs to have.

This situation leads us not to ban mutual visibilities or other cycles. Certainly cycles should be reduced to the minimum. Eliminating them completely, however, leads to either forcing the trade-off between one-way and two-way associations or large packages whose clients do not need all the visibility that is implied.

Modeling Principle: If a package only needs visibility to part of another package, consider splitting the latter package into two mutually visible packages.

Figure 8 shows another example of this situation. The product (see Analysis of Derivative Contracts, Section 3) is added in its own package.
The preceding arguments lead to the mutual visibilities among product, party, and contract. This leads to fairly coupled domain model packages. The application packages, however, need to see only parts of the picture, and each application package has slightly different needs. The three mutually visible packages allow us to be clear on these needs.

Another way of doing this puts protocols on packages. Then the party, product, and contract packages are combined and three separate protocols are provided to correspond to the old packages. Applications then select the protocols in the same way that they select the packages shown in Figure 8.



Figure 8. Adding a product to the package.
Again different application needs may be served by mutually visible packages.

To summarize, when types are naturally closely coupled, we have three options. We can decouple the types by making the associations one-way (but this makes it harder for the user of the types). We can put them into a single large package (but this means that any user of the package has visibility to the whole package, even if only part of it is needed). We can have two mutually visible packages (but this introduces cycles into the package structure). If you have protocols on packages, you can have one big package with separate protocols.

3. Sub-typing Packages

Visibility is easiest to consider with sub-typing. The sub-type always needs to see a super-type, but we should avoid the reverse.
Hence we add combinations, options, and barriers (described in Analysis of Derivative Contracts), as shown in Figure 9.

We should also avoid mutual visibility between a sub-type and its super-type.



Figure 9. Adding various kinds of options.
Sub-types need visibility to their super-types, but not vice versa.

The whole point of sub-typing is to allow a type to be extended without the super-type being aware of it. If we design types with super-types knowing about their sub-types, then future specialization is likely to be more difficult because we have built assumptions about sub-typing into the super-type. Any effort to remove such dependencies is repaid in later enhancements. Design ing super-types correctly usually requires experience in designing a few sub-types first, so it is better not to fix the super-type until a few sub-types have been put together.

4. Concluding Thoughts

Visibility always implies trade-offs. To restrict visibility reduces the ease with which the model can be navigated. With lots of one-way visibilities, getting around the model can be rather like getting around a city with lots of one-way streets. Two-way visibilities make navigation much easier, which means less code to write and maintain. Such visibilities come at a price, however. The more bits of the system see each other, the more difficult it is to control the effects of change in the model. Restricting visibility cuts down this interdependence.

Different OO modelers make this trade-off differently. Some restrict visibility to a great extent, using techniques such as one-way associations and visibility graphs on types. We find this too restrictive. We consider visibility at the package rather than the type level. The n-tier architecture separates a system into basic layers. Within the domain tier, further visibility restrictions can be used, but this is seldom simple. We prefer this approach, however, because of our experience with information systems. Other kinds of developments merit different trade-offs.

Most projects do not consider package architecture in any great detail. Often only the basic layers of the architecture are in place, if anything. This results in disadvantages to the project concerned and makes it difficult to assess the value of a properly enforced architectural model.
Only more practice will allow us to further understand the trade-offs discussed here.

If developing a package architecture is complex for one project, the complexity increases tenfold when we try to integrate information systems for a large organization. Large organizations are plagued by multiple systems that cannot communicate. Even if the hardware and software are beaten into shape, such integration is defeated by the difference between the concepts that underlie the systems. One generally recognized solution is to do enterprise-wide modeling. The problem with this approach, however, is that it takes too long. By the time it is done, if it ever is, the effort is usually discredited and out of date. We believe that there is an upper limit to the size of chunk of modeling that can be tackled in one go, and this is linked to delivering useful systems that justify the expense of modeling within a reasonable period of time. A more opportunistic approach needs to be taken to integrating them. For this task we believe that packages and visibilities are necessary tools. They are not sufficient for the task, and we will not pretend to know what else is needed. Such enterprise-wide integration is still little understood and, like many people, we have only learned what not to do!