|
Folks,
I appreciate Scott's detailed response to my comments on
the use cases. Just a few points to help us move on. First, the use cases we are
using seem perfectly suited to the analysis task. My only point was that
components as defined by UML are implementation phase artifacts that represent
physical packaging of functionality. Since we are still at the use case stage
(analysis) it did not make apparent sense to me why we were jumping ahead to
components. I have no objection to using them at the appropriate phase assuming
we are roughly following UML notation and intend to get that far in this effort
(one might say that for a standard all you need is the interfaces defined not
the components that implement them). Second, I tried to suggest a way of seeing
the functionality of the components as use cases, perhaps my point was unclear.
Modeling the functionality of the components as use cases has the benefit of
developing a true use case model at the highest level of abstraction. I only
looked at the big fish, all the rest of the use cases under review could easily
fall into that model.
Let me know if I am way off base here. I apologize for
not having the background of the group's prior conversations, assumptions, and
decisions. I am only reacting to the artifacts and what I understand to be
standard methodology.
I do have one question however. Is there a written goal for
this standards activity, that is, what deliverables are planned? If I could see
that it might help me better understand the methods being
followed.
Regards,
james
Scott and
all,
I’m sorry I had a
conflict with yesterday’s ECF TC conference call and missed this discussion of
what we mean by a use case. However, I am in general agreement with
Scott on the two issues he addresses, and would like to see us resolve these
semantic issues quickly and move on.
To paraphrase Scott,
if we’re not using the accepted definition of use cases (ala Jacobson and
Cockburn), we should call them something else. And we need to have some
way of grouping the use cases according to function. I don’t have a
problem with the term “component” but if we are not going to use that term, we
need to agree on some other term soon.
Jim
From: Scott
Came [mailto:scott@justiceintegration.com]
Sent: Tuesday, February 08, 2005 8:45
PM
To:
courtfiling-reqts@lists.oasis-open.org
Subject: [courtfiling-reqts] Use cases,
components, etc.
First of all, Tom or Eric, if this isn't the right
list for requirements methodology discussions, please let me know and I'll
post it to the right one. I thought the Blue Drafting SC list was just for
focused discussion regarding specific changes to proposed deliverable
documents, and that the Requirements SC list was for hashing out other issues.
But lately there has been a blurring of the lists, so feel free to point me to
the right place if I'm not in it.
I had some thoughts regarding the
issues of use case form discussed on today's call, but it was my phone causing
static on the call (I think) so I wanted to stay muted, plus I didn't want to
derail the limited conference call time. So I'll raise the issues
here...
Issue #1: Use Case methodology
I think it's important to
keep in mind that eventually, if we're successful, our requirements will be
read by implementers who have not participated in our deliberations. They will
primarily be interested in the formal specification, but will look to the
requirements for background.
As many of us know, most technicians and
analysts mean something quite specific when using the term "use case." It is a
particular form of documenting the behavioral requirements of something
(usually but not always a piece of software.) This form has been developed by
Jacobson, Cockburn, and others. There is some quibbling over just what should
be in a use case, and over how formal one should be, but there does seem to be
consensus among the principals that a use case should identify, at a
minimum:
1. A system under design/analysis
2. A primary actor
3.
A goal the actor wishes to achieve by using the system under
design/analysis
4. A sequence of interactions between actor and SUD that
results in the actor's achievement of the goal
(Note that use cases are
primarily a textual, not graphical, form. Jacobson's use case diagrams can be
useful for context, but the formal requirements need to be
textual.)
With our future broader audience in mind, I think we should
either stick to this basic form in writing our use cases, or we should call
what we're producing something else. Calling our requirements use cases but
not including all the parts could weaken our requirements model in the eyes of
our audience, and could confuse them.
In particular, I think it is
important to label the system under analysis/design...to give it a name. Maybe
it's just "the system" or "the e-filing system" or something vague, but it
does need to have a name. (And it should be noted that back in December the
former requirements subcommittee had some significant discussion over this
issue, with the consensus being that it should be called "the LegalXML
System.")
I also think it needs a definition, in addition to a name.
That definition will tell our audience what is in and out of the scope of the
standard.
Without naming an SUD, the first question readers ask will
be, "for what are these use cases the requirements?" I think that's a
significant question, and the answer should be clear, and it should be stated
clearly in each use case.
Issue #2: The need for components
My
understanding has always been that Blue is intended to support the broadest
possible range of business models. (Perhaps this needs to be reconfirmed by
the TC?) It is certainly true that some business models will involve selling
products to customers that implement only the "externally facing" behavior of
Blue; that is, the Blue functions that are used directly by human beings or
external information systems (e.g., court CMSes or DMSes). Customers who find
this kind of solution attractive will likely not care much about the internal
"componentry" of the product, and will not find individually defined
components in the Blue standard very useful.
However, there are
potential business models in which a vendor may wish to specialize in
implementing only certain components, and in doing so will expect
standard-compliant vendors of other components to interoperate in ways defined
by the standard. That is, I should be able to market a compliant Filing
Assembly component and have it interoperate with some other vendor's compliant
Filing Review component.
Of course, our "user use cases" are useful in
supporting both models. Whether the entire e-filing solution is purchased from
one vendor or several, there are still externally-facing behavioral
requirements, and those need to be documented.
But we need well-defined
components, and requirements for them, if we are to support the second
business model, no? If I wish to go into business as a vendor of the
component-that-sits-at-the-court-and-receives-filings-and-presents-them-for-clerk-review,
then I need to know what it means to make such a thing. As a customer, if I
purchase such a thing, and it says on the box (not literally) that it is a
Blue-compliant Filing Assembly component, then I need to know what that
means.
Therefore, unless we intend not to support the second model
(which I don't think I've heard proposed), we need to continue down the path
of defining components and requirements for their interfaces.
I'm not
wedded to the word "component," though again the old requirements subcommittee
debated this at some length and couldn't come up with anything better.
Regardless, whatever the name is, as long as we define it properly somewhere,
it shouldn't matter too much.
Thanks.
--Scott
Scott
Came
President and Principal Consultant
Justice Integration Solutions,
Inc.
Olympia, Washington
360-402-6525
scott@justiceintegration.com
http://www.justiceintegration.com
|