From the top-down, what defines a UI is (1.) roughly the stripped-down application logic transfered to a (2.) UI approach with some (3.) optimizations for usability.
Same for persistance: the (1.) stripped-down application logic is transfered to a (2.) storage approach (like “relational database”) and then (3.) optimized.
The plan is to leave 1. up to the programmer by letting him create the UI logic, e.g. as diagram, and move 2. to a kit. The kit also needs some (3.) hints in order to achieve a workable UI.
The logic of the UI
Ideas from object-orientation are currently used to describe the model.
The model contains classes with their attributes, actions and relations as they are exposed in the UI. However, it contains only classes, which are intristic to the application subject, e.g. "Person", and not classes, which are bound to the UI, e.g. "Window".
I used the term “stripped-down application logic” above, because the UI logic is often mostly a subset of the application logic.
The UI logic is a different thing from the object orientated application logic, but they propably will look very similar in practice, as they both have the same root: the subject of the application, expressed in object orientation.
In other words, both are models of the same thing, but with different points of view and scopes.
Their relationship can be compared with the one between application logic and data storage logic.
bla
If needed, e.g. for to-many-relationships or inheritance, build-in data types can be represented as classes, but such classes must not have attributes.
All build-in data types, including primitive data types, are available.
Build-in data types (may better be defined by taskets):
Basic
Bool
Integer (w/ and w/o range)
enum
Float
String (formatted and non-formatted, maybe with size-spec)
Standard
Color
DateTime (maybe just date or time)
File
Actions are similar to methods in OO programming classes and define actions, which can be performed on the object.
The following operations must be provided by every object:
Lifecycle operations (creation, deletion, moving, copying)
equals (must return true, if both object references point to the same object instance, otherwise false)
Relations can be seen as attributes of the objects on every end. They may have an identifer (“be named”) on any end and both a minimal and a maximal cardinality must be specified for every end. The following cardinalities are supported: 0, 1 and * (* means “any member of N0” and is only valid as maximum).
3 distinct typed of relations are supported: pointing, aggregate and composition relations. All of them are directed (e.g. pointer from A to B), but can be navigated in both directions. Aggregate and composition relations have a containing semantic.
Only binary relations (relations with 2 ends) are supported. Relations and roles must not have attributes by themselves.