Question on UC generalization/specialization

[mhdhallak]

Hi everyone..

I got into a debate with a coworker over UC generalization concept. His point is that there is no such thing and he reasons that generalization has more to do with objects rather than behaviour (use cases) and that the <<extend>> sterotype should be used instead of generalization.

I myself disagree. I believe that generlization of UCs is appropriate at times.

Now I need you to analyze the following scenario and tell me what is the most appropriate modelling approach:

------------------

One of my system actors, Client Worker, must log on to the system in order to Request a Service from the company I'm modelling the system for. So, in a nutshell, a Client Worker places a request for a service which could be any of a set of, say, 10 predefined services.

Each predefined service has its own parameters that are potentially different from the other services. However, all services have some common attributes such as Service Name, Due Date, etc.

The approach I'm taking to model this scenario is to have a super UC called Request Service from which I derive 10 chilld UCs, one for each service. This is a bit complicated but I thought it's the best way to indiciate that each UC has its own attributes and information that must be provided by the Client Worker when requesting the service.

My coworker says you should only have the super UC and elminiate the child, "service-specific" UCs. If you agree with him, then where would I model the exact services and their parameters later on in my model?

[Paolo F Cantoni]

As Jim Shaw points out on the EA Wiki:
Use Case Textual Specifications

A use case is, all at the same time:

a Specialization of the BehavioredClassifier in the UML meta-model
a Type classifier;
a Behavior Specification; and,
a Scenario Template

In addition, a use case may be in a relationship with actors and other use cases. The nature of these relationships are important to the use case's behavior. Failure to grasp these concepts leads to much confusion in writing use cases.

So, since it is a BehavioredClassifier, it could be Generalized/Specialized.

However the question is should it?

I agree with your coworker.  The Services are NOT the UseCase.  Each «extended» UseCase uses the appropriate Specialized Service.  The Services should be represented as Classes.

If Generalization of UseCases were more common, it would have been mentioned in the [size=13]UML 2.1 Superstructure (interim)[/size] Specification.  That's not to say it can't happen, it's just it would be extremely rare.

My AU$0.05
Paolo

[mhdhallak]

I agree with your coworker.  The Services are NOT the UseCase.  Each «extended» UseCase uses the appropriate Specialized Service.  The Services should be represented as Classes.

I sort of agree now as well. Seems more "natural".

On a similar note, say the Client Worker has another use case called Print Client Report which he uses to print out a report from a set of predefined reports, then where would we indicate what those reports are, their structure, format etc in our model?

[Paolo F Cantoni]

I sort of agree now as well. Seems more "natural".

On a similar note, say the Client Worker has another use case called Print Client Report which he uses to print out a report from a set of predefined reports, then where would we indicate what those reports are, their structure, format etc in our model?

Firstly,  getting back to Request a Service - you should only create extension UseCases when there is an essential behavioural difference.  If there's no essential behavioural difference, then the main use case should suffice...

So, with respect to Print Client Report we can apply the same concept...

There should be as many UseCases as there are essential behavioural differences.  In this case, I suspect there won't be.  (Select Menu Item, Select Report, Enter Parameters, Execute Report)  You'll be able to create a hierarchy of classes corresponding to the different types of reports.

Does that help?
Paolo

[mhdhallak]

Firstly,  getting back to Request a Service - you should only create extension UseCases when there is an essential behavioural difference.  If there's no essential behavioural difference, then the main use case should suffice...

So, with respect to Print Client Report we can apply the same concept...

There should be as many UseCases as there are essential behavioural differences.  In this case, I suspect there won't be.  (Select Menu Item, Select Report, Enter Parameters, Execute Report)  You'll be able to create a hierarchy of classes corresponding to the different types of reports.

Does that help?
Paolo

So the keyword to look for here is essential behavioural difference. My interpretation of this is the following:

Only use extending (and rarely specializing) use cases when the extending or specializing use case essentially alters the course of the basic path scenario of the main use case. This is as opposed to when the main use case can be repeatedly applied to multiple cases where the variation has more to do with the application of the use case rather than on its essential defined behaivour.

If that's the right conclusion, then yes you've been very helpful.  

[«Midnight»]

Pretty much so.

Take a look at Scott Ambler's "The Elements of UML 2.0 Style" for some additional pointers on when specialization is preferrable to using <<extend>>.

Your coworker was correct back in the UML 1.x days. Since then the treatment of use cases has changed. While the changes appear somewhat limited at first glance, their design strongly encourages a more formal approach to use cases. If you take the trouble to do it right - which is entirely in line with what's been said and referenced above - this will produce excellent results when compared with the 'old way' in UML 1.x.

David

[sargasso]

Just to be basic:

A specialised use case, would inherit the behaviour of the general class, unless overridden Sounds silly to me.

Modelling reports:
One could if one wished, model each report as a use case.  However, the user's objective is to "obtain a (perhaps hardcopy) snapshot of (particular) information in the system".  Now thinking about that objective from the users viewpoint and not from the system design viewpoint results in us describing usually one or very few use cases that describe the interactions that occur between the user and the system in order for the user to achieve that objective.

In general, every time one of my people come up with the FAQ, I say "Go back and describe the user's (or initiating actor's) objective.  Stop designing the system and start describing the interaction(s) needed to achieve that"

hth
Bruce

[jeshaw2]

I'm still developing my Use Case article for the wiki.  (An initial draft for comments should be available in a few days.)  I'm just now begining deal with the confusion that exists around use case relationships.  

Best advice I can give now is to write your use cases without resorting to <<include>>, <<intend>> and <<generalize>> use cases.  While these features provide technically elegant use case designs, they can lead to stakeholder and developer confusion if used too liberally or incorrectly.  These special use cases are distilled out by a refactoring process; they are not used in an initial writing.

[sargasso]

 from somewhat above

then where would we indicate what those reports are, their structure, format etc in our model?

Like screen designs, UML has nothin' to say on these aspects of system design.

Since most report delivery these days is done from report generators i.e. the design activity delivers the implementation, there is no theoretical "need" to include report layout in a toolkit such as UML.  In practice....

If one can imagine a scenario where modelling report layouts is "needed" one usually finds that the issue has arisen from current or past misunderstandings regarding the information that is desired by the user ("requirements setter").  As a result prior systems have not met expectations becasue the infortmation they are capturing / providing is not what is needed by the user.

The task of the modeller using UML is to extract from the user the information need, not the report layout.  IOW, when we get to Quarterly Sales Report #16, start asking who gets this report currently, what do they use it for and exactly which bit of information on it is pertinent to each of these uses.

I wish I had a dollar for every report I have had to produce over my career that I knew full well had absolutely no business value, supported antiquated business practices and on occassions was even downright misleading at the business level.

One particular one always pops into mind.  Customer was (at the time) an extremely large international bank (now defunct - so to say).  One stakeholder demanded that the new system we were putting in produce this particular report every day and would not be put off - even when we quoted (say in today's terms, several hundred thousand dollars to code it).  This was because the system did not "store" the information in a way that could produce that report.

On delivery, I obtained permission to walk the report output around the business.

It was between one and two hundred pages of speedfold thick.  At is first stop, the clerk tore off the back (summary) page and dropped the rest in the shredder bin.  He then took a single number off the summary and calculated an apportionment based on some "historically used ratios".  These three numbers were typed up in a memo and sent to an accounting clerk sitting around 12 feet away.  This second clerk added the three numbers together and entered them in the day ledger.  The number in question was a daily total turnover in a particular financial product.  The same figure was reported online in real time - updated  every transaction in the new system - and included as a line item in the automatic GL interface.

How could such a rediculous requirement arise?  Three systems (and several management changes) ago, a breakdown of this turnover figure into sub-products was requested.  The then system did not hold the subproduct detail after the transaction had completed.  So a method was invented to create the sub product figures baseed on statistical ratios i.e. the normal daily ratios.  In the system after that the sub-product detail was available, but no single line total for the daily posting schedule.  So some bright spark came up with the idea of using the pre-exisiting report (i.e. the fudged figures) and have someone add them together.  The reason for the sub-product breakdown had now disappeared into the mists of time.

Such is the value of report design !

bruce

NB This war story is true.  They had been using fudged figures for 8 years and a business process that was entirely un-necessary and finally spent several hundred thousand on a report that they never needed.

[jhawn]

I'm wondering... I'm doing business analysis and having a time finding the line.  It appears that you are quite a bit farther along if you are trying to capture things in classes.   Does the business analysis break things down into classes?  If not, how do you document that there are different services, or different reports?

Thanks,
Jan

[Paolo F Cantoni]

I'm wondering... I'm doing business analysis and having a time finding the line.  It appears that you are quite a bit farther along if you are trying to capture things in classes.   Does the business analysis break things down into classes?  If not, how do you document that there are different services, or different reports?

Yes, Jan, the BA should be able to create classes.  Just remember that the Classes the BA creates are conceptual - that is, are at abstraction levels of CIM (Computationally Independent Model) or higher.  That way, you are describing the business environment your Use Case exists in.  The downstream architects developers will be developing the PIM (Platform Independent Model) and PSM (Platform Specific Model) Classes, which should be derivable from yours.  If they aren't, then there's a disconnect between the the front-end and back-end processes which should be resolved ASAP.

HTH,
Paolo

[thomaskilian]

...

ROFL That's a real life example I encounter almost every day. I still wonder what all this BPMxyz stuff can do about it. Business is burned into peoples brains and even the slightes changes will not be accepted. Funny enough: if for some chance the management decides to re-organize business according to some re-engineering, it will fail in almost all cases. I guess we need more social engineers...

[Paolo F Cantoni]

ROFL That's a real life example I encounter almost every day. I still wonder what all this BPMxyz stuff can do about it. Business is burned into peoples brains and even the slightest changes will not be accepted. Funny enough: if for some chance the management decides to re-organize business according to some re-engineering, it will fail in almost all cases. I guess we need more social engineers...

Thomas, in the highlighted section, you are meaning that if management initiates a Business Process Re-Engineering (BPR) effort - typically by calling in BPR experts, it will usually fail; are you not?

Having observed a few BPR "experts" and talked to them, I can put forward some reasons why the BPR efforts fail.

Care to share some thoughts on why?

Paolo

[thomaskilian]

Sure, although I might know the answer already

[Paolo F Cantoni]

Sure, although I might know the answer already

It wasn't a rhetorical question, I'm after your views...

There are a number of process improvement jobs on offer around here...

Paolo