I think I am clear on what to use where for Associations: The label is very specific, identifying the association or relationship between the two specific nodes. A stereotype doesn't normally make sense for associations, since it identifies a kind of association. Examples I have seem is <<include>> for use cases, and identification of the protocol for component associations.
For Dependencies: A label often does not make sense, since the relationship is always "depends on." A stereotype further defines the nature of the dependency.
Thursday, May 05, 2005
Good UML Links
I really like Scott Ambler's stuff at: http://www.agilemodeling.com/style/
This looks like a solid overview: http://www.vico.org/UML_FAQ_jGuru.pdf
Looks interesting: http://www-inf.int-evry.fr/COURS/UML/semantics/
And of course: http://www.uml.org/#UML2.0
Hmmm: http://www.holub.com/goodies/uml/
This looks like a solid overview: http://www.vico.org/UML_FAQ_jGuru.pdf
Looks interesting: http://www-inf.int-evry.fr/COURS/UML/semantics/
And of course: http://www.uml.org/#UML2.0
Hmmm: http://www.holub.com/goodies/uml/
Wednesday, May 04, 2005
Thoughts on Requirements Terminology
It occurred to me a while back that there are two distinct categories of requirements: Those that are deemed necessary and can be categorically verified, and those that are more lofty and more difficult to test.
I suggest that the first set are called Imperative Requirements, or simply requirements. These are binary in nature, either they make it into the system or they don't--a test case can be written that will pass or fail. Use cases and functional requirements fall into this category, as well as performance, reliability, security, and perhaps other non-functional areas as well.
The second category, which I'll call Non-Imperative Requirements (or maybe just Qualities), are different. They can not be tested or verified in any straight forward way, but rather are qualities to shoot for. Scalability, maintainability, useability, and ease-of-development, for example, fall into this category. These Qualities are better expressed as goals with relative importance. Those less verifiable, these need not be completely useless. Qualities can be expressed with relative importance weights, and still traced with a correlation matrix.
In future posts, I plan on fleshing out my idea of a requirements model, especially regarding how requirements should be systematically addressed in architecture.
I suggest that the first set are called Imperative Requirements, or simply requirements. These are binary in nature, either they make it into the system or they don't--a test case can be written that will pass or fail. Use cases and functional requirements fall into this category, as well as performance, reliability, security, and perhaps other non-functional areas as well.
The second category, which I'll call Non-Imperative Requirements (or maybe just Qualities), are different. They can not be tested or verified in any straight forward way, but rather are qualities to shoot for. Scalability, maintainability, useability, and ease-of-development, for example, fall into this category. These Qualities are better expressed as goals with relative importance. Those less verifiable, these need not be completely useless. Qualities can be expressed with relative importance weights, and still traced with a correlation matrix.
In future posts, I plan on fleshing out my idea of a requirements model, especially regarding how requirements should be systematically addressed in architecture.
Subscribe to:
Posts (Atom)