I'm a little lost in much of the above detail, so what I say may cut accross some of it. There are clearly many aspects I agree with.
There are four layers of validation required:
Character Level: Alphas where only numerics are acceptable etc. They are just part of field level validation.
Field Level:- Age < 16 etc. These can be tested in the UI (client) or on the server side.
Form Level:- Maiden Name required if married female etc. Again these can be client or server side: client side needs rules and data, server side is a bit slower (thick/thin client and all that).
System Level:- That Bank Account is NOT a savings account. etc. These can only be carried out on the server side.
The possible server side Levels map nicely into OO classes.
Field Level -> Constraint on an attribute in a class
Form Level -> Constraint on the class, checking some link between attributes
System Level -> three different types:
Pre-condition on a method:- is status correct etc.
Post-Condition on a method:- did it perform the correct algorithm
Contraint on an Association:- you can only borrow a maximum of four books from the library.
All the functional business rules MUST belong to one of these five cases or a use case description.
Now, take the n-tiered (more than the old fashioned 2 or 3 layers) architecture, and assume checking is done on the server side.
UI may need data for the form and may return data to it. This is normally provided as a Data Transfer Object or DTO. Mostly this will look like one of the business class with a few differences:
Not all attributes will be included,
Some other classes may have been 'joined',
Inheritance classes will have been flattened, because most remot UI APIs cant handle items more complex than 2D arrays.
In a Web system, this DTO is used to create a page of HTML; using either JSP, ASP or similar. In an on-line application the DTO is used either by the Swing, VB etc. Both systems have callbacks or other methods of detecting the arrival of some user input. By then, any client-side checking will have been completed client side checking allows immediate feedback at the field level if necessary.
The next few tiers or sub-tiers deal with security, session management, transaction control etc. These may produce errors to be reported using the mechanism described below.
At the bottom of this heap is the lowest level Application Controller. This more or less reflects the steps you wrote in the use case. Its job is to call the Business Objects as outlined in the sequence diagram. Again, it may find errors in its own right, but mostly, it will just pick up errors from the Business Classes. This is where the constraints listed above are used for validation.
Now we need to get the errors found back to the UI. Getting them back to the Application Controller can be done as you like; exceptions or error classes are fine. in the Application Layer, they need to be packaged up into reader friendly reports. To do this, the common method is to create and error page (panel) which is either displayed on its own ot at the top or bottom of the original form. This of course is done by the JSP,ASP, VB, Swing or whatever.
Finally, you need to think about client side validation.
The standard approach is to ensure that all validation is done server-side, because
you dont have 100% control of some clients
they may be language specific (as you say)
you may want to swap the UI software from Swing to JSP or JSP to Flash etc
all the constraints are in well defined places in the use cases and on the classes, and can more easily be made reliable, tested etc.
marshalling of all errors found are more easily found because you can use exceptions etc
However there can often be big improvements in performance if they can be done on the client side. A common approach is to duplicate the tests on the client side. In this case, it is only necessary to have the most common ones done on the client side, because a complete check will be made on the server side.
Gil
