Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 70858

Summary: Simplify statistics views
Product: z_Archived Reporter: Curtis d'Entremont <curtispd>
Component: HyadesAssignee: Terry Fountoulakis <tfoun>
Status: CLOSED FIXED QA Contact:
Severity: enhancement    
Priority: P1 CC: ewchan, kcandrew, slavescu, who
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
icons for new views, and object icon for showing object level information in SD none

Description Curtis d'Entremont CLA 2004-07-26 16:50:27 EDT 
Issues I want to address:

1. Inconsistency between coverage statistics and the others. Coverage 
statistics shows all 3 levels of information (package, class, method) rolled up 
into one view. The other views separate these (albeit inconsistently).

2. Viewing execution time analysis information at the package and memory 
analysis at the class level, as examples. Right now you have to play around and 
change the table's columns and individually pick the ones you want to see (then 
you have to change again when you want to go back). Also, you initially see all 
zeros if you try to open package stats while doing execution time analysis only 
because the initial columns are for memory only.

Ok, right now we have 5 tables (excluding object references, which I consider 
to be different - its purpose isn't to show statistics).

Here are the descriptions:

Package statistics: Shows memory information at the package level. Can be 
manually changed to show execution info.
Class statistics: Shows memory information at the class level. Also shows the 
methods for each class. Can be manually changed to show execution info.
Method statistics: Shows execution time information at the method level.
Instance statistics: Shows memory information at the class level with instances.
Coverage statistics: Shows coverage information at the package, class, and 
method levels.

What I propose is to follow the lead of the Coverage statistics from the 
Toulouse team, and do the following:

Memory statistics: Shows memory information at the package, class, and instance 
levels.
Execution statistics: Shows execution time information at the package, class, 
and method levels.
Coverage statistics: Shows coverage information at the package, class, and 
method levels. (no change)

There would be toolbar buttons to switch between the different levels, just 
like in the coverage statistics view. There would also be a top level 
item "Summary" which will show the totals for all the items in the view, which 
can be useful.
Comment 1 Curtis d'Entremont CLA 2004-07-26 16:51:55 EDT 
Comments from Wayne:

I like the idea of simplifying the statistics views.  The idea of having a 
single stats/table view with the ability to switch between class, package, 
method is good.  Consistency with the coverage views is positive

As Eugene suggests, we should consider how this type of interaction can be used 
consistently throughout Hyades or Hyades-based UIs.  

For example, a somewhat related issue (Bugzilla 45678) is the current single 
Sequence Diagram view that is shared across 8 different "views" (as they show 
up separately in the "Open with>" menu).
Comment 2 Curtis d'Entremont CLA 2004-08-16 16:30:17 EDT 
Created attachment 13990 [details]
icons for new views, and object icon for showing object level information in SD
Comment 3 Marius Slavescu CLA 2004-09-15 10:42:53 EDT 
I would like to propose that during this simplification we should make the
statistical viewer more dynamic/generic. This could be done in a separate defect.

One suggestion is to make the "Choose columns" dialog generic and also the table
header and label provider, so depending on the object type we automatically
discover the set of properties that can be shown in the view.

E.g. if TRCClass needs to be displayed we should build the view columns by
queering the meta-model of TRCClass. In that way the viewer will reflect
automatically newly added attributes. We can do the same for computed fields
like "average base time" etc.

We should also add support for Properties view, when we select an object in any
view we should be able to see all the displayable properties of that object, see
any generated EMF.Editor.
Comment 4 Marius Slavescu CLA 2004-09-15 10:45:14 EDT 
Please read "querying" instead "queering" :)
Comment 5 Curtis d'Entremont CLA 2004-09-15 10:48:53 EDT 
Could you open separate bugs to track these two? Thanks..
Comment 6 Curtis d'Entremont CLA 2004-10-28 19:30:49 EDT 
Fix submitted.
Comment 7 Curtis d'Entremont CLA 2004-11-03 20:40:02 EST 
Verified. Closing bug.