لطفا منتظر باشید ...
10.3 Overview of the Dependencies Space
The vocabulary of dependencies presented in this chapter is based on the simple assumption that component interdependencies are explicitly or implicitly related to patterns of resource production and usage. In other words, these activities are those that need to interact with other activities, either because they use resources produced by other activities or because they share resources with other activities.
The definition of resources can be made broad enough to make this assumption cover most (if not all) cases of component interaction encountered in software systems. Our current definition of resources encompasses four components:
Processor time (control)
Data of various types
Operating system resources (memory pools, pipes, sockets, etc.)
Hardware resources (printers, disks, multimedia adapters, etc.)
In every resource relationship, participating activities can be distinguished by one of two roles:
Resource producers
Resource consumers
The existence of two different roles in resource relationships implies the existence of three different classes of dependencies:
Dependencies between producers and consumers
Dependencies among consumers who use the same resources
Dependencies among producers who produce for the same consumers
Dependencies between producers and consumers are modeled using a family of dependencies called flow dependencies. Malone and Crowston (1994) have observed that in general, whenever flows occur, one or more other subdependencies are present. In particular, flow dependencies can be decomposed to the following set of lower-level dependencies:
Usability. Users of a resource must be able to effectively use the resource. For data resources, this dependency encompasses issues relating to format conversion, semantic equivalence, etc.
Accessibility. In order for a resource to be used by an activity, it must be accessible by that activity (more precisely, it must be accessible by the processor that executes the activity). This requirement might require physical transportation of a resource, or conversely, relocation of an activity.
Prerequisite. A resource can only be used after the producer activity has been completed. Producers must notify users, or conversely, users must be able to detect when production is complete.
Resource sharing. When more than one activity requires usage of a resource, some protocol must manage how the resource will be shared among them. For example, if concurrent access of a resource is not permitted, some kind of mutual exclusion protocol must be put in place.
User sharing. When more than one producers are producing for the same users, a dependency analogous to resource sharing exists among them. Users become a shared ''resource''for producers and some protocol must manage how they are ''shared''among multiple producers. For example, users might not be able to use more than one, out of many, resources directed to them. In such cases selection among producers might have to take place.
Sections 10.6 and 10.7 are devoted to a detailed discussion of flow dependencies.Dependencies contained inside flows are shared on the assumption that multiple users of a resource are independent, and therefore competing with one another for resource access. In many applications, however, users (or producers) of a resource are cooperating in application-specific ways. In those cases designers must explicitly specify additional dependencies that describe the patterns of cooperation among users (or producers). Imagine, for example, a database resource that is generated by some activity and subsequently used by three other activities. In a particular application, one of the users of the database is using it to write values that will be read by the other users. This application-specific pattern of cooperation among users of the database requires the specification of an additional prerequisite relationship between the writer and the reader activities (figure 10.1).Application-specific patterns of cooperation among activities that share resources are expressed using additional flows and another family of dependencies called timing dependencies. Timing dependencies express constraints on the relative flow of control among a set of activities. The most widely used are prerequisite dependencies (A must complete before control flows into B) and mutual exclusion dependencies (A and B cannot execute at the same time).
In addition to specifying application-specific cooperation patterns, timing dependencies are often used to specify implicit resource relationships. For example, mutual exclusion dependencies are often used to specify implicit resource-sharing relationships, in which support for resource accesses is embedded inside the code of each activity. Also prerequisite dependencies often specify implicit flow relationships in which resource production and consumption are embedded inside the code. Section 10.8 describes a family of timing dependencies. For each dependency, its relationship with a resource dependency is illustrated.
Figure 10.1: Example of cooperative resource use
Throughout the chapter it becomes apparent that apart from classifying and enumerating elementary dependency types, it is also useful to begin to collect and classify sets of frequently occurring composite dependency patterns. In many cases designers have developed specialized, more effcient joint coordination processes for such patterns. Section 10.9 will present a few useful composite patterns of flows and joint coordination processes for managing them.
