Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
6. Software Dependency Anne Example, Ed A. McAuthor and Edna Nother 6.1 Introduction To repeat the closing words of the previous chapter, low coupling is an objective greatly to be desired in a distributed application. However, a moment’s thought reveals that the same, low, amount of coupling cannot be sustained in all remote interfaces of an application. Rather, it is reasonable to expect appropriate coupling to be the goal in the design of distributed systems: that is, given a certain requirement, employing the lowest appropriate coupling to realize the requirement. What are these requirements? In the following pages, we introduce the notion of dependency. Imagine that you are filling in your tax return. You get a tax deduction on some of the bank charges. You cannot recall the figures from memory. Therefore, you go to the filing cabinet, pull out the bank statements, copy the charges for the year. You then put the statements back, walk back to your desk, add up the charges and apply the tax deduction rule. You enter the resultant total in the tax return. You complete the return, and post it to the tax office, perhaps recorded or registered post to have some guarantee of delivery. You (may) receive an acknowledgment. You then go about your business. A month later, you receive a communication from the tax office, giving the results of their processing of your tax return. 6.2 Identifying Software Dependencies In this scheme of things, we must first identify the requirement, the dependency. The dependency itself must be identified correctly; otherwise (as with implementing dependencies with appropriate coupling) we are in danger either of introducing an avoidable cost or introducing integrity problems into the system. In certain instances, establishing the appropriate dependency is a trivial matter. For example, as we have seen, in taking an order actions such as performing a credit check or creating the order header imply processing dependencies: the calling module needs the results of the remotely performed credit check to proceed to the next step, creating the order header, and the result of this action for the following step, creating an order line, and so on. But in other situations the choice can be more difficult. 2 Example, McAuthor and Nother Sometimes informational dependencies masquerade as processing dependencies, sometimes simple processing and/or informational dependencies take the guise of transactional dependencies. In these situations, it is important that the discerning designer uncovers the actual underlying dependency. 6.2.1 Processing Versus Informational Dependencies Does the result of the work done remotely on behalf of application component X only return an acknowledgment?, and is the acknowledgment really necessary for component X to carry out or complete its task? If the answer to the first question is “Yes” and the answer to the second “No”, then it is very likely that we are looking at an informational dependency. Because, if we only require the acknowledgment as an assurance of delivery, then the same effect is achieved if we “put” the necessary information in a MOM that provides guaranteed or assured delivery. Imagine that the order entry task creates a sales order for some types of goods (items maintained in stock) and a manufacturing order for others (items manufactured to order). In the latter case, which is really a request to manufacture, the order entry software in the sales department currently updates the (remote) manufacturing system database as part of the order entry task. For successful completion, the order entry task software requires an acknowledgment of this update. However, we can reason that if the order entry module has access to a third party (middleware) that promises to deliver the manufacturing order to the manufacturing system, then its responsibility can be limited simply to making the manufacturing order available to the middleware. The order entry task need not rely on the results of any activity in the manufacturing system, since its responsibility is merely one of making the information available. Therefore, typically where a piece of remote work returns an acknowledgment to the calling module, and the acknowledgment is not necessary for the calling module to carry out or complete its task the apparent processing dependency can be resolved as an informational one. 6.2.2 Transactional Versus Non-Transactional Dependencies A common source of ambiguity occurs when we try to determine the dependencies between two data entities with some business relationship tying them together, for example, insurance policy and agent commission; order (order line) and inventory. Can this relationship be implemented in a transactional or non-transactional manner? Then there is the case of replicated data: when a local process updates local data, should the update of remote instances of replicated data impose a transactional or non-transactional dependency? Below, we examine these cases. Dependencies Between Different Entities Consider an insurance premium administration task (Fig. 6.1), which registers a premium payment by a policy holder against a policy. Each policy has an agent, who receives a commission from each premium payment. If applying the premium and applying the commission are not implemented together as a transactional unit of Software Dependency 3 work, there will be a transient inconsistency in the system between the time of update of the premium and the update of the agent’s commission. In general, if this inconsistency can be tolerated, then there is no impediment to implementing the functions in a non-transactional manner. One possible avenue is as follows. The order processing task has a processing dependency only with the module responsible for premium registration. Once the premium is registered, then this information is publicized, and the agent administration system “picks up” this information to update the agent’s commission. Commission Policy/ Customer Agent Accounts Agent Queries and Updates Premium Premium Admin Agent Admin HWY Commission Policy/ Customer Commission Agent Accounts Agent Queries and Updates Premium Premium Admin Agent Admin Figure 6.1. Resolving transactional dependencies – example 1. 6.3 Additional Examples The following text was not part of the original example, and was added in by the editors of Volume Graphics to meet the presentation requirements of the book. 6.3.1 An Example of Programming Code Segments The following style <Program> is designed for presenting code segments in the main text. The tab setting may be adjusted by authors to suit the complexity of the code. The Times-New Roman font may be used to present comments as it takes much less space than Courier-New. 4 Example, McAuthor and Nother -------------------------------------------------for i:=0 to 100 do {initialisation} array[i] := i; end for; -------------------------------------------------- 6.3.2 Examples of Equations The following equations (Eqs. 6.1 and 6.2) are constructed using Microsoft Equations 3.0 with the examples from the pre-print of the International Workshop on Volume Graphics (including Chapters 10 and 17). exp LUT1 8 j k i , j , j k i , j j i a 45 LUT1 8 j , j i k , j , j i k exp j k vil, j , k ik ik (6.1) v l vil1, j , k i 1, j , k l l vi , j 1, k vi , j 1, k v l l v i , j , k 1 i , j , k 1 (6.2) These equations are inserted as objects (under the Insert Menu). The recommended settings for Microsoft Equations are listed in Table 6.1. Table 6.1. Recommended settings for Microsoft Equations. Size Settings Style Settings Type Size Type Font Bold Italic Yes Yes Full 10 pt Text Times-N.-R. Sub/Superscript 8 pt Function Times-N.-R. Sub-sub/superscript 6 pt Variable Times-N.-R. Yes Symbol* 16 pt L. C. Greek Symbol Yes Sub-symbol* 10 pt U. C. Greek Symbol Yes Symbol* Symbol Maxtrix-Vector Times-N.-R. Number Times-N.-R. * e.g. summation, integral. Yes Software Dependency 5 6.3.3 An Example of Tables In addition to Table 6.1, another example table is given in Table 6.2, which was constructed based on a table in Chapter 12. It is recommended to use 1/2 pt double lines for the top and bottom boundaries, and the separation line underneath the column headings if there is any; and to use 1/2 single lines for the rest. 1/2 dotted line may also be used to provide further divisions. Table 5.2. Comparison of distance transform execution times. Distance matrix Average execution time (sec.) Average time to render a 300x300 image (sec.) City Block 10.016 141.211 Chess Board 26.266 163.493 2 28.166 161.577 226.408 142.244 5x5x5 6.3.4 Predefined Styles Table 6.3 lists the main “styles” pre-defined for this book. Please do not make major changes to these styles unless you are sure that this would not lead to inconsistency with others. However, it is necessary to change some properties of these styles from time to time. It is often better to define a new style based on what is necessary. Do not switch on the automatic style redefinition. In case that some of authors are not familiar with MS-WORD97, the following changes may sometimes be necessary because of the default settings on individual computers: Changing the Language Setting for Spelling <Format Menu>, <Style ...>, Choose “Normal” in Styles Window, <Modify ...>, <Format>, <Language ...>, Choose “English (British)” or “English (United States)”. Changing the Measurement Unit This template is designed to use metric units. <Tool>, <Option ...>, <General>, Choose “Centimeters”. Changing Paper Size <File>, <Page Setup ...>, <Page Size>, Choose “A4 210 x 297”, <Margins>, Make sure the margins are set as Top: 5cm, Bottom: 4.7cm, Left: 4.5cm, Right: 4.5cm, Gutter: 0cm, Header: 4.1cm and Footer: 4.3cm. 6 Example, McAuthor and Nother Changing Equation Settings <Insert>, <object ...>, <Microsoft Equations 3.0>, <Style>, <Define ...>, and repeat this process for <Size>, <Define ...>. Unless you are editing an equation, you could add an unwanted blank object into the document after this process. Table 6.3. Predefined styles. <Normal> This is used for the main body text. Please note that it is defined as an indented paragraph. For the first paragraph in a section, the indentation has to be removed. In MS-WORD97, you may remove the indentation by simply typing the backspace key, or adjusting the margin ruler. <Heading 1> This is used for a chapter heading. <Heading 2> This is used for a section heading, i.e. at the 1.2 level. <Heading 3> This is used for a sub-section heading, at the 1.2.3 level. <Heading 4> This is used for a sub-section heading at the 1.2.3.4 level, without explicit numbering. <Heading 5> This is used for a sub-section heading at the 1.2.3.4.5 level, without explicit numbering. It is not recommended to use a heading at this level unless it is absolutely necessary. <Author> It is used for author names under a chapter heading. <Equation> It is used for equations. <Caption> It is used for figure captions or table captions. <Figure> It is used for figures. <Table: Item> It is used for items within a table. It is currently defined as a centered paragraph, but authors may change the alignment according to their needs. <Table: Heading> It is used for headings (either column headings or row headings) within a table. <List: Bullet> It is used for bullet points with a correct hanging distance. <List: Number> It is used for numerically-ordered lists with a correct hanging distance. <Header> It is defined for running headings. <Program> It is defined for program code segments. <Reference> It is defined for references. Software Dependency 7 References 1. Kaufman K, Cohen D, Yagel R. Volume graphics. IEEE Computer 1993; 26(7):51-64. 2. Wang SM, Kaufman A. Volume sampled voxelization of geometric primitives. In: Proc. IEEE Symposium on Volume Visualisation, Los Alamos, CA, October 1993; 78-84. 3. Wang S, Kaufman A. Volume sculpting. In: Proc. Symposium on Interactive 3D Graphics, April 1995; 151-156. 4. Galyean TA, Hughes JF. Sculpting: an interactive volumetric modeling technique. ACM/SIGGRAPH Computer Graphics 1991; 25(4):267-274 5. Avia RS and Sobierajsk LM. A haptic interaction method for volume visualisation. In: Proc. IEEE Symposium on Volume Visualisation, San Francisco, CA, October 1996; 197-204. 6. Levoy M. Efficient ray tracing of volume data. ACM Transaction on Graphics 1990; 9(3):245-261. 7. Laur D and Hanrahan P. Hierarchical splatting: a progressive refinement algorithm for volume rendering, ACM/SIGGRAPH Computer Graphics 1991; 25(4):285-288 8. Preparata FP and Shamos MI. Computational Geometry: An Introduction. Springer-Verlag, New York, 1985.