Business Rules and UC

[«Midnight»]

I was responding to the "internal" in

the UC internal requirements are actually responsibilities.

[Paolo F Cantoni]

David,

I don't like the idea of distinguishing between an element's internal versus external requirements - to me it's a bit of a non-sense.  However, when Sparx said (in the context of classes) that they were the class' Responsibilities, it made sense (at least to me).

Now, that requires that the tab marked Require be changed.  However, because of the polymorphism, that tab will appear in many other Element types (such as UseCases)..  The concept of an element's responsibilities may not apply to all subtypes of elements...

I think responsibilities are primarily for Objects and Classes (coming from the CRC card process).  Since a UseCase often cuts across a number of Objects, the notion of a UseCase having a set of responsibilities is somewhat suspect.

In fact, I recently observed (in an offline post to Jim Shaw) that just as we have the well known Semantic Impedance between the OO Model and the Relational Model, there is a similar semantic impedance between the Functional (UseCase) Model and the OO Model.

Thus we have an impedance mismatch at both ends!

It is the bridging of these semantic impedances that constitute the more significant challenges for modern systems design.

HTH,
Paolo

[jeshaw2]

I think responsibilities are primarily for Objects and Classes (coming from the CRC card process).  Since a UseCase often cuts across a number of Objects, the notion of a UseCase having a set of responsibilities is somewhat suspect.
 
In fact, I recently observed (in an offline post to Jim Shaw) that just as we have the well known Semantic Impedance between the OO Model and the Relational Model, there is a similar semantic impedance between the Functional (UseCase) Model and the OO Model.

At least one published author has taken the position that even though most of the UML is object oriented, use cases were not.  Be that as it may, many other authors in the OO community define an object as something we can talk about and to which we may assign a unique name.  

My take on this is that a use case is something we may talk about and also assign a unique name; therefore a use case may be considered to be an object.  Agreeing with Paolo then, I can conceive of talking about the use case's responsibilities.

Some of these responsibilities might be:

• Effective pursuit of the actor's goal;
• Realization of a subset of the system's requirements; and,
• Fulfilling the promises of the Post-conditions
  

Perhaps there are others hidden around somewhere in the use case?  Does it make sense to bring them forward in some organzied way?  Doing so, might be useful in defining topics for the quality assurance folks to look after.

[TrtnJohn]

I find the idea of documenting a use case's responsibilities attractive, but none of the textual use case templates I've run across seem to include a Responsibilities section.  Is this something I should be considering for the future?

Doesn't the structure of your template define the responsibilities?  Each Use Case instance has different entries, but it seems you had to define the responsibilities of a Use Case before you could have a template that describes it?  

[Paolo F Cantoni]

[size=13][SNIP][/size]
My take on this is that a use case is something we may talk about and also assign a unique name; therefore a use case may be considered to be an object.  Agreeing with Paolo then, I can conceive of talking about the use case's responsibilities.
[size=13][SNIP][/size]

Well Jim, it may be an object, but not as we know it...

You may be agreeing with me, but I'm not sure I'm agreeing with you.

To be an object, the thing has to be an instance of a Class.  If anything, it might be a meta-object.

In my view, it would only become an object if we were modelling a modelling application (such as EA).

That having been said,  I like the idea of documenting the goals or outcomes (from bruce's suggestions elsewhere)  against the UseCase.  They can be displayed on diagrams by switching to rectangle notation and displaying the responsibilities.

If you wanted to go "the whole hog", one could conceive of the the idea of Design by Contract being applicable to UseCases and documenting the pre-conditions, post-conditions and invariants (during the execution of the UseCase) in this section.  In fact, if we renamed the section Contract, then the aforementioned Responsibilities of a Class would fit right in!

Thoughts?
Paolo

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

[jeshaw2]

Paolo;

I'm comfortable with all that you said here with the possible exception of

To be an object, the thing has to be an instance of a Class.

I may be taking this quote out of context but:

• A class defines a classification of objects sharing common features
• A truly unique object would not have features common with other objects and thus would not fit any classification; but it would still exist. Take me as a case in point.    Mom always said I was unique...
• Thus, class membership is not a prerequisite for an object's existence
• The UML allows a <<generalization>> relationship between use cases.  Does that not allude to the possible existence of a use case class structure? Or are we talking about a different kind of class too?
  

The rest of your comments are exactly what I'm talking  about.

Additionally, I'm thinking that it is the primary actor that might have the responsibilities, the actor / use case relation is like my man with the mechanical arm.  Is the arm part of the man struggling with the environment, or is the arm part of the environment with which the man is struggling?  

Put another way, can a use case exist without an actor? Perhaps more strangely, given that an actor is a role, can an actor exist without a use case (be it manual or automated)?

I'm postulating the existence of an abstract composite structure some where having both the actor and the use case as components, and it is that abstract composite that has the responsibilities.  Perhaps I'd be more correct talking about a collaboration between an actor object and a use case object?  But then, perhaps, I've been helping myself to too much of Bruce's beer in the fridge.  

[jeshaw2]

To be an object, the thing has to be an instance of a Class.  If anything, it might be a meta-object.

Thinking a bit further on quote...

Actually, one may view a use case to be a class from which multiple objects may be instantiated.  We call these objects scenarios.  Each scenario is a specific control flow path through the network of activities performed in the use case

Just thought I toss that out for consideration

[sargasso]

I like the idea of documenting the goals or outcomes (from bruce's suggestions elsewhere)  against the UseCase.

I think there is a distiction between the "goal" of a usecase, which is a viewpoint exposing the need for the usecase and the usecase responsibilites, which to me are at a next lower step of the analysis.

Consider the call centre operator,  ask them what their ptrimary use case is and 99% will say "Answer the Phone".  On my planet this is NOT the use case at all.  Using the "piece rate" filter, I cannot imagine a manager paying an operator 20c per "connected call" (conectline1-hangup-connectline2-hangup-connectline1, ...) therefore it is rejected  automatically from the model.  However, let's let it go through to this step in the analysis. The goal would be "allows operator to service customer"  whereas the UC responsibilities would include such things as "creates call log entry", "removes call from queue", etc

bruce

[bioform]

I am currently using internal and external requirements this way....

Features (External) mapped to (High-level Functional) Requirement (External)

Furthur decomposition into child.derived HLF requirements (External),

then when this decomposed requirements clearly map to my UCs, any furthur decomposition is done as (internal) Requirements...

I find that the internal requirments tend to follow recurring patterns that allows me to leverage the pattern across all UCs as appropriate...

Additionally I create "logical" UI screen objects (no UI details, just use the screen as the container for the BRs that are implemented through these UIs...

So when I look at the heirachy view of a requirement, I see links to: HLF req (external), UCs that have relationships with this UC (extends, includes, etc.), actors associations (person/system events), UI that realize the UC, and business domain objects that have an association with the UC... This seems to make for VERY robust traceability and with the Hierachy window up helps with both navigation to the objects (via double-click or Usage navigation) details and quickly visualizing scope...