1
Vote

View Definition

description

These are the Use Cases for defining Views, based on a host DSL domain model of any complexity.

Hierarchical View

Objective
Define a view that represents a sub-part of a domain model. Since a domain model is inherently hierarchical, it makes sense to want to define a view that includes domain classes rooted at some point in the hierarchy, containing multiple branches, and each branch terminating at a particular domain class in the hierarchy.
Requirements
  • This kind of view will have a single root, and multiple branches, each branch with many levels and children.
  • Each branch would need termination, either defined explicitly by user, or implicitly at end of branch.
  • Each branch expose children domain classes, relationships and properties of each child and relationship.
  • In cases of 1-to-1 relationships, the user should be able to choose to ignore the intermediate relationship in the view.
    Use Experience
  • In the DSLEditor shape, the user chooses a domain class from the host DSL as the root class of the view
    -> The user is then presented with the entire domain model rooted at that class, showing its child relationships and domain classes in a hierarchical list (indented to indicate ancestry). This list would include items representing the embedding relationships, and potentially reference relationships. These relationships may be presented with visual difference.
    -> Each domain class and relationship would also expose each of its domain properties as a sub list item.
    -> Each domain class, relationship and domain property would be displayed with a checkbox (or similar UI cue) to allow user to select/deselect it. By default all classes and relationships are checked.
  • The user browses the list of (collapsed) items, and can expand/collapse and check/uncheck each checkbox.
    -> For domain properties this indicates whether to include the property of the domain class or relationship in the view with the domain class or relationship
    -> For domain classes or relationships, un-checking indicates the termination of that branch, indicating that the remaining branch is not included in view.
  • The user can chose to re-include a domain class or relationship by re-checking its checkbox, and this forces inclusion of all its ancestor items (which are unchecked if any in that branch)
    -> 0-to-1 or 1-to-1 relationships, can be indicated uniquely to user, these can then be skipped or omitted from the view for simplicity (perhaps context menu feature or Boolean property).
     

Aspect View

Objective
Define a view that represents a single aspect of the host DSL domain model (i.e. security, state etc). Again it makes sense to want to define a view that includes domain classes rooted at some point in the hierarchy, containing multiple branches, and each branch terminating at a particular domain class in the hierarchy. The difference between this view type and the previous, is that these aspects are domain property centric.
Not entirely sure if this view type is accounted for in previous view type.
 

Reporting View

Objective
Define a view that reports on one or more aspects of a view. The primary difference between this view type and previous, is that this view is primarily read-only, and totals, may somehow be included.

comments