Community
Participate
Working Groups
Not all users need equivalence classes. The users who do not need them are often confused by them. There should be the ability to hide equivalence classes from users who do not need them.
Equivalence classes can be hidden from the user programmatically, and this is currently done by one of the Rational products consuming the datapool editor. The ability to hide the equivalence class concept is not currently exposed to the user via UI. I'm not sure I understand how this will improve usability unless we also set the "hide equivalence classes" option to true by default. This would make the editor easier to use, but would also visible functionality for new users. Perhpas this is a good thing, but I'd like to hear from Product Management if they are okay with this. Serge, can you please comment? I am triaging this to future for now, but if it's something that PM ok's, we can move it forward into 3.2.
Adding some comments as a result of the Hyades UI meeting on Sept 22, 2004: Certain types of Testers (e.g., performance testers) do not understand the concept of equivalence classes. However, the Hyades Datapool editor surfaces the concept to the user and requires the user to create an equivalence class prior to being able to enter records. The concept of equivalence classes can cause difficulties during data entry as well as for CSV File importing, as by default the “First column contains equivalence class names” is selected. Testers unfamiliar with equivalence classes are unlikely to have CSV files formatted to contain equivalence classes, resulting in unexpected results after an import. Suggestions: Provide the flexibility to support different types of testers: those that do not need or understand equivalence classes, and those that do need to leverage them. Note: it is possible to hide equivalence classes from the user programmatically but it may be necessary to consider whether equivalence classes should be shown by default, etc.
The solution to this problem appears rather simple which is not showing any data, or actions related to equivalance classes for various types of users. But one thought to consider is what is the right granularity at which to control the visibility of the equivalence classes. I see a couple of options: 1) At a UI workbench level. - E.g. user preference checkbox (show equivalence classes in datapool) 2) At a data asset level. - Property of the EMF data model that provides "hint" of appropriate way to view the data in an editor #1 has its pros of being global, mostly hidden and users of a certain type probably always want the option always enabled or disabled. The con is it doesn't support the x-domain use cases very well where if equivalance classes were created but a "eq.class" ignorant user is viewing the data isn't provided all of the essential data in the datapool. Of course, if he doesn't understand the eq. class maybe that's not a bad thing. #2 has its pros that it supports the x-domain use case above much better in that each datapool could have a different option depending on the usage of the test data. The cons is that it's more exposed to the user since it's now a property of the datapool editor and ignorant users are more likely to trip over the setting since it's not hidden away in preferences. Since I think datapool creation is typically done from a specific domain tool such as a test for load testing, unit testing, etc. Then typically that test editor can correctly set the default value of that property to the correct value to avoid exposing advanced data concepts unnecessarily. There's a blend to #1 and #2 above which is having both. Then it's just a mixture between the preferences about what actually happens. You could have a user preference for 1) show according to model "hint", 2) always show eq. classes 3) always hide eq classes Then if you have #3 for a particular domain you could just entirely hide the preference in the editor as well that exposes eq classes. Then of course you also have to decide what the default values are for the various options above (and make a test EMF model change). The only other item to consider is whether ultimately solving the "eq. class" visibility problem requires supporting Hyades UI customization in terms of "roles" or "capabilities" (possibily tied to Eclipse capabilities as well) that allowed vendors to supply a "load tester" role for example that would then control various preferences in Hyades about what's visible or possible. If there's not good general agreement on what the right defaults are, we might need to have the ability for a vendor to specify those preferences thru an extension and control how much power/flexibilty inside of Hyades to expose depending on the technical needs of that testing domain or skill level of the tester.
As a result of the discussion at Hyades UI meeting on 10/20, it is agreed that equivalence classes will be presented in tabs of the datapool editor. One tab for each equivalence class. A new datapool is opened with a default equivalence class (with one data table tab) so that new users not familiar with equivalence classes can start editing straight. Users only worry about editing of records(rows), variables(columns) and cells inside the data table tab. Creation, removal, and management of equivalence classes will be available on the overview page for more advanced users who want to take advantage of equivalence class. User can also change the default equivalence class on the overview page to work with the runtime api. (On overview page, see bugzilla # 74864.
*** Bug 64788 has been marked as a duplicate of this bug. ***
*** Bug 74869 has been marked as a duplicate of this bug. ***
Equivalence class is now presented as a separate data table tab in datapool editor and is thus hidden inside of each table. Overview page contains variables and equivalence classes in tree viewers and editable through properties viewer on selection. Implemented in 3.3 stream and available in Hyades build 3.0_20050209_2138. Updated UXS document and a demo to follow as this has products and doc impact.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
