Re: Is it a facade

Responding to Sanjay...

Now this audit record is what every application is interested in and
can build using the classes that are well defined ( _subsystems_  ).
Now we think of giving API's to these exisitng applications ( _clients_
), so that the clients deal with API's that are interfaces taking
simple context information.


This is where I am getting lost.  Who is building (instantiating?)
classes from the audit record?  Why do you see these as subsystems?  (In



The classes inside the Audit Module under consideration is building
this Audit record.

OK, so the Audit Module itself may be a subsystem requiring several objects from different classes to build the audit records.

Normally an original audit record is pretty simple and is easily formatted into a DB update query of file record write. So I am getting the impression that this auditing system of yours is not a typical financial auditing system. (Or the processing here is some sort of second tier consistency analysis of the audit records vs. actual transaction records.)

my world a subsystem captures a particular <large scale> subject matter
that is implemented with multiple objects from multiple classes.)

These "other applications" seem to just need the audit record.  So why
don't they read it from the file and process it (i.e., the original
audit module is now out of the picture)?



I guess I didnot complete my problem, the audit record is not for the
clients. They are used by the Audit Module under consideration to
generate reports.

Hmmm. In you situation requires multiple objects to /build/ the audit records. The records are then stored persistently. At some point -- presumably later -- the audit records are used to create reports. Generating reports usually requires a suite of objects that abstract the invariants of reports (e.g., Heading, Page, Paragraph, Table, etc.).

All this complexity suggests to me that building the audit records and creating reports from them are two quite different subject matters. Their separation in time also suggests this (i.e., the context for each activity is different, probably with different clients). So that suggests to me that the report generation also wants to be encapsulated in its own subsystem. Then we would have a system view that looked something like:

[Auditing Client]               [Reporting Client]
       |                                |
       |                                |
       V                                V
[Audit Record Creation]         [Report Generation]
       |                                |
       |                                |
       +-----------> [DB Access] <------+

where the arrows indicate flows of requirements in client/service relationships.

The clients systems help the Audit module under consideration to build
an Audit record.

You will have to put more words around this also. In particular, what do you mean by 'help'?

I would expect that other subsystems just generate events when they do certain processing and those events are directed to the Audit Record Creation subsystem. But all the processing of the event would be in the Audit Record Creation subsystem.

[Isolating audit processing from the processing that's being monitored is a pretty fundamental security issue. An auditing system may access other data persisted by the other subsystems to check consistency with the event data packet and whatnot but they are unlikely to directly access the other subsystems because that would provide too much information about how the audit records are created and the audit process itself. IOW, the auditors want to make it difficult for the developers maintaining the other subsystems to "cook" the audit records.]

Why do the other applications need APIs rather than the audit record
whose information they access?



These API's are interfaces for the client system to build the Audit
records.

Hmmm. I'm still missing something. More and more I am getting the impression you aren't doing financial auditing here. B-)

Usually auditing is event-based. The event data packet contains the necessary information to describe what happened in the source system (e.g., a Deposit transaction in banking software). So the only interface the clients need is a single event message of {event ID, <data packet>}. They would need to understand how to form the data packet for each event, but once the event is formed the API is pretty simple to "push" it.

These API's are exposed to the clients through an interface called
AuditManager class.


Since you don't have a particular application in mind we can't abstract
identity from a particular problem space entity, so I guess I'll have
ignore my concerns here.  But XxxxManager still makes me queasy.  B-)



Do you still see any concerns here, I am unable to understand your
concerns.

Any time one sees an XxxxManager class name the odds are very good that it is a god object designed to coordinate (sequence) collaborations among other objects. Such classes are essentially higher level nodes in a functional decomposition tree. Since OO collaborations are supposed to be peer-to-peer, that is a Major No-No in OOA/D. IOW, there should be no middleman objects sequencing collaborations. So such a name is like waving a red flag to a reviewer.

[There are situations where an entity in the problem space actually has exactly such coordination responsibilities. However, those situations tend to be rare so one would still have to justify that it exists with the reviewer.]


*************
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



.