Responsibilities - let's fix it!

[Paolo F Cantoni]

In another thread on [urrl=http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=UMLPRO;action=display;num=1149007845;start=15#15]Business Rules and UseCases[/url], I once again brought up the dichotomy within EA regarding the Require tab enabled on many classifiers.

The EA Help file says:

Internal requirements in EA are class (or any element) Responsibilities

Looking around at the various parts of EA - the majority seem to label what is being input here as Responsibilities.  Thus it seems to me that it is time Sparx put an end to this confusion and labelled the tab consistently.

However, before they do, I want to put forward this idea from the other thread...

[size=13][SNIP][/size]
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![size=13][SNIP][/size]

If the tab were labelled Contract, then one could subsume the existing Responsibilities and start to extend it toward Design by Contract capabilities.  It seems to me that Design by Contract concepts are more widely applicable to more Classifiers (and other elements) than straight Responsibilities (or the, hopefully, deprecated internal requirements).

Consistency, Consistency, Consistency! ^TM

Thoughts and votes?
Paolo

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

[sargasso]

Not knowing a great deal about this Design-by-contract approach, I'm not to sure whether using the term contract would be more of the same problem as "requirement".

A contract to me, implies two parties are involved.  This is a fine viewpoint for the behavioural features of an element but maybe not so for the overall element itself.

Then again maybe this is where the fundamental issue needs to be looked at.  EA seems to have got to a point where the UML element & feature attributes are now implemented in a variety of different ways. IOW, not only is  the UI unique, but also the UML!

Looking at the latest spec I have I note that, for example,
a constraint is a packageable element in its own right.  IMO this means that the constraint attributes af an element should be likened unto the "external requirement"  beasty.  That is, manipulatable within the element but existent as a separate element.

So it seems to me that this is a much wider review of EA than just the requirement/responsibility/contract matter.

JM20cAUD !
bruce

p.s.  IMO use cases, being a behavioral element have all the right in the world to have responsibilities!

[Paolo F Cantoni]

Not knowing a great deal about this Design-by-contract approach, I'm not to sure whether using the term contract would be more of the same problem as "requirement".

bruce, check out:
[size=13]Building bug-free O-O software: An introduction to Design by Contract^(TM)[/size]
[size=13]Design by contract (Wikipedia)[/size]
For a quick overview.

A contract to me, implies two parties are involved.  This is a fine viewpoint for the behavioural features of an element but maybe not so for the overall element itself.

Au contraire (IMV)...

Then again maybe this is where the fundamental issue needs to be looked at.  EA seems to have got to a point where the UML element & feature attributes are now implemented in a variety of different ways. IOW, not only is  the UI unique, but also the UML!.

I think I follow... Are you saying that EA has done things that are not mentioned in the UML specs - that's true, but in the main,they are extensions and don't contradict UML (but then I like everyone else can't take in all the features of EA in one go!)  If I've misunderstood, then please correct me.

Looking at the latest spec I have I note that, for example,
a constraint is a packageable element in its own right.  IMO this means that the constraint attributes of an element should be likened unto the "external requirement"  beasty.  That is, manipulatable within the element but existent as a separate element.

Missed that! But interesting!

So it seems to me that this is a much wider review of EA than just the requirement/responsibility/contract matter.

I'm not averse to opening Pandora's box!

IMO use cases, being a behavioural element have all the right in the world to have responsibilities!

I see the example in the other thread.  Looks OK.

I guess the only thing I'd add is that each UseCase responsibility would need (eventually) to be distributed to one or other of the constituent Classes (or decomposed further and redistributed).  A bit like tracing requirements, but in this case tracing Responsibilities.

I guess it also should be the case that any given Responsibility should be the responsibility of only one UseCase?

Paolo

[sargasso]

I guess it also should be the case that any given Responsibility should be the responsibility of only one UseCase?

I dont see that as necessarily true - in fact there are many world examples where different usecases may "share" responsibilities.  There are also a set of responsibilities that should not be shared!

For example: Many usecases may have the responsibility "creates transaction log entry" but in given system maybe there is a constraint that only one usecase can have the responsibility "creates customer account".

A bit like tracing requirements, but in this case tracing Responsibilities.

 Indeed!!


bruce

[Paolo F Cantoni]

Quote: I guess it also should be the case that any given Responsibility should be the responsibility of only one UseCase?

I don't see that as necessarily true - in fact there are many world examples where different UseCases may "share" responsibilities.  There are also a set of responsibilities that should not be shared!

For example: Many UseCases may have the responsibility "creates transaction log entry" but in given system maybe there is a constraint that only one UseCase can have the responsibility "creates customer account".
[size=13][SNIP][/size]

Good point, bruce!

The question then is which are common and which are unique to one UseCase?  I think we can take an idea out of AOP (Aspect Oriented Programming)  We can separate those responsibilities that are related to cross-cutting concerns:  From Wikipedia on AOP: Logging offers the prototypical example of a crosscutting concern, because a logging strategy necessarily affects every single logged part of the system. Logging thereby crosscuts all logged classes, methods, and procedures..  These responsibilities can be shared; others, perhaps shouldn't be.  It may be necessary to decompose a UseCase into smaller UseCases (which can be referenced in multiple UseCase) so that the responsibility is correctly (uniquely) located.

Thoughts?

Paolo

[Martin_Leduc]

The question then is which are common and which are unique to one UseCase?  I think we can take an idea out of AOP (Aspect Oriented Programming)  We can separate those responsibilities that are related to cross-cutting concerns:  From Wikipedia on AOP: Logging offers the prototypical example of a crosscutting concern, because a logging strategy necessarily affects every single logged part of the system. Logging thereby crosscuts all logged classes, methods, and procedures..  These responsibilities can be shared; others, perhaps shouldn't be.  It may be necessary to decompose a UseCase into smaller UseCases (which can be referenced in multiple UseCase) so that the responsibility is correctly (uniquely) located.

There are good references on that topic I read recently. You have Aspect-Oriented Analysis and Design: The Theme Approach and Aspect-Oriented Software Development with Use Cases. Both mention weaving models to compose the system. I found the Theme approach more practical. The Use Cases approach, without software support, can lead to unmanageable situations. Worse, it leads naturally to the emergence of controller classes, which is discouraged in Executable UML: A Foundation for Model-Driven Architecture for really good reasons.

So, see that as I cautionary note that even though it make sense, it won't be just a matter of splitting responsibilities/contracts using aspect use cases. Depending on your strategy, there might be a need for software support to make it viable!

Martin