Events, Signals, and Messages

Ivan Marsic • Rutgers University 118 essentially a bit more than the commonplace “block diagrams.” I should mention that context diagrams are not part of UML; they were introduced by Michael Jackson [1995] based on the notation dating back to structured analysis in 1970s. The context diagram represents the context of the problem that the developer sets out to solve. The block diagrams we encountered in Figure 1-8b and Figure 1-24 are essentially context diagrams. Essentially, given the partitioning shown in Figure 3-1, we show different domains as rectangular boxes and connect them with lines to indicate that they share certain phenomena. Figure 3-7 is Figure 1-8b redrawn as a context diagram, with some more details added. Our system, labeled “machine” or SuD, subsumes the broker’s role and the figure also shows abstract concepts such as portfolio, trading order, and i th stock. Jackson uses the term “machine” in an effort to get around the ambiguities of the word “system,” some of which were discussed in Section 2.2.3. The reader who rather prefers SuD is free to use it. A context diagram shows parts of the world Figure 3-1 that are relevant to our problem and only the relevant parts. Each box in a context diagram represents a different domain. A domain is a part of the world that can be distinguished because it is conveniently considered as a whole, and can be considered—to some extent—separately from other parts of the world. Each domain is a different subject matter that appears in the description of the problem. A domain is described by the phenomena that exist or occur in it. In every software development problem there are at least two domains: the application domain or environment, or real world—what is given and the machine or SuD—what is to be constructed. The reader may notice that some of the domains in Figure 3-7 correspond to what we called “actors” in Chapter 2. However, there are other subject matters, as well, such as “Investment portfolio.” To help simplify our considerations, we decide that all the domains in the context diagram are physical. In Figure 3-7, while this may be clear for other domains, even “Investment portfolio” should be a physical domain. This is achieved by taking this box to stand for the physical representation of the information about the stocks that the trader owns. In other words, this is the representation stored in computer memory e.g., on hard disk or displayed on a screen or printed on paper. The reason for emphasizing physical domains and physical interactions is because the point of software development is to build systems that interact with the physical world and change it. Machine SuD Machine SuD Stock exchange Trader Bank Investment portfolio Investment portfolio Context diagram symbols: A box with a double stripe is a machine domain A box with a single stripe is a designed domain A box with no stripe is a given domain i th stock Trading order Figure 3-7: Context diagram for our case study 2: investment advisory system. Chapter 3 • Modeling and System Specification 119 Domain Types Domains can be distinguished as to whether they are given or are to be designed. A given domain is a problem domain whose properties are given—we are not allowed to design such a domain. In some cases the machine can influence the behavior of a given domain. For example, in Figure 3-7 executing trading orders influences the behavior of the stock exchange given domain. A designed domain is a problem domain for which data structures and, to some extent, its data content need to be determined and constructed. An example is the “Investment portfolio” domain in Figure 3-7. Often, one kind of problem is distinguished from another by different domain types. To a large degree these distinctions arise naturally out of the domain phenomena. But it is also useful to make a broad classification into three main types. ♦ A causal domain is one whose properties include predictable causal relationships among its causal phenomena. A causal domain may control some or all or none of the shared phenomena at an interface with another domain. ♦ A biddable domain usually consists of people. The most important characteristic of a biddable domain is that it lacks positive predictable internal causality. That is, in most situations it is impossible to compel a person to initiate an event: the most that can be done is to issue instructions to be followed. ♦ A lexical domain is a physical representation of data—that is, of symbolic phenomena. Shared Phenomena So far we considered world phenomena as belonging to particular domains. Some phenomena are shared. Shared phenomena, viewed from different domains, are the essence of domain interaction and communication. You can think of the domains as seeing the same event from different points of view. Figure 3-8 shows eject ? start stop eject load enable disable enable disable activate shut down Power button Play button Eject button Disc tray Display activate shut down notify notify Figure 3-8: Domains and shared phenomena in the problem of controlling a CD player.