Re: Interface to a file?

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



.