Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: What You Must Do

 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
This posting again focuses on only one statement in the requirements to determine
if this one statement is sufficiently unambiguous with respect to fat or thin clients,
and more specifically, whether or not Data must expose it's methods to the client.
Quote:

What you must do
The following are the "top level" features that must be implemented:
1. ...
2. A data access system that provides record locking and a flexible search mechanism
3. ...

Points (1) and (3) do not relate to the question. Item (1) simply means that every
client will have a GUI, and, in some unspecified fashion, it will connect to the database.
It does not specifically mean that Data will expose it's methods to the client. Item (3)
simply means that the database can be reached from the client through the network.
The only phrase to parse is item (2). Let it be assumed that the "data access" class
is indeed Data, as that is explicitly stated elsewhere. The statement is then re-written
thus:
"A data access system called Data that provides record locking and a flexible search
mechanism,"
Note the immediate clash between the words "system" and "Data". This is too much.
Maybe it is inappropriate to substitute Data into this phase. "system" certainly suggests
something greater than just Data, which would allow Data to co-exist with other objects.
But, for the remainder of this post, even though it is somewhat forced, let's assume,
and very likely quite incorrectly, that "Data" can be substituted into the above phrase.
The word "provides" does not in and of itself suggest anything about what goes where and
what methods are exposed to whom, as Phil has quite correctly pointed out.
The phrase "record locking" simply means that a logical record locking will provide
maximal concurrency for the server, but does not necessarily mean that the client
has to actually call lock() and unlock().
That leaves only one sub-phrase to parse: "data access system." What does this mean?
Well, it is, obviously, a system to access data, or software to access data, or more
specifically, a class to access data (note, however, that it is, I think, inappropriate to
refer to one, single class as a System!, but we are being generous here). Let's draw a chart:

Does the above diagram conflict with the use of the phrase " 'top level' features"? Or would
the following diagram be more accurate?

Or do both diagrams make sense?
What are your opinions?
There is no doubt in my mind, that so called "top level" features can certainly be
embellished: think, for instance, of Shenker diagrams in music. Yes, you have
structural tones:

but you also have the actual music, the actual implementation, the actual appogiatura,
which changes the "top level" features to a specific realization, a specific design, such
as

My opinion is that the use of the phrase: "top level" features, simply denotes a crude outline,
and it does not imply that Data must expose its methods to the client. Is Data a top level
feature: yes. Is Business Methods an embellishment? yes. That is, given the context that
Sun has told us that Data is a "top level" feature. Business methods is like in
music an embellishment, which "smooths the flow" of the musical conversation, elevating it
from crudeness to art. No one listens to Shenker diagrams! They listen to detailed
implementations, they listen to art.
You should not, in my opinion, erroneously jump to the conclusion that embellishments,
borrowing a term from music, are bad within a software design implementation. For this
clearly is not the case. Designs are iterated, classes added, subtracted, modified, all to
make the final result comprehensible to the designer and developer. These changes
for the most part involve embellishments, such as the the following:

where MicroData has all its methods synchronized, and each method focuses narrowly
on simple reading and writing raw bytes.
So, one would be quite incorrect to say that any embellishment is an "extra"; coherent
design and implementation thrive on precisely conceived embellishment.
If Sun's intention was that Data expose its methods to the clients, then clearly Sun has
failed to state this in an unambiguous fashion. It is unclear why Sun doesn't simply
come forward and say what their intentions were in this matter: either they goofed and
decided to live with it, or they decided it didn't really matter, or they decided it didn't
really matter and for future exams they would try to make this clearer (such as posted
in this group, a new exam stated quite explicitly that Data's methods must be exposed
to the client). It's also possible that Sun really did consider both options as viable
solutions, and that they never goofed, and that we really are suppossed to agonize over
this topic! Nevetheless, it would certainly save me a lot of grief considering this issue if it had
been made clearer; is this conversation really helping my Java design and development
skills? Ironically, it is. For I keep comparing the two options; but, if Sun had simply said
expose or don't expose Data's methods to the client, I would not have thought about it
as much. Finally, it makes us consider what a design embellishment is, and philosophically
consider its merits and contributions to coherent and reliable software applications.
Here is one final consideration, Data implements the DBMain interface. Does this
sway the argument one way or the other? Not really, it just means that the designer new the
power of coding to interfaces. One implementation of DBMain might use java.nio, another
implementation might use a RandomAccessFile, and still another implementation might use
an in-memory cache, and so forth. Therefore, again, there is nothing here to suggest that it
is a requirement that data expose it's methods to the client. By coding to interfaces, when
the server is designed, different implementation of DBMain can be experimented with.
Thanks,
Javini Javono
[Obviously, when considering your instructions, you must read all instructions and weigh
them accordingly; this specific post focused and parsed one specific instruction to see if
it, in and of itself, was unambiguous.]
[ February 20, 2004: Message edited by: Javini Javono ]
[ February 29, 2004: Message edited by: Javini Javono ]
 
janvy wei
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,javini.
IMO,i think the whole instructions don't tell us Data must or must not expose it's methods to
the client.
it's free for us to expose it's methods to the client or not,it's just our design.
A data access system called Data that provides record locking and a flexible search
mechanism

we could has only one Data class to represent the data access system,or have some
classes to do it.the emphasis is "record locking and flexible search".
Let's draw a chart:

code:
--------------------------------------------------------------------------------
Client says "Give me data" --RMI--> Business Methods --> Data --> Database representation.
--------------------------------------------------------------------------------
Does the above diagram conflict with the use of the phrase " 'top level' features"? Or would
the following diagram be more accurate?

code:
--------------------------------------------------------------------------------
Client says "Give me data" --RMI--> Data --> Database representation
--------------------------------------------------------------------------------
Or do both diagrams make sense?

i believe that both diagrams are OK,but the first is better.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic