Training Guide and Workbook

Application V 1









© March 2017 SageTea® Software Inc.  All Rights Reserved                                    


Table of Contents

Module 1: Course Overview        5

Introduction        5

Module 2: Introduction to SageTea and Text-to-Software        8

Module Objectives        8

The SageTea Concept        8

How it Works        9

Module 3: Text-to-Software Connections Tab        10

Module Objectives        10

Exercise 3-1: Logging in and creating user profiles        14

Exercise Objective        14

Context        14

Exercise Instructions        14

Module 4: Text-to-Software Requirements Tab        15

Module Objectives        15

Module 5: Importing, Exporting and Saving Applications        20

Module Objectives        20

Exercise 5-1: Load an application into Text-to-Software; upload to server        23

Exercise Objective        23

Exercise Instructions        23

Exercise 5-2: Importing and Exporting Requirements using Microsoft Word and Chat        25

Exercise Objective:        25

Exercise Instructions:        25

Module 6: SageTea Runtime        27

Module Objectives        27

Installing a Text-to-Software Application        27

Overview of the SageTea Browser Interface        30

SageTea Browser Navigation        30

Find        31

Orientation to the INSAPP Text-to-Software Training Application        31

Home        32

Query Submitted Reports        32

Inspection Details Container        33

Additional Details Container        33

Vessel or Gear Inspected Container        33

Catch Inspected Container        34

Non-Compliance Container        34

Temp Inspection Report        34

Submitted Inspection Report        35

Creating New Input Screens        35

Exercise 6-1: Working with Text-to-Software and INSAPP        37

Exercise Objective        37

Exercise Instructions        37

Module 7: Mapping Requirements from Text-to-Software        38

Module Objectives        38

Review of a Simple Requirements Document        38

Exercise 7-1: Mapping Requirements in Text-to-Software and INSAPP        39

Exercise Objective:        39

Exercise Instructions:        39

Module 8: Smart Parts        41

Module Objectives        41

Working with Smart Parts        41

Exercise 8-1: Getting to know Smart Parts        43

Exercise Objective:        43

Exercise Instructions:        43

Module 9: Building Applications Using Text-to-Software        44

Module Objectives        44

Introduction        44

Accessing Basic Commands by Right-Clicking        44

Working in the Software Lifecycle Field        44

Working With Elements        48

Creating Elements        49

Elements Commands        50

Working with Groups        51

Working with Activities        53

Working with User Interface Screens (States)        54

Working with User Interface Transitions        56

Working with User Interface Events and Actions        58

Exercise 9-1: Creating and editing use cases and requirements        59

Exercise Objective:        59

Exercise Instructions:        59

Exercise 9-2: Creating fields        60

Exercise Objective        60

Exercise Instructions        60

Exercise 9-3: Creating forms, activities and user interface screens        61

Exercise Objective        61

Exercise Instructions        61

Exercise 9-4 Creating and editing User Interface Transitions        62

Exercise Objective        62

Exercise Instructions        62

Exercise 9-5: Building INSAPP        63

Exercise Objective        63

Exercise Instructions        63

Module 10: Orientation to Business Intelligence Tab        67

Module Objectives        67

Business Intelligence        67

Defining the Data Link Profile        68

Defining the Connection Type        68

Selecting the Group for the New Application        68

Creating Mapping        69

Importing the Data        69

Additional Features        69

Exercise 10-1: Importing data into INSAPP        70

Exercise Objective        70

Exercise Instructions        70

Module 11: Working with Logic Using the Text-to-Software Editor        71

Module Objectives        71

Working in Controller States        71

Exercise 11-1: Creating controller events and actions using the rule Smart Part        78

Exercise Objective        78

Exercise Instructions        78

Module 12: Introduction to Content Manager        79

Module Objectives        79

Working with Themes        79

Working with the Text-to-Software Graphics        81

Working with Web Controls        82

Exercise 12-1: Creating and customizing application themes        84

Exercise Objective        84

Exercise Instructions        84

Appendix        85

Figures        85



Module 1: Course Overview


Welcome to the INSAPP Text-to-Software® Training Guide and Workbook.

Module 2: Introduction to SageTea and Text-to-Software

This module introduces SageTea and its suite of products and tools. By the end of this module, participants will:

Module 3: The Text-to-Software Connection Tab

This module introduces the Text-to-Software Connection Tab and shows how to connect to the Text-to-Software Application Server. By the end of this module, participants will:

Module 4: The Text-to-Software Requirements Analysis Tab

This module introduces the Text-to-Software Requirements Tab, including what each of the components does and how they relate to one another. By the end of this module, participants will:

Module 5: Importing, Exporting and Saving Applications

This module demonstrates how to save and import application data into Text-to-Software from the Text-to-Software server and external data sources. By the end of this module, you will be able to:

Module 6: SageTea Runtime

This module will provide an introduction and orientation to an application developed using Text-to-Software. This application will also provide the context to being introduced to Runtime – the “shell” in which all Text-to-Software-developed applications are launched. By the end of this module, participants will:

Module 7: Mapping Requirements from Text-to-Software

This module will introduce the logic flow from a requirements document, through the Text-to-Software tool to a finished business application. By the end of this module, participants will:

Module 8: Smart Parts

This module will introduce you to Smart Parts. At the end of this module, participants will know:

Module 9: Building Applications Using Text-to-Software

This module will introduce how to manipulate text using Text-to-Software, in order to create software. At the end of this module, participants will be able to:

Module 10: Creating Events and Actions Using the Virtual Machine Editor

This module will orient participants to defining events and actions using business logic, using the Virtual Machine Editor and the Text-to-Software Editor. This is an advanced Text-to-Software feature that requires some knowledge of coding and development. As such, the training will not go into details related to logic, but will orient participants to the Virtual Machine Editor, with the assumption that they have a basic understanding of programming logic.

Module 11: Introduction to Text-to-Software Content Manager

This module will explain how to change the look and feel of an application. At the end of this module, participants will be able to:

Module 12: Orientation to Business Intelligence Tab

This module will introduce how to import data from external sources into an application built using Text-to-Software.  By the end of this module, participants will:



Module 2: Introduction to SageTea and Text-to-Software

Module Objectives

This module introduces SageTea and its suite of products and tools. By the end of this module, participants will:

The SageTea Concept

SageTea was created with the vision of delivering customized software effectively and efficiently, in shorter time and lower cost. SageTea Inc. is a Canadian company located in Ottawa that is able to create working software directly from text.

Text-to-Software means that people can use text to develop software rather than needing to be developers and know how to write computer code.

When any business software is opened, whether it is using Word, Excel, or Internet Explorer, its basic shape is a rectangle. Inside that rectangle are groups of things that are also rectangles. Inside those rectangles are things we use every day: buttons, text boxes, text areas, which are also rectangles.

What the SageTea system does is draw rectangles inside rectangles down to any level. This creates the ability to create any number of programs. That’s how SageTea makes software.

When creating software using Text-to-Software:

For people acquainted with Unified Modelling Language (UML) a lot of what is in SageTea will be familiar:  






Groups and Elements were added to traditional UML in order to make up SAGETEA. Subsequently, it has been called it by its trademarked name SageTea®. SageTea® is the name of the company and an acronym that represents:








SageTea allows for modelling anything needed to be seen on a screen and all the individual parts of a database - no matter how refined. The result is that with SageTea, a complete structure is available to express any computer system. That’s how Text-to-Software works.

SageTea compresses any set of database tables down to seven. So, it’s like mp3 but for SQL databases. Commercial projects can have hundreds or even thousands of database tables. SageTea can do the same job and use only seven database tables. Reducing database tables means:

To deploy SageTea, a set of products has been developed. These are:

How it Works

A business analyst takes business requirements in English – the common language of business worldwide – from clients either over the phone, in a text document, off a website, or from an SQL database. The business analyst then feeds the requirements into Text-to-Software, where they are processed. When the requirements are converted into the Text-to-Software format, in one button click, the business analyst can then upload a program that does what the English says it is supposed to do.

The cycle is done without programming, giving users reductions in cost and time.


Module 3: Text-to-Software Connections Tab

Module Objectives

This module introduces the Text-to-Software Connection tab and shows how to connect to the Text-to-Software Application Server. By the end of this module, participants will:



Figure 1: Text-to-Software Connections Screen

Connections Tab

Applications can be developed in Text-to-Software without having to connect to the Text-to-Software server. However, being connected to the server is required in order to upload or download application data so that it can be launched as an application. If the user tries to close Text-to-Software without saving application data, they will be prompted to do so. If the user chooses to upload the application to the server and if they are not already connected, they will need to connect.  

Every time Text-to-Software is started, the default starting point is the First tab.  Connecting to the Text-to-Software server is done through the Connections tab. To access the Connections tab, click on the Connections tab near the top of the screen.

Login Details

The Connections tab has a number of fields and buttons. There are four fields located in the Login Details area of the Connections tab that are required to be completed. They are:

Username and Password, go without saying. However, an important thing to note when working with Text-to-Software, each application being developed is assigned a specific port on a particular Text-to-Software Server.

The Text-to-Software Server Address identifies the Text-to-Software server where the application being developed will reside.  The Text-to-Software Server Port identifies the port on the Text-to-Software Server where the application can be accessed.  

In order to connect to the Text-to-Software Application Server to upload or download an application, a user will need to know not only their Username and Password, but also the Text-to-Software Server Address and Port associated with that application.

The connection buttons below these field are:

“Web Server Status” field is clickable and is hyperlink to preview that enables you to open the application once you have uploaded your changes.

Working with Profiles

Saving that information as a profile can skip the tedious process of typing the user name, password, server address and port every time a user connects. To do this, click the Add button in the Profiles field and give the profile a name. Then click the profile, type the login information, and click the Save button.

Every application has a different port. When working on multiple applications, different login information will be required to access each application.

Profiles can be added, deleted, saved, renamed, imported and exported using the icons shown below.


Renaming profiles can be useful for assigning them a memorable name – the application or the user’s own name, for example.

Since Text-to-Software is system-specific, profiles can also be Imported and Exported in order to have them on multiple systems.

Best Practice Alert!!

Remembering different login information for multiple applications can be a challenge. So, to make things easier, you can create a profile for each application, and whenever you want to log in to work on a particular application, you can simply select that application’s profile – the four fields will fill in automatically. Then click Connect.

Inputting Networking Settings

The network settings must be entered in order for Text-to-Software and the Application Server to communicate with each other.  Just like the login details section of the Connections tab provide the relevant information for the Application Server being used, the network settings below the login details provide the relevant information related to the client network.  Only when both of these sections are properly completed will you be able to connect to the Application Server.

Before being able to set these variables, ports must be opened on the client network. This is usually done by accessing the router and adding Port Forwarding settings.  If you do not have direct access to the router, you will need to contact your system administrator to do this for you.

The WAN IP Address is the public IP address. It can be manually entered but it is safer to find it automatically found by clicking on the Get button.

The IIOP Port Range is range of ports that have been assigned to Text-to-Software, one of which is opened on the client router.

Connecting to SageTea Runtime

Once the login information has been entered and saved as a profile, the user can then connect to the Text-to-Software server by clicking the Connect button.

After a few seconds, the buttons that were grey – Download, Upload, Disconnect– become active, and the Connect and New buttons becomes grey. This indicates that Text-to-Software is connected to the server.

If these button changes do not occur, verify that the login information has been entered in each field correctly and try again. If that still doesn’t work, contact the system administrator for assistance.


Exercise 3-1: Logging in and creating user profiles

Exercise Objective

To successfully use Text-to-Software to log in to a copy of the training application using the username, password, SageTea Server Address, and SageTea Server Port assigned to you.


For the purposes of training, each participant will be working on separate copies of an application called INSAPP. This is so that when one participant does something on the application, he or she will not interfere with the work being done by other participants. All of the different copies of the training version of INSAPP are on the same SageTea Server, but each copy is accessed through a different port.

To connect to the SageTea server for the purpose of this training, you will need to input your assigned Username and Password, the SageTea Server Address and your specific SageTea Server Port. The course instructor will provide that information to you. Note that usernames and passwords are case sensitive.

Exercise Instructions

Once you have received your individual login information from your instructor:

  1. 1.On the Connection Tab, type your login information in the appropriate fields. 

  2. 2.Click Connect. 

  3. 3.Once you are logged in, create a profile for yourself by clicking Add and give it a memorable name. 

Once you have completed these steps, inform your instructor.

If you have problems logging in or creating your profile, please also inform your instructor.


Module 4: Text-to-Software Requirements Tab

Module Objectives

This module introduces the logic used in Text-to-Software as applied in the Requirements tab, including what each of the components does and how they relate to one another. By the end of this module, participants will:


Figure 2: Text-to-Software Requirements Screen



Figure 3: Text-to-Software Requirements, Requirements Description, right-click menu

Requirements Tab

Text-to-Software automates the application development process. Its underlying logic is the same logic that has been used for decades to program business software. For those that have developed software before, this will not be new.

In Text-to-Software, most of the time is spent working on the Requirements tab.

The Requirements tab is divided into three sections. The top third documents the application project and requirements using the Software Lifecycle and Requirement Description of Requirement field. The middle third relates to the application’s structure and user interface, and the bottom third relates to the application’s logic.

The top third of the Requirements tab does not directly affect an application. It is used to document requirements and the underlying application structure and logic. Nothing in this top third appears in an application unless it is eventually transferred to one of the seven fields in the bottom two thirds of the Requirements tab.  Business analysts are the primary users of the upper third section of the Requirements tab.

Best Practice Alert!!

While you can develop applications without completing the top section of the Requirements tab, it is not advisable to do so. Completing this section with as much detail as possible allows for referring back to the initial requirements and logic upon which the application is based when making adjustments and future customizations.

Software Lifecycle

The Software Lifecycle field is where application Use Cases and Requirements are defined. In Text-to-Software, the term Use Case refers to a complete process – a complete workflow or scenario – from beginning to end and which includes associated requirements.

The field drop down, accessed by right clicking the field, contains functions and sub-sections like:

Publish is a useful tool as it can be used in business to generate proposal requirements like estimates, Statement of Work, Contract, etc.  

Test can be used to document software testing processes.  Every requirement should have a Test Case.

Instantiate creates working elements from the Use Case requirements.  Use Cases can be instantiated in manual, semi auto or full auto modes.  Instantiating in full auto mode will create the corresponding groups, activities and states for that Use Case as well as the elements.  If the Use Case is instantiated in manual mode only its elements will be created.  How Use Cases are instantiated for your application can be set in the Project Lifecycle tab at the top of the page.  

Best Practice Alert!!

Each Use Case should be described in detail and in plain language in the Description field.


Requirements are the things that need to be done in the workflow. A requirement is the reason why something exists in the application. If there is no requirement, then there is no need for a particular state, field, action, etc. Therefore, there is a requirement behind every component of Text-to-Software. Once a requirement has been created in a use case, its associated Text-to-Software component can be developed.

To create a requirement, the name of the requirement is typed into the Requirement box in the top middle of the Requirement tab and the Use Case where the requirement will reside is selected. Clicking the Add button then adds the requirement to the highlighted Use Case in the Software Lifecycle box.

As with Use Cases, each requirement can also be described in more detail, using the Requirement Description box. To do that, create the requirement, and then select it in the Software Lifecycle box and type the description in the Description box.  

All of these boxes in the top third of the Requirements tab work together to document how the application is being built based on client requirements.

Best Practice Alert!!

Adding a flowchart, image or diagram of the application data structure and logic is helpful for developers as they create applications.


Elements are the basic building blocks of all applications. An element is anything and everything that one sees and doesn’t see in an application. One of the uses of elements in an application is data entry boxes, check boxes and the like. They can also become rules for events and actions. Elements also become instantiated into groups, activities, and states.

Using the client relations management system example presented earlier, some of the elements for the use case related to maintaining a client database may be client name, home phone number, work email address, etc.

In Text-to-Software, every field is a requirement in a Use Case.  To make a field, first create a requirement in a Use Case and then instantiate to create the field (element) and corresponding group that represents that requirement.


To make sure the elements that belong together are displayed together, they must be organized into groups. Elements will not appear in an application unless they are brought together in a group.

Groups organize elements (and other groups) so that they travel together. For example, if an application has seventeen elements that should appear together in a state, they would be joined together under a single group.


Activities are tasks or processes a user does. They contain and manage groups. A group has to be in an activity in order to appear in a state. The logic is that if nothing is happening to a group, there is no need for a state to show it. A state contains an activity, which contain a group, which contain elements, however activities themselves do not appear as part of the application user interface; they are what take place “behind” it.


When adding an activity to a state, it means the group (and related sub-groups) the activity contains displays on that screen in the application. For a screen to be displayed in an application, it must contain an activity. Each activity can only contain one group, and each screen can contain only one activity.  There are two settings for a screen: visible and invisible. Screens automatically appear in an application as visible but can be changed to invisible. Invisible screens can be used for a number of reasons; for example: screens under development and screens that have activities related to them that should not appear as part of the user interface for any number of reasons.


Transitions make things happen or move the user from place to place in the application. On the user interface, any two screens need a transition between them to allow users to move from one to another. The transition is the process that happens when a user clicks on a button, for example, but it is not the button itself. User interface transitions are based on simple if/then logic: if this button is triggered, then change from screen A to screen B.

On the controller side, transitions also create movement from one state to another. For example, moving from the state of being idle (waiting for user input) to the state of checking for email. A transition can be created that defines under what conditions that will happen. It’s like a nudge to let the computer know that it’s time to do something.


Events define under what conditions a transition will occur; i.e. it triggers a transition. An event can be initiated by a user (such as a button click) or by the system (such as a timer counting down).


Actions define what happens when an event triggers a transition. For example, when the internal clock reaches a particular time (event), then the system will check for email (action).

When setting-up a transition for the user interface, events and actions will be defined automatically.  

Module 5: Importing, Exporting and Saving Applications

Module Objectives

This module demonstrates how to save and import application data into Text-to-Software from the Text-to-Software server and external data sources. By the end of this module, participants will be able to:


When working in Text-to-Software, most of the time is spent on the Requirements Tab. This is where the application’s data and logic is created.

When first launching Text-to-Software, there will be data loaded into the tool. This is called Default Application in the Software Lifecycle field, and includes some states, activities, groups, and elements. This isn’t really an application, but a few initial data elements to begin working with.

The Requirements Tab can be used to manipulate this data to create an application in manual mode without connecting to the Text-to-Software server. Closing Text-to-Software without saving the application data will cause a prompt to save the application. To upload or download the application data to the server, requires a connection to the server.

If an application has already been started and saved using the Text-to-Software tool, that application can be imported from multiple sources. Three of those sources are: a .dlc file; Text-to-Software server; and a requirements document.

Importing an Application from a .dlc file

First, start with a new application by clicking File, New Application.

Now Text-to-Software is ready to begin the development of a new application.

To import an existing application from a .dlc file, click File, Load Application. Find the appropriate .dlc file and click Open. The application data will be imported into Text-to-Software.

Uploading an Application to the Server

To upload the application from Text-to-Software to the server, click the

Connection Tab and then click the Upload button. Note that this will overwrite any application data that is currently on the server. To prevent overwriting an existing application on the server if it is uncertain if a version already exists, check the Abort on Version Change checkbox. This will stop Text-to-Software from overwriting the application on the server, for example if someone else is also working on the same application.