Test case generation

[HGustavs]

Currently I do think that there are issues related to generating relationships from ER models (and/or UML models?).

It is unclear how complete this functionality is.

If this functionality is fully or partially working, can we use this code as a base to generate test cases from the state chart models?

A very important goal is to have as much code reuse as possible so that we minimize re-invention of any kinds of wheels.

[HGustavs]

A good first step to addressing this issue could be to document the current code generation functionality.

[b21oscpe]

To clarify, the issue is to document the current code generation functionality.

[ghost]

There appears to be a key bind for generating relations. This is done by using ctrl+4. There are also relations for different diagrams that are stored in an element types Enum. the Enum currently has relation types for the following: uml, er and ie. There is also an object that uses the name of each element type( in this case relations instead of numbers). There are also objects describing the inheritance state of uml and iee. The code also describes the different types of lines you can draw between elements, normal, double or dashed. There are also options to display cardinalities next to each line, many or 1. You can also connect icons to the end of lines that have to uml elements connected: triangle, arrow, white diamond or black diamond. There is a comment in the code mentioning that the icons need to be fixed so that each icon corresponds to an option in a dropdown. I believe the dropdown referred to is the one on line 6008 There also appears to be descriptions of what these icons correspond to but I have no idea what some of the mean : ZERO_MANY: "0-M", ZERO_ONE: "0-1", ONE: "1", FORCEDONE: "1!", ONE_MANY: "1-M", MANY: "M", WEAK: "Weak" The code also appears to keep track of things like the attributes connected to each other, what lines go from attributes to other attributes, all the relations in the diagram and so on The code also has functions for finding UML inheritance from a line. it checks if the ID that goes from a line and the ID for the connection to the other line both are of type UML relation and if they are returns 1 otherwise -1.

er tables are also generated in string format in the code. The function starts off by first setting up what to keep track of. It then sorts the data and divides it into entities, attributes and relationships. The function then finds out which relationships and entities are connected. This is done by first checking if the ID of lines match the ID of the relations. Then we find if the entity is connected to each relation by checking the ID of the line and entity to see if they match. A similar Process is done to identify what attribute belong to what entity. The function also checks if there are attributes that are connected to themselves. The function also separates strong entities from week once and checks their cardinalities. The function then deals with strong and week entities in the relation and makes sure that the keys are stored correctly depending on if it a many to 1 relation or 1 to 1 relation. The function then goes on to create the actual string that is going to be the final table.

Note that there is much more going on in the function when it comes to validating relations but that this is just an overview and it is best to go through and look at the large amounts of code that are in this function before you work with it. basically the function first sets everything up so that relations and entities are stored in arrays and validates each relation case to ensure that everything is accounted for, strong entities, week entities , cardinality, attributes, keys and so on. that each attribute is placed in the correct entity.

The ddrawLine function is where the lines are being drawn for the relations as far as I understand. The function makes sure that uml and iee relations are straight line segments. It also deals with cases where the relation is recursive.

When drawing elements, if an er element is involved in an error with an er entity it will be outlined in red. This is done in the drawElement function.

The checkElementError checks for the following errors which is related to the section above: checks entities with the same name and if the ID of the element differs from the ID of the data and if so it is flagged as an error, if 2 entities are connected and the connection id's are er elements it is flagged as an error, if attributes are connected to entities and the ID for the elements do not match the attributes are not connected correctly and an error is flagged, if the wrong key types are being connected an error is flagged, if er attributes with the same name are detected an error is flagged, if there is more than one strong entity related to a week entity an error is flagged, if an element does not have a strong relation to an entity an error is flagged, if an entity element has any lines connected to it and the entity does not have exactly one key an error is flagged(note that there is duplicate code on line 8797 and 8888 and I am not sure why that is), if an entity has a weak relation an error is flagged, if 2 attributes have the same name an error is flagged, if an element is connected directly to another relation an error is flagged, if an er attribute is connected to more than 2 err attributes an error is flagged, if a relationship with the same name exists but different properties such as different line types or cardinality it is flagged as an error, if the number of attributes in 2 relations are not equal an error is flagged, if the same attribute name appears more than once in the same relation an error is flagged. There is a check if a normal line is connected to a weak entity, which should not be the case. If there is such a line, then the code searches for other lines connected to the weak entity and checks if they are connected to a strong entity. If they are, then the weak entity is connected to both strong and weak entities, which is incorrect and an error is flagged. The code is checking if a normal line is connected to a weak entity, which should not be the case. If there is such a line, then the code searches for other lines connected to the weak entity and checks if they are connected to a strong entity. If they are, then the weak entity is connected to both strong and weak entities, which is incorrect and an error is flagged. There is also duplicate code on line 8797 and 8892. No idea why that is. note that there are more error checks in the function and that you should take the time to go through it. I have just listed the once I believe are important. I believe the checkElementError function should be divided into smaller functions. As it is right now it spans at least over 100 lines of code and it is quite a lot to read and understand. Dividing it up would increase readability and maintainability.