I'm very impressed by this project. The following are a few suggestions which I hope can make ClassBuilder a even more greater tool that will be-all-and-kill-all!
1) The TreeView and the ClassDiagram should *always* be in sync.
I just followed the steps doc-ed in the "Getting Started" manual, where all the operations are performed in the TreeView. After everything is done, I "add" a new ClassDiagram, and found nothing is there!
I think the operation "add" is mis-named; it should be called "open" :-). Which means, after I worked on the TreeView for a while, and "open" the ClassDiagram, everything should be auto-magically generated.
I think the default behaviour of ClassBuilder should sync the update between ClassDiagram <-> TreeView, in both direction, and all the time.
2) bug report: ClassDiagram -> TreeView.
My second experiment with ClassBuilder is to follow the "Getting Started" manual again, and re-start a new DataModel, but I choose to work only on the ClassDiagram from the very beginning. To much of my delight, The TreeView *is* updated with each operation on the Diagram.
However when I try to change the type of member b of B (please ref to the doc.) from 'int' to 'char'. The TreeView is correctly updated, but in the ClassDiagram, the method GetB() entry is removed completely from class B. I consider this is a bug, please fix it.
3) single navigation of relations.
The default behaviour is to establish bi-directional navigation for each relation R between A <-> B. Can we add an option to allow user to establish single direction navigation? ie. A -> B, A ->>B, A <- B, or A <<- B.
4) Random accessible Multis
Currently ClassBuilder has three options to model Multi relations: standard (a double-linked list), Value Tree, and AVL-Tree. Can we add Random accessible multis as well, like array([]) or STL vector?
5) init value for class member.
Can we put 0(NULL) as the default value? just like those in Java.
6) In the Output RTF dialog, shall we defaultly tick all the optional boxes, and set proper input template/output file name, and all other style fields?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have passed these items onto the original listserve for classbuilder (classbuilder@coollist.com). If you want to join this listserve see the home page.
Craig
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. THIS IS IMPOSSIBLE!!!! and undesired behaviour!!!!!!
Think about it, for every non trivial design the diagrams woulld become far to complicated to be usefull. The diagrams show only the relevant pieces of information. For example it is useless to have the Get/Set methods of a member on the diagram it adds no information but it takes up considerable space on the page. The same for the relation methods each relation add more then 10 methods to the class, it makes no sense to put them on the diagram, the fact that the class is related automatically implicate the existence of the methods. Thus in order to have readable usefull diagrams not everything is exposed but the user selects what he wants to see. If you want everything that is fine, with the select members and methods option you can establish that with a few seconds of effort.
2. See above it is not common to have the Get/Set methods in the diagram, they do not add information. Further the Get/Set methods are removed and regenerated to gurantee that the generated code, argument and return types are correct. As a side effect they disappear from the drawing. You can call it a bug, but this behaviour is better as an inconsistent diagram or inconsistent Get/Set methods.
3. With uni directional relations consistency can not be guaranteed, study the chapter about the lifetime of relations again. When objects are deleted its relation is automatically updated, this can only accomplished with bi-directional relations. Without this object could point to objects which do not longer exist.
4. This has to do with 3, templated list classes or array etc are unidirectional, they do not enforce referential integrity. Un top of that they are not very efficient since they normally would require an extra indirection. When the indirection is avoided by putting the complete object in the list, then they do not scale very well. e.g. It is difficult to embed the same object in two or more lists, in that cas ethe implementation has to be changed and a lot of code using the relation in the previous mannaer has to be adjusted. For this reason these kind of solutions are not very suited for code generation. You are howevery free to use the stl classes and implement the relations with that. Just put them in as extern class and use them as member further you can add a relation in the diagram which is a diagram relation only.
5. Just fill in the initial value field for the member.
6. The question is not very clear, use the suplied template and experiment and you will find out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1)
OK, I understand your consideration now, you should say it clearly in the docs.
> Thus in order to have readable usefull diagrams
> not everything is exposed but the user selects
> what he wants to see.
In this case, I think you should implement "drag & drop" from TreeView to ClassDiagram. So the user can easily "selects what he wants to see" by just pick the class from the TreeView and drop it on to the ClassDiagram. (Or ClassBuilder already have this mechanism which I haven't find out.)
> If you want everything that is fine, with the
> select members and methods option you can
> establish that with a few seconds of effort.
How to do that in version 2.3? you mean "drag & drop"?
2)
> You can call it a bug, but this behaviour is
> better as an inconsistent diagram or
> inconsistent Get/Set methods.
Then the GetB() method shouldn't be in the ClassDiagram in the first place. Think about it: it's there when I add the new member; and it dispears when I change the type of that member. The impression is that this IS a bug. If you intend not to include GetMethod in the ClassDiagram, then choose to do it from the very beginning; otherwise you mis-lead your user.
3) & 4) I understand with uni-directional relations, consistency will not be guaranteed. But you should give the user more freedom by providing more options. Random accessible multis are very useful in lots of applications.
5)
> Just fill in the initial value field for the
> member.
I may not express myself clearly. This is exactly what I want ClassBuilder to do: "fill in the initial value field"; and let the uesr change the default value 0(NULL) only when he has a special need to put other init values. In most cases 0(NULL) is good enough. I always think init value should be provided by (in this order): (1) the compiler, like javac; (2) the tool, like CB; (3) the programmer, so he can concentrate on more interesting jobs.
6) Like 5), what I mean is that all those "DataModel / Class / Group / Item ... Heading Styles" should have a reasonable default value filled *BY* the ClassBuilder; instead of asking the user to "experiment" with it. This will saves the user's time.
Hope this time I make it clear. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe that automatically adding a default initialization value to a class member is not a good idea for the following reasons.
1. The reliance on classbuilder to magically assign value to variables during initialization would be useful but would result in the creator becoming complacent about defining values that are appropriate for the variable.
2. From my experience, member variables that are not given initial values are added automatically as arguments to the classbuilder generated constructor. I like this behavior because if I forgot to give an initial value to a variable and find it as an unwanted argument in the constructor, I simply deleted the constructor, assign the value, and re-create the constructor. I feel this is enforcing good programming habits!
As per the class diagram comments I feel that the user can define what members and methods to display as well as automatically displaying some other data (see the checkboxes). I often use multiple class diagrams, first to show basic object relationship, then object details with light relationship details, and finally if needed detailed relationships between classes. If the class diagram were always updated to display everything, it would make quite a mess of the diagram. I tend to subscribe to the Keep It Simple, Stupid philosophy of diagramming. Give only enough information to describe what you want to be represented in the diagram. Give more then is required and it will become confusing. That is my opinion, take it for what its worth.
Jeremy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm very impressed by this project. The following are a few suggestions which I hope can make ClassBuilder a even more greater tool that will be-all-and-kill-all!
1) The TreeView and the ClassDiagram should *always* be in sync.
I just followed the steps doc-ed in the "Getting Started" manual, where all the operations are performed in the TreeView. After everything is done, I "add" a new ClassDiagram, and found nothing is there!
I think the operation "add" is mis-named; it should be called "open" :-). Which means, after I worked on the TreeView for a while, and "open" the ClassDiagram, everything should be auto-magically generated.
I think the default behaviour of ClassBuilder should sync the update between ClassDiagram <-> TreeView, in both direction, and all the time.
2) bug report: ClassDiagram -> TreeView.
My second experiment with ClassBuilder is to follow the "Getting Started" manual again, and re-start a new DataModel, but I choose to work only on the ClassDiagram from the very beginning. To much of my delight, The TreeView *is* updated with each operation on the Diagram.
However when I try to change the type of member b of B (please ref to the doc.) from 'int' to 'char'. The TreeView is correctly updated, but in the ClassDiagram, the method GetB() entry is removed completely from class B. I consider this is a bug, please fix it.
3) single navigation of relations.
The default behaviour is to establish bi-directional navigation for each relation R between A <-> B. Can we add an option to allow user to establish single direction navigation? ie. A -> B, A ->>B, A <- B, or A <<- B.
4) Random accessible Multis
Currently ClassBuilder has three options to model Multi relations: standard (a double-linked list), Value Tree, and AVL-Tree. Can we add Random accessible multis as well, like array([]) or STL vector?
5) init value for class member.
Can we put 0(NULL) as the default value? just like those in Java.
6) In the Output RTF dialog, shall we defaultly tick all the optional boxes, and set proper input template/output file name, and all other style fields?
Thanks.
I have passed these items onto the original listserve for classbuilder (classbuilder@coollist.com). If you want to join this listserve see the home page.
Craig
1. THIS IS IMPOSSIBLE!!!! and undesired behaviour!!!!!!
Think about it, for every non trivial design the diagrams woulld become far to complicated to be usefull. The diagrams show only the relevant pieces of information. For example it is useless to have the Get/Set methods of a member on the diagram it adds no information but it takes up considerable space on the page. The same for the relation methods each relation add more then 10 methods to the class, it makes no sense to put them on the diagram, the fact that the class is related automatically implicate the existence of the methods. Thus in order to have readable usefull diagrams not everything is exposed but the user selects what he wants to see. If you want everything that is fine, with the select members and methods option you can establish that with a few seconds of effort.
2. See above it is not common to have the Get/Set methods in the diagram, they do not add information. Further the Get/Set methods are removed and regenerated to gurantee that the generated code, argument and return types are correct. As a side effect they disappear from the drawing. You can call it a bug, but this behaviour is better as an inconsistent diagram or inconsistent Get/Set methods.
3. With uni directional relations consistency can not be guaranteed, study the chapter about the lifetime of relations again. When objects are deleted its relation is automatically updated, this can only accomplished with bi-directional relations. Without this object could point to objects which do not longer exist.
4. This has to do with 3, templated list classes or array etc are unidirectional, they do not enforce referential integrity. Un top of that they are not very efficient since they normally would require an extra indirection. When the indirection is avoided by putting the complete object in the list, then they do not scale very well. e.g. It is difficult to embed the same object in two or more lists, in that cas ethe implementation has to be changed and a lot of code using the relation in the previous mannaer has to be adjusted. For this reason these kind of solutions are not very suited for code generation. You are howevery free to use the stl classes and implement the relations with that. Just put them in as extern class and use them as member further you can add a relation in the diagram which is a diagram relation only.
5. Just fill in the initial value field for the member.
6. The question is not very clear, use the suplied template and experiment and you will find out.
1)
OK, I understand your consideration now, you should say it clearly in the docs.
> Thus in order to have readable usefull diagrams
> not everything is exposed but the user selects
> what he wants to see.
In this case, I think you should implement "drag & drop" from TreeView to ClassDiagram. So the user can easily "selects what he wants to see" by just pick the class from the TreeView and drop it on to the ClassDiagram. (Or ClassBuilder already have this mechanism which I haven't find out.)
> If you want everything that is fine, with the
> select members and methods option you can
> establish that with a few seconds of effort.
How to do that in version 2.3? you mean "drag & drop"?
2)
> You can call it a bug, but this behaviour is
> better as an inconsistent diagram or
> inconsistent Get/Set methods.
Then the GetB() method shouldn't be in the ClassDiagram in the first place. Think about it: it's there when I add the new member; and it dispears when I change the type of that member. The impression is that this IS a bug. If you intend not to include GetMethod in the ClassDiagram, then choose to do it from the very beginning; otherwise you mis-lead your user.
3) & 4) I understand with uni-directional relations, consistency will not be guaranteed. But you should give the user more freedom by providing more options. Random accessible multis are very useful in lots of applications.
5)
> Just fill in the initial value field for the
> member.
I may not express myself clearly. This is exactly what I want ClassBuilder to do: "fill in the initial value field"; and let the uesr change the default value 0(NULL) only when he has a special need to put other init values. In most cases 0(NULL) is good enough. I always think init value should be provided by (in this order): (1) the compiler, like javac; (2) the tool, like CB; (3) the programmer, so he can concentrate on more interesting jobs.
6) Like 5), what I mean is that all those "DataModel / Class / Group / Item ... Heading Styles" should have a reasonable default value filled *BY* the ClassBuilder; instead of asking the user to "experiment" with it. This will saves the user's time.
Hope this time I make it clear. Thanks.
I believe that automatically adding a default initialization value to a class member is not a good idea for the following reasons.
1. The reliance on classbuilder to magically assign value to variables during initialization would be useful but would result in the creator becoming complacent about defining values that are appropriate for the variable.
2. From my experience, member variables that are not given initial values are added automatically as arguments to the classbuilder generated constructor. I like this behavior because if I forgot to give an initial value to a variable and find it as an unwanted argument in the constructor, I simply deleted the constructor, assign the value, and re-create the constructor. I feel this is enforcing good programming habits!
As per the class diagram comments I feel that the user can define what members and methods to display as well as automatically displaying some other data (see the checkboxes). I often use multiple class diagrams, first to show basic object relationship, then object details with light relationship details, and finally if needed detailed relationships between classes. If the class diagram were always updated to display everything, it would make quite a mess of the diagram. I tend to subscribe to the Keep It Simple, Stupid philosophy of diagramming. Give only enough information to describe what you want to be represented in the diagram. Give more then is required and it will become confusing. That is my opinion, take it for what its worth.
Jeremy