Re: Client/Service relationships & Flow of Requirements.

On Tue, 30 Jan 2007 18:53:09 +0000, H. S. Lahman wrote:

That's why I prefer the notion of a client/service dependency as a flow of
requirements rather than communications (invocations of behavior). Thus a
UI service might send a message to the Client that causes the attributes
of the a bunch of Client objects to to written to an RDB through a DB
Access service. The cause-and-effect is UI -> Client -> DB Access rather
than Client -> UI followed by Client -> DB Access as a sequence controlled
solely by the Client.

Ah! Ok. I agree with that and I think that pinpoints the source of our
disagreement over "call graph".

I regard "call-graph" being a mathematical digraph
http://mathworld.wolfram.com/DirectedGraph.html
where the nodes are symbol declarations and definitions. And
the edges meaning "depends on" are from definitions to declarations, from
declarations to declarations of symbols referenced in the declaration, and
definitions to the declarations of symbols referenced in the definition.
And that must be acyclic.

The "calling sequence" in terms of at run time, this function runs, then
that one, then that one... can and will often be cyclic.

--


John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@xxxxxxxxxx
New Zealand


.

Quantcast