Re: Interface to a file?

H.S.,

First of all, many thanks for the detailed reply, as always instructive and
provocative.

So if I get the idea, the idea is that at the logical/design level the file
shouldn't really exist, since it's really just a realization of a
persistence mechanism. If anything, there might be an access layer that
allows the application to see the persistent data the way it likes, or if I
want to get close to the idea of a file, then have a File object with the
appropriate access operations as you describe below.

Then if I want to show that there really is a file realizing the
persistence, I can do that in a deployment view.

At least that's more or less what I think you were saying ...

thanks again,

John

"H. S. Lahman" <h.lahman@xxxxxxxxxxx> wrote in message
news:Bs54g.7931$cc.7495@xxxxxxxxxxx
Responding to JMF...

This is a UML modeling question. Consider a component that accesses an
external file for some configuration data. Suppose it's simply an ASCII
text file with the data in some sort of format. So the component will
open the file and read the configuration data.

The question is how to model this situation.

What is actually that file? It doesn't seem to be an "object." It doesn't
have an interface of its own -- it just gets read.

That is correct. Persistence is something external to your software
application. The solution to the customer problem that the application
provides should be indifferent to whether the file is ASCII or binary, or
whether it is stored in flat files, an RDB, an OODB, or on clay tablets.


Some colleagues are saying "the file's interface is its format." I see
what they're getting at - it's a bit like the schema for a database. But
it still doesn't seem right at all. On the other hand, the format of the
file is clearly a factor. Change the format and the calling component has
to be changed, so there's some kind of dependency there.

This is almost correct. Persistence must provide some sort of access
mechanisms, which can be anything from C's fgets to SQL. You don't have
control over that unless you are also designing the persistence
mechanisms.

OTOH, the problem solution has its own specialized view of the problem
data. That may or may not closely match the structure the persistence
mechanisms provide. To be independent of the persistence mechanisms, the
application solution needs to invoke an interface that is designed around
its view of the data. That allows the application to access persistence
in exactly the same way even if the persistence mechanisms change.

So how does one get from the interface that the problem solution wants to
use and the interface that the persistence mechanisms provide? One
essentially needs a mapping function. Typically that will be an
application subsystem or layer that is responsible for providing the
conversion. Then if the persistence mechanisms change, one only needs to
touch that subsystem.

Note that the layered models that support CRUD/USER processing already do
this and they provide infrastructures like MVC that provide the interface
conversions "behind the scenes" in layer interfaces. However, that only
works well if the persistence paradigms are fixed (e.g., RDBs) and the
data needs are driven by fixed UI paradigms (GUI, or web browser), which
is exactly the case in RAD applications for USER/CRUD environments. As
soon as one is outside the realm of CRUD/USER processing where the problem
being solved essentially is just converting views, that sort of pipeline
architecture tends to break down and one needs to provide one's own
interfaces to persistence.


At deployment time, the file surely is an artifact. But at design time,
what is it? Since the component accesses it, one would tend to think
there's an association between component and file. But I tend to
associate an association with the ability to call an operation - but as I
said, this plain old ASCII file doesn't have operations, it just sits
there and gets read.

Deployment is a separate concern from the solution and persistence access
logic. You can use a UML Deployment Diagram to describe how the notion of
'file' fits into the scheme of things. [Whether you have a File object in
your persistence access subsystem will probably depend upon the interface
that the persistence mechanisms provide. For flat files using something
primitive like fgets, then you probably will have a File object that
handles things like opening and closing the file and reading lines. If
the interface is SQL, then the notion of 'file' is likely to be
superfluous.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH





.

Relevant Pages

  • Re: Abstract public member variales?
    ... I submit that writing the Composite tree back out to persistence is a symmetrical operation with the factory ... Just as a factory object needs to know what the object is to invoke the correct constructor, the persistence object needs to know what the object is to invoke the right deconstruction method. ... In Serializer it is elegantly polymorphic because a common interface to the grunt code was provided. ...
    (comp.object)
  • Re: in need of a pattern
    ... A classic problem of changing one's mind about persistence mechanisms. ... consistently by both the problem solution and the RDB access. ... solution (which for a RDB would probably be a Table and a column)? ... First design the interface. ...
    (comp.object)
  • Re: Abstract public member variales?
    ... I like to make heavy use of composition and polymorphism in the factory for my objects. ... You need to read its attributes, convert referential attributes to identity, and write them to the persistence mechanism. ... Converting references to object identifiers is trickier but it is essentially the same activity you would have to do in the protocol method in if was composed from. ... It is just going in the other direction, so let's call it an "interface object" in deference to Ivar Jacobson. ...
    (comp.object)
  • Java design pattern question
    ... looking for a way to abstract a persistence layer interface in a way ... I've implemented the persistence layer as a package of three ... The main data store interface holds all the usual ... I'm still pretty new to patterns and Java, ...
    (comp.lang.java.programmer)
  • Java design pattern question
    ... looking for a way to abstract a persistence layer interface in a way ... I've implemented the persistence layer as a package of three ... The main data store interface holds all the usual ... I'm still pretty new to patterns and Java, ...
    (comp.lang.java.help)