Collaboration Messages advice

[sargasso]

According to Iconix, actors should not have associations with or pass messages to controller objects.

I am trying to sort out in my own mind how best to model active web pages.

The user sends a GET message to the web server listener which responds with a html page.  Now, on that page is a form that has a submit action of POST.  The server listener is supposed to receive that request, process it and generate a response page via its page engine.

It appears to me, that either I have to include the browser and webserver listener which are components not objects in the collaboration chain, or the user can send a message to a controller (the ASP script)?

Has anyone got any good ideas?

[mchiuminatto]

Hi Sargasso.

I've never read ICONIX, I prefer to read the source better. And from the source (Rumbaugh, Booch, Jacobson):

"Actor instance communicate with the system by sending and receiving message instances (signals and calls) to and from the use case instances and, at realization level, to and from the objects that implement the use case. This is expresse by the association between the actor and the use case" (Unified  Modelong Language, The eference Guide )

You could  show the interaction between Actor (Operation Invoker) and the controller object (Web Server Listener) by means of a collaboration diagram or a sequence diagram as you like.

If this does'n solve your proble, let me know why.

Regards

[JourneymanDave]

The reason that may still be unclear is that a Controller object, by definition, has no directly accessible interface through which the Actor can reach it.  Providing that interface is the responsibility of the Boundary object.  It's about clear division of responsibility really, which promotes more optimal coding practices and greatly enhances maintainability.

This common problem is modeled in the MVC design pattern (Model, View, Controller, see Design Patterns; Erich Gamma et al).  In practical terms for ASP, the design plays out this way:

The user interacts with a form page (ASP/HTML with formatted content and controls), which POSTs to another ASP (this time, only containing the script logic, with no interface), and during that processing it may interact with a data store, and when done it calls another presentation page (ASP/HTML) to format and present the output.  

The flow of control in MVC terms would go something like:  Actor -> View object (ASP/HTML) -> Controller object (ASP) -> View object (ASP/HTML).  The Controller object may/may not access a Model object (data store) during that interchange.

BTW, the MVC terminology is analogous to the ICONIX terminology of Boundary (View), Control (Controller), Entity (Model). If you look at EA's Analysis diagram toolbox, you'll find these objects available for modelling using the ICONIX terminology.

[JourneymanDave]

Sargasso, I'm wrong in part of what I said.  ICONIX still says you can't get directly to a Controller object, but MVC disagrees.  I went back and reviewed the Java Model 2 architecture, which is basically the Java-weenie version of MVC.  It specifically calls for the user to interact directly with the Controller.  

Here's a link to a related article for your review: http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html.  

So, this means then that the flow for Model 2/MVC would go more like:
Actor -> Controller -> Model -> Controller -> View

Fundamentally, this is a architectural difference in the way these two viewpoints see the design.  I should have looked at this material again before I opened my mouth.  You're still left with a question of how to model this though, and I don't know whether the boundary/control/entity diagram elements will allow the latter version of this design to be modelled in EA.