... | @@ -37,21 +37,31 @@ How the Apollon repository is set up, each diagram relationship type can have it |
... | @@ -37,21 +37,31 @@ How the Apollon repository is set up, each diagram relationship type can have it |
|
|
|
|
|
### Modifying the Popup
|
|
### Modifying the Popup
|
|
|
|
|
|
The popup should have a property of "element" that will reference the UMLAssociation created in the uml-association.ts that was previously discussed. This will allow us to modify the element itself when changes are made. It's also important to include the "DispatchProps" to allow for the redux actions to take place and help manage the state of the program. When exporting the Popup itself, it renders a div divided into sections. The first section describes the object and renders buttons to allow for the flipping and deleting of the relationship line. The second section renders a dropdown menu that allows for the user to select the new type of the relationship. `<Dropdown value={element.type as keyof typeof ClassRelationshipType} onChange={this.onChange}> <Dropdown.Item value={ClassRelationshipType.ClassAggregation}> {this.props.translate('packages.ClassDiagram.ClassAggregation')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassUnidirectional}> {this.props.translate('packages.ClassDiagram.ClassUnidirectional')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassBidirectional}> {this.props.translate('packages.ClassDiagram.ClassBidirectional')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassComposition}> {this.props.translate('packages.ClassDiagram.ClassComposition')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassDependency}> {this.props.translate('packages.ClassDiagram.ClassDependency')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassInheritance}> {this.props.translate('packages.ClassDiagram.ClassInheritance')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassRealization}> {this.props.translate('packages.ClassDiagram.ClassRealization')} </Dropdown.Item> </Dropdown> `Here we see an example of the popup for a class diagram. Notice value is set to be the different types of the ClassRelationshipType and that when the value is changed, it calls an onChanged handler (which will be discussed later). Each Dropdown.Item's value should then be bound to the different types available for the relationship. This will automatically call onChange when the value changes, with the new value that is selected by the user. To display values for the dropdown item, the popup will call this.props.translate('packages....'). This path leads the program to the src/main/i18n/en.json(or de.json depending on the language), where the user will be able to declare how it is displayed. For example, to display "Realization" for the realization type, you would write: `"packages": { "ClassDiagram": { "Package": "Package", "Class": "Class", "ClassRealization": "Realization", },` The third and fourth section allow for the user to change the multiplicity and role of the target and the source. These can be removed if the functionality is not required.
|
|
The popup should have a property of "element" that will reference the UMLAssociation created in the uml-association.ts that was previously discussed. This will allow us to modify the element itself when changes are made. It's also important to include the "DispatchProps" to allow for the redux actions to take place and help manage the state of the program. When exporting the Popup itself, it renders a div divided into sections. The first section describes the object and renders buttons to allow for the flipping and deleting of the relationship line. The second section renders a dropdown menu that allows for the user to select the new type of the relationship. `<Dropdown value={element.type as keyof typeof ClassRelationshipType} onChange={this.onChange}> <Dropdown.Item value={ClassRelationshipType.ClassAggregation}> {this.props.translate('packages.ClassDiagram.ClassAggregation')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassUnidirectional}> {this.props.translate('packages.ClassDiagram.ClassUnidirectional')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassBidirectional}> {this.props.translate('packages.ClassDiagram.ClassBidirectional')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassComposition}> {this.props.translate('packages.ClassDiagram.ClassComposition')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassDependency}> {this.props.translate('packages.ClassDiagram.ClassDependency')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassInheritance}> {this.props.translate('packages.ClassDiagram.ClassInheritance')} </Dropdown.Item> <Dropdown.Item value={ClassRelationshipType.ClassRealization}> {this.props.translate('packages.ClassDiagram.ClassRealization')} </Dropdown.Item> </Dropdown> `
|
|
|
|
Here we see an example of the popup for a class diagram. Notice value is set to be the different types of the ClassRelationshipType and that when the value is changed, it calls an onChanged handler (which will be discussed later). Each Dropdown.Item's value should then be bound to the different types available for the relationship. This will automatically call onChange when the value changes, with the new value that is selected by the user. To display values for the dropdown item, the popup will call this.props.translate('packages....'). This path leads the program to the src/main/i18n/en.json(or de.json depending on the language), where the user will be able to declare how it is displayed. For example, to display "Realization" for the realization type, you would write: `"packages": { "ClassDiagram": { "Package": "Package", "Class": "Class", "ClassRealization": "Realization", },` The third and fourth section allow for the user to change the multiplicity and role of the target and the source. These can be removed if the functionality is not required.
|
|
|
|
|
|
### OnChange and OnUpdate
|
|
### OnChange and OnUpdate
|
|
|
|
|
|
OnChange is built to handle the changing of types, while OnUpdate is built to handle the changing of values for role and multiplicity. OnChange is fairly straightforward: it takes a type of the Diagram's Relationship Types, and updates the element to that new type. OnUpdate is slightly different. It takes whether the item changing is multiplicity or role, and whether it is a source or target element, and then calls an update to the associated Association file (in this case it is UMLAssociation, which was discussed earlier, and it changes the different properties of that element such as how there is a target with multiplicity and role and a source with the same properties).
|
|
OnChange is built to handle the changing of types, while OnUpdate is built to handle the changing of values for role and multiplicity. OnChange is fairly straightforward: it takes a type of the Diagram's Relationship Types, and updates the element to that new type. OnUpdate is slightly different. It takes whether the item changing is multiplicity or role, and whether it is a source or target element, and then calls an update to the associated Association file (in this case it is UMLAssociation, which was discussed earlier, and it changes the different properties of that element such as how there is a target with multiplicity and role and a source with the same properties).
|
|
|
|
|
|
Now that the popup itself has been explored, it's time to understand the different types and how to implement them.
|
|
Now that the popup itself has been explored, it's time to understand the different types and how to implement them.
|
|
|
|
|
|
## Implementing Relationship Types
|
|
## Implementing Relationship Types
|
|
|
|
|
|
Implementing different types of relationships takes more work for Unidirectional relationships. This is where the Bidirectional and Unidirectional implementations begin to differ most. Be prepared for lots of creating of new files and jumping between them. You will be mainly modifying the uml-relationship-type.ts file, uml-relationships.ts file, and the corresponding index.ts file that coordinates with your new diagram type. If there are multiple types, you will be creating entirely new files dedicated to the specific type.
|
|
Implementing different types of relationships takes more work for Unidirectional relationships. This is where the Bidirectional and Unidirectional implementations begin to differ most. Be prepared for lots of creating of new files and jumping between them. You will be mainly modifying the uml-relationship-type.ts file, uml-relationships.ts file, and the corresponding index.ts file that coordinates with your new diagram type. If there are multiple types, you will be creating entirely new files dedicated to the specific type.
|
|
|
|
|
|
###index.ts
|
|
###index.ts
|
|
|
|
|
|
This is definitely the easiest modification to make. Here, you will declare a type (in the case of the Class Diagram, it is ClassRelationshipType, where you declare an option for each type you want to support. This will be referenced throughout the rest of the program, and you can see an example in popup section.
|
|
This is definitely the easiest modification to make. Here, you will declare a type (in the case of the Class Diagram, it is ClassRelationshipType, where you declare an option for each type you want to support. This will be referenced throughout the rest of the program, and you can see an example in popup section.
|
|
|
|
|
|
###uml-relationship-type.ts
|
|
###uml-relationship-type.ts
|
|
|
|
|
|
This part is also pretty straightforward. Here you will do three things: declare a baseline relationship type that will store all the types created in your respective index.ts called UMLRelationshipType, create a constant that also stores all those types also called UMLRelationshipType, and set a default type for each diagram type called DefaultUMLRelationshipType. You will be modifying an already created file, so understanding isn't as difficult. For the first two variables, you simply plug your new types created in index.ts as they are already shown for previous diagram types. For the third variable however, you must wait until you have at least one type declared for yourself.
|
|
This part is also pretty straightforward. Here you will do three things: declare a baseline relationship type that will store all the types created in your respective index.ts called UMLRelationshipType, create a constant that also stores all those types also called UMLRelationshipType, and set a default type for each diagram type called DefaultUMLRelationshipType. You will be modifying an already created file, so understanding isn't as difficult. For the first two variables, you simply plug your new types created in index.ts as they are already shown for previous diagram types. For the third variable however, you must wait until you have at least one type declared for yourself.
|
|
|
|
|
|
###uml-relationships.ts
|
|
###uml-relationships.ts
|
|
|
|
|
|
Here is where the bulk of the compatibility issues will begin. It seems fairly straightforward to add a type, which it is, but for unidirectional it requires a little bit of extra work. This is where you will begin to add your own files. To begin create a file for your new relationship type, something that references the diagram type and the relationship type you are trying to add. Then include your type that was declared in index.ts (in the case of Class Diagram, it is ClassRelationshipType), as well as the Association Type that was discussed in the very first section of this guide (in this case it was UMLAssociation, the file tied directly to the component). Then, export this new type as a class that extends the association type (UMLAssociation in this case once again), and write `type = ClassRelationshipType.ClassAggregation;` where ClassRelationshipType.ClassAggregation is your type declared in the index.ts type. You can then return to the uml-relationships.ts file and link the type declared in the inedex.ts to this newly created class as so (with Class Aggregation as the example): `[UMLRelationshipType.ClassAggregation]: UMLClassAggregation`.
|
|
Here is where the bulk of the compatibility issues will begin. It seems fairly straightforward to add a type, which it is, but for unidirectional it requires a little bit of extra work. This is where you will begin to add your own files. To begin create a file for your new relationship type, something that references the diagram type and the relationship type you are trying to add. Then include your type that was declared in index.ts (in the case of Class Diagram, it is ClassRelationshipType), as well as the Association Type that was discussed in the very first section of this guide (in this case it was UMLAssociation, the file tied directly to the component). Then, export this new type as a class that extends the association type (UMLAssociation in this case once again), and write `type = ClassRelationshipType.ClassAggregation;` where ClassRelationshipType.ClassAggregation is your type declared in the index.ts type. You can then return to the uml-relationships.ts file and link the type declared in the inedex.ts to this newly created class as so (with Class Aggregation as the example): `[UMLRelationshipType.ClassAggregation]: UMLClassAggregation`.
|
|
|
|
|
|
Congratulations, your new type is now available for use! You can also now change the default type to this new type in uml-relationship-type.
|
|
Congratulations, your new type is now available for use! You can also now change the default type to this new type in uml-relationship-type.
|
|
|
|
|
|
Hopefully this information is helpful in getting your bearings on creating a new relationship type. It isn't completely comprehensive, but it should help in getting you more familiar with what you will be modifying. Always make sure to familiarize yourself with the code first by jumping to where declarations are made and use debuggers before you make modifications! |
|
Hopefully this information is helpful in getting your bearings on creating a new relationship type. It isn't completely comprehensive, but it should help in getting you more familiar with what you will be modifying. Always make sure to familiarize yourself with the code first by jumping to where declarations are made and use debuggers before you make modifications! |
|
|
|
\ No newline at end of file |