Chapter 7. Road Map to Part II

In Part II we move from the overall systems engineering view described in Chapter 6 to the somewhat more detailed perspective of a particular subject matter or subsystem. That perspective is composed of two complementary views of a subject matter: a static model and a dynamic model. This section is about the static view; Part III will deal with the dynamic view of subject matter.

If you are into anatomical analogies, subsystems form the skeleton of an application. Because of the militant encapsulation of subject matters described in the previous chapter, it could be argued that the subsystem skeleton is really an exoskeleton that surrounds and isolates the critical portions of the anatomy. We can also make the analogy that the static model of a subsystem represents an internal skeleton because it provides a structure or framework for the subject matter over which the dynamic model is intimately laid.

But a more poetic view is that the static model is really the heart of a subject matter¹ because the static model is where OO problem space abstraction is most prominent. To build it properly we need insight into the essence of what problem space entities are. Thus the class abstractions composing the static model represent both the heart of the OO approach and the heart of the problem space subject matter. This overview identifies the basic elements of the static model that will be used in subsequent chapters. The other chapters in this section deal with each element in more detail.

Unfortunately, this presents a problem because we are pressed for space and can’t really do the topic full justice. Fortunately, there is already a good book on doing class modeling: Leon Starr’s Executable UML: How to Build Class Models.² Another important book is Steve Mellor and Marc Balcer’s Executable UML.³ While the book is aimed at defining an MDA profile for translation, the examples are excellent. In addition, there are literally dozens of books that deal with the syntax of UML notation and how to manipulate it. So, rather than reinventing the wheel, we are going to minimize discussion of syntax and its interpretation while emphasizing how we apply OO principles to design.

What Is the Static Model?

Static is one of those overloaded terms in software development. In the context of OOA/D, though, it is very close to the traditional dictionary definition: “1. acting by mere weight without motion (~pressure), 2. relating to bodies at rest or in equilibrium, 3. not moving; not active.”⁴ Unlike the definitions often applied in computer languages, there is no implication of scope in the OOA definition.

In practice, negative definitions (i.e., not active) are often of limited use in understanding what’s happening, so OOA/D subscribes to a somewhat more proactive quality for the notion of static model in the OOA context: The model defines a fixed structure implicit in the overall solution context. Thus OOA/D places a somewhat different spin on the idea of “static” that has connotations of (identifiable) structure and invariants rather than lack of motion.

Of the static models or views in OOA/D, two are required and one is optional. The last chapter described application partitioning, which is an inherently static view because we do not want the partitioning or allocation of responsibilities to change over time. We use the Component diagram to represent that static view because in UML it describes the deployment of logical deliverables. The Package diagram represents the static structure of the application from a configuration management viewpoint. The Package diagram is an optional documentation element in MBD because it deals with issues that are beyond the scope of this book.

The Class diagram is the primary representation of the static model for a particular subject matter where individual objects live. It will be the subject of this part of the book. In MBD, each designed subsystem will have its own Class diagram that describes the structure of that subject matter. In keeping with the notion of static, the Class diagram’s primary function in life is to simply identify elements of the problem solution. The elements that it defines are

Classes. These identify the intrinsic properties shared by a set of objects. Objects do not appear explicitly in the Class model because they are instantiated dynamically, so their instances come and go based on solution context. We include classes because they define the structure of any object member of the set.

Responsibilities. From set theory, a Class defines a suite of properties that all members of the class possess. Member objects always have the property, so it is a static or structural element of the objects. In the OO context, a property is abstracted as a responsibility for either knowing something or doing something. Note that only the responsibility (what) is defined, not its implementation (how). The Class diagram simply identifies intrinsic responsibilities.

Relationships. These are logical ties between members of different classes. Such ties form the basis for collaboration among objects. A Class diagram relationship only defines the constraints on which objects can participate in particular collaborations. It does not identify specific participants in the relationship. In other words, relationships define the structure of participation in collaborations. In relational model terms, relationships are defined between n-ary relations.

Generalization. Generalization was discussed in Chapter 3. In the Class diagram we describe the structure of the generalization n-ary relation as a Venn diagram in tree form.

The reason the Class diagram is a static model is that it doesn’t actually do anything. All it really does is identify things that will eventually do something (behavior responsibilities) and things that will support their doing something (knowledge responsibilities and relationships). The Class diagram then organizes those things so that the developer can easily overlay a dynamic problem solution. One can look at the Class diagram as a sort of parts list for the problem solution.

This pearl of wisdom summarizes several things that are worth discussing individually. The subject matter of any subsystem almost always represents a unique problem space. This is true even when we abstract the same underlying entities in different subsystems. Typically a subject matter defines a unique perspective with its own view of abstraction. It also represents some unique functionality that can be traced to particular functional requirements. Finally, a subsystem often captures a unique paradigm. Thus the Window/Control paradigm for a GUI and the Table/Tuple view of RDB persistence represent different problem spaces because each subject matter deals with different views, rules, policies, and paradigms when presenting and storing the same data.

The parts list defined in the Class diagram is a list of things necessary to solve a very specific problem. The context of the problem in hand is that of the subsystem’s subject matter and its functional requirements. In other words, the problem in hand is limited to that defined by the subsystem’s requirements—and only that subsystem’s requirements.

We cannot emphasize enough how fundamental this is to OO development. By identifying building blocks abstracted from the problem space first, and then constructing a behavioral solution to a particular problem by cobbling together those blocks, the OO paradigm is fundamentally different than other software development approaches.

Knowledge versus Behavior

In the OO paradigm, knowledge and behavior are quite different beasts. In Chapter 2 we noted that one difference was the use of different communication models during collaboration. However, there are a number of other very fundamental differences. The obvious one is that behavior is dynamic while knowledge is static. But what do we really mean by that?

Clearly the value of knowledge changes with dynamic context. When we refer to knowledge as static, we mean that its semantics and structure do not change during the execution of the problem solution. Consider an object like a simple traffic light that has a knowledge responsibility to know its current color. The semantics is such that the traffic light always has a color. More to the point, every member of the traffic light set has a color with the same semantics. In addition, the number of allowed colors is limited to a particular value domain (e.g., green, yellow, red) and that constrains the semantics. But the colors of a traffic light can also have structure that transcends the basic semantics of color and its allowed value domain. That is, there is a predefined order in which the values can change: green → yellow → red → green → . . . . For any traffic light, the value of the current color changes with regularity, but the semantics of the current color and its structure are fixed.

The view of behavior is, in quasi-mathematical terms, a dual⁵ of the view of knowledge. The notion of value is expressed in terms of the results rather than the behavior itself. Although every object member of a class has exactly the same behavior implementation, that behavior can yield different results based on dynamic context. Thus the value of the object’s knowledge at any moment depends on the object’s identity; it will be pure serendipity for two different objects to have the same value for the knowledge. But for behavior the results depend on the dynamic context, not the object identity.⁶ So the same behavior could yield different results for the same object, or the same results for different objects, depending on the dynamic context.

This may seem like an arcane distinction, but it is quite important. One way that it is manifested is through polymorphism. Only behaviors can be polymorphic. The notion is essentially meaningless for knowledge because we substitute results directly by changing the value of the knowledge. More to the point, knowledge semantics are immutable with respect to DbC contracts. Green is green in a Traffic Light context and level of abstraction does not come into play. But entire behaviors can be substituted by changing the level of abstraction in a DbC contract, as we saw in Chapter 3.⁷

Practical Note

We have very strongly emphasized the notion that we develop the static structure of a subject matter in a Class diagram prior to worrying about the dynamics of the solution, particularly sequences of operations. This is very important to get the right frame of mind for OO construction. However, that frame of mind can be driven into the ground in practice.

The reality is that a subject matter must satisfy functional requirements, and functional requirements are pretty much all about behavior. Thus it is not possible in practice to identify the static solution elements needed to solve the problem without some idea about what behaviors will be required. Nor can we determine the necessary relationships without having some notion about how those behaviors will collaborate. Finally, the most useful form of requirements specification is use cases, where sequence is painfully obvious.

The trick lies in making behaviors and their sequencing peripheral to the development of the static model. We do this through abstraction, by thinking about them at such a high level of abstraction that they are barely recognizable. This is largely why OO development has its own special suite of buzz words and phrases used to describe OOA/D. Hence, classes have responsibilities rather than behaviors; objects collaborate rather than provide services; and an object sends a message rather than requesting an operation. This pedantic legerdemain enables us to raise the level of abstraction of the OOA/D away from the 3GL view of the computational model. That is,

Perhaps more important, the static and dynamic views of a subject matter are tightly linked together, and the subject matter development is not complete until both have been described. Therefore, in practice, the static and dynamic models are developed in an iterative fashion so that the static model may be modified to deal with issues uncovered during dynamic modeling.

Note that this is in contrast to application partitioning. The application partitions must be defined in the stone of problem space invariants. We may change the interfaces and the implementations of subsystems as requirements change, but the nature of the subject matter should not change as long as the customer remains in the same business. One way to rationalize the contrast is that application partitioning is defined in a single model for the entire application. That model is at a higher level of abstraction than the models for individual subject matters, so there should be no reason for it to change unless there are very drastic changes in the business requirements.

On the other hand, the static and dynamic views of a subject matter are on the same level of abstraction and they complement one another. Although complexity management urges us to develop those views separately, the views are still of exactly the same thing and need to be coordinated, hence there is iteration and feedback between the models when designing subsystems. The tricky part is to ensure the separation of concerns for static and dynamic models that provides a unique context for that iteration and feedback. Therefore tools, such as abstraction, and mental gymnastics, such as dealing in responsibilities, help us to maintain that separation of concerns.