Hi all > Even though we use RUP, we try to avoid the controller, > entity, and 'the > stereotype I can't recall' classes. I see no value in using > the stereotypes > (especially in analysis). BTW, I'm really surprised that the three > stereotypes are even recommended for analysis: They seem > more like a design > concept (one of which I'm not all that fond). The "other stereotype" is <<boundary>>. The way RUP works is that in use case analysis you do the following: For every use case, you would work on one use case realisation that would detail the classes you need to make that use case work. You are allocating responsibility around these classes, drawing class and interaction diagrams (sequence or collaboration diagrams) to work out the best allocations of responsibility. As a starting point, you can use the analysis stereotypes of <<entity>>, <<boundary>> and <<control>> in the following way: 1) For every actor linked to that use case via a <<communicates>> association, put in at least one <<boundary>> class. You may add more than one, but these are all placeholders for later work, esp during design. <<Boundary>> classes are the link between the rest of the classes in the use case realisation and the outside world and would later be replaced by UI's or system interfaces of some sort. 2) For each use case realisation, you add a <<control>> class to make sure the flow of events in the use case happen in the right order - the <<control>> class controls the use case realisation (not the system). This usually gets factored out later in design into more classes/subsystems or nothing if the logic gets allocated to the other classes. 3) Anything else you need in the use case is probably an <<entity>> class and should be carried through from your business model (if appicable), domain models or key abstractions in the problem domain, or from the flow of events. These <<entity>> classes are usually persistent. So these stereotypes can be seen just as useful visual indicators, and a way of organising your thoughts in this stage of the A&D workflow. I find people get some value out of having some almost mechanical way of starting to populate the use case realisation - so they don't just start with a blank sheet of paper for each use case realisation. There is more to use case analysis in RUP (now broken into slightly different steps in RUP 2000/2001) - but hope that simple explanation helps a bit to understand why we have these stereotypes. If these stereotypes cause confusion, then it is quite OK to leave them out. regards anthony ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Admin.Subscription Requests: [EMAIL PROTECTED] * Archive of messages: http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * * To: [EMAIL PROTECTED] * Subject:<BLANK> * Body: unsubscribe rose_forum * *************************************************************************
