Download 6. Software Dependency

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


ik


 ik


(6.1)

v l
 vil1, 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.