Chapter 1: Common Features of High Level Programming Languages 2

TABLE OF CONTENTS
Chapter 1: Common Features of High Level Programming Languages

Data Type Summary
Variables
Use of Operators in High Level Programming Languages
Functions
2
2
4
8
16
Chapter 2: Develop a software component design specification

Decision Tables
Structure Charts
19
19
21
Chapter 3: Prepare for Testing

Test Plans
IEEE 829 Test Plan Structure
Types of Programming Errors
Testing Techniques
25
25
26
27
28
Chapter 4: Identify Health and Safety Requirements

Basic Safety Rules for Technology Labs
Ergonomics
Repetitive Strain Injury
30
30
31
32
References
36
INTERNATIONAL TRAINING COLLEGE LINGUA
Page 1
Create Designs for Software

Chapter 1
Common Features of High Level Programming Languages
Data Type Summary
The examples used in this section are based on the Visual Basic & C Programming languages.
The following table shows the Visual Basic data types, their supporting common language runtime types, their
nominal storage allocation, and their value ranges.
Common
language
Nominal storage
runtime type
allocation
structure
Depends on
Boolean
implementing
platform
Byte
1 byte
0 through 255 (unsigned)
Char
2 bytes
0 through 65535 (unsigned)
Date
DateTime
8 bytes
Decimal
Decimal
16 bytes
Visual Basic
type
Boolean
Byte
Char (single
character)
Double
(doubleDouble
precision
floating-point)
Integer
Long (long
integer)
Value range
True or False
0:00:00 (midnight) on January 1, 0001 through 11:59:59

PM on December 31, 9999
0 through +/-79,228,162,514,264,337,593,543,950,335 (+/7.9...E+28) with no decimal point; 0 through +/7.9228162514264337593543950335 with 28 places to the
right of the decimal;
smallest nonzero number is +/0.0000000000000000000000000001 (+/-1E-28)
-1.79769313486231570E+308 through 4.94065645841246544E-324 for negative values;
8 bytes
Int32
4 bytes
Int64
8 bytes
4.94065645841246544E-324 through
1.79769313486231570E+308 for positive values
-2,147,483,648 through 2,147,483,647 (signed)
-9,223,372,036,854,775,808 through
9,223,372,036,854,775,807 (9.2...E+18 ) (signed)
4 bytes on 32-bit
platform
Object
Object (class)
Any type can be stored in a variable of type Object

8 bytes on 64-bit
platform
Page 2
SByte
Short (short
integer)
Single (singleprecision
floating-point)
String
(variablelength)
UInteger
SByte
1 byte
-128 through 127 (signed)
Int16
2 bytes
-32,768 through 32,767 (signed)
UInt32
Depends on
implementing
platform
4 bytes
ULong
UInt64
8 bytes
-3.4028235E+38 through -1.401298E-45 for negative values;

Single
String (class)
4 bytes
Depends on
User-Defined (inherits from
implementing
(structure)
ValueType)
platform
UShort
UInt16
2 bytes
1.401298E-45 through 3.4028235E+38 for positive values

0 to approximately 2 billion Unicode characters
0 through 4,294,967,295 (unsigned)
0 through 18,446,744,073,709,551,615 (1.8...E+19 )
(unsigned)
Each member of the structure has a range determined by its
data type and independent of the ranges of the other
members
0 through 65,535 (unsigned)
In scientific notation, "E" refers to a power of 10. So 3.56E+2 signify 3.56 x 102 or 356, and 3.56E-2 signifies
3.56 / 102 or 0.0356.
Note
For strings containing text, use the StrConv function to convert from one text format to another.
When you declare an elementary data type, it is not safe to assume that its memory consumption is the same
as its nominal storage allocation. This is due to the following considerations:
Storage Assignment. The common language runtime can assign storage based on the current
characteristics of the platform on which your application is executing. If memory is nearly full, it might
pack your declared elements as closely together as possible. In other cases it might align their memory
addresses to natural hardware boundaries to optimize performance.
Platform Width. Storage assignment on a 64-bit platform is different from assignment on a 32-bit
platform.
Composite Data Types

The same considerations apply to each member of a composite data type, such as a structure or an array. You
cannot rely on simply adding together the nominal storage allocations of the type's members. Furthermore,
there are other considerations, such as the following:
Overhead. Some composite types have additional memory requirements. For example, an array uses
extra memory for the array itself and also for each dimension. On a 32-bit platform, this overhead is
currently 12 bytes plus 8 bytes for each dimension. On a 64-bit platform this requirement is doubled.
Storage Layout. You cannot safely assume that the order of storage in memory is the same as your
order of declaration. You cannot even make assumptions about byte alignment, such as a 2-byte or 4-
Page 3
byte boundary. If you are defining a class or structure and you need to control the storage layout of its
members, you can apply the StructLayoutAttribute attribute to the class or structure.
Object Overhead
An Object referring to any elementary or composite data type uses 4 bytes in addition to the data contained in
the data type.
Variables
Definition: Variable In computing, a variable is a named unit of storage that can be changed to any of a set of
specified values during execution of a program.
Local Variable
In computer science, a local variable is a variable that is given local scope. Such a variable is accessible only
from the function or block in which it is declared. In programming languages with only two levels of visibility,
local variables are contrasted with global variables. On the other hand, many ALGOL-derived languages allow
any number of levels of nested functions with private variables, functions, constants and types hidden within
them.
In most languages, local variables are automatic variables stored on the call stack directly. This means that
when a recursive function calls itself, local variables in each instance of the function are given separate
memory address space. Hence variables of this scope can be declared, written to, and read, without any risk of
side-effects to processes outside of the block in which they are declared.
Definition of a local variable for a function
int i =0;
//Global variable
void f(void);
main() {
int i ;
// local variable for main
i =0;
printf("value of i in main %d\n",i);
f();
printf("value of i after call%d\n",i);
}
void f(void) {
Page 4
int i=0; //local variable for f

i = 50;
}
Programming languages that employ call by value semantics provide a called subroutine with its own local
copy of the arguments passed to it. In most languages, these local parameters are treated the same as other
local variables within the subroutine. In contrast, call by reference and call by name semantics allow the
parameters to act as aliases of the values passed as arguments, allowing the subroutine to modify variables
outside its own scope.
Variables of local scope are used to avoid issues with side-effects that can occur with global variables.
Global variable
In computer programming, a global variable is a variable that is accessible in every scope (unless shadowed).
Interaction mechanisms with global variables are called global environment (see also global state)
mechanisms. The global environment paradigm is contrasted with the local environment paradigm, where all
variables are local with no shared memory (and therefore all interactions can be reconducted to message
passing).
They are usually considered bad practice precisely because of their non-locality: a global variable can
potentially be modified from anywhere (unless they reside in protected memory or are otherwise rendered
read-only), and any part of the program may depend on it.[1] A global variable therefore has an unlimited
potential for creating mutual dependencies, and adding mutual dependencies increases complexity. See action
at a distance. However, in a few cases, global variables can be suitable for use. For example, they can be used
to avoid having to pass frequently-used variables continuously throughout several functions.
Global variables are used extensively to pass information between sections of code that do not share a
caller/callee relation like concurrent threads and signal handlers. Languages (including C) where each file
defines an implicit namespace eliminate most of the problems seen with languages with a global namespace
though some problems may persist without proper encapsulation. Without proper locking (such as with a
mutex), code using global variables will not be thread-safe except for read only values in protected memory.
C and C++
The C language does have a 'global keyword. However, variables declared outside a function implicitly have a
scope covering everything in the ".c file or compilation unit containing its declaration. In a small program
contained in a single file, such variables effectively have global scope. On the other hand, a variable that is
required to have global-scope in a multi-file project needs to import individually into each file using the extern
keyword. Such global access can be made implicit by placing the extern declaration in a shared header file,
since it is common practice for all .c files in a project to include at least one .h file: the standard header file
"errno.h" is an example, making the errno variable accessible to all modules in a project. Where this global
access mechanism is judged problematic, it can be disabled using the static keyword which restricts a variable
to file scope, and will cause attempts to import it with extern to raise a compilation error.
Page 5
An example of a "global" variable in C:

/* Note that this example is correct.
global does not qualify as a global variable as it is not "in scope everywhere".
*/
#include <stdio.h>
int global = 3; /* This is the external variable. */
static void ChangeGlobal(void)
{
global = 5; /* Reference to external variable in a function. */
}
int main(void)
{
printf("%d\n", global); /* Reference to external variable in another function. */
ChangeGlobal();
printf("%d\n", global);
return 0;
}
As the variable is an external one, there is no need to pass it as a parameter to use it in a function besides
main. It belongs to every function in the module.
The output will be:
3
5
Variable Scope
A variable does not exist until it is declared. When the script, form, or session, in which it is declared, goes
away, the variable leaves with it (unless the variable was defined with a Global or Addin scope). The duration
of a variable definition, and the extent to which it is accessible from other places, is called the variables scope.
The scope of a variable can be local, layout, session, or global.
Procedures in Visual Basic
A procedure is a block of Visual Basic statements enclosed by a declaration statement (Function, Sub,
Operator, Get, Set) and a matching End declaration. All executable statements in Visual Basic must be within
some procedure.
Calling a Procedure
You invoke a procedure from some other place in the code. This is known as a procedure call. When the
procedure is finished running, it returns control to the code that invoked it, which is known as the calling code.
Page 6
The calling code is a statement, or an expression within a statement, that specifies the procedure by name and
transfers control to it.
Returning from a Procedure
A procedure returns control to the calling code when it has finished running. To do this, it can use a Return
Statement (Visual Basic), the appropriate Exit Statement (Visual Basic) statement for the procedure, or the
procedure's End (Visual Basic) statement. Control then passes to the calling code following the point of the
procedure call.
With a Return statement, control returns immediately to the calling code. Statements following the
Return statement do not run. You can have more than one Return statement in the same procedure.
With an Exit Sub or Exit Function statement, control returns immediately to the calling code.
Statements following the Exit statement do not run. You can have more than one Exit statement in the
same procedure, and you can mix Return and Exit statements in the same procedure.
If a procedure has no Return or Exit statements, it concludes with an End Sub or End Function, End
Get, or End Set statement following the last statement of the procedure body. The End statement
returns control immediately to the calling code. You can have only one End statement in a procedure.
Parameters and Arguments

In most cases, a procedure needs to operate on different data each time you call it. You can pass this
information to the procedure as part of the procedure call. The procedure defines zero or more parameters,
each of which represents a value it expects you to pass to it. Corresponding to each parameter in the
procedure definition is an argument in the procedure call. An argument represents the value you pass to the
corresponding parameter in a given procedure call.
Types of Procedures
Visual Basic uses several types of procedures:
Sub Procedures perform actions but do not return a value to the calling code.
Event-handling procedures are Sub procedures that execute in response to an event raised by user
action or by an occurrence in a program.
Function Procedures return a value to the calling code. They can perform other actions before
returning.
Property Procedures return and assign values of properties on objects or modules.
Operator Procedures define the behavior of a standard operator when one or both of the operands is a
newly-defined class or structure.
Generic Procedures in Visual Basic define one or more type parameters in addition to their normal
parameters, so the calling code can pass specific data types each time it makes a call.
Procedures and Structured Code

Every line of executable code in your application must be inside some procedure, such as Main, calculate, or
Button1_Click. If you subdivide large procedures into smaller ones, your application is more readable.
Page 7
Procedures are useful for performing repeated or shared tasks, such as frequently used calculations, text and
control manipulation, and database operations. You can call a procedure from many different places in your
code, so you can use procedures as building blocks for your application.
Structuring your code with procedures gives you the following benefits:
Procedures allow you to break your programs into discrete logical units. You can debug separate units
more easily than you can debug an entire program without procedures.
After you develop procedures for use in one program, you can use them in other programs, often with
little or no modification. This helps you avoid code duplication.
Method
A way to identify a software function that performs an action or a service for a particular object. For
example, the Hide() method for form Form1 removes the form from the program display but doesn't
unload it from memory. It would be coded:
Form1.Hide
Event Procedure
A block of code that is called when an object is manipulated in a Visual Basic program. The
manipulation can be done by a user of the program through the GUI, by the program, or through some
other process such as the expiration of a time interval. For example, most Form object have a Click
event. The Click Event Procedure for the form Form1 would be identified by the name Form1_Click().
Use of Operators in High Level Programming Languages

To compute inputs from users and to generate results, we need to use various mathematical operators. In
Visual Basic, except for + and -, the symbols for the operators are different from normal mathematical
operators, as shown in Table below:
Arithmetic Operators
Operator
Mathematical function
Example
Exponential
2^4=16
Multiplication
4*3=12,
Division
12/4=3
Modulus(return the
Mod
remainder from an integer

division)
(5*6))2=60
15 Mod 4=3
255 mod
10=5
Page 8
Integer Division(discards
\
the decimal places)
+ or &
String concatenation
19\4=4
"Visual"&"Basic"="Visual
Basic"
Conditional Operators
To control the program flow, we can use various conditional operators. Basically, they resemble
mathematical operators. Conditional operators are very powerful tools, they let the program compare
data values and then decide what action to take, whether to execute a program or terminate the program
and more. These operators are shown below:
Table : Conditional Operators
Operator
Meaning
Equal to
>
More than
<
Less Than
>=
More than and equal
<=
Less than and equal
<>
Not Equal to
Logical Operators
In addition to conditional operators, there are a few logical operators which offer added power to the
programs. These are shown in Table below:
Operator
Meaning
And
Both sides must be true
or
One side or other must be true
Xor
One side or other must be true but not both
Not
Negates truth
Page 9
Programming Constructs
Structured programming is based around three basic constructs: Sequence, Selection and Iteration. The
Sequence construct is the simplest; whereby statements are executed in the order they're found in the code.
Both the Selection and Iteration constructs require a Logical Test. Logical tests can be performed on variables,
literal values, calculations, and results of functions The test will evaluate to either true or false.
Selection Constructs
The Selection constructs are used when the flow of execution may flow down two or more paths.
The if Statement
The if statement is used to control the flow of execution down one of two or more paths, depending on the
result of a logical test. Further conditions may be specified with else if, should previous conditions be false,
and else may be used should none of the above be true. There is no semicolon at the end of an if statement.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Simple if Statement</title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
</head>
<body>
<p>
<?php
$morning = date("I");
if ($morning == "1")
print "Good morning <br>";
else
print "Good afternoon <br>";
?>
</p>
</body>
</html>
If statements can be nested, and the combined with logical operators.
If more than one line should be executed should a condition be True, the lines should be enclosed within curly
braces.
if ($x == 10)
{
print "That's an excellent result <br>";
print "You should be extremely proud of yourself! <br>";
}
Note: A common mistake is to use the assignment operator instead of the equality operator when checking for
equivalence. The following statement will always evaluate to True as x is assigned the value 10 which is a nonzero number.
if ($x = 10)
Page 10
The switch Statement

When there are many conditions, the switch statement can be used if the values are discrete. The switch
statement is easier to read than multiple if statements when there are a large number of discrete values.
The switch statement can be used when multiple if statements become messy and difficult to read. Each case
statement is an entry point, and execution will continue from that point unless a break statement is found.
The break statement causes the program to continue from the end of the switch statement. Only discrete
values may be used for the cases. The default statement is used if none of the listed cases are True. There is
no semicolon at the end of the switch statement.
The following example prints the word for the numbers 1 to 10 passed from a form to the PHP script.
simpleForm.html
<html>
<head>
<title>Basic Form</title>
</head>
<body>
<h1>Number Converter</h1>
<form id="selection" name="selection" method="post" action="printNumber.php">
<p>
<input type="text" size="5" value="" name="numWord"><br>
<input type="submit" value="Display Word" name="convert">
</p>
</form>
</body>
</html>
The following is the PHP script that is called from, simpleForm.html.
printNumber.php
<html>
<head>
<title>Number to Word</title>
</head>
<body>
<p>
<?php
switch ($numWord)
{
case 1:
print "One <br>";
Page 11
break;
case 2:
print "Two <br>";
break;
case 3:
print "Three <br>";
break;
case 4:
print "Four <br>";
break;
case 5:
print "Five <br>";
break;
case 6:
print "Six <br>";
break;
case 7:
print "Seven <br>";
break;
case 8:
print "Eight <br>";
break;
case 9:
print "Nine <br>";
break;
case 10:
print "Ten <br>";
break;
default
print "Number not between 1 and 10 <br>";
}
?>
</p>
</body>
</html>
Iteration Constructs
The Iteration constructs are used when a block of code is required to be executed continually until a condition
is met.
Pre-Condition Loops
Pre-condition loops allow for a condition to be tested at the start of the loop. This type of loop is used when
you only want to execute the block of code should the condition be true. If there is more than one line to be
included in the iteration, it should be contained within curly braces.
A semicolon is not added to the end of the while statement. If one is added in error, then the block of code
will be executed exactly once. The following example uses a pre-condition loop to calculate the factorial of a
number (a number that is multiplied by every integer number below itself down to 1).
Page 12
simpleForm.html
< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
<html>
<head>
<title>Basic Form</title>
</head>
<body>
<h1>Factorials</h1>
<form id="selection" name="selection" method="post" action="printFactorial.php">
<p>
<input type="text" size="5" value="" name="num"><br>
<input type="submit" value="Display Factorial" name="convert">
</p>
</form>
</body>
</html>
The following is the PHP script that is called from, simpleForm.html.
printFactorial.php
<html>
<head>
<title>Factorial</title>
</head>
<body>
<p>
<?php
$factorial = 1;
// Use a pre-condition loop to calculate the factorial
while ($num > 1)
$factorial *= $num--;
print "Factorial: " . $factorial;
?>
</p>
</body>
</html>
Post-Condition Loops
Post-condition loops allow for a condition to be tested at the end of the loop. This type of loop is used when
you want to execute the block of code at least once. If there is more than one line to be included in the
iteration, it should be contained within curly braces. The following example increments the value of result at
least once, and continues incrementing result while it has a value less than 10.
Page 13

<html>
<head>
<title>Post Condition Loop</title>
</head>
<body>
<p>
<?php
$result = 1;
/*
Use a post-condition loop to increment the result and
continue incrementing the result while it has a
value less than 10
*/
do
{
$result++;
print $result . "<br>";
}
while ($result < 10);
?>
</p>
</body>
</html>
Sequence
Structured programming provides a number of constructs that are used to define the sequence in which the
program statements are to be executed.
Consecutive
Page 14
Statements within a structured program are normally executed in the same sequence as they are listed within
source code. If a code fragment consists of three statements following one another then statement one will
execute first, statement two second, and statement three last. To change from this straight consecutive
execution sequence requires the use of one of the other structured programming constructs which are
described below.
pseudo code
statement-1
statement-2
statement-3
example
input a
b=5+2*a
print b
Block
Statements may be blocked together. A block of statements may be substituted wherever a single statement
is allowed.
The symbol or keyword used to indicate the start and end of each block differs depending on the
programming language used.
pseudo code
{
statement-1
statement-2
statement-3
}
Subroutine
Page 15
A subroutine is a code segment that has been separated from the preceding and following code. A subroutine
usually consists of a series of statements that perform a particular task. The task performed is usually
identified by the name given to the subroutine.
Once a subroutine has been defined it can then be called from one or more places within the program. This
allows a program to perform the same task a number of times without having to repeat the same code. A
single call statement replaces (stands in for) all of the statements contained within the subroutine. Parameters
can be passed to a subroutine which will supply the data required to perform the task and perhaps to return
values for use by the subsequent processing.
A subroutine can either be compiled with (internal to) the calling program or separately (external).
pseudo code
call subroutine-1(var1, var2)
subroutine-1(var1, var2)
{
statement-1
statement-2
}
example
call output(a, b)
output(a, b)
{
print a
print b
}
Functions
A function is similar to a subroutine except that a function always returns a value to the calling program. A
function is usually called implicitly by embedding the function call into another statement in place of the
returned value rather than having a separate call statement.
A function works in the same way as a subroutine except in the way that it is called. A function can be
compiled internally or externally. Some programming languages also provide functions built into the language
Page 16
itself.
pseudo code
var2 = function-1(var1)
function-1(var1)
{
statement-1
statement-2
return var2
}
example
b = cube(a)
cube(a)
{
b=a*a*a
return b
}
Iteration in computing is the repetition of a process within a computer program. It can be used both as a
general term, synonymous with repetition, and to describe a specific form of repetition with a mutable state.
When used in the first sense, recursion is an example of iteration, but typically using a recursive notation,
which is typically not the case for iteration.
However, when used in the second (more restricted) sense, iteration describes the style of programming used
in imperative programming languages. This contrasts with recursion, which has a more declarative approach.
Here is an example of iteration relying on destructive assignment, in imperative pseudocode:
var i, a = 0
// initialize a before iteration
for i from 1 to 3 // loop three times
{
a=a+i
// increment a by the current value of i
}
print a
// the number 6 is printed
In this program fragment, the value of the variable i changes over time, taking the values 1, 2 and 3. This
changing valueor mutable stateis characteristic of iteration.
Page 17
Iteration can be approximated using recursive techniques in functional programming languages. The following
example is in Scheme. Note that the following is recursive (a special case of iteration) because the definition of
"how to iterate", the iter function, calls itself in order to solve the problem instance. Specifically it uses tail
recursion, which is properly supported in languages like Scheme so it does not use large amounts of stack
space.
;; sum : number -> number
;; to sum the first n natural numbers
(define (sum n)
(if (and (integer? n) (> n 0))
(let iter ([n n] [i 1])
(if (= n 1)
i
(iter (- n 1) (+ n i))))
((assertion-violation
'sum "invalid argument" n))))
An iterator is an object that wraps iteration.
Iteration is also performed using a worksheet, or by using solver or goal seek functions available in Excel.
Many implicit equations like the Colebrook equation can be solved in the convenience of a worksheet by
designing suitable calculation algorithms.
Page 18

Chapter 2
Develop a software component design specification
Decision tables
Decision tables are a precise yet compact way to model complicated logic.
Decision tables, like flowcharts and if-then-else and switch-case statements, associate conditions with actions
to perform, but in many cases do so in a more elegant way.
In the 1960s and 1970s a range of "decision table based" languages such as Filetab were popular for business
programming.
Structure
The four quadrants
Conditions Condition alternatives
Actions
Action entries
Each decision corresponds to a variable, relation or predicate whose possible values are listed among the
condition alternatives. Each action is a procedure or operation to perform, and the entries specify whether (or
in what order) the action is to be performed for the set of condition alternatives the entry corresponds to.
Many decision tables include in their condition alternatives the don't care symbol, a hyphen. Using don't cares
can simplify decision tables, especially when a given condition has little influence on the actions to be
performed. In some cases, entire conditions thought to be important initially are found to be irrelevant when
none of the conditions influence which actions are performed.
Aside from the basic four quadrant structure, decision tables vary widely in the way the condition alternatives
and action entries are represented. Some decision tables use simple true/false values to represent the
alternatives to a condition (akin to if-then-else), other tables may use numbered alternatives (akin to switchcase), and some tables even use fuzzy logic or probabilistic representations for condition alternatives. In a
similar way, action entries can simply represent whether an action is to be performed (check the actions to
perform), or in more advanced decision tables, the sequencing of actions to perform (number the actions to
perform).
Example
The limited-entry decision table is the simplest to describe. The condition alternatives are simple Boolean
values, and the action entries are check-marks, representing which of the actions in a given column are to be
performed.
Page 19
A technical support company writes a decision table to diagnose printer problems based upon symptoms
described to them over the phone from their clients.
The following is a balanced decision table.
Printer troubleshooter
Rules
Printer does not print
Conditions A red light is flashing
Printer is unrecognised
Y Y Y Y N N N N
Y Y N N Y Y N N
Y N Y N Y N Y N
Check the power cable

Check the printer-computer cable
Actions
X
X
Ensure printer software is installed X
Check/replace ink
Check for paper jam
X X
X
X X
X
Of course, this is just a simple example (and it does not necessarily correspond to the reality of printer
troubleshooting), but even so, it demonstrates how decision tables can scale to several conditions with many
possibilities.
Software engineering benefits
Decision tables, especially when coupled with the use of a domain-specific language, allow developers and
policy experts to work from the same information, the decision tables themselves.
Tools to render nested if statements from traditional programming languages into decision tables can also be
used as a debugging tool.
Decision tables have proven to be easier to understand and review than code, and have been used extensively
and successfully to produce specifications for complex systems.[7]
Program embedded decision tables
Decision tables can be, and often are, embedded within computer programs and used to 'drive' the logic of
the program. A simple example might be a lookup table containing a range of possible input values and a
function pointer to the section of code to process that input.
Page 20
Static decision table

Input Function Pointer
'1'
Function 1 (initialize)
'2'
Function 2 (process 2)
'9'
Function 9 (terminate)
Multiple conditions can be coded for in similar manner to encapsulate the entire program logic in the form of
an 'executable' decision table or control table.
Structure chart
Page 21
A process flow diagram describing the construction of a structure chart by a so called Subject Matter Experts
(SME).
This hierarchy chart represents data passing between two modules. When the module Pay_Bill is executed, the
pseudocode checks if the bill is already paid by searching for the payment receipt (execute Search_Receipt). If the
receipt is not found then it will execute the module Give_Money_To_Debt_Collector to finish the job.
A Structure Chart (SC) in software engineering and organizational theory, is a chart which shows the
breakdown of a system to its lowest manageable levels. They are used in structured programming to arrange
program modules into a tree. Each module is represented by a box, which contains the module's name. The
tree structure visualizes the relationships between modules.
structure chart is a top-down modular design tool, constructed of squares representing the different modules
in the system, and lines that connect them. The lines represent the connection and or ownership between
activities and subactivities as they are used in organization charts.[4]
In structured analysis structure charts, according to Wolber (2009), "are used to specify the high-level design,
or architecture, of a computer program. As a design tool, they aid the programmer in dividing and conquering
a large software problem, that is, recursively breaking a problem down into parts that are small enough to be
understood by a human brain. The process is called top-down design, or functional decomposition.
Programmers use a structure chart to build a program in a manner similar to how an architect uses a blueprint
to build a house. In the design stage, the chart is drawn and used as a way for the client and the various
software designers to communicate. During the actual building of the program (implementation), the chart is
continually referred to as the master-plan".
A structure chart depicts:
the size and complexity of the system, and

number of readily identifiable functions and modules within each function and
whether each identifiable function is a manageable entity or should be broken down into smaller
components.
Page 22
A structure chart is also used to diagram associated elements that comprise a run stream or thread. It is often
developed as a hierarchical diagram, but other representations are allowable. The representation must
describe the breakdown of the configuration system into subsystems and the lowest manageable level. An
accurate and complete structure chart is the key to the determination of the configuration items, and a visual
representation of the configuration system and the internal interfaces among its CIs. During the configuration
control process, the structure chart is used to identify CIs and their associated artifacts that a proposed
change may impact.[2]
A process flow diagram describing the construction of a structure chart by a so called Subject Matter Experts
(SME).
According to Wolber (2009), "a structure chart can be developed starting with the creating of a structure,
which places the root of an upside-down tree which forms the structure chart. The next step is to
conceptualize the main sub-tasks that must be performed by the program to solve the problem. Next, the
programmer focuses on each sub-task individually, and conceptualizes how each can be broken down into
Page 23
even smaller tasks. Eventually, the program is broken down to a point where the leaves of the tree represent
simple methods that can be coded with just a few program statements".
In practice, see figure, first it is checked if a Structure Chart has been developed already. If so an expert needs
to review it to ensure it represents the current structure and if not, updates the chart where needed.
Page 24

Chapter 3
Prepare for testing: Record & Analyse Test Results
Test Plan
A test plan is a document detailing a systematic approach to testing a system such as a machine or software.
The plan typically contains a detailed understanding of what the eventual workflow will be.
A test plan documents the strategy that will be used to verify and ensure that a product or system meets its
design specifications and other requirements. A test plan is usually prepared by or with significant input from
Test Engineers.
Depending on the product and the responsibility of the organization to which the test plan applies, a test plan
may include one or more of the following:
Design Verification or Compliance test - to be performed during the development or approval stages of
the product, typically on a small sample of units.
Manufacturing or Production test - to be performed during preparation or assembly of the product in
an ongoing manner for purposes of performance verification and quality control.
Acceptance or Commissioning test - to be performed at the time of delivery or installation of the
product.
Service and Repair test - to be performed as required over the service life of the product.
Regression test - to be performed on an existing operational product, to verify that existing
functionality didn't get broken when other aspects of the environment are changed (e.g., upgrading
the platform on which an existing application runs).
A complex system may have a high level test plan to address the overall requirements and supporting test
plans to address the design details of subsystems and components.
Test plan document formats can be as varied as the products and organizations to which they apply. There are
three major elements that should be described in the test plan: Test Coverage, Test Methods, and Test
Responsibilities. These are also used in a formal test strategy.
Test coverage in the test plan states what requirements will be verified during what stages of the product life.
Test Coverage is derived from design specifications and other requirements, such as safety standards or
regulatory codes, where each requirement or specification of the design ideally will have one or more
corresponding means of verification. Test coverage for different product life stages may overlap, but will not
necessarily be exactly the same for all stages. For example, some requirements may be verified during Design
Verification test, but not repeated during Acceptance test. Test coverage also feeds back into the design
process, since the product may have to be designed to allow test access (see Design For Test).
Test methods in the test plan state how test coverage will be implemented. Test methods may be determined
by standards, regulatory agencies, or contractual agreement, or may have to be created new. Test methods
also specify test equipment to be used in the performance of the tests and establish pass/fail criteria. Test
Page 25
methods used to verify hardware design requirements can range from very simple steps, such as visual
inspection, to elaborate test procedures that are documented separately.
Test responsibilities include what organizations will perform the test methods and at each stage of the
product life. This allows test organizations to plan, acquire or develop test equipment and other resources
necessary to implement the test methods for which they are responsible. Test responsibilities also includes,
what data will be collected, and how that data will be stored and reported (often referred to as
"deliverables"). One outcome of a successful test plan should be a record or report of the verification of all
design specifications and requirements as agreed upon by all parties.
IEEE 829 test plan structure
IEEE 829-2008, also known as the 829 Standard for Software Test Documentation, is an IEEE standard that
specifies the form of a set of documents for use in defined stages of software testing, each stage potentially
producing its own separate type of document.[1]
Test plan identifier

Introduction
Test items
Features to be tested
Features not to be tested
Approach
Item pass/fail criteria
Suspension criteria and resumption requirements
Test deliverables
Testing tasks
Environmental needs
Responsibilities
Staffing and training needs
Schedule
Risks and contingencies
Approvals
There are also other IEEE documents that suggest what should be contained in a test plan:
829-1983 IEEE Standard for Software Test Documentation (superseded by 829-1998

829-1998 IEEE Standard for Software Test Documentation (superseded by 829-2008)
1008-1987 IEEE Standard for Software Unit Testing
1012-2004 IEEE Standard for Software Verification & Validation Plans
1059-1993 IEEE Guide for Software Verification & Validation Plans (withdrawn)
IEEE 829-1998, also known as the 829 Standard for Software Test Documentation, is an IEEE standard that
specifies the form of a set of documents for use in eight defined stages of software testing, each stage
potentially producing its own separate type of document. The standard specifies the format of these
documents but does not stipulate whether they all must be produced, nor does it include any criteria
regarding adequate content for these documents. These are a matter of judgment outside the purview of the
standard. The documents are:
Page 26
Test Plan: a management planning document that shows:
How the testing will be done (including SUT (system under test) configurations).
Who will do it
What will be tested
How long it will take (although this may vary, depending upon resource availability).
What the test coverage will be, i.e. what quality level is required
Test Design Specification: detailing test conditions and the expected results as well as test pass
criteria.
Test Case Specification: specifying the test data for use in running the test conditions identified
in the Test Design Specification
Test Procedure Specification: detailing how to run each test, including any set-up preconditions
and the steps that need to be followed
Test Item Transmittal Report: reporting on when tested software components have progressed
from one stage of testing to the next
Test Log: recording which tests cases were run, who ran them, in what order, and whether each
test passed or failed
Test Incident Report: detailing, for any test that failed, the actual versus expected result, and
other information intended to throw light on why a test has failed. This document is
deliberately named as an incident report, and not a fault report. The reason is that a
discrepancy between expected and actual results can occur for a number of reasons other than
a fault in the system. These include the expected results being wrong, the test being run
wrongly, or inconsistency in the requirements meaning that more than one interpretation could
be made. The report consists of all details of the incident such as actual and expected results,
when it failed, and any supporting evidence that will help in its resolution. The report will also
include, if possible, an assessment of the impact of an incident upon testing.
Test Summary Report: A management report providing any important information uncovered
by the tests accomplished, and including assessments of the quality of the testing effort, the
quality of the software system under test, and statistics derived from Incident Reports. The
report also records what testing was done and how long it took, in order to improve any future
test planning. This final document is used to indicate whether the software system under test is
fit for purpose according to whether or not it has met acceptance criteria defined by project
stakeholders.
Types of Programming Errors
Runtime Errors
When a program is running, or executing, it is said to be in runtime. The term is mostly used by
software developers to specify when errors in a program occur. A "runtime error" is an error
that happens while the program is executing. For example, if a program told you that 2 + 2 was
5000, that would be a runtime error. A memory leak, where the program sucks up excessive
amounts of system memory is also a runtime error. The other major type of program error is a
compile-time error, where the application will not even compile into an executable program.
Examples of compile-time errors are syntax errors in the program code and file linking errors.
Page 27
Runtime is a good term to know, but you most likely won't hear it used very often unless you
like to hang out with computer nerds.
Syntax Errors
Error of language resulting from code that does not conform to the syntax of the programming
language; "syntax errors can be recognized at compilation time"; "a common syntax error is to
omit a parenthesis"
Logical Errors
In computer programming, a logic error (sometimes called a semantic error) is a bug in a

program that causes it to operate incorrectly, but not to terminate abnormally (or crash). A
logic error produces unintended or undesired output or other behavior, although it may not
immediately be recognized as such.
Logic errors occur in both compiled and interpreted languages. Unlike a program with a syntax
error, a program with a logic error is a valid program in the language, though it does not behave
as intended.
Testing Techniques
1. White Box Testing
White-box testing (also known as clear box testing, glass box testing, transparent box testing, and
structural testing) is a method of testing software that tests internal structures or workings of an
application, as opposed to its functionality (i.e. black-box testing). In white-box testing an internal
perspective of the system, as well as programming skills, are required and used to design test cases.
The tester chooses inputs to exercise paths through the code and determine the appropriate outputs.
This is analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT).
While white-box testing can be applied at the unit, integration and system levels of the software
testing process, it is usually done at the unit level. It can test paths within a unit, paths between units
during integration, and between subsystems during a system level test. Though this method of test
design can uncover many errors or problems, it might not detect unimplemented parts of the
specification or missing requirements.
White-box test design techniques include:
Control flow testing

Data flow testing
Branch testing
Path testing
Page 28
2. Black Box Testing

Black-box testing is a method of software testing that tests the functionality of an application as
opposed to its internal structures or workings. Specific knowledge of the application's
code/internal structure and programming knowledge in general is not required. Test cases are built
around specifications and requirements, i.e., what the application is supposed to do. It uses
external descriptions of the software, including specifications, requirements, and designs to derive
test cases. These tests can be functional or non-functional, though usually functional. The test
designer selects valid and invalid inputs and determines the correct output. There is no knowledge
of the test object's internal structure.
This method of test can be applied to all levels of software testing: unit, integration, functional,
system and acceptance. It typically comprises most if not all testing at higher levels, but can also
dominate unit testing as well.
Typical black-box test design techniques include:
Decision table testing

All-pairs testing
State transition tables
Equivalence partitioning
Boundary value analysis
Page 29

Chapter 4
Identify Health and Safety Requirements
Basic Safety Rules for Technology Labs
Basic safety rules are implemented in technology labs to prevent accidents and injuries to users. They also
help prevent abuse and damage to the equipment in the lab. Knowledge of these basic safety rules is
important before conducting any work in a technical lab.
Spills
Keep food and drinks away from electrical equipment and live outlets. This helps prevent accidental
electrocution and shortages in equipment due to spillage. In the event any food or drinks are spilled on to
equipment make sure all equipment is unplugged and in the off position before attempting to remove or clean
up the spill.
Organization
All electrical cords should be kept neat and organized, away from walkways and areas where they could
accidentally be tripped over or damaged. Keeping cords out of the way and safely contained helps make them
easy to access while preventing damage, falls and other possible injuries.
Overloads
Use heavy duty ground outlets for large amounts of equipment such as a bank of computers or a large
machine that requires an extraordinary amount of electricity. When using technical lab equipment with a
regular outlet, be mindful of the output limits of the outlet and use an electrical strip with a surge protector to
reduce the strain on the outlet.
Efficiency, safety and ergonomics should drive the design of any computer lab. Your setup must facilitate a
variety of instructional techniques and teaching scenarios. The instructor and assistants need to observe each
person's monitor and provide assistance without encountering obstacles. Users also need easy access to
shared resources, like printers, without disrupting the lab.
Measure the room to determine how many computers you can install. When you use tables, provide at least
three feet of space for the computer and the user. If you purchase self-contained workstations or carrels,
allow room for space between them.
Identify the location of the power outlets in the lab. This can affect the capacity of the lab and your design. For
safety, avoid running long extension cords across the floor in the workspace.
Page 30
Find out the total amperage of the room before you install equipment. Do not overload the electrical system
with more computers and accessories than it can handle safely. This could result in constant power problems
that cause data loss or even cause a fire.
Place the computer tables or workstation in an open square, "U" or semi-circle as close to walls as possible.
This design makes instruction, monitoring and assistance more efficient than computers in long rows.
Plug surge protectors into the wall outlets. Do not daisy chain surge protectors. Instead, move your computers
closer or use a heavy-duty extension cord to make it possible to place the surge protector near the computers
safely.
Leave space for shared resources, like printers, between every three or four computers. Users should not have
to cross the entire room and disturb others to retrieve documents.
Install the computers, peripherals and accessories. Position the equipment and furniture in the instructor's
work area so that the entire lab is visible. Check your setup for user comfort, ease of instruction and
monitoring.
Run electrical cords inside of the lab's work area under carpeting or heavy plastic runners. You can use duct
tape or cord channels if necessary. If you used extension cords from the wall to the rear of your workstations
or tables, they will not be in the path of normal travel, but taping them down increases lab safety.
Tips & Warnings
Consider designing your lab so that power hungry peripherals like laser printers do not share an
electrical outlet with a group of computers. Ergonomic workstations that have adjustable
keyboard trays help to accommodate users whose height and arm reach differ.
Be aware of the maximum load rating for uninterruptible power supplies and surge protectors
that you use. An overload could result in damage to your connected equipment.
Ergonomics the study of efficiency in working environment

Ergonomics is the study of designing equipment and devices that fit the human body, its movements, and its
cognitive abilities.
The International Ergonomics Association defines ergonomics as follows:[1]
Ergonomics (or human factors) is the scientific discipline concerned with the understanding of interactions
among humans and other elements of a system, and the profession that applies theory, principles, data and
methods to design in order to optimize human well-being and overall system performance.
Ergonomics is employed to fulfill the two goals of health and productivity. It is relevant in the design of such
things as safe furniture and easy-to-use interfaces to machines and equipment. Proper ergonomic design is
Page 31
necessary to prevent repetitive strain injuries, which can develop over time and can lead to long-term
disability.
Repetitive strain injury
Repetitive strain injury (RSI) (also known as repetitive stress injury, repetitive motion injuries, repetitive
motion disorder (RMD), cumulative trauma disorder (CT), occupational overuse syndrome, overuse
syndrome, regional musculoskeletal disorder) is an injury of the musculoskeletal and nervous systems that
may be caused by repetitive tasks, forceful exertions, vibrations, mechanical compression (pressing against
hard surfaces), or sustained or awkward positions. Different sections of this article present contrasting
perspectives regarding the causes of RSI.
Types of RSIs that affect computer users may include non-specific arm pain or work related upper limb
disorder (WRULD). Conditions such as RSI tend to be associated with both physical and psychosocial stressors.
Causes
RSI is believed by many to be caused due to lifestyle without ergonomic care ], E.g. While working in front of
computers, driving, traveling etc. Simple reasons like 'Using a blunt knife for everyday chopping of vegetables',
may cause RSI.
Other typical habits that some sources believe lead to RSI.
Reading or doing tasks for extended periods of time while looking down.
Page 32
Sleeping on an inadequate bed/mattress or sitting in a bad armchair and/or in an uncomfortable position.

Carrying heavy items.
Holding one's phone between neck and shoulder.
Watching TV in incorrect position e.g. Too much to the left/right.
Sleeping with head forward, while traveling.
Prolonged use of the hands, wrists, back, neck, etc.
sitting in the same position for a long period of time.
Illness
Symptoms
The following complaints are typical in patients who might receive a diagnosis of RSI
Short bursts of excruciating pain in the arm, back, shoulders, wrists, hands, or thumbs (typically diffuse
i.e. spread over many areas).
The pain is worse with activity.
Weakness, lack of endurance.
In contrast to carpal tunnel syndrome, the symptoms tend to be diffuse and non-anatomical, crossing the
distribution of nerves, tendons, etc. They tend not to be characteristic of any discrete pathological conditions.
Frequency
A 2008 study showed that 68% of UK workers suffered from some sort of RSI, with the most common problem
areas being the back, shoulders, wrists, and hands.
Physical examination and diagnostic testing
The physical examination discloses only tenderness and diminished performance on effort-based tests such as
grip and pinch strengthno other objective abnormalities are present. Diagnostic tests (radiological,
electrophysiological, etc.) are normal. In short, RSI is best understood as an apparently healthy arm that hurts.
Whether there is currently undetectable damage remains to be established.
Definition
The term "repetitive strain injury" is most commonly used to refer to patients in whom there is no discrete,
objective, pathophysiology that corresponds with the pain complaints. It may also be used as an umbrella
term incorporating other discrete diagnoses that have (intuitively but often without proof) been associated
with activity-related arm pain such as carpal tunnel syndrome, cubital tunnel syndrome, thoracic outlet
syndrome, DeQuervain's syndrome, stenosing tenosynovitis/trigger finger/thumb, intersection syndrome,
golfer's elbow (medial epicondylosis), tennis elbow (lateral epicondylosis), and focal dystonia.
Finally RSI is also used as an alternative or an umbrella term for other non-specific illnesses or general terms
defined in part by unverifiable pathology such as reflex sympathetic dystrophy syndrome (RSDS), Blackberry
thumb, disputed thoracic outlet syndrome, radial tunnel syndrome, "gamer's thumb" (a slight swelling of the
thumb caused by excessive use of a gamepad), "Rubik's wrist" or "cuber's thumb" (tendinitis, carpal tunnel
Page 33
syndrome, or other ailments associated with repetitive use of a Rubik's Cube for speed cubing), "stylus finger"
(swelling of the hand caused by repetitive use of mobile devices and mobile device testing.), "raver's wrist",
caused by repeated rotation of the hands for many hours (for example while holding glow sticks during a
rave).
Although tendinitis and tenosynovitis are discrete pathophysiological processes, one must be careful because
they are also terms that doctors often use to refer to non-specific or medically unexplained pain, which they
theorize may be caused by the aforementioned processes.
Doctors have also begun making a distinction between tendinitis and tendinosis in RSI injuries. There are
significant differences in treatment between the two, for instance in the use of anti-inflammatory medicines,
but they often present similar symptoms at first glance and so can easily be confused.
Treatment
On their own, most RSIs will resolve spontaneously provided the area is first given enough rest when the RSI
first begins. However, without such care, some RSIs have been known to persist for years, or have needed to
be cured with surgery.
The most often prescribed treatments for repetitive strain injuries are rest, exercise, braces and massage. A
variety of medical products also are available to augment these therapies. Since the computer workstation is
frequently blamed for RSIs, particularly of the hand and wrist, ergonomic adjustments of the workstation are
often recommended.
Ergonomics
Modifications of posture and arm use (ergonomics) are often recommended.
Page 34
Ergonomics: the science of designing the job, equipment, and workplace

Adaptive software
There are several kinds of software designed to help in repetitive strain injury. Among them, there are speech
recognition software, and break timers. Break timers software reminds the user to pause frequently and
perform exercises while working behind a computer. There is also automated mouse-clicking software that
has been developed, which can automate repetitive tasks in games and applications.
Adaptive hardware
Adaptive technology ranging from special keyboards, mouse replacements to pen tablet interfaces might help
improve comfort.
Mouse
Switching to a much more ergonomic mouse, such as a roller mouse, vertical mouse or joystick, or switching
from using a mouse to a stylus pen with graphic tablet may provide relief, but in chronic RSI they may result
only in moving the problem to another area. Using a graphic tablet for general pointing, clicking, and dragging
(i.e. not drawing) may take some time to get used to as well. Switching to a track pad or pointing stick, which
requires no gripping or tensing of the muscles in the arms may help as well. Inertial mice (which do not require
a surface to operate) might offer an alternative where the user's arm is in less stressful thumbs up position
rather than rotated to thumb inward when holding a normal mouse. Also, since they do not need a surface to
operate ("air mice" function by small, forceless, wrist rotations), the wrist and arm can be supported by the
desktop.
Keyboards and keyboard alternatives
Exotic keyboards by manufacturers such as Datahand, OrbiTouch, Maltron and Kinesis are available. Also one
can use digital pens to avoid the strain coming from typing itself. Other solutions move the mode of input
from one's hands entirely. These include the use of voice recognition software or pedals designed for
ergonomics and gaming to supplant normal keyboard input.
Tablet computers
Tablet computers such as the iPad are also valuable to RSI sufferers, since overall strain is much reduced by
the keyless nature of the device and the minimal finger movement involved, as well as the much greater
variety of body postures while using the device and the replacement of the mouse by a touch screen. ]
Although not a complete solution, it can be a good way to do day-to-day personal computing tasks.
Page 35
References
Rethinking Systems Analysis & Design by Gerald M. Weinberg, ISBN: 978-0-932633-08-8 , 1988 208
pages [ softcover]
Code Complete: A Practical Handbook for Software Construction, 2nd Edition by Steve McConnell,
2004
Patterns of Enterprise Application Architecture (The Addison-Wesley Signature Series) [Hardcover]
Refactoring: Improving the Design of Existing Code (Object Technology Series) [Hardcover]
Page 36

Chapter 1: Common Features of High Level Programming Languages 2

Uploaded by

Copyright:

Available Formats

Chapter 1: Common Features of High Level Programming Languages 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 1: Common Features of High Level Programming Languages 2

Uploaded by

Copyright:

Available Formats

TABLE OF CONTENTS

Chapter 1: Common Features of High Level Programming Languages

Chapter 2: Develop a software component design specification

Chapter 3: Prepare for Testing

Chapter 4: Identify Health and Safety Requirements

INTERNATIONAL TRAINING COLLEGE LINGUA

Create Designs for Software

0 through 255 (unsigned)

0 through 65535 (unsigned)

0:00:00 (midnight) on January 1, 0001 through 11:59:59

Any type can be stored in a variable of type Object

INTERNATIONAL TRAINING COLLEGE LINGUA

-128 through 127 (signed)

-32,768 through 32,767 (signed)

-3.4028235E+38 through -1.401298E-45 for negative values;

1.401298E-45 through 3.4028235E+38 for positive values

Composite Data Types

INTERNATIONAL TRAINING COLLEGE LINGUA

// local variable for main

int i=0; //local variable for f

An example of a "global" variable in C:

Parameters and Arguments

Procedures and Structured Code

Use of Operators in High Level Programming Languages

remainder from an integer

INTERNATIONAL TRAINING COLLEGE LINGUA

the decimal places)

More than and equal

Less than and equal

Both sides must be true

One side or other must be true

One side or other must be true but not both

INTERNATIONAL TRAINING COLLEGE LINGUA

The switch Statement

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"

INTERNATIONAL TRAINING COLLEGE LINGUA

INTERNATIONAL TRAINING COLLEGE LINGUA

INTERNATIONAL TRAINING COLLEGE LINGUA

INTERNATIONAL TRAINING COLLEGE LINGUA

Create Designs for Software

INTERNATIONAL TRAINING COLLEGE LINGUA

Check the power cable

Ensure printer software is installed X

INTERNATIONAL TRAINING COLLEGE LINGUA

Static decision table

INTERNATIONAL TRAINING COLLEGE LINGUA

the size and complexity of the system, and

INTERNATIONAL TRAINING COLLEGE LINGUA

INTERNATIONAL TRAINING COLLEGE LINGUA

Create Designs for Software

Test plan identifier

829-1983 IEEE Standard for Software Test Documentation (superseded by 829-1998

Test Plan: a management planning document that shows:

In computer programming, a logic error (sometimes called a semantic error) is a bug in a

Control flow testing

INTERNATIONAL TRAINING COLLEGE LINGUA

2. Black Box Testing

Decision table testing

INTERNATIONAL TRAINING COLLEGE LINGUA