Internal requirements in EA are class (or any element) Responsibilities
[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).
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]
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:
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,Missed that! But interesting!
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.
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 it also should be the case that any given Responsibility should be the responsibility of only one UseCase?
A bit like tracing requirements, but in this case tracing Responsibilities.Indeed!!
Quote: I guess it also should be the case that any given Responsibility should be the responsibility of only one UseCase?Good point, bruce!
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]
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.