Rosetta Design ¶

Rosetta Design is a sophisticated model editor that allows the user to edit model files in their own working environement (called a Workspace). This Rosetta Component features different Views, which the user can switch between, and different tools that make the navigation and the use of the editor user friendly.

We recommend that users get familiar with Workspace management basics prior to reading this Rosetta Design section.

In this section, you will learn about:

• Rosetta Design Window
• Rosetta Design Model Explorer
• Rosetta Design Content Assist

Rosetta Design Window ¶

Rosetta Design Window is the main space displayed by default in a Workspace Window. When the user uses other Rosetta Components or Features such as Rosetta Ingest, Projection, Validation or Reports, the Rosetta Design Window occupies the top half of the Window (unless the user expands that other Component or Feature to be full-screen).

The Rosetta Design window comprises 3 parts:

• The Rosetta Design View bar
• The model content (shown in accordance with the selected view)
• The Rosetta Design Toolbar

Rosetta Design View bar ¶

To visualise a model, the user can choose from different available views in the Rosetta Design View bar at the top-left of the Rosetta Design Window.

Different Views: different representations of the same component ¶

Rosetta Design comprises the following views:

• Textual View

This is the main view of Rosetta Design that displays functional expressions of data and business logic of a model as text. This is where users primarily develop the logical model using the Rosetta DSL syntax. The Rosetta Design Model Explorer is displayed by default on the left hand-side and you can resize it by dragging the right hand-side of the panel.

The Rosetta Design Model Explorer displays the logical model as a tree. The tree is displayed in a hierarchical structure and the user can expand and collapse nodes to display the contents of the tree.

• Definition View

This is a view displaying all the components of a model in a table. A description of each component is available based on information edited from the Textual View. This view is useful to screen concepts and definitions that populate a model thanks to the Find All search function. It is particularly appropriate for subject-matter experts from the domain being modelled, who want to quickly access a glossary of model components.

• Graphical View

This is a view displaying any selected part of a model as an interactive graphical tree. It indicates the relationship (either through inheritance of inclusion as attribute) between the different model components. This view is particularly useful to test and validate progress on model editing in the Textual View, thus accelerating logical modelling. It also helps easily locate a specific data field in the data model and the corresponding path from a root type, which facilitates mapping exercises and the writing of rules.

The following example based on the Demonstration Model displays a graphical representation of the VehicleOwnership with its attributes and inheritances (i.e. when a component extends another component and inherits from its attributes).

New Regulation Panel (Documentation Reference View) ¶

When the new regulation Panel is available a toggle will be displayed at the top right of the panel, this toggle will switch between the legacy and new view.

The new regulation panel focuses on document references (docRefs) within the model, offering users a comprehensive overview which comprises of three vertical panels, each grouping and organising the docRefs."

1. Body Corpus List
   The initial column groups docRefs based on Body Corpus, allowing users the ability to pinpoint their area of interest.

2. Hierarchical Rule Types and Segments
   The middle column displays all docRefs associated with the selected Body Corpus in an hierarchical list. These are grouped by rule type and subsequently by docRef segments, presenting a structured overview.

3. Provision Details
   Column three is a flat list with details about each document reference. The details displayed depends on the model but the available items are:

• Provision
• Rationales
• Reporting Rule
• Provisions on the same rule
• Dependent provisions

Switching from one View to another ¶

The user can easily switch from one view to another, which facilitates the navigation through the different representations of a same model component:

• From the Graphical View to the Textual View: by clicking on the Textual View button in the right hand-side panel.

• From the Regulation View to the Textual View: by clicking on the name of the reporting field displayed as hyperlink, or on the rule definitions of the information summary for the considered reporting field.

Rosetta Design Toolbar ¶

All the editing tools available are accessible in the Rosetta Design Toolbar shown at the top-right of the Textual View.

Rosetta Design Toolbar comprises of

• Open Commands: List of editor tools
• Search All Rosetta Files: Search engine for free text across all model files
• Go To Symbol: Search engine for model elements and types across all mode files
• Undo/Redo: Undo/Redo functionalities
• Go Back/Forward: Back/Forward page navigation within the Textual View
• Zoom In/Out: Zoom in/out of functional expression display in the Textual View
• Toggle Wrap Text: Formatting of the lines in the Textual View (expanding or collapsing, with no model impact)

Most of these tools and commands are meant to be familiar to users of traditional dev kits, albeit much slimmed-down in order to resemble a basic text editor which non-developers can also get comfortable using.

An important difference with a traditional text editor is that model elements are hyper-linked in the Application. This implies that each model element can be navigated to and from:

• either by searching for the element directly, via the Go to Symbol command in the Rosetta Design toolbar, here used to search for the vehicle element in the Demonstration Model

• or by pressing Ctrl / Cmd + Click on the element name wherever it appears in the Rosetta Design Window. Simply hovering over the element brings its description to the foreground (illustrated here with the Specification Type in the Demonstration Model):

This is akin to having a text editor associated to a dictionary, where any occurrence of a word from that dictionary provides a handle to navigate to the definition of that word.

Rosetta Design Model Explorer ¶

Rosetta Design contains a list of model files that have been copied across from the chosen model source-control repository and into the user Workspace. Each file is accessible by clicking its name in the left-side Model Explorer panel of Rosetta Design. The current file opened in the right-hand side Rosetta Design Window is highlighted in the Model Explorer:

The Rosetta Design Model Explorer allows the user to keep track of changes made to the model in their Workspace, by annotating which files have been modified with the initial M. Those changes can be discarded and reverted back to the original source-control version by clicking on the Discard back arrow:

Add New Namespace ¶

To add a new namespace to the model, follow these steps:

1. Open the Rosetta Design Model Explorer panel in your application
2. Locate the “New Namespace” button at the bottom of the panel and click on it
3. A “Create Namespace” popup will appear, divided into three sections: Namespace Path, File Type, and Namespace Preview
4. In the Namespace Path section, enter the desired path where you want the new namespace to be stored. This path determines the location for the namespace and its associated file
5. Choose the appropriate File Type for your namespace in the respective section
6. The “Namespace Preview” section will display a preview of the new namespace structure based on the provided path and file type
7. Take a moment to review the namespace preview to ensure it aligns with your expectations and requirements
8. When you are satisfied with the namespace details, click the “Create” button
9. The new namespace will be added to the model, and the associated file will be automatically selected for further editing or customization

By following these steps, you can easily add new namespaces to your model.

Rosetta Design Content Assist ¶

Rosetta Design features a number of content-assist tools to guide users through editing the model:

• Syntax highlighting
• Syntax checking
• Auto completion
• Auto compilation

We recommend that users get familiar with the Rosetta DSL documentation for how the model is expressed, prior to reading this section.

Syntax Highlighting ¶

Rosetta Design highlights different syntax features to improve readability of the model being edited, as shown in the colour-coding schemes displayed in the below example and further down in the documentation:

The model elements being highlighted in different colours are:

• DSL syntax keywords like func, alias etc.
• text (as string elements between "")
• numbers

Syntax Checking ("Validation") ¶

The syntax checking feature works similarly to spell checking in a text editor, with the model providing the underlying dictionary. However, syntax checking is strictly enforced against the formal Rosetta DSL: the model is invalid if there is any syntax error.

In the below example, we introduce a syntax error by mis-spelling the term VehicleFeature in the Demonstration Model. The resulting term gets underlined in red as VehiclFeature is not a valid term in the dictionary:

Often, editing the model in one place may trigger syntax errors in some other place. To aid users identify those, files containing errors are shown in red in the Model Explorer and a red cursor in the right-side scroll-bar points to the line(s) where errors appear. Users could also review the errors one by one by clicking on the Go To Next Error button next to the Rosetta Design Toolbar.

Auto Completion ("Scoping") ¶

To prevent syntax errors occuring in the first place, Rosetta Design can guide editing of the model by offering auto-completion suggestions in a drop-down list as the user types. Auto-completion is aware of the surrounding scope in which the model is being edited and offers suggestions that are relevant to that scope.

In the below example, the user is editing a type (CarOwnership) in the Demonstration Model and is looking to complete the type of one of its attributes (of name: vehicle). As they start to type a V, Rosetta Design is aware that the user is able to use Vehicle as a type, because it already exists as a defined type in the model:

The auto-completion tool-tip can also be invoked manually by pressing Ctrl / Cmd + Space.

Auto Compilation ¶

As soon as a model is syntactically correct in the Rosetta DSL, it becomes executable and Rosetta Design will automatically try to generate and compile executable code from it. A traffic light icon at the bottom-right representing the status of the model compilation (by default: from Rosetta DSL into Java) is updated in real-time as the user edits their model.

The traffic light colour code corresponds to the following status:

• green: the model compiles without any issue
• amber and spinning: compilation is running
• amber and static: the model cannot compile due to syntax erros
• red: the model compilation fails

Because the model syntax is pre-validated, the code generation process should normally generate valid code that compiles. However, in certain cases this process could fail with the compilation ending-up in red status with an error message being reported. There are 2 cases where this could occur:

1. The Rosetta DSL syntax validation is not strict enough to capture all cases where invalid code could be generated.
2. The compilation depends on some "static" code (i.e. code that is not dynamically generated from the model), and the model has introduced incompatibility with such code.

Users are advised to contact the Rosetta support team who can help resolve when they encounter such issue. Users can use the in-app chat to raise a request and copy/paste the error message reported in the application.

The Rosetta Design application is constantly being improved and looking to eventually eliminate the occurence of the above 2 issues. This requires removing all static code by having all code driven from the Rosetta DSL syntax, and making the Rosetta DSL syntax validation comprehensive. Every issue occurence raised will help the support team identify the gaps that may still exist and which should be addressed.

See Rosetta Code Generation for further technical information on how the code generation process works.