Walter,
I was not speaking about inherance, this is another very interesting part of reflexion, I began to write a paper about it some month ago thinking about how to model "use case inherance" withing UML specification. I didn't find an ideal way to give a strict specification for a generic implementation. Because extension could be seen in 2 differents ways : 1 - Inherance from the object paradigm : polymorphism, generalization 2 - Extension from the use case model paradigm : grain fined analyse. In short : in the first one, we want to reuse : comportement, data, presentation from the "parent" in the second one, we want de propose sub fonctionnality to module main use case ( create item <<extends>> manage item...) : ideal to create group menu, or graphic css style by example For the first case, I was thinking using this example: -> Extension create a item create a vehicule create a car where we could consider : create a vehicule as an extension of create an item, and create a car as a extension of create a vehicule. the aim of reflexion is : ok, we would like to easely reuse - persistence manipulation - high-level business process - graphical presentation. Finaly, persistence problems could be resolve by using an interface[load, save, update, remove, get] implemented.overrided by each object manipulated in th bp.(not trivial). The High level bp problems could also be mecanicly resolve.... bu problems is : how to present them, in wich order ? and, we're only speaking about Business Process Modeling, that's the most important part. Example : considere, create item Step 1 : describe item Step 2 : classify in catalogue Step 3 : define price Step 4 : define delivry parameters and "create vehicule" extends "create item": - Does it override each step ? - In each step, do we need one or mone jsp de get or display data, in wich order? - Wich field, with wich caption, in wich order do we want to appear in the jsp ? - what if we want to add a new step between step2 and 3 ? - Do we want or not to use the same css ? etc.... For the moment, it's raise for me much more problems that solutions My short conclusion about that is : it's generaly simplier and faster to manually develop specific and few jsp and to pilot them with a main activity graph with decision point. To progress in this reflexion we should decompose the concept of inherance for use case by considering: - <action state> inherance. - <action state> stereotype/properties - merge point in activity graph. what's your opinion ? regards --- What i was speaking first is more about the relation <<inclusion>> I would speak more about it in my answer to wouter. -- Michael THOMAS. Software Architect [EMAIL PROTECTED] Paris - France. _________________________________________________________ Reply to the post : http://galaxy.andromda.org/forum/viewtopic.php?p=1851#1851 Posting to http://forum.andromda.org/ is preferred over posting to the mailing list! ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Andromda-user mailing list Andromda-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/andromda-user
