[EBOB-DISCUSS] [Fwd: [ ebob-Use Cases-1071495 ] Add Object to Object Bench (Complete)]

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

The formatting for the trackers on sourceforge... in a word... sucks. As 
you guys noticed with my first use case submission, the HTML is escaped, 
and as such isn't parsed. Well, they also don't convert spaces into 
&nbsp;, so I'm really unsure as to how to format anything.

I vote for choosing a new method for storing use cases, as the current 
system... well, again, it sucks.

Here are two suggestions for replacements- PLEASE either vote for one of 
these or come up with an alternative suggestion (OR vote for keeping the 
SourceForge tracker).

One possible suggestion... what we did for our SoftEng project in E Term 
was to write the use cases in HTML, and then check them in to CVS. That 
way, if we made changes, we could always run a diff, and we also got 
nice formatting whenever we wanted to show the use cases to people. (How 
exactly should we be showing use cases to our 'audience'?) This would 
favor HTML coded either by hand or by a really basic editor- anything 
created in Dreamweaver or FrontPage would probably be too difficult to diff.

Another suggestion is to put them in the "Docs" section in SourceForge. 
We get the formatting (still in HTML), and it makes it MUCH easier for 
visitors to view them by visiting our site. (It also allows us to be 
much lazier by not having to take them out of CVS and put them on our 
website.) The downside of this compared to the above option is that 
diffs are harder, but we already have a system for marking changes in 
our Docs section anyway (comments at the top of the document). It really 
doesn't matter whether you edit the HTML by hand or not in this case- 
all that should be required is that it's suitable for future changes (it 
shouldn't be so obscure that you can't edit it any more).

Neither of these suggestions have features I'd like such as automatic 
feature matrix generation, assignment of ownership, etc... but then 
again, the SourceForge tracker didn't really have automatic feature 
matrix generation either, and we can easily say "Use Case X, Owned by 
Person Y" in HTML.

Here's my complete "Add Object to Object Bench" use case, in all its 
formatted glory. This is the only place you can see it at the moment.

Liam

-------- Original Message --------
Subject: 	[ ebob-Use Cases-1071495 ] Add Object to Object Bench (Complete)
Date: 	Mon, 22 Nov 2004 23:34:59 -0800
From: 	SourceForge.net <no...@so...>
To: 	no...@so...

Use Cases item #1071495, was opened at 2004-11-23 02:31
Message generated for change (Comment added) made by imotic
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=697946&aid=1071495&group_id=123169

Category: Complete
Group: None
Status: Open
Priority: 9
Submitted By: Liam Morley (imotic)
Assigned to: Liam Morley (imotic)
Summary: Add Object to Object Bench (Complete)

Initial Comment:
Create New Instance

Primary Actor: Developer

1. Developer selects Add To Object Bench Wizard from
one of the following locations:
    - A button on the object bench itself
    - The "New..." Wizard selection
    - The context menu for .java files and public Java
classes
    - Developer can drag-and-drop a public Java class
or .java file to the Object Bench
   If a .java file is selected, it is assumed that the
public class within that file is to be used.
2. Developer fills out the name for the instance, and
selects a class from the workbench.
3. System validates the name and class (while the
Developer types) to make sure that:
    - The name is a legal java variable identifier
    - The name hasn't already been selected by an
object currently on the Bench
    - The class is either in the classpath or on the
workbench

   EXTENSIONS:
    3a. The only constructor for this class is a
default no-argument constructor:
        .1 System displays only the "Finish" action as
enabled, and notifies Developer that this is the case.
        .2 Developer selects "Finish" and advances to
step 9.
    3b. There is no default no-argument constructor
available for this class:
        .1 System displays only the "Next" action as
enabled.
        .2 Developer selects "Next" and advances to step 4.
    3c. There is both a no-argument constructor as well
as one other constructor available for this class:
        .1 System displays both "Next" and "Finish" as
enabled.
        .2 Developer selects either "Next" or "Finish"
and advances to either step 4 or step 9, respectively.

4. Developer selects "Next".
5. Developer selects a constructor.
6. System displays a list of arguments.
7. Developer specifies the parameters. Parameters can
be specified either as literals, in-place objects, or
references to objects currently on the Object Bench
(referenced by name).
8. Developer selects "Finish".
9. System creates the object using the supplied
constructor and arguments and adds it to the Object
Bench. If the Object Bench view is not already visible,
the System makes it visible.

   EXTENSIONS:
    9a. The System has an unrecoverable error that
prevents an object from being constructed from this class:
        .1 System displays message indicating this, and
presents "Cancel" action.
        .2 Developer cancels wizard.
    9b. The System has an error which prevents an
object from being constructed using the supplied arguments:
        .1 System displays message indicating this, and
presents both "Cancel" and "Back" options.
           9b1a. Developer cancels wizard.
           9b2a. Developer selects "Back" and returns
to step 6.
    9c. The System has an error which prevents an
object from being constructed using the supplied
constructor:
        .1 System displays message indicating this, and
presents both "Cancel" and "Back" options.
           9c1a. Developer cancels wizard.
           9c2a. Developer selects "Back" and returns
to step 5; the previously chosen constructor is removed
from the list of possibilities.

----------------------------------------------------------------------

>Comment By: Liam Morley (imotic)
Date: 2004-11-23 02:34

Message:
Logged In: YES 
user_id=150393

OPEN ISSUES:
1. Currently, any class from the workbench (meaning, any
class from any open java project) or the classpath can be
added to the Object Bench. This could be a potential
problem, as two classes with the same fully qualified name
can exist in separate projects. (A real world example is
having two different branches of the same source code
checked out into two separate projects.) It currently hasn't
been decided as to how this will be dealt with, or where the
responsibilities lie. This may be changed later.
2. It's currently uncertain whether or not objects will be
represented by Eclipse's internal type structure (see: IType
in the JDT Javadoc). There are potential issues concerning
the changing of the class definition of an object that is
currently attached to the Object Bench. More research is
necessary.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=697946&aid=1071495&group_id=123169