DOF-INSAPP

Text-to-Software®

Training Guide and Workbook

Application V 1.5

 

 

 
 

 

 

 

 

 

 

© June 2017 SageTea® Software Inc.  All Rights Reserved                                   

 

Table of Contents

Module 1: Course Overview.. 5

Introduction. 5

Text-to-Software® Auto Trainer Module. 7

Description  7

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

Elements Commands. 49

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

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

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

Introduction

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:

·         Be able to define what Text-to-Software is;

·         Understand the kinds of applications that can be developed using Text-to-Software;

·         Know the three main products/tools that make-up the Text-to-Software suite; and

·         Appreciate the savings that Text-to-Software brings to software development.

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:

·         Be able to locate the Connection Tab;

·         Understand the need for the four Login Details fields;

·         Understand how to set Client Network settings;

·         Create a user profile for a single application;

·         Be able to connect to an assigned Text-to-Software training application using a username, password, Text-to-Software Server Address and Text-to-Software Port;

·         Know when you are connected to the server; and

·         Know whom to contact if you cannot connect.

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:

·         Know what use cases, requirements and the seven SageTea components are; and

·         Understand the logic of how use cases, requirements and the seven Text-to-Software components are used to create applications.

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:

·         Import and export application data from/to a .dlc file;

·         Upload and download application data from/to the Text-to-Software server;

·         Clear Text-to-Software in order to start developing a new application; and

·         Export application data to a Word document.

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:

·         Know what each of the buttons and menus items on Runtime does;

·         Understand what the training application is intended to do; and

·         Be able to navigate the training application using Runtime features and the application’s built-in navigation features.

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:

·         Be able to locate, in the Requirements Tab, business requirements that are written in a Word document; and

·         Be able to locate where those same requirements appear in a finished application.

Module 8: Smart Parts

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

·         What Smart Parts are;

·         What each type of Smart Part does; and

·         How to turn an input field into a Smart Part.

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:

·         Create, rename, delete, and reorder use cases and requirements;

·         Create, rename, and delete states, activities, groups, sub-groups, elements, and transitions; and

·         Turn input fields into Smart Parts.

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:

·         Set the background and field colours of Text-to-Software;

·         Create a Theme for an application;

·         Define the background colour for an application; and

·         Define the colour for each Smart Part within an application.

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:

·         Understand the purpose of the Text-to-Software Business Intelligence Tab

·         Know how to select the source of external data;

·         Know how to map exiting data to the data fields of the Text-to-Software-developed application

Text-to-Software® Auto Trainer Module

Description

Text to Software has a built in Auto Trainer which provides self guided learning, an overview of key features of Text to Software, theory and techniques. The Auto Trainer will automatically create its own training portal if it sees one is needed for a particular user.

The Auto Trainer is launched by clicking File -> Training from the main menu in Text to Software:

 


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:

·         Be able to define what Text-to-Software is;

·         Understand the kinds of applications that can be developed using Text-to-Software;

·         Know the three main products/tools that make-up the Text-to-Software suite; and

·         Appreciate the savings that Text-to-Software brings to the development of software.

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:

·         Labour costs for application development are reduced by 50%;

·         Delivery time is lowered by an average of 60%;

·         Human coding errors are virtually eliminated; and

·         Design quality is consistent and easy to maintain.

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

States

Activities

Transitions

Events

Actions

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:

States

Activities

Groups

Elements

Transitions

Events

Actions

 

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:

·         Database maintenance costs are dramatically reduced;

·         Data is faster and easier to find; and

·         Finding bugs in database tables becomes an easy task.

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

·         The Text-to-Software tool, which is used to develop applications;

·         The SageTea Application Server, which runs applications developed using Text-to-Software;

·         The SageTea Browser, which interfaces with the Application Server to launch applications over the Web; and

·         SageTea Runtime, which gives the end-user experience.

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:

·         Be able to locate the Connections tab;

·         Understand the need for the four Login Details fields;

·         Create a user profile for a single application;

·         Be able to connect to an assigned Text-to-Software training application using a username, password, Text-to-Software Server Address and Text-to-Software Port;

·         Know when you are connected to the server; and

·         Know whom to contact if you cannot connect

 

Figure 1: Text-to-Software Connections Screen

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

vLogin 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

·         Password

·         SageTea Server Address

·         SageTea Server Port

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:

·         Connect

·         Download

·         Disconnect

·         Upload

·         New

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

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

  Add Profile

  Delete Profile

  Save Profile

  Rename Profile

  Import Profile

  Export Profile

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.

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

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

Context

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.       On the Connection Tab, type your login information in the appropriate fields.

2.       Click Connect.

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:

·         Know what use cases, requirements and the seven SageTea components are; and

·         Understand the logic of how use cases, requirements and the seven SageTea Text-to-Software components are used to create applications.

Figure 2: Text-to-Software Requirements Screen

 

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

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

 

vSoftware 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:

·         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

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.

wRequirements

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.

xElements

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.

yGroups

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.

zActivities

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.

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

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

} Events

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

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:

·         Import and export application data from/to a .dlc file;

·         Upload and download application data from/to the Text-to-Software server;

·         Clear Text-to-Software in order to start developing a new application; and

·         Export application data to a Word document.

u Introduction

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

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

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

Figure 4: Text-to-Software Connections Tab

Saving Application Data as a .dlc file

There are times when exporting an application as a data file is required. This is useful for:

·         Transferring an application from one system to another; and

·         Backing up an application.

To do this, click File, Save Application As.

Figure 5: Text-to-Software Connections, File Menu

 

Just as with many other applications or documents, once the application has been saved once, it can continue to be saved simply by clicking File, Save Application.

Downloading Application Data from the Server

Downloading an application from the server is the easiest way to import application data into the Text-to-Software tool, assuming that application already exists on the server.

To download a copy of the INSAPP training application from the Text-to-Software server, go back to the Connections tab and click the Download button.  Proceed to the Requirements tab to see and work with the application data.

Best Practice Alert!!

Do NOT click the Upload button when you do not have the latest version of the application loaded into Text-to-Software. Clicking the Upload button takes whatever data is in the Text-to-Software tool and OVERWRITES what is on the server. So, instead of downloading the application from the server, it would overwrite that application with the default data that is already in Text-to-Software.

Saving an Application as a Requirements Document in Word

Exporting an application to Word is slightly different from using a .dlc file. This is closer to working with Text-to-Software. This exercise will focus on the process of exporting into Word.  Later modules will look at the actual content of the Word document.

Exporting to Word is useful when a document that outlines the business requirements is needed. Text-to-Software has the ability to reverse engineer requirements into text. So, in this case it’s not Text-to-Software, it's actually software to text.

To do this requires having the application in Text-to-Software, and also having Word installed on the system being used.

From the Requirements tab, click on the Project Lifecycle menu, then Text-to-Software, then Export Word Doc.

Text-to-Software immediately opens and creates a Word document. It will then prompt to give it a file name and save it.

Best Practice Alert!!

It is important to NOT click on the Word document as it is being created.  Doing so will cause the text to continue to be written wherever you click in the document.


 

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

Exercise Objective

To successfully:

·         Load an application into Text-to-Software using a .dlc file;

·         Upload an application to the Text-to-Software server;

·         Save a copy of an application as a .dlc file on the SageTea Browser; and

·         Download an application from the Text-to-Software server into Text-to-Software.

Exercise Instructions

Part 1 – Loading an Application into Text-to-Software

1.       From the Requirements tab, clear Text-to-Software of any existing data by clicking File, New Application. When prompted to save the application, select No.

2.       Load the INSAPP.dlc file by:

3.       Clicking File>Load Application;

4.       Finding the INSAPP.dlc file and click Accept.

 

Part 2 – Connecting to an Application Database in Server Control

1.       Enter the DB Hostname, DB Port, DB Name, User ID and Password; and

2.       Click the Connect button at the bottom of the field to connect to the database for this application.

 

Part 3 – Uploading an Application to the Text-to-Software server

1.       Click the Connections tab; and

2.       Enter the Username, Password, SageTea Server Address, SageTea Server Port, WAN IP Address (use Get to find the address of your computer) and IIOP Port Range, if not already entered, then click Connect; then

3.       Click the Upload button to upload the application to the server.

 

Part 3 – Saving an Application as a .dlc File to the SageTea Browser

1.       Click File>Save Application As;

4.       Give the file the name {INSAPP-yourlastname.dlc} and save it on the SageTea Browser; and

5.       Click Accept.

 

Part 4 – Downloading an Application from the Text-to-Software Server into Text-to-Software

1.       From the Requirements tab, clear Text-to-Software of any existing data by clicking File, New Application. When prompted to save the application, select No;

2.       Click the Connections tab;

3.       If you are not connected to the server, click Connect; then

4.       Click the Download button and wait for the application to download; and

5.       Return to the Requirements tab to make sure the application has been downloaded from the server.

Inform your instructor once you have completed.


 

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

Exercise Objective:

To successfully export a copy of the INSAPP training application to create a Word-based requirements document.

Exercise Instructions:

1.       Start with a blank application.

2.       From the Requirements tab, with a blank application in Text-to-Software, click Project Lifecycle -> Text-to-Software -> Import Word Doc -> INSAPP.docx. 

3.       You should see the following application in the Requirements Tab:

 


Figure 6:Text-to-Software, Requirements, INSAPP after import from text

4.       From the Requirements tab, click Project Lifecycle -> Text-to-Software -> Export Word Doc.  A word doc will open and the application will load automatically in text version.

5.       Once completed, Word will prompt you to give the file a name. 

6.       The Word document will close automatically and return you to Text-to-Software.

7.       Open the file and enter the sentence “INSAPP has a Use Case named My New Use Case.” at the end of the document.

8.       Load the document into Text-to-Software. You should see the new use case in the Software Lifecycle box on the left.

 

Practice editing the Word document using similar phrases to what you see in the document. Create all the parts of SAGETEA from Word following the style and syntax in the Word document. Reimport your changes using the Text-to-Software->Import Word Doc feature.

Inform your instructor once you have completed this section.


 

Module 6: SageTea Runtime

Module Objectives

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 Text-to-Software Runtime – the shell in which all Text-to-Software-developed applications are launched. By the end of this module, participants will:

·         Know what each of the buttons and menus items on Text-to-Software Runtime does;

·         Understand what the INSAPP training application is intended to do; and

·         Be able to navigate the INSAPP training application using Text-to-Software Runtime features and the application’s built-in navigation features.

Installing a Text-to-Software Application  

Text-to-Software is used to build applications. Every application developed using Text-to-Software is launched using one of three versions of Text-to-Software Runtime:

1.       The SageTea Browser is a stand-alone version that is located locally on a computer;

2.       The Browser is launched via the SageTea cloud browser; and

3.       The Text-to-Software Client, which is integrated into Text-to-Software.

The SageTea Browser can be thought of as the shell that surrounds the application. For training purposes, the Text-to-Software Browser will be used.

Installation Mode:

To install an application using the SageTea Browser, you first need to download and install the Browser.  Use the link provided to you to begin downloading the application.

1. The SageTea Browser Setup Wizard will guide you through the different stages.  Follow the prompts and click Next to continue.

 

 

 

                                                

 

 

 

 

 

2.       This is the second stage.  Click on Install for Current User and then click Next. 

 

 

 

 

 

3.       Select Typical and then click Next.  

 

 

 

 

 

 

 

4.       Click Install to install the program.    Once that is complete, click Finish.             

 

 

 

 

 

 

Go to your computer downloads folder or search function to find the downloaded “SageTea Browser” and open it.

To install the program:

1.       Click on Computer Health Check first to see your computer capacity.  Then click Next.

 

 

 

 

 

 

 

 

 

 

2.       Click Have Account and then Next to move forward. 

 

 

 

 

 

 

 

3.       First, check I have a private server, then enter the User Name, Password, My Cloud Server and My Cloud Number.    This is information that would have been given to you by the Presenter. 

Note that the information is case sensitive.

When complete, click Connect to Cloud to open the application.       

 

 

 

 

 

4.       Now that the application has been installed, whenever a DFO officer uses the application they will login directly using this screen with their username and password. 

 

 

 

 

Overview of the SageTea Browser Interface

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.

SageTea Browser Navigation

Figure 7: Menu Buttons

There are four navigation buttons 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.

SageTea Browser

Name

Menu

What it Does

 

New

File>New

Adds another instance of whatever you are currently working on (form, file, record, state, etc.).

 

Delete

File>Delete

Deletes current the instance, record, file.

 

Find

View>Find

Allows the user to search the application for Screens, Records, words, etc.  (disabled for this application)

 

Logout

File>Logout

Enables the user to logout of the application

 

Additional menu items

File>New

Allows the user to create a New form or record.

File>Delete

Allows the user to Delete a form or record.

File>Rename

Allows the user to Rename a form or record.

File>Logout

Allows the user to log out of the application.

View>Next Item

Allows the user to move to the Next Item in a list.

View>Previous Item

Allows the user to move to the Previous Item in a list.

View>Next Step

Allows the user to move to the Next Step or screen.

View>Previous Step

Allows the user to move to the Previous Step or screen.

View>Find

Allows the user to search the application for Files, Records, words, etc.

Help>Help

Brings up the Help dialogue box.

Find

The Find Search engine is very useful for locating information or moving to another Screen in the application or item on a screen.  It was disabled in the INSAPP application to keep the process very simple and straightforward, but generally to access it:

1.       Click the Find button (magnifying glass) or View>Find in the menu. The Navigator Sidebar will then appear on the left side of the screen.  

There are three tabs at the top – Jump to, Navigator and Search.

1.       Jump to – lists all the Screens in the application.  This enables you to jump to any Screen in the application, without having to go through the steps to get there.  To use:

a.       Click on the name of the desired Screen and the application will move to that Screen

2.       Navigator – lists all the items belonging to the Screen that you are on, i.e. if on “Temp Inspection Report”, the Navigator will list all the reports.  To use:

a.       Click on an item in the list to see that item’s details displayed on the Screen

3.       Search – this is a multi-purpose search feature.  Any word or name can be searched within the application.  To use:

a.        Enter the word or name in the top bar, set the filters, if desired, then click the Search button.  The results will be displayed in the field below. 

b.       Click the Clear button to clear all results when finished.

Orientation to the INSAPP Text-to-Software Training Application     

The INSAPP Text-to-Software application, that was used to build INSAPP, is an application that is comprised of screens, forms and fields. For the purpose of training, it is important to have a good understanding of how this application works, its general purpose and logic, as well as some of its main components, so that it can be worked with in Text-to-Software.

This application was built to provide remote report generation and report management for Department of Fisheries Field Officers.  The application’s functions are the creation and local storage of new reports plus the uploading of new and downloading of archived reports. 

Each tabbed screen contains information about the inspection details.  Screens are linked together in a workflow and the user clicks “Next” to move to the next screen or stage in the report.  

                    

Home

When INSAPP is first launched, it opens to the Home screen because this is the first screen listed in Text-to-Software.

On this screen, you can see the two buttons for creating a new or viewing an archived report (Query Submitted Reports).

 

Query Submitted Reports

Is the dashboard for searching archived reports, in whichever the data base the application is connected to. 

 

 

 

 

 

Inspection Details Container

This screen shows all the information about the container inspection.

The details include date, time, location and officer(s).

 

 

Additional Details Container

This screen displays all additional details from the inspection.

There are tabs at the top of the file list that sorts the information into Main, Vessel, Vehicle, Site, Gear and Person.

 

 

Vessel or Gear Inspected Container

This screen displays the checked inspection details and whether they were compliant or not. 

It also records the gear inspection and dockside monitoring checklist.

 

 

 

Catch Inspected Container

This screen shows the details of the catch inspected. 

 

 

Non-Compliance Container

This is where the details of a non-compliant container are listed and what action will be taken.

 

 

Temp Inspection Report

This screen is where all completed reports, not yet been uploaded from a Toughbook, can be viewed.

At the bottom is the “Submit Report” button to submit and button to create a next new report.

 

 

Submitted Inspection Report

This show the same copy of the report, now submitted and with no “Submit Report” or “Create Another Report” buttons at the bottom. 

 

 

 

 

Creating New Input Screens

New input screens are made by using the Add button to the right of the subgroup.

Figure 8: INSAPP, Creating New Input Screens

 

To create a new input screen using the subgroup function:

1.       Click on the Add button to the right of the subgroup.

2.       Click on the new empty, highlighted row to activate the input fields below the sub-group.

A new input screen will be created associated with the blank row in the subgroup.  The screen will be given a generic name and will have to be named manually in the pop up box.

When creating an input screen using this method, it will automatically be linked to the originating screen and show in the sub-group once complete.

 


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

Exercise Objective

To navigate the INSAPP Text-to-Software training application using the application navigation features and effectively add new records and information into the system.

Exercise Instructions

Follow the instructions in the actions column below, and indicate what you did and what happened in the centre and right-hand columns respectively.

Action

What You Did

What Happened

In Catch Inspected Container, create a new input screen called Test 1.

 

 

 

Enter the data into the report.

 

 

Create a new record called Test 2.

 

 

Add the data into the Test 2 record.

 

 

Open Test 1 and change the name of the Species and Refresh the data by clicking the Refresh button to the right of the sub group.

 

 

Navigate through Jump to in the sidebar to Temp Inspection Report to see the records that were created.

 

 

Inform your instructor once you have completed.

Module 7: Mapping Requirements from Text-to-Software

Module Objectives

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:

1.       Be able to locate, in the Requirements Tab, business requirements that are written in a Word document; and

2.       Be able to locate where those same requirements appear in a finished application.

Review of a Simple Requirements Document

There are three kinds of basic information that need to be considered when developing an application in Text-to-Software:

1.       The Requirements document – which is something a client or business analyst will either provide or that will be developed with a client;

2.       The Text-to-Software tool – which will be used to manipulate requirements in order to create an application; and

3.       The final application.

The skill that needs to be developed is to be able to look at any one of these three pieces of information and see, in one’s mind, what the other two should look like.

In given a Requirements document, one should be able to begin to see what the final application might look like and what those seven boxes in Text-to-Software might contain.

When working in Text-to-Software, one should imagine what the Requirements document might contain, and what the final application should look like as well - and the same if looking at an application. The three are intrinsically related, and one mirrors the other.

We will begin by comparing and contrasting these three pieces of information by using a set of business requirements written in Word for the INSAPP application, which can be found on the next twelve pages. This is an edited version of the Word document that was exported from Text-to-Software once INSAPP was created. It captures everything that is currently part of INSAPP. Take a few minutes to read through the requirements.

Note

Use the exported Word document created in “Saving an Application as a Requirements Document in Word” on page 22.

Your instructor will work with you to edit the document.

 

 

 

               

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

Exercise Objective:

To correctly locate business/application requirements written in a Word document in Text-to-Software and the INSAPP application.

Exercise Instructions:

Work in pairs.

1.       On separate computers, one participant opens INSAPP in the Requirements tab in Text-to-Software, and the second participant opens INSAPP as an application in Runtime or Browser.

2.       Locate the requirements taken from the Word document in Module 7, in the left-hand column of the table below, in both the Text-to-Software Requirements Analysis tab AND the INSAPP application.

3.       Write your answers in the table below, being sure to indicate every location where the requirement was found.

4.       You may use short-hand responses (e.g.: “5 times in the Activity field”)

The instructor will review the exercise once everyone is finished.

Requirement

Found in Text-to-Software

Found in INSAPP

Inspection Details Container has a field named Inspection Date.

 

 

 

 

 

Query Submitted Reports has a sub group named Submitted Inspection Report.

 

 

 

 

State named Non-Compliance Container.

 

 

 

 

Subgroup named Additional Details - Person.

 

 

 

 

 

Element named Species.

 

 

 

 

Field named Add Officer.

 

 

 

 

 

 

State named Query Submitted Reports.

 

 

 

 

 

 

Activity named Manage NonCompliance

 

 

 

 

 

 

 


 

Module 8: Smart Parts

Module Objectives

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

·         What Smart Parts are;

·         What each type of Smart Part does; and

·         How to turn a field into a Smart Part.

Working with Smart Parts

Elements can be changed from simple fields into Smart Parts to give them functionality.

Reminder:

As described earlier, every Element is associated with a requirement in a Use Case. To make an Element, you first create a Requirement in a Use Case, and then create the associated Element.

The default setting for an element is an Input field. This 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.

Figure 9: Text-to-Software, Smart Parts Editor

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; and

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

Figure 10: Text-to-Software, Smart Part Placement

The following is a list of some of the Smart Parts in the application along with an image for each.

Drop Down List

                        Preloaded list                                                                             

 

 

Text Area (expandable)

Accepts text notes

Date Field

Sets dates

 

 

Check Box

 

Turns input fields into check boxes

File Sub-Group

Linked files in a sub-group

 

 

 

 

Input Field

Information input

Exercise 8-1: Getting to know Smart Parts

Exercise Objective:

To correctly identify what a particular Smart Part is and why it may be used in an application.

Exercise Instructions:

1.       Identify each Smart Part in the table below and why it may be used; and

2.       Write your answers in the table below.

You may refer back to your notes and information in module 8 to assist you.

Smart Part Image

What is it?

Why it May be Used

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Inform your instructor when you are finished.


 

Module 9: Building Applications Using Text-to-Software

Module Objectives

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:

Introduction

Working with Text-to-Software Components is easy and relatively intuitive. Depending on what information is given about a client’s requirements, there are different ways to manipulate those requirements in order to develop the application.

Of course, having requirements written clearly in a way that Text-to-Software understands them would be best. In that case, the requirements would simply be imported, the application uploaded to the server and it would be done. Unfortunately, rarely will a set of requirements be provided that are that clear or complete. There will undoubtedly need to be some manipulation of the requirements in Text-to-Software in order to create the final application. This module will explain how to add, delete, move, and edit components in Text-to-Software from scratch.

Accessing Basic Commands by Right-Clicking

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.

Best Practice Alert!!

To ensure that an application adopts any changes made in Text-to-Software, upload the changes before opening the application and save your application when exiting.

Working in the Software Lifecycle Field

Reminder:

There is a requirement behind every component of Text-to-Software. A use case and its associated requirements should be created for each part of an application. Use cases and requirements, when they appear in the top portion of the Requirements tab, are for application planning and documentation purposes only and do not appear in the application.

 

 

 

 

Software Lifecycle Commands

Figure 1: Text-to-Software Requirements, Software Lifecycle right-click commands

The following table outlines the right-click commands to work with use cases and requirements.

In Order To:

Select:

Right-Click and Select:

Commands Related to Documents in the Software Lifecycle

Store background documentation that is not part of the application itself

Anywhere in the field

Documentation>Add Page

Rename a document in the Software Lifecycle field

Select the document

Use Cases>Rename

Delete a document in the Software Lifecycle field

Select the document

Delete

Commands Related to Managing Use Cases

Reorder use cases

Anywhere in the field

Reorder Use Cases

Add a new use case

Anywhere in the field

Use Cases >Add

Rename a use case

Select the use case

Uses Cases>Rename

Delete a use case

Select the use case

Use Cases>Delete

Create fields, forms, activities and states from existing use cases and requirements

Select the use case

Use Cases>Instantiate

Turns a use case into a test case document

Select the use case

Testing>New Test Case

Reset the use case description text to just the title of the use case

Select the use case

Use Case>Re-Initialize

Commands Related to Managing Requirements

Reorder requirements within a use case

Select the use case

Reorder Requirements

Add a requirement to a use case

Select the use case

Use Cases>Add Requirement

Add multiple requirements to a use case

Select the use case

Use Cases>Add Requirement Set

Turn a requirement into a use case

Select the requirement

Requirements>Become Use Case

Rename a requirement

Select the requirement

Requirements>Rename

Remove extraneous text and characters (i.e. to, and, &^%,) from the description

Select the requirement

Requirements>Filter Text

Turn each word of the text in the Description field into an individual requirement

Select the requirement

Requirements>Refactor (Consider using Filter Text first)

Delete a requirement

Select the requirement

Requirements>Delete

Commands Related to Rules

To create a rule in the Software Lifecycle and have it also become a field/element

Anywhere in the field

Rule>New Rule

To edit a rule using the Text-to-Software™ Editor

Select the element

Smart Part>Value Change Notification

Rename an existing rule

Select the rule

Rename Rule

Delete a rule

Select the rule

Delete Rule

Other Commands

Find a use case, requirement, test case or document that contains a particular character or word

Anywhere in the field

Search

To reduce the number of steps to add a requirement, a requirement can also be added to a use case by highlighting the use case in the Software Lifecycle field, then typing the name of the requirement in the Requirement field. Then click the Add button. The requirement will automatically be added to the selected use case.

Figure 2: Text-to-Software Requirements, Requirements Definition Area

Best Practice Alert!!!

Text-to-Software is intended to make programming easier. It was built to capture as much information as possible so that later it is clear what was intended in the first place. Therefore, it is a best practice to add a description in the Description field for every use case and requirement created.

Images or Screenshots

To associate an image or screenshot to a use case, an image can be uploaded to the Image or Screenshot field. This can be particularly useful when working with legacy systems, and want to have a reference back to what the different components of that system looked like. It can also be useful to include the business logic diagrams for specific use cases.

  To upload an image to the Image or Screenshot field:

·         first click and highlight the associated use case,

·         and then right-click on the name,

·         select Images in the dropdown box,

·         select Edit Image and then a dialogue box opens and the image to be uploaded can be selected,

·         click the Accept button,

·         resize, if necessary,

·         click Yes in “Updated Image for Selected Element” dialogue box.

Figure 3: Text-to-Software, Requirements, Software Lifecycle, Images

Working With Elements

Reminder:

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. 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 may become any part of an application, including elements, forms, activities, screens, transitions, actions, and events. Therefore, in order to make one of these other components, it must first be created as an element and then turned into that component.

Best Practice Alert!!

In order to reduce confusion and to be able to navigate an application more easily, give each element a unique name.

There are three ways to create an element:

In this module, we focus on the first two ways.

 

Creating Elements

When converting text from the Requirement Description box into elements, right-clicking in the Requirement Description field can be quite useful.

The following table outlines the commands to reverse engineer elements and groups from text in the Description field.

Figure