OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

courtfiling-reqts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [courtfiling-reqts] Use cases, components, etc.


Yes, we're not intending the term "component" in the same sense as UML intends it.  We've been using it as perhaps a layperson would...as a synonym for "part."  So maybe we should use a different term.  Maybe subsystem is more appropriate.

In the general sense, a component is something that has a standard interface that other components can talk to.  This is the sense in which we have been using it to guide our task:  namely, divide up an abstract e-filing solution into reasonable parts, and standardize the interface to each part.  The first step in standardizing the interface to each part is documenting how the component would be used by other components.  A good way to document how something is to be used is to do it in use cases.

I think that fairly summarizes what we've been thinking.

--Scott

> 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
>
>
>
>
> ________________________________
>
> From: Cabral, James E. [mailto:JCabral@mtgmc.com]
> Sent: Wednesday, February 09, 2005 4:00 PM
> To: scott@justiceintegration.com;
> courtfiling-reqts@lists.oasis-open.org
> Subject: RE: [courtfiling-reqts] Use cases, components, etc.
>
>
>
> 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
>
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]