Chapter 5: The Notation 209 of messages. Messages with the same sequence number are unordered relative to each other; messages with lower sequence numbers are dispatched before messages with higher sequence numbers. Duplicate sequence numbers and missing sequence numbers allow a partial ordering of messages. Example Figure 5-25 shows an example of an object diagram for the hydroponics gardening system, whose context is the class category Planning, first described in Figure 5-7. The intent of this diagram is to illustrate a scenario that Figure 5-25 Hydroponics Gardening System Object Diagram traces the execution of a common system function, namely, the determination of a predicted net cost-to-harvest for a specific crop. Carrying out this system function requires the collaboration of several different objects. We see from this diagram that the action of the scenario begins with some PlanAnalyst object invoking the operation timeToHarvest() upon the class utility PlanMetrics. Note that the object C is passed as an actual argument to this operation. Subsequently, the PlanMetrics class utility calls status() upon a certain unnamed GardeningPlan object; our diagram includes a development note indicating that we must check that the given plan is in fact executing. The GardeningPlan object in turn invokes the operation maturationTime() upon the selected GrainCrop object, asking for the time the crop is expected to mature. After this selector operation completes, control then returns to the PlanAnalyst object, which then calls C.yield() directly, which in turn propagates this operation to the crop's superclass (the operation Crop::yield()). Control again returns to the PlanAnalyst object, which completes the scenario by invoking the operation netCost() upon itself. Chapter 5: The Notation 210 This diagram indicates a link between the PlanAnalyst and GardeningPlan objects. Although no messages are passed, the presence of this link serves to highlight the existence of a semantic dependency between the two objects. Advanced Concepts The elements we have presented thus far constitute the essential parts of the notation for object diagrams. However, a number of particularly knotty development issues require that we extend this basic notation slightly. As we warned in our discussion on class diagrams, we must again emphasize that Figure 5-26 Roles these advanced features should be applied only as necessary to capture the intended semantics of a scenario. Roles, Keys, and Constraints In an earlier section, we noted that associations in a class diagram may be adorned with a role denoting the purpose or capacity wherein one class associates with another. For certain object diagrams, it is useful to restate this role on the corresponding link between two objects. Often, this adornment helps to explain why one object is operating upon another. Figure 5-26 provides an example of this advanced feature. Here we see that some PlanAnalyst object inserts a specific crop into an anonymous CropEncyclopedia object, and does so while acting in the role of Contributor. Using the same notation we introduced in class diagrams, we may indicates the keys or constraints associated with an object or a link. Data Flow As we described in Chapter 3, data may flow with or against the direction of a message. Occasionally, explicitly showing the direction of a data flow helps to explain the semantics of a particular scenario. Borrowing from the notation for structured design, we use the icon shown in Figure 5-26 to show that the value succeeded returns upon completion of the message insert. Chapter 5: The Notation 211 We may use either an object or a value in a data flow. Visibility In certain complicated scenarios, it is useful to keep track of exactly how one object has visibility to another. Although associations in class diagrams denote the semantic dependencies that may exist among the classes of two objects, they do not dictate exactly how those instances can see one another. For this reason, we may adorn the links in our object diagrams with icons that represent the visibility of one object to another. This adornment is also important for tools that support forward code generation and reverse engineering. Figure 5-27 is a refinement of Figure 5-25, and includes some of these adornments, which are similar to the icons we used to represent physical Figure 5-27 Visibility containment in class diagrams, but with the addition of a letter designating the kind of visibility. For example, the G adornment shown on the link from the PlanAnalyst object to the PlanMetrics class utility denotes that the class utility is global to the declaration of the analyst object. The object C is visible to the PlanAnalyst object and the GardeningPlan object through two different paths. From the perspective of the PlanAnalyst object, the GrainCrop object C is visible as a parameter to some analyst operation, (the P adornment); from the perspective of the GardeningPlan object, the object C is visible as a field (that is, as a part of the plan aggregate object). To generalize, the following adornments may be used to indicate visibility: • G The supplier object is global to the client. Chapter 5: The Notation 212 • P The supplier object is a parameter to some operation of the client. • F The supplier object is a part of the client object. • L The supplier object is a locally declared object in the scope of the object diagram. Consistent with the adornments for physical containment in class diagrams, these adornments may be written as an open box with a letter (representing that the object's identity is shared) or as a filled box wit that the object's identity is not structurally shared). The absence of a visibility adornment means that the precise visibility between the two objects is left unspecified. In practice, it is common to adorn Figure 5-28 Active Objects and Synchronization only a few key links in an object diagram with these visibility symbols. The most common use of these symbols is to represent whole/part (aggregation) relationships between two objects; the second most common use is to represent transitory objects that are passed into the object diagram's scenario as parameters. Active Objects and Synchronization As noted in Chapter 3, certain objects may be active, meaning that they embody their own thread of control. Other objects may have only purely sequential semantics, while yet others might not be active, yet still guarantee their semantics in the presence of multiple threads of control. In each of these circumstances, we must address two issues: how to signify the active objects that denote roots of control in a scenario, and how to represent different forms of synchronization among such objects. Chapter 5: The Notation 213 In our earlier discussion on the advanced features of class specifications, we noted that classes may have one of four concurrency semantics: sequential, guarded, synchronous, and active. By implication, all instances of a class take on the concurrency semantics of their class; all objects are sequential unless otherwise stated. We may explicitly reveal the concurrency semantics of an object in an object diagram by adorning its object icon with the names sequential, guarded, synchronous, or active, placed in the lower left of the icon. For example, in Figure 5-28, we see that H, C, and the anonymous instance of the EnviommentalController class are all active objects and thus embody their own thread of control. Unadorned objects (such as L) are assumed to be sequential. The message synchronization symbol we introduced earlier (the simple directed line) represents simple sequential message passing. In the presence of multiple threads of control, however, we must specify other forms of synchronization. Figure 5-29 Time Budgets Albeit slightly contrived, the example in Figure 5-28 illustrates the different kinds of message synchronization that: may appear in an object diagram. The message turnOn() is an example of simple message passing, and is represented with the directed line. The semantics of simple message passing are guaranteed only in the presence of a single thread of control, in contrast, all the other messages involve some form of process synchronization; all such advanced forms of synchronization apply only to suppliers that are non-sequential. For example, the message startUp() is synchronous, meaning that the client will wait forever until the supplier accepts the message. Synchronous message passing is equivalent to Ada's rendezvous mechanism among tasks. The isReady() message denotes balking message passing, meaning that the client will abandon the message if the supplier cannot immediately service the message. The restart() message denotes a timeout synchronization: the client will abandon the message if the supplier cannot service the message within a specified amount of time. In each of these last three cases, the client must wait for the supplier to completely process the message (or abandon the message) before control can resume. In the case of the message failure(), the semantics are different. This is an example of an asynchronous message, which Chapter 5: The Notation 214 means that the client sends the event to the supplier for processing, the supplier queues the message, and the client then proceeds without waiting for the supplier. Asynchronous message passing is akin to interrupt handling. Time Budgets For certain time-critical applications, it is important to trace scenarios in terms of exact time relative to the start of the scenario. To designate relative time, we use sequence numbers that denote time (in seconds), prefixed by the plus symbol. For example, in Figure 5- 29, we see that the message startUp() is first invoked 5 seconds after the start of the scenario, followed by the message ready() 6.5 seconds after the start of the scenario, and then followed by the message turnOn() after 7 seconds. Specifications As for class diagrams, each entity in an object diagram may have a specification, which provides us complete definition. Because the specifications for objects and object relationships add no information beyond what we have already described in this section, we need not discuss their textual specification here. On the other hand, the specifications for object diagrams as a whole do have one significant piece of nongraphical information that we must consider. As we described at the beginning of this section, every object diagram must designate a context. We do so in the diagram's specification, as follows: Context: global | category | class | operation In particular, the scope of an object diagram may be global, or in the context of a named class category, class, or operation (including both methods and free subprograms). 5.5 Interaction Diagrams Essentials: Objects and Interactions An interaction diagram is used to trace the execution of a scenario in the same context as an object diagram. 56 Indeed, to a large degree, an interaction diagram is simply another way of representing an object diagram. For example, in Figure 5-30, we provide an interaction diagram that duplicates most of the semantics of the object diagram shown in Figure 5-25. The advantage of using an interaction diagram is that it is easier to read the passing of messages in relative order. The advantage of using an object diagram is that it scales well to many objects with complex invocations, and permits the inclusion of other information, such as links, attribute values, roles, data flow, and visibility. Because each diagram has compelling benefit we include both of them in the method. 57 56 These diagrams are generalizations of Rumbaugh's event trace diagrams [14] and Jacobson's interaction diagrams [15]. 57 Object diagrams and interaction diagrams are sufficiently close in terms of their semantics that it is possible for tools to generate one diagram from the other, with minimal loss of information. Chapter 5: The Notation 215 Interaction diagrams introduce no new concepts or icons; rather, they take most of the essential elements of object diagrams and restructure them. As Figure 5-30 indicates, an interaction diagram appears in tabular form. The entities of interest (which are the same as for object diagrams) are written horizontally across the top of the diagram. A dashed vertical line is drawn below each object. Messages (which may denote events or the invocation of operations) are shown horizontally using the same syntax and synchronization symbols as for object diagrams. The endpoints of the message icons connect Figure 5-30 Hydroponies Gardening System Interaction Diagram with the vertical lines that connect with the entities at the top of the diagram and are drawn from the client to the supplier. Ordering is indicated by vertical position, with the first message shown at the top of the diagram, and the last message shown at the bottom. As a result, it is unnecessary to use sequence numbers. Interaction diagrams are often better than object diagrams for capturing the semantics of scenarios early in the development life cycle, before the protocols of individual classes have been identified. As we explain in the next chapter, early interaction diagrams tend to focus on events as opposed to operations, because events he1p to define the boundaries of a system under development. As development proceeds and the system's class structure is refined, the emphasis tends to migrate to object diagrams, whose semantics are more expressive. Advanced Concepts Interaction diagrams are conceptually very simple; however, there are two straightforward elements that can be added to make them more expressive in the presence of certain complicated patterns of interaction. Scripts For complex scenarios that involve conditions or iterations, interaction diagrams can be enhanced by the use of scripts. As we see in the example in Figure 5-31, a script may be written to the left of an interaction diagram, with the steps of the script aligning with the Chapter 5: The Notation 216 message invocations. Scripts may be written using free form or structured English text, or using the syntax of the chosen implementation language. Focus of Control Neither simple object diagrams nor interaction diagrams indicate the focus of control as messages are passed. For example, if object A sends messages X and Y to other objects, it is not clear if X and Y are independent messages from A or if they have been invoked as part of the same Figure 5-31 Scripts and Focus of Control enclosing message Z. As we show in Figure 5-31, we may adorn the vertical lines descending from each object in an interaction diagram with a box representing the relative time that the flow of control is focused in that object. For example, here we see that the anonymous instance of the GardeningPlan is the ultimate focus of control, and its behavior of carrying out a climatic plan invokes other methods, which in turn call other methods that eventually return control back to the GardeningPlan object. 5.6 Module Diagrams Essentials: Modules and Their Dependencies A module diagram is used to show the allocation of classes and objects to modules in the physical design of a system. A single module diagram represents a view of the module structure of a system. During development, we use module diagrams to indicate the physical layering and partitioning of our architecture. Certain languages, most notably Smalltalk, have no concept of a physical architecture formed of modules; in such cases, module diagrams are unnecessary. The two essential elements of a module diagram are modules and their dependencies. Chapter 5: The Notation 217 Modules Figure 5-32 shows the icons we use to represent various kinds of modules. The first three icons denote files, distinguished by their function. The main program icon denotes a file that contains the root: of a program. In C++ for example, this would likely be some cpp file that contains the definition of the privileged nonmember function called main. Typically, there is exactly one such module per program. The specification icon and the body icon denote files that contain the declaration and definition of entities, respectively. In C++, Figure 5-32 Module and Subsystem lcons for example, specification modules denote h files, and body modules denote cpp files. We will explain the meaning of the subsystem icon in a later section. A name is required for each module; this name typically denotes the simple name of the corresponding physical file in the development directory. We usually write such names without their suffixes, which would be redundant when associated with a particular module icon. If the name is particularly long, it can either be elided or the icon magnified. Every full file name must be unique according to its enclosing subsystem. Depending upon the needs of our particular development environments, we may impose other constraints upon names, such as requiring distinctive prefixes or requiring unique names across the entire system. Each module encompasses the declaration or definition of classes, objects, and other language details. Conceptually, we can zoom in to a module to see the physical contents of its corresponding file. Dependencies The only relationship we may have between two modules is a compilation dependency, represented by a directed line pointing to the module upon which the dependency exists. In C++ for example, we indicate a compilation dependency by #include directives. Similarly in Ada, compilation dependencies are indicated by with clauses. In general, there may be no cycles within a set of compilation dependencies. Performing a topological sort upon all the dependencies of a system's module structure is sufficient to calculate a partial ordering of compilation. Example In Figure 5-33, we provide an example of this notation, drawn from the physical architecture of the hydroponics gardening system. Here we see six modules. Two of them, climatedefs and cropdefs, are only specifications, and serve to provide corm-non types and Chapter 5: The Notation 218 constants. The remaining four modules are shown with their specification and bodies grouped together: this is a typical style of drawing module diagrams, since the specification and body of a module are so intimately related. Because we have overlaid the two parts, the dependency of the body upon the corresponding specification is hidden, although it in fact exists. Similarly, the name of the body is hidden, which is not a problem because our convention is to name specifications and bodies the same except for a distinguishing suffix (such as .h and .cpp, respectively). Figure 5-33 Hydroponics Gardening System Module Diagram The dependencies in this diagram suggest a partial ordering of compilation. For example, the body of climate depends upon the specification of heater, which in turn depends upon the specification of climatedefs. Essentials: Subsystems As explained in Chapter 2, a large system may be decomposed into many hundreds, if not a few thousand, modules. Trying to comprehend the physical architecture of such a system is impossible without further chunking. In practice, developers tend to use informal conventions to collect related modules in directory structures. For similar reasons, we introduce the notion of a subsystem for module diagrams, which parallels the role played by the class category for class diagrams. Specifically, subsystems represent clusters of logically related modules. [...]... and results of each release to the next iteration of analysis and design The process is incremental in the sense that each pass through an analysis/ design/evolution cycle leads us to gradually refine our strategic and tactical decisions, ultimately converging upon a solution that meets the end user's real (and usually unstated) requirements, and yet is simple, reliable, and adaptable An iterative and. .. classical approach to object-oriented analysis (page 155 ) to generate a set of candidate classes and objects Early in the life cycle, tangible things and the roles they play are good starting points Later in the life cycle, following events will yield other first- and second- order abstractions: for each event, we must have some object that is ultimately responsible for detecting and/ or reacting to the... and sensors in the system Figure 5- 36 Hydroponics Gardening System Process Diagram Advanced Concepts Tailoring Figure 5- 35 shows the standard icons we use to represent processors and devices, but it is reasonable and in fact desirable to allow alternate representations For example, we might define specific icons to graphically represent an embedded microcomputer (a processor), a disk, a terminal, and. .. perspectives: namely, its logical and physical structure, and its static and dynamic semantics • The notation for object-oriented development includes four basic diagrams (class diagrams, object diagrams, module diagrams, and process diagrams) and two supplementary diagrams (state transition diagrams and interaction diagrams) • A class diagram is used to show the existence of classes and their relationships... and possibly exceed the customer's expectations, was developed in a timely and economical fashion, and is resilient to change and adaptation By this measure, we have observed two traits that are common to virtually all of the successful object-oriented systems we have encountered, and noticeably absent from the ones that we count as failures: • The existence of a Strong architectural vision • The application. .. to anyof a wide spectrum of object-oriented programming languages Chapter 5: The Notation 2 25 This chapter has described the essential products of object-oriented development, including their syntax and semantics The next two chapters will describe the process that leads us to these products The remaining five chapters demonstrate the practical application of this notation and process to a variety of... like this: most involve the balancing of a unique set of functional and performance requirements, and this task demands the full creative energies of the development team Furthermore, any human activity that requires creativity- and innovation demands an iterative and incremental process that relies upon the experience, team member .59 It is therefore impossible to provide any cookbook recipes Towards... relationships among these classes and objects Specify the interface and then the implementation of these classes and objects Let's examine each of these activities in detail Identifying Classes and Objects Purpose The purpose of identifying classes and objects is to establish the boundaries of the problem at hand Additionally, this activity is the first step in devising an object-oriented decomposition... the physical collection of processors and devices that serve as the platform for execution of our system The three essential elements of a process diagram are processors, devices, and their connections Processors Figure 5- 35 shows the icon we use to represent a processor A processor is a piece of hardware capable of executing programs A name is Figure 5- 35 Processor and Device icons required for each... iterative and incremental development life cycle 227 Chapter 6: The Proccess Architectural Vision A system that has a sound architecture is one that has conceptual integrity and, as Brooks firmly states, "conceptual integrity is the most important consideration in system design" [1] As we described in Chapters 1 and 5, the architecture of an object-oriented software system encompasses its class and object . generation and reverse engineering. Figure 5- 27 is a refinement of Figure 5- 25, and includes some of these adornments, which are similar to the icons we used to represent physical Figure 5- 27. in the method. 57 56 These diagrams are generalizations of Rumbaugh's event trace diagrams [14] and Jacobson's interaction diagrams [ 15] . 57 Object diagrams and interaction. Processors Figure 5- 35 shows the icon we use to represent a processor. A processor is a piece of hardware capable of executing programs. A name is Figure 5- 35 Processor and Device icons