Author Topic: Simplified language definition and user experience (not based on UML profiles)  (Read 139 times)

adepreter

  • EA User
  • **
  • Posts: 53
  • Karma: +2/-2
    • View Profile
Sparx shines thanks to its UML implementation. But the focus on UML and low levels abstractions is also an impediment.

We should be able to create languages without any UML profile.
The user experience, the architecture and the implementation of Sparx might be simplified if languages could be defined independently of UML.

We should be able to create elements, connectors, properties, shapes, metamodels and other consistency rules from scratch.

The language author would create
- Element and connector types (no stereotype)
- Properties (not tag)
- User-defined shapes (not derived from any UML type)
- Properties validation rules (including but not limited to enumerations)
- A metamodel (defining possible combinations of elements and connectors)

The end user of the language would enjoy a simplified user experience user i.e.
- Element and connectors types (no stereotype)
- Properties (not tag) which are editable either in shapes, in property windows and or in catalog sheets (result sets)
- Automatic validation of connectors based on the metamodel, and of properties based on properties validation rules

UML (and legacy UML profiles) would be languages as any other.

qwerty

  • EA Guru
  • *****
  • Posts: 8961
  • Karma: +136/-123
  • I'm no guru at all
    • View Profile
The cross with languages is that you need at least a syntax - and then the trouble starts with semantics. I have no idea how you would ship around those cliffs.

q.

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6193
  • Karma: +47/-5
    • View Profile
The problem isn't that a profile has been used to define the language. It's how to display, edit and report on user defined fields that EA has no knowledge of. Ultimately, regardless of how the language is defined, you are going to end up with a list of properties. ie. It's going to look like our tagged value list. As for the stereotype display, there's probably no reason why we couldn't display to the user no stereotype if the stereotype defines a metatype.

Defining validation rules for connectors and properties isn't something that is in the current profile language. (Although we have been doing a bit in that direction in version 14 if you look at the recent webinar)  But that doesn't have anything to do with how the language is defined. If it was added into existing profiles, it provides exactly the same advantage to users.

The only "extra" work defining profile for a language requires is extending a base UML metaclass. If you want to ignore UML, I'd choose 'Class' and 'Dependency'. Because of the database schema you're working with, you would still need to make that decision if you weren't creating a profile)
Simon

support@sparxsystems.com

Glassboy

  • EA User
  • **
  • Posts: 896
  • Karma: +52/-54
    • View Profile
I'm not sure how different building a universal grammar and specialising UML actually would be.

adepreter

  • EA User
  • **
  • Posts: 53
  • Karma: +2/-2
    • View Profile
OK Simon :)  Indeed it could be fixed only by improving and simplifying the UI and the configuration features (though I still believe it would be simpler to have UML, BPMN or whatever language defined altogether from scratch).

At the end of the day, users of our MDGs would be happy if they had...

a) A single list of properties (not tag) which are editable either in shapes, in property windows or in catalog sheets.

b) Automatic validation of connectors based on the metamodel, and of properties based on properties validation rules

c) Quick links which are transparently derived from the metamodel (without these extra quick links that we cannot get rid of).

--

(a) would require some filter defining which properties and tags need to be visible, in what sequence and for which role
The catalog sheet (like a spreadsheet) would require some sort of element lists which are dynamic and editable. Dynamic legends could also be applied for creating catalog heat maps.


(b) and C) can be implemented either using a metamodel or a language metamodel. For example, we implemented the second option in this language metamodel:

http://labnaf.one/guidance/index.html?guid=688CA55E-E24A-4561-B272-775DDAA01A08

The advantage of a language metamodel is that it can be more easily used for language documentation as it is easily understandable by modelers.


Cheers,
Alain