Important Sentence Types in Natural Language in Font

Generating QR Code ISO/IEC18004 in Font Important Sentence Types in Natural Language

Punctuation symbols are used to emphasize sentence types. Imperative sentences often end with an exclamation mark. Declarative sentences end with a period. Interrogative sentences end with a question mark. The punctuation marks guide readers, indicating how to inflect the sentence in other words, where to put the emphasis and with what tone. How a sentence is inflected contributes to the way a listener interprets it. There are other sentence types, such as vocative and performative, but the ones that are of interest in a software context are primarily the three listed. When applied to communication between software entities, imperative sentences represent commands, such as method calls that return no data. Declarative sentences represent statements of fact, such as notifications in a publish-subscribe

2. Christopher Alexander, Sara Ishikawa, and Murray Silverstein, A Pattern Language: Towns, Buildings, Construction (New York: Oxford University Press, 1977); Christopher Alexander, The Timeless Way of Building (New York: Oxford University Press, 1979).

system, alerting subscribers of potentially interesting occurrences. An interrogative sentence is a request for information, such as a method that returns data. When applied to software interactions, I ll call sentence types interaction types. Table 9-2 shows software examples for each interaction type.

a.DoSomething(); FireDownloadComplete(); int i = a.GetValue();

The imperative example invokes a method to make an object do something. The declarative example fires an event, telling any subscribers that a download operation has completed. The interrogative example calls a method to obtain the value of a variable. Interactions are often more complex than a single method call, requiring several exchanges between the parties involved. I ll use the word conversation to include all the exchanges that are part of a larger interaction. When characterizing conversations, there are other things to consider besides interaction types, such as who starts the conversation, who controls it, who finishes it, what the purpose of it is, what assumptions govern it, and so on. Different interaction patterns emerge, depending on which variables you focus on.

One of the simplest ways of classifying an interaction is based on which way information flows in relationship to the party starting the interaction. If one party gives information to another party, the information is said to be pushed. If one party requests information from another party, the information is said to be pulled. In push-pull models, don t worry about lower-level interaction details, such as whether exchanges are synchronous or asynchronous. What matters the most is the overall direction of information flow relative to the party starting the conversation. Let s look at push and pull interactions more in detail.

A process P1 needs to send commands to P2. The frequency of commands is unknown or extremely variable. The system is sensitive to the processing load of P2, and it is crucial for P2 to never miss a command.

Forces If commands are expected to be infrequent, it is inefficient for P2 to continually poll P1 to see if commands are available. Since P1 knows when commands need to be sent, and you want P2 to get commands as soon as possible, it is more efficient to let P1 control the interaction.

The purpose of a push interaction is for one party to deliver information and/or execution control to another. I ll use the word talker to designate the party starting the interaction, and the word listener for the party with whom the talker interacts. In a push interaction, the talker sends a command to the listener, as shown in Figure 9-1.

Figure 9-1. The push-interaction pattern A command can include data. A push interaction is an imperative interaction. Push interactions are effective when the following two things apply: 1. The talker acts as a controller of the listener. 2. The talker decides when to issue commands to the listener. Push interactions form the basis of event-driven systems. Publishers are talkers, and subscribers are listeners. When something occurs to the publisher, notifications are sent to available subscribers to inform them of the event. Using push interactions to propagate changes through a system is particularly efficient when the talker needs to send the same command to a large number of listeners. If you have to implement the system without using push interactions, the alternative would require each listener to poll the talker periodically, waiting for changes to occur. A significant amount of processing time would be wasted in polling loops. Using a push interaction pattern frees the listeners from devoting resources to monitor the talker. While the talker has no new data, the listener can use its own resources to do more useful things than sitting in a polling loop. Due to their efficiency, push interactions are a good solution in real-time systems. When changes occur at very high speed, you might use a single notification to describe multiple changes at once. There are numerous examples of the push pattern in everyday life and in computing.

Example 1 Consider the process of getting up one morning at a given time, using a clock. One option is to stay awake all night, monitor the clock, and get up at the given time. The problem with this polling approach is that it wastes resources when the desired information (the time to get up) isn t available frequently (once every 24 hours). If you want to get up on time by means of a polled interaction with the clock, you would have to stay awake the entire night to watch the time. The polling process itself would impede the implementation of an important goal (getting some sleep). The push interaction centralizes the decision of when to consume processing time to send a notification. If no information is available, no notifications are ever pushed. An alarm clock is just the ticket. You tell it what data you are interested in (the time to go off), and you get your full night s sleep. The alarm clock notifies you when it s time to get up. Example 2 In a system that must react to the depressing of a button, it isn t efficient for the system to poll the button s status constantly because the button is only used occasionally. Using a push interaction, the button notifies the system when it is depressed. Example 3 The classic Model View Controller paradigm, or more specifically, the way the model interacts with the viewers, illustrates a push interaction. When the controller makes changes to the model, the latter pushes notifications to the viewers. The model acts as an event publisher, the viewers as event subscribers. The model can support any number of viewers. When changes occur in the model, a change notification is broadcast to all viewers. In response, the latter usually refresh all or part of a window. Viewers have no knowledge of each other and are controlled by the model s notifications.