Modeling a VUE app with UML Class and Sequence Diagram

Question

I am trying to model a part of my VUE app with UML. I used a class diagram to show the structure and a sequence diagram to show one specific behavior.

There are some things I am not sure about:

• in regards to the class diagram: the Form copmonent imports the data criteria, whos criterium is passed to the child and the option to the grand-child. So each instance of the child FormItem holds one criterium of criteria and each instance of the grandchild BaseRadio holds one option of the options array. So the data flow is through the parent. Can I still relate criterium - FormItem and option - BaseRadio as indicated by the blue composition arrows?
• in regards to the sequence diagram, my aim is to visualize the cross-component data flow and custom event communication with emitting events and passing props. I sketched these as synchronous messages, since they don't return anything but this feels weird?
• are the functions called within one component supposed to be reflexive messages? (as shown in the sequence diagram for setoption(option):void for example). And I guess the presentation of computed properties integrationChance and integrationProspectPercentage as reflexive message is wrong, since they dont represent functions?

Here, the draft of the UML class-diagram sketching the VUE app:

And the sequence diagram:

And here the description of what this app does:

• The data for the function is imported as a JSON Object criteria.
• For each criterium (e.g. gender, age, etc.) criteria holds an object named criterium, which has a label and an array options. The options array holds an option for each attribute (male, female, etc.).
• Each option has a name (e.g. male) and a correspondent value (e.g. 0).
• The Form component imports the criteria object and two other components: FormItem and FormResultBar. The Form holds only one FormResultBar. For each criterium in criteria the form holds one FormItem and for each option the FormItem holds one BaseRadio button.
• When the user clicks on a BaseRadio button, its computed property selectedValue emits an event to the FormItem, passing the value of the option that was clicked and the correspondent criteriumKey.
• The FormItem component then sets the selected option (setOption()) and saves it (saveOption(option, criteriumKey) by emitting an event to the parent component Form and passing the parameters option and criteriumKey. In the Form component the saveOption(option, criteriumKey) saves the selected Option by storing it in the selections Object.
• The selections Object holds all the selected options for each criterium. The computed property integrationChance in Form item then calculcates the integrationChance by adding all the values of the options stored in selections. The method integrationChancePercentage transform the logisitic regression value into percentages. The integrationChancePercentage is then passed as the prop “result” to the FormResultBar, where the result gets displayed.

You can find the implemented part of the application here.

Answer 1

The key question here is not whether UML is suitable for the job or not, but what do you want to show in your diagrams:

In this other question I have developed what relevant diagrams could be used for in a JS context with Electron. I think it may answer your question about which diagrams to use.

You have opted for a class diagram. It explains well the the internal structure based on classes and their relationships:

• A Vue component can be represented by a class:

  Components are reusable Vue instances with a name (source: Vue guide)

• props may be shown it as an UML property:

  Props are custom attributes you can register on a component. When a value is passed to a prop attribute, it becomes a property on that component instance. (source: Vue guide)

  UML classes are usually represented with a box with 2 separators. The first part is the class name, the second part is for the properties and a third part are for operations. Since props can be accessed from other components, it seems better to give them a public accessibility in the class diagram (+ instead of -)

• Computed properties could be shown as derived properties, i.e. with its name preceded by /:

(...) its value or values may be computed from other information. Actions involving a derived Property behave the same as for a nonderived Property. Derived Properties are often specified to be read-only (i.e., clients may not directly change values). But where a derived Property is changeable, an implementation is expected to make appropriate changes to the model in order for all the constraints to be met, in particular the derivation constraint for the derived Property. (source: UML specifications)

• Your “methods” are operations in UML,.

• I’m not a Vue expert, but I understand that “watchers” seem to be some special kind of methods.

More generally, I'd suggest to use a custom UML profile for Vue. It may define stereotypes for each of these kind of elements (e.g. «Vue component», «props», «computed») that would precede the name of the element or be above it. This could convey a more precise semantic, especially if there could be ambiguities (e.g. methods vs watchers).

Your narrative explains the interaction between components. This is best documented with a sequence diagram. Lifelines would be instances of components or props instances of a component, and messages exchanged between lifelines would correspond to Vue methods, and other means to exchange information.