| |||||||||||||||||||||||
Section 23.7. What You Need to Know
23.7. What You Need to KnowSo, do you really need to remember everything in this chapter? I certainly hope not, because I can't even remember it in my day-to-day work. Your database administrator, on the other hand, probably needs to know most of this stuff. In addition to satisfying healthy curiosity, my goal in presenting this material was to help allay any misgivings programmers might have about what happens under the hood. Whether or not you've ever had such concerns, there are a number of important points to remember about what goes on inside PL/SQL:
Now ... if you've made it through this entire chapter, I may one day come and bother you with my questions. |
3.3. Problem-Definition Prerequisite
< Free Open Study > |
3.3. Problem-Definition PrerequisiteThe first prerequisite you need to fulfill before beginning construction is a clear statement of the problem that the system is supposed to solve. This is sometimes called "product vision," "vision statement," "mission statement," or "product definition." Here it's called "problem definition." Since this book is about construction, this section doesn't tell you how to write a problem definition; it tells you how to recognize whether one has been written at all and whether the one that's written will form a good foundation for construction.
A problem definition defines what the problem is without any reference to possible solutions. It's a simple statement, maybe one or two pages, and it should sound like a problem. The statement "We can't keep up with orders for the Gigatron" sounds like a problem and is a good problem definition. The statement "We need to optimize our automated data-entry system to keep up with orders for the Gigatron" is a poor problem definition. It doesn't sound like a problem; it sounds like a solution. As shown in Figure 3-4, problem definition comes before detailed requirements work, which is a more in-depth investigation of the problem. Figure 3-4. The problem definition lays the foundation for the rest of the programming process[View full size image] The problem definition should be in user language, and the problem should be described from a user's point of view. It usually should not be stated in technical computer terms. The best solution might not be a computer program. Suppose you need a report that shows your annual profit. You already have computerized reports that show quarterly profits. If you're locked into the programmer mindset, you'll reason that adding an annual report to a system that already does quarterly reports should be easy. Then you'll pay a programmer to write and debug a time-consuming program that calculates annual profits. If you're not locked into the programmer mindset, you'll pay your secretary to create the annual figures by taking one minute to add up the quarterly figures on a pocket calculator. The exception to this rule applies when the problem is with the computer: compile times are too slow or the programming tools are buggy. Then it's appropriate to state the problem in computer or programmer terms. As Figure 3-5 suggests, without a good problem definition, you might put effort into solving the wrong problem. Figure 3-5. Be sure you know what you're aiming at before you shoot[View full size image]
|
< Free Open Study > |
6.1 Overview
| |
6.1 OverviewIn a servlet-based Web application, you can specify application-wide initialization parameters�known as context initialization parameters�for your application in the deployment descriptor; for example, the following code fragment stores the value es-MX in a context initialization parameter:
You might suspect that the parameter name javax.servlet.jsp.jstl.fmt. locale serves some official purpose, and you'd be right�if you add that context initialization parameter to your deployment descriptor (WEB-INF/web.xml), as in the preceding code fragment, you will set the default locale for JSTL I18N and formatting actions. In the preceding code fragment, that locale is set to Mexican Spanish. It's often desirable to override settings for a particular scope; for example, you might want to temporarily override the javax.servlet.jsp.jstl.fmt.locale context initialization parameter for a page, request, or session, so JSTL lets you create scoped variables that override context initialization parameters. Those scoped variables are known as configuration variables, and they are most often created by JSTL actions; for example, you can use the <fmt:setLocale> action like this:
The <fmt:setLocale> action in the preceding code fragment creates a French Canadian locale and stores it in a configuration variable in request scope. During the request, that configuration variable will take precedence over the context initialization parameter named javax.servlet.jsp.jstl.fmt.locale. When the request is over, the configuration variable is removed, and the default locale returns to the value specified in the context initialization parameter, assuming no other configuration variables of the same name exist in other scopes. The combination of context initialization parameter and configuration variable is defined by the JSTL specification as a configuration setting. Configuration settings let you specify default values with context initialization parameters and subsequently override those defaults with configuration variables with a JSTL action or a business component. Configuration settings are defined by static constants in the javax.servlet.jsp.jstl.core.Config class and a name that corresponds to that constant; for example, the configuration setting named javax.servlet.jsp.jstl.locale is defined by the FMT_LOCALE constant in the Config class. You use a configuration setting's name in deployment descriptors, but you use the static constants in business components, such as servlets or life-cycle listeners. Throughout this book, configuration settings are referred to by their constants; for example, the configuration setting named javax.servlet.jsp.jstl.fmt.locale is referred to as the FMT_LOCALE configuration setting. The FMT_LOCALE configuration setting discussed in this section is one of six configuration settings in JSTL 1.0. All of the JSTL 1.0 configuration settings are listed in Table 6.1.
The first three configuration settings listed in Table 6.1 are used by JSTL I18N and formatting tags. The fourth, which lets you specify a time zone, is used only by formatting actions. The last two let you specify an SQL data source and a limit for database queries. In JSTL 1.0, four actions change configuration settings. Table 6.2 lists those actions and the configuration settings they modify.
Notice that all of the actions in Table 6.2 are named setXXX, where XXX represents a configuration setting. The FMT_FALLBACK_LOCALE and SQL_MAX_ROWS configuration settings are not set by any JSTL actions; if you want to set them, you can specify them as context initialization parameters or you can set them in a business component. Configuration settings all work the same way, so we will focus mostly on one configuration setting�FMT_LOCALE�throughout the rest of this chapter. Learning about that configuration setting will help you understand how all configuration settings work. The FMT_LOCALE Configuration SettingThis book documents JSTL configuration settings with tables like Table 6.3, which documents the FMT_LOCALE configuration setting
Each configuration setting has a type. All JSTL configuration settings can be specified with a string or an object; for example, you can specify the FMT_LOCALE configuration setting as a string, such as en-US or fr-CA, or as an instance of java.util.Locale. Table 6.3 also tells you which JSTL actions set the FMT_LOCALE configuration setting (only <fmt:setLocale>) and which actions use it (quite a few). Temporarily Overriding Configuration SettingsFigure 6-1 shows a simple Web application that illustrates how the FMT_LOCALE configuration setting works. There are two JSP pages in the application. The first page, referred to as Page 1, is shown at startup (shown on the left in Figure 6-1). That page has a submit button that takes you to the second page, referred to as Page 2 (shown on the right in Figure 6-1). Figure 6-1. Using the FMT_LOCALE Configuration SettingThe first thing you need to know to make sense of the application shown in Figure 6-1 is that French is specified as the default locale with a context initialization parameter in the deployment descriptor. That deployment descriptor is listed in Listing 6.1. Listing 6.1 WEB-INF/web.xml
When the application shown in Figure 6-1 starts up, it displays Page 1 (page_1.jsp), which is designated as a welcome file in the deployment descriptor. That page uses a scriptlet to print the value of the FMT_LOCALE configuration setting, which is initially French (fr) because that's what was specified in the deployment descriptor. Listing 6.2 shows how that JSP page is implemented. The scriptlet that prints the value of the FMT_LOCALE configuration setting uses the static find method from the JSTL Config class to find the value of the FMT_LOCALE configuration setting. That method searches for a configuration variable in page, request, session, and application scopes, in that order; if it finds the configuration variable, it returns that variable's value. If the method does not find the configuration variable, it checks to see if a corresponding context initialization parameter exists; if so, it returns that parameter's value. In that way, scoped variables override context initialization parameters for configuration settings.[3]
Listing 6.2 page_1.jsp
After it prints the FMT_LOCALE configuration setting, the preceding JSP page uses the <fmt:setLocale> action to override that setting with English for page scope, like this:
Subsequently, the JSP page prints the FMT_LOCALE configuration setting again, to verify that for Page 1, the default locale has changed from French to English. When you click on the submit button in Page 1, the browser loads Page 2, which is listed in Listing 6.3. Listing 6.3 page_2.jsp
Page 2 (page_2.jsp), listed above, prints the FMT_LOCALE configuration setting with the same scriplet used in Page 1. Clicking on the submit button in Page 1 generates a new request, so the English override of the context initialization parameter in Page 1�which was specified for page scope�goes out of scope. Because that override goes out of scope, the FMT_LOCALE configuration setting for Page 2 returns to French. What would happen if you changed this line of code from Page 1:
to this:
Will the output be different? No, because clicking on the Go to Page 2 button generates a new request, and the <fmt:setLocale> action in Page 1 sets the FMT_LOCALE configuration setting for the current request, so the setting once again goes out of scope. If you want to change the FMT_LOCALE configuration setting for Page 2, you can specify session or application scope for <fmt:setLocale>, like this:
With the <fmt:setLocale> scope attribute set to session, as in the preceding code fragment, the FMT_LOCALE configuration setting will hold for Page 2, as shown in Figure 6-2. Figure 6-2. Overriding the FMT_LOCALE Configuration Setting in Session Scope |
| |
5.2 Chasing/Evading
< Day Day Up > |
5.2 Chasing/EvadingTo show how to implement potential-based chasing (or evading), we need only add a few bits of code to AIDemo2-2 (see Chapter 2 for more details). In that example program, we simulated the predator and prey units in a continuous environment. The function UpdateSimulation was responsible for handling user interaction and for updating the units every step through the game loop. We're going to add two lines to that function, as shown in Example 5-1.
Example 5-1. Chase/evade demo UpdateSimulation
As you can see, we added a check to see if the PotentialChase flag is set to true. If it is, we execute the AI for Craft2, the computer-controlled unit, which now uses the potential function. DoAttractCraft2 handles this for us. Basically, all it does is use the potential function to calculate the force of attraction (or repulsion) between the two units, applying the result as a steering force to the computer-controlled unit. Example 5-2 shows DoAttractCraft2. Example 5-2. DoAttractCraft2
The code within this function is a fairly straightforward implementation of the Lenard-Jones function. Upon entry, the function first calculates the displacement vector between Craft1 and Craft2. It does this by simply taking the vector difference between their respective positions. The result is stored in the vector r and a copy is placed in the vector u for use later. Note that u also is normalized. Next, several local variables are declared corresponding to each parameter in the Lenard-Jones function. The variable names shown here directly correspond to the parameters we discussed earlier. The only new parameter is d. d represents the separation distance, r, divided by the unit's length. This yields a separation distance in terms of unit lengths rather than position units. This is done for scaling purposes, as we discussed in Chapter 4. Aside from dividing r by d, all the other parameters are hardcoded with some constant values. You don't have to do it like this, of course; you could read those values in from some file or other source. We did it this way for clarity. As far as the actual numbers go, they were determined by tuning�i.e., they all were adjusted by trial and error until the desired results were achieved. The line that reads U = -A/pow(d, n) + B/pow(d, m); actually calculates the steering force that will be applied to the computer-controlled unit. We used the symbol U here, but keep in mind that what we really are calculating is a force. Also, notice that U is a scalar quantity that will be either negative or positive, depending on whether the force is an attractive or repulsive force. To get the force vector, we multiply it by u, which is a unit vector along the line of action connecting the two units. The result is then rotated to a local coordinate system connected to Craft2 so that it can be used as a steering force. This steering force is applied to the front end of Craft2 to steer it toward or away from the target, Craft1. That's all there is to it. Upon running this modified version of the chase program, we can see that the computer-controlled unit does indeed chase or evade the player unit depending on the parameters we've defined. Figure 5-2 shows some of the results we generated while tuning the parameters. Figure 5-2. Potential chase and evadeIn Figure 5-2 (A), the predator heads toward the prey and then loops around as the prey passes him by. When the predator gets too close, it turns abruptly to maintain some separation between the two units. In Figure 5-2 (B), we reduced the strength of the attraction component (we reduced parameter A somewhat), which yielded behavior resembling the interception algorithm we discussed in Chapter 2. In Figure 5-2 (C), we increased the strength of attraction and the result resembles the basic line-of-sight algorithm. Finally, in Figure 5-2 (D), we reduced the attraction force, increased the repulsion force, and adjusted the exponent parameters. This resulted in the computer-controlled unit running from the player. Adjusting the parameters gives you a great deal of flexibility when tuning the behavior of your computer-controlled units. Further, you need not use the same parameters for each unit. You can give different parameter settings to different units to lend some variety to their behavior�to give each unit its own personality, so to speak. You can take this a step further by combining this potential function approach with one of the other chase algorithms we discussed in Chapter 2. If you play around with AIDemo2-2, you'll notice that the menu selections for Potential Chase and the other chase algorithms are not mutually exclusive. This means you could turn on Potential Chase and Basic Chase at the same time. The results are very interesting. The predator relentlessly chases the prey as expected, but when it gets within a certain radius of the prey, it holds that separation�i.e., it keeps its distance. The predator sort of hovers around the prey, constantly pointing toward the prey. If the prey were to turn and head toward the predator, the predator would turn and run until the prey stops, in which case the predator would resume shadowing the prey. In a game, you could use this behavior to control alien spacecraft as they pursue and shadow the player's jet or spacecraft. You also could use such an algorithm to create a wolf or lion that stalks its victim, keeping a safe distance until just the right moment. You even could use such behavior to have a defensive player cover a receiver in a football game. Your imagination is the only limit here, and this example serves to illustrate the power of combining different algorithms to add variety and, hopefully, to yield some sort of emergent behavior. |
< Day Day Up > |
2.4 The Big Picture
| I l@ve RuBoard |
2.4 The Big PictureThis chapter has provided an overview of the entire process. The remainder of the book covers the details of what exactly needs to be done to build and compile Executable UML models. Chapter 3 and Chapter 4 address the topics of working out what needs to be modeled in the first place, addressed in this chapter as Section 2.1: The System Model. Chapter 5 and Chapter 6 cover the class diagram, addressed here as Section 2.2.1: Classes. Chapter 7 covers action semantics and action language (Section 2.2.3: Procedures) and Chapter 8 covers constraints on the class diagram. Chapter 9 covers the basics of statechart diagrams (Section 2.2.2: State Machines). Chapter 10 through Chapter 14 cover ways to build sets of communicating statechart diagrams. Chapter 15 covers model verification (Section 2.3.1: Model Verification). Chapter 16 covers model management. Chapter 17 and Chapter 18 cover weaving the models together so they will execute (Section 2.3.2: Model Compilation). |
| I l@ve RuBoard |
Python Phrasebook: Essential Code and Commands
| |||||||||||||||||||||||||||||
| Table of Contents | Index |
Python Phrasebook Brad Dayley Essential Code and Commands Python Phrasebook gives you the code Concise and Accessible Easy to carry and easy to uselets you Flexible and Functional Packed with more than 100 customizable code Brad Dayley is a software engineer at Programming / Python $16.99 USA / $20.99 CAN / £11.99 Net |