Hi Remi,We probably have different sorts of customers! To me, the use case often becomes a very detailed description of the expected customer experience. The operation of the UI is fundamental and though it involves object manipulation eventually, it is not that that makes the customer satisfied (IME). So JFacets may be very useful for object manipulation, but it can only be a part of the whole, the whole being the use case.Best wishesKit
You've just put good words on my feeling about the facet approach :-)
(As other froggies out here, I sometimes can't find the english words to express what I think...)
I fully agree that the customer thinks in a more "process-oriented" way, and that's why I also consider that Use Cases are the most they can see of my UML spec. I mean, they don't know about the objects behind, all they express is the visual aspect of each screen (using drawings), and the expected result of each action (probably in a textual fashion).
That's the starting point : interactions, which are defined from requirements, expressed by the customer (under torture :-P).
Then, we (architects, analysts, developers... software builders in general) have to open the black box and design the inside (the other stuff in the UML model).
To do so, we follow scenarios for each use case, and end up with a domain model.
Basically, the "back end" guys handle implementation of the persistence and business logic, and provide API so that the model can be manipulated throug a UI.
The "front-end guys" have to cerate "screens" that the user will use to interact with the objects.
If you forget about how you present the information, what you do then is display objects and interact with them (navigate through links, changing properties through forms, etc.).
Actually, the "user experience" is always the result of "object manipulation" in some way... then it's more a graphical design question than an architectural or methodological one.
Oh, yeah, btw, another interesting stuff related to UML and methodology...
Use Cases are also about actors
Typically, a Use Case is realized by
an actor, and some collaboration between objects allows it.
Facets are not only linked to object types, they also are linked to profiles
, which can be organized as a graph (like UML actors can inherit from other actors)...
This provides once again a very natural transition from the model to UI implementation !
Facets being assigned to object types
(classes) and profiles
(actors), they provide a consistent way to structure UI code related to particular use cases. In fact I do it this way 99% of the time ! The actors graph almost always ends up to a trivial JFacets ProfileRepository
mapping, and screens (or parts of screens) and events almost always end up to be implemented as facets linked to the profiles
and executed on application objects
You may check this tuto
, it briefly explains how a typical facet-based application is built.
As you'll see, the starting point is
use cases :-)
Last but not least, I think facets fit well with MDA, since they provide semantic
information about the application, independant of implementation.
As an example, I was thinking of a JFacets AndroMDA cartridge last time...
You would define the facets by creating a class in your CASE tool, stereotyping it (e.g. <readable and understandable in the model !
You know what an actor can do with any object just by following dependency links...
You could also define facet compositions, execution flows (state diagrams), generate facets for a given environment (Swing, Web, ...) and probably a lot of other stuff (I only use a little of UML actually, only the "pragmatic part of it" ;-P)...
What do you think of this ?