Glossary of Terms

Actions

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.

Activities

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.

Boolean Operators

Boolean operators are simple words that you use to create conditions that the application has to check before performing the actions you tell it to.
The Boolean operators you can use are:

• “And”—Write “and” to add another condition that has to be fulfilled before doing an action.

• “Or”—Write “or” when you want your program to do one thing or another, but not both.

• “Not”—Write “not” when you are looking for a condition to be not true. For example, you could tell your application to check if it is raining, and if is it not raining, to put its umbrella down. If you tried to write this command without using not, you would end up telling your application to check to see if it’s sunny, if it’s cloudy, if it’s snowing, and so on. You’ll find it simpler to just tell your application to check if it’s not raining by using a “not” statement.

Business Intelligence Tab

Text-to-Software’s Business Intelligence is a tool that allows for data import and mapping the fields in a new application against existing data sources, whether they be files or databases.

Business Rule

Business rules aren’t forms or fields or things you can see on the screen. Business rules define what the application does. A business rule contains a transition and a description of what that transition does.
Business rules appear under use cases in the Software Lifecycle box on the Requirements Analysis tab.

Chat Bot

Chat Bot is an interactive natural language interface that allows an end user to talk directly with the AI and ask it questions. The context of the conversation is limited to talking about the regulatory topic. It offers various advantages, such as user-friendliness, fast processing, ability to infer solutions (which may or may not have been created previously) and an ability to converse in various languages.

Controller States

The controllers of an application are the engines that do the work behind the scenes. For example, the user interface states (screens) display the graphical elements of your application, and the controllers do the work behind the scenes.
Controllers make things happen when:

• The user presses a button
• A timer is up
• A variable equals something
• Any other number of events occur

Switching between user interface, client controller, server controller, and web server controller states can be done easily in Text-to-Software from the Tools menu. Different states will be displayed when in each of these views. When in user interface states, the screens of the application will be displayed.
Use the Tools menu to assist in setting controllers.

Transitions between controller states (client, server, and web controller) tell the application when to move from one state to another. Transition events and actions between controller states can be defined from the Requirements Tab, or using the Virtual Machine Editor.

Data Link Profile

Data Link Profile is a field in the Business Intelligence Tab, where the data import process is defined.

Default Application

Default Application is the data loaded into the Text-to-Software, when first launching the tool. It 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.

Elements

Elements are the basic building blocks of applications made with Text-to-Software. An element is anything and everything that is seen and not seen 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. In Text-to-Software, every element is associated with a requirement in a use case. To make an element, create a requirement in a use case, and then create the associated element to respond to that requirement.
Elements can be changed from simple fields into Smart Parts to give them functionality.
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.

Events

Events define under what conditions transitions occur and actions define what happens when the transition occurs; 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 a state transition occurs. When setting up a transition in the user interface view, events and actions will be defined automatically.

Groups

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.

Input Field

Input field is the default setting for an element. It lets the user type in information such as a name or reference number. Once a field has been created from a requirement, it can then be converted into a Smart Part by right-clicking the field and selecting Smart Parts from the list of options. This opens the Smart Parts window, where the Smart Part can be selected and defined.

Instantiate

Instantiate is one of the menu options for Use Cases. 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.

Requirements

In the context of Text-to-Software, 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.
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.

*every requirement should have a Test Case.

SageTea Runtime

SageTea Runtime is Text-to-Software tool which gives the end-user experience. It is the shell in which all Text-to-Software-developed applications are launched.
Every application developed using Text-to-Software is launched using one of three versions of Text-to-Software Runtime:

• The SageTea Browser is a stand-alone version that is located locally on a computer
• The Browser is launched via the SageTea cloud browser
• The Text-to-Software Client, which is integrated into Text-to-Software.

Smart Part

Smart Part is an element that is created from a requirement and then converted into a Smart Part to become functional. Conversion into a Smart Part can be done by right-clicking the field and selecting Smart Parts from the list of options.

Software Lifecycle Right-click Commands

Simply right-clicking the mouse either on the relevant Text-to-Software field or a component contained in that field will give access to most of the commands that will be needed. For more information, please see Accessing Software Lifecycle Basic Commands (Create, Rename, Delete, Reorder, etc.) by Right-Clicking.

SQL database

SQL database is a domain-specific language used in programming and designed for managing data held in a relational database management system (RDBMS), or for stream processing in a relational data stream management system(RDSMS). It is particularly useful in handling structured data where there are relations between different entities/variables of the data. SQL offers two main advantages over older read/write APIs like ISAM or VSAM. First, it introduced the concept of accessing many records with one single command; and second, it eliminates the need to specify how to reach a record, e.g. with or without an index.

States

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.

The IIOP Port Range

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.

The Project Lifecycle Tab

The Project Lifecycle Tab is located at the top of the page.
How Use Cases are instantiated for your application can be set in the Project Lifecycle tab at the top of the page.

The Requirements document

When developing an application in Text-to-Software, the Requirements Document is something a client or business analyst will either provide or that will be developed with a client.

The SageTea Application Server

A server which runs applications developed using Text-to-Software.

The SageTea Browser

A browser which interfaces with the Application Server to launch applications over the Web.

The SageTea Browser Interface features

The SageTea Browser standard features include navigation buttons, and a menu bar. They need to be added to Text-to-Software by entering Link as a requirement. Navigator then appears in the list of Groups and Elements. To ensure that this feature is at the top of the Screen, drag and drop the Navigator to the top of the list of smart parts in each Group.

The SageTea Browser Navigation Buttons

The SageTea Browser Navigation Buttons are the four navigation buttons (New, Delete, Find, and Logout) at the top of the screen. They help navigate an application. Many of their features can be replicated in the features of an application, but the buttons provide an extra way to access those features. The menu items and navigation buttons are the same for all Text-to-Software applications. Some of the button functions also exist in the menu items.

The SageTea Concept

SageTea was created with the vision of delivering customized software effectively and efficiently, in shorter time and lower cost. Developed by David Long, The SageTea Concept is the company’s methodology that is based on the acronym that represents: States, Activities, Groups, Elements, Transitions, Events, and Actions.
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.

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.

The benefits of creating software using Text-to-Software:

• Labour costs for application development are reduced by 50%
• Delivery time is lowered by an average of 60%
• Human coding errors are virtually eliminated
• Design quality is consistent and easy to maintain

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.

Benefits of reducing database tables include:

• Dramatically reduced maintenance costs
• Faster and easier-to-find data
• A much easier way to find bugs in database tables

Text-to-Software includes other products, such as:
• The SageTea Application Server
• The SageTea Browser
• SageTea Runtime

The Smart Parts Window

The window where Smart Parts can be selected and defined.
This window allows for:
• Selecting the Smart Part from a drop-down list
• Defining the size of the Smart Part when it appears on the screen
• Defining the characteristics of that Smart Part, if necessary – such as the elements to put in a drop-down list
• Determining whether that Smart Part will stay on the same line of the screen as the one previous to it or go to another line on the screen.

The Virtual Machine Editor

The Virtual Machine Editor displays a visual representation of an application’s controller states. States display as boxes, and transitions display as arrows that connect the boxes. The Virtual Machine Editor provides the ability to draw arrows between boxes to add and edit transitions.

Test Case

Test Case is an option in the Software Lifecycle field, used when defining Use Cases and Requirements. Test Case is used to document software testing processes and must be used when defining requirements.
Text-to-Software

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. 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.

The Text-to-Software Assistant Editor

Once the start and end states for the transition have been defined and given a name, the transition that is to take place must then be defined. This is done using business rules. The Text-to-Software Assistant Editor helps convert the text business rules for controller state transitions into code that can be used in an application.

The Text-to-Software Assistant Editor is set up in three parts:
• Rule Name at the top and left defines events
• Select Logic at the top right selects logic
• Patterns at the bottom right sets the pattern. The functions of the top and bottom left work similarly to each other.

The top and bottom parts are also divided into left and right.

• The right side selects the logic to apply
• The left side defines the rule and converts text into software

The Text-to-Software Connections Tab

Text-to-Software Connections Tab is used to connect to the Text-to-Software server (connecting to the server is required in order to upload or download application data so that it can be launched as an application). It is located on the top, left-hand side of the Text-to-Software Connections Screen. For more information, see Using the Text-to-Software Connection Tab.

The Text-to-Software Content Management Tab

The Text-to-Software Content Management Tab is used mainly to change the feel and the look of the application. With the help of this tab, you can add or change themes, graphics, labels, set web controls, and other elements that will help to create the perfect look for your application.

The Text-to-Software Editor

This is an advanced Text-to-Software feature that requires some knowledge of coding and development.

The Text-to-Software Requirements Tab

Text-to-Software Requirements Tab can be found right next to the Connections Tab.
The Requirements tab is divided into three sections.

1. The top third documents the application project and requirements using the Software Lifecycle, Requirement Description of Requirement, and ChatBot fields.
2. The middle third relates to the application’s structure and user interface, and the bottom third relates to the application’s logic.
3. 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.

The Text-to-Software Server Address

The Text-to-Software Server Address identifies the Text-to-Software server where the application being developed will reside. It is required for connecting to the Text-to-Software Application Server.

The Text-to-Software Server Port

The Text-to-Software Server Port identifies the port on the Text-to-Software Server where the application can be accessed. It is required for connecting to the Text-to-Software Application Server.

The WAN IP Address

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

Transitions

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.

Use Case

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. Each Use Case can also be described in more detail using the Software Lifecycle field and selecting various options from the drop-down menu.
The field drop down, accessed by right clicking the field, contains functions and sub-sections like:

• Project – Edit Project Data and Initialize Project
• Text-to-Software – Import Word Doc and Export Word Doc
• Reorder Use Cases
• Reorder Requirements
• Renumber Requirements
• Renumber All
• Add to User Manual
• Remove from User Manual
• Search
• Delete
• Use Cases – Add, Rename, Delete, Instantiate, Re-Instantiate, Reorder Requirements, Add Requirement and Add Requirements Set
• Requirements – Add, Become Use Case, Rename, Filter Text, Refactor, Move, Change Management, Delete and Design
• Documentation – Application, Add Page, Rename Page, Delete Page and Update Project
• Publish – Estimate, Work Breakdown Structure, Proposal, Statement of Work, System Design Document, System Quality Assurance Report, User Acceptance Test Plan, Contract, Initialize User Manual and User Manual
• Images – Workflow Diagram, View Image, Edit Image, Delete Image, Add Image to Element and Convert all images to Elements
• Rules – New Rule, Edit Rule, Rename Rule and Delete Rule
• Testing – New Test Case, Edit Test Case, Rename Test Case and Delete Test Case
• Automation Level – Manual Mode, Semi Auto Mode and Full Auto Mode
• Save As

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.