You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kato-spec@incubator.apache.org by Steve Poole <sp...@googlemail.com> on 2009/02/25 13:33:09 UTC

[Vote] User story summary so far (try 2)

Oops - forgot the list!
---------------------------------

Hi all -  I'd like to get some feedback on the list of potential user
stories that have been posted so far.     Unless I hear to the contrary by
Monday 2nd March I'm going to assume that the user stories listed below are
agreed as being the initial set for the tools in question.   ( FYI - there
are still two sets of user stories outstanding -  those for the Runtime
Investigator and the Trend Analysis tools.  )

Thanks

Steve

List of Stories
========

User stories for the explorer tools and the native memory analysis tool.

RE1 : As a Service Engineer diagnosing the causes of a dump, I want to see
as much as possible of the the dump's Java runtime artifacts.

RE2 : As a Developer producing a JSR 326 compliant implementation, I want to
see all the Java Runtime artifacts in order to verify my implementation.

RE3 : As a Service Engineer I want to have basic search and query facilities
over the contents of a dump (such as show me all the classloaders), in order
to diagnose the problem in the shortest time possible.

RE4 : As a Service Engineer I want to have a summary page when the tool
opens that shows the most commonly accessed/useful Java Runtime artifacts,
in order to diagnose the problem in the shortest time possible.

PE1:     As a Service Engineer diagnosing the causes of a dump, I want to
see as much as possible of the dump's contents

PE2:     As a Service Engineer, I want to be able to extract memory from the
dumps and to format it according to a given primitive type;

PE3:     As a Service Engineer, I want to list the result of a search for a
string or sequence of bytes in the dump;

NMAT1: as a Service Engineer, I want to have a summary for each memory
section, in order to get an initial memory profile.

NMAT2: as a Service Engineer, I want to know which are the memory
allocations, their sizes and their base addresses;

NMAT3: as a Service Engineer, given the address of a memory
allocation, I want to know where in the memory it is referenced and
whether it corresponds to any symbol;

NMAT4: as a Java Service Engineer, given the address of a memory
allocation, I want to list all the Java objects having a reference to
that address;

NMAT5: as a Java Service Engineer, given a sequence of bytes, I want
to list all of its occurrences in the address space, to be able to
find possible eyecatchers;

NMAT6: as a Java developer or Service Engineer, I want to list all the
occurrences of direct buffers and their path back to the heap roots,
in order to find the potential causes of native memory leaks;

NMAT7: as a Java developer, i want to list all the occurrences of JNI
references (as reported by the runtime) that cannot be found in any
native stack, in order to find the potential causes of native memory
leaks.

Re: [Vote] User story summary so far (try 2)

Posted by Steve Poole <sp...@googlemail.com>.
It's Monday 2nd March. No dissenters apparent so I declare this particular
list complete.

On Wed, Feb 25, 2009 at 1:33 PM, Steve Poole <sp...@googlemail.com>wrote:

> Oops - forgot the list!
> ---------------------------------
>
> Hi all -  I'd like to get some feedback on the list of potential user
> stories that have been posted so far.     Unless I hear to the contrary by
> Monday 2nd March I'm going to assume that the user stories listed below are
> agreed as being the initial set for the tools in question.   ( FYI - there
> are still two sets of user stories outstanding -  those for the Runtime
> Investigator and the Trend Analysis tools.  )
>
> Thanks
>
> Steve
>
> List of Stories
> ========
>
> User stories for the explorer tools and the native memory analysis tool.
>
> RE1 : As a Service Engineer diagnosing the causes of a dump, I want to see
> as much as possible of the the dump's Java runtime artifacts.
>
> RE2 : As a Developer producing a JSR 326 compliant implementation, I want
> to
> see all the Java Runtime artifacts in order to verify my implementation.
>
> RE3 : As a Service Engineer I want to have basic search and query
> facilities
> over the contents of a dump (such as show me all the classloaders), in
> order
> to diagnose the problem in the shortest time possible.
>
> RE4 : As a Service Engineer I want to have a summary page when the tool
> opens that shows the most commonly accessed/useful Java Runtime artifacts,
> in order to diagnose the problem in the shortest time possible.
>
> PE1:     As a Service Engineer diagnosing the causes of a dump, I want to
> see as much as possible of the dump's contents
>
> PE2:     As a Service Engineer, I want to be able to extract memory from
> the
> dumps and to format it according to a given primitive type;
>
> PE3:     As a Service Engineer, I want to list the result of a search for a
> string or sequence of bytes in the dump;
>
> NMAT1: as a Service Engineer, I want to have a summary for each memory
> section, in order to get an initial memory profile.
>
> NMAT2: as a Service Engineer, I want to know which are the memory
> allocations, their sizes and their base addresses;
>
> NMAT3: as a Service Engineer, given the address of a memory
> allocation, I want to know where in the memory it is referenced and
> whether it corresponds to any symbol;
>
> NMAT4: as a Java Service Engineer, given the address of a memory
> allocation, I want to list all the Java objects having a reference to
> that address;
>
> NMAT5: as a Java Service Engineer, given a sequence of bytes, I want
> to list all of its occurrences in the address space, to be able to
> find possible eyecatchers;
>
> NMAT6: as a Java developer or Service Engineer, I want to list all the
> occurrences of direct buffers and their path back to the heap roots,
> in order to find the potential causes of native memory leaks;
>
> NMAT7: as a Java developer, i want to list all the occurrences of JNI
> references (as reported by the runtime) that cannot be found in any
> native stack, in order to find the potential causes of native memory
> leaks.
>
>
>
>
>