A VISUAL PROGRAM DESIGN LANGUAGE

by QI-QUAN XU, B.E.

A THESIS

IN

COMPUTER SCIENCE

Submitted to the Graduate Faculty of Texas Tech University in Partial Fulfillment of the Requirements for the Degree of MASTER OF SCIENCE

Approved

August, 1998 n ^

ACKNOWLEDGEMENTS

This author wishes to thank the following individuals for their support. Dr.

Donald J. Bagert, Jr., advisor; Dr. Gopal Lakhani. the graduate committee member; Mr.

ChuangGuang He and Cai Gao, team members of STRIDES project.

I would like to dedicate this paper to my parents and my wife. God has truly blessed me with your love. TABLE OF CONTENTS

ACKNOWLEDGEMENTS i

LIST OF FIGURES iv

CHAPTER

I. INTRODUCTION 1

II. LITERATURE SURVEY 3

III.RESEARCH OBJECTIVES 5

3.1PDL/C++ 6

3.2 Visual PDL/C++ 6

3.3 Adding Functions to Visual PDL/C++ 7

3.4 Anticipated Benefits of This Research 7

IV. VISUAL PDL ENVIRONMENT 9

4.1 Overview of PDL 9

4.2 Languages Dependency of PDLs 10

4.3 Visual PDL 11

4.4 Visual PDL Environment 13

4.5 Major Functionality of Visual PDL/C++ 14

V. PDL/C++ 17

5.1 Why Propose a Formal PDL/C++ 17

5.2 Characteristics of PDL/C++ 17

5.3 Components of PDL/C-H- 18

n VI. VISUAL PDL/C-

6.1 Overview of Visual PDL/C++ 26

6.2 Visual PDL/C++ Programming 27

6.3 Code Generation and Syntactic Correction 33

VII. DEPENDENCY DIAGRAMS AND PSEUDOCODE-BASED TESTING 38

7.1 Dependency Diagrams 38

7.2 Pseudocode-Based Testing 43

VIII. VISUAL PDL/C++ VERSUS STRIDES 49

8.1 Introduction of STRIDE 49

8.2 Integrating Visual PDL/C++ With STRIDES 51

8.3 An Example 53

IX. CONCLUSIONS AND FUTURE RESEARCH 59

9.1 Conclusions 59

9.2 Future Research 60

REFERENCES 62

111 LIST OF FIGURES

4.1 Visual PDL Environment 13

6.1 Major Functionality of Visual PDL/C-H- 26

6.2 Class Declaration 27

6.3 Global Function Declaration 28

6.4 Class Method Definition 29

6.5 Comment a Method in a Class 30

6.6 Statement Editor Interface 31

6.7 Example of Visual Expression in Visual PDL/C^^ 34

6.8 Example of Visual Programming and Code Generation 35

6.9 Example of Local Variable Declaration Interface 36

6.10 Example of Visual PDL/C++ Programming 3 7

7.1 Example of Object Dependency Diagram 40

7.2 Example of Internal Dependency Diagram 42

7.3 Example of Control Construct and Level Diagram 46

7.4 Example of CCLD from Source Code 47

8.1 Relationship between CASHY and STRIDESVPT 50

8.2 Relationships between Parts in New STRIDES 52

8.3 Example Interface of CASHY CASE Tool 55

8.4 Example of Visual PDL/C++ Interface 56

8.5 Example of STRIDESVPT 58

IV CHAPTER I

INTRODUCTION

Improving software productivity and reliability has been the most imponant goal of software process improvement. To realize the goal of a mature software process, many methods and tools have been proposed and adopted.

Software design sits at the technical kernel of the software development life c\ cle.

"Beginning once software requirements have been analyzed and specified, software design is the first of three technical activities - design, code generation, and testing - that are required to build and verify the software" [14]. Software design is an iterative process through which requirements are translated into a "blueprint'" for constructing the software. Good design is critical to ensure software quality.

It has been docimiented that a significant number of errors are being introduced during the software design process. Medis reported that up to 60% of software errors could be traced back to design errors [10]. This fact has motivated widespread adoption of software design tools. More advanced and sufficient tools are needed for robust software systems design, because defecting and fixing errors as soon as possible is much easier and cheaper. Many design methods and tools are being applied throughout the industry. Each introduces unique heuristics and notation, as well as a somewhat parochial view of what characterizes lead to design quality [14].

Program Design Language (PDL) is one of the most frequently used techniques introduced to help designers to design robust systems. The use of PDL encourages more detailed specification of the design which can be easily understood and modified. PDL is "a pidgin language in that it uses the vocabulary of one language (i.e.. English) and the overall syntax of another (i.e., a programming language)"[3]. PDL is also called

Structured English or Pseudocode. Many PDLs have been introduced and practiced in the sofhvare engineering community, most of which are programming language dependent.

For example, PDL-Ada is popularly used by designers of software which is to be implemented in Ada.

Design tools such as PDL are used to improve software producti\'it\. while software testing is adopted to ensure the quality of application systems. Testing is a practical means of detecting program errors that can be highly effective if performed rigorously. Many software testing methods have been introduced, such as white-box testing, basis path testing, and control structure testing.

This research focuses on proposing a visual PDL environment called Visual

PDL/C-H-, which aids the designer to design a system. It also includes testing function which can be used to test the source code after the system is implemented or partial!} implemented.

A brief synopsis of the coming chapters is given below. Chapter II introduces some previous research related to visual programming and PDL tools. In Chapter III, the major objectives of this research are presented. Chapter FV gives an overview of program design languages, followed by discussion of language dependency of PDL. A Visual PDL environment and relationship between VPDL and OOD are also depicted. Chapter V proposed a PDL/C++. Chapter VI and VII mainly introduce fijnctionality of the proposed Visual PDL/C++. Integrating Visual PDL/C++ with STRIDES is discussed in

Chapter VIII, followed by conclusions and future research directions given in Chapter DC. CHAPTER II

LITERATURE SURVEY

Visual PDL is a new concept proposed by this research to improve software productivity and reliability. There are, however, many articles related to visual programming or PDL.

The term "visual programming" in the computer field is used in several different ways. In this research, visual programming refers to the use of visual expressions (such as graphics, drawings, or icons) in the process of programming to illustrate data, functions, classes, or the structure of a program. Several projects have been working on the basic theories of visual programming, such VLCC [7], Positional Grammars and DR Parsers

[6].

There are two types of visual programming: small-grain and large-grain. If almost every element of a specific language is visualized using visual expression, it is called

"small-grain" visual programming; otherwise it is called "large-grain." Some things, like mathematical formulas and numerical algorithms, are handled better wdth text. A typical

"small-grain" visual programming environment is introduced by Clinert [5]. An iconic

BNF (Backus-Naur Form) proposed by STRIDES project generalizes the "large-grain" expressions of traditional language. STRIDES {©and™ 1997 Texas Tech University) developed by the Department of Computer Science at Texas Tech University is an iconic environment for design and generating code in traditional programming languages, currently supporting C-H- [18]. The STRIDES project indicates that visual programming environment is usefiil to help users imderstand the structure of a program and reduce programming errors. This research is extension of the STRIDES group research project. which is a variation and extension of the previous research product BACCII++ {©and ^^^

1992 - 1995, Ben A. Calloni) [4].

Program Design Languages have been in extensive use since PDL was introduced in 1975 [3]. The examples of PDL are PDL/Ada, PDL-Caine, PDL-Arcturus, and

BYRON [11]. The work of Linger, Mills, and Witt provided a definitive treatment of

PDL [14]. Regarding PDL as an informal high level language, Zheng proposed an interactive software design tool called PDL/M2, which was used as an input to the system to express the general and detailed design [19]. PDL/M2 could also automatically translate PDL code (pseudocode) into Modula-2 programs. A PDL syntax-directed editor package was developed to help programmers write pseudocode [1]. Syntactical correctness is performed automatically. An interesting article written by Oman described an analysis tool that extracts complexity metrics from PDL [13]. The author had used the tool to measure consistency within and across modules and for assessing traceability between PDL and the corresponding source code. The control Structure Diagram (CSD) is a graphical notation intended to increase the comprehensibility of software written in block-structured languages such as Ada, Pascal, and Modula-2, or their associated PDLs

[8]. A software engineering tool which provides for the automatic generation of control structure diagram (CSD) from Ada 95 is also available [9]. CHAPTER III

RESEARCH OBJECTIVES

There is a widespread use of visual programming today. From these practices, one thing that has been learned is that "large-grain" solution for visualization is much better than a "small-grain" solution [18]. Visual programming is good at expressing high-level structure, omitting much of the implementation details, while PDL is usually used to outline a program design. The output of a PDL is called pseudocode. Therefore, appl\ ing visual programming technology to the field of PDL is almost seamless.

There are lots of design tools introduced to improve the software development process, but no single one suits all designers' needs. One solution may be that the designer uses different design tools in different situation. However, the difference between notations defined in different tool leads to problems of increased software defects, decreased imderstandability and increased levels of effort to develop software.

"Thus, the ideal situation would be the emergence of one superior design tool" [12].

Visual PDL/C-H- environment proposed by this research is a complex tool which has many fimctions besides the original one: Visual Programming. All functions in Visual

PDL/C-Hh are internally connected. It not only facilitates system design, but also reduces the cost of design tool and unprove efficiency of the tool.

The research objectives consist of three major sections:

1. Propose a ?DLIC++ which is designated as the basis of Visual PDL/C++.

2. Propose a Visual ?DLIC++ environment which is originally aimed at helping

the designer to perform visual PDL/C++ programming. 3. Add more functions, particularly Pseudocode-Based Testing to \'isual

PDL/C-t-+, making it a complex tool.

Because environments such as STRIDES have alread> demonstrated how \'isual

Programming Languages can be implemented [18], this research focuses on both

PDL/C++ and the components and ftmctionality of Visual PDL/C++ environment, and not focus on the implementation of the system.

3.1 PDL/C

There is no formal PDL/C++ currently existing. This research primarily concentrates on proposing a PDL/C-I-+ which is used as the basis of the Visual PDL/C— system. In other words. Visual PDL/C+-I- is a visualized PDL/C-I-+.

PDL/C+-I- consists of a set of reserved keywords, constructs and syntax rules. It provides a tool to help the designer to design a system which is going to be implemented in C-H-. Main elements in PDL/C-H- are explored and defined and the syntactic constraints are set up. Usually C++ is used as the implementation language in software systems which are designed using Object-Oriented Design technology; therefore,

PDL/C++ should have mechanisms to facilitate Object-Oriented PDL programming.

3.2 Visual PDL/C

This research proposes a Visual PDL/C+* environment based on PDL/C++. It is initially aimed at allowing the designer to outline software systems in a user-friendly visual environment. The class and function declaration and definition are performed in Visual PDL/C^^ flexibly and \ isually. Syntactic constrains are automatically enforced.

The system can internally generate pseudocode from \ isual expression.

3.3 Adding ftmctions to Visual PDL C—

This research adds more functions to Visual PDL/C++. Besides Visual

Programming, Syntactic Correcting and Pseudocode Generating. \'isual PDL/C— can produce Object Dependency Diagram and Internal Dependency Diagram, and perform

Pseudocode-Based Testing.

This research realizes that pseudocode not only is useful for helping programmers implement a system, but also can play an important role in software testing. This method is referred to as Pseudocode-based Testing, which is a new concept and ver\ complicated. This research proposes this idea and explores possible mechanisms to do pseudocode-Based testing. It is a good direction for fliture research.

3.4 Anticipated Benefits of This Research

Improving software productivity and reliability is always an important goal of researches in the field of software engineering. This research tries to make a contribution in this area.

VPDL will provide software designers with a useflil tool which can produce formal PDL pseudocode. It will also help designers easily grasp the whole structure of pseudocode. The visual programming interface hides much of the implementation details, while it reduces the possibility of syntax errors. Also VPDL provides a good opportimit> to evaluate Pseudocode-Based Testing. Pseudocode-Based Testing will not find all source code errors, but it could dramatically reduce the number of errors which are caused b\' inconsistencies between pseudocode and source code. Automatic testing will reduce the debugging time.

This research can also be used to measure consistency between PDL and source code in these projects which are targeted at automatically generating source code from

PDL. CHAPTER IV

VISUAL PDL ENVIRONMENT

4.1 Overview of PDL

Program Design Language (PDL) is "a pidgin language in that it uses the vocabulary of one language (i.e., English) and the overall syntax of another (i.e., a structured programming language)" [3]. It is a popularly adopted design tool to help designers outline software systems. PDL is also called Structured English. In some cases,

PDL is the abbreviation of Program Description Language [1], which has the same meaning as Program Design Language.

A basic PDL syntax should include data declaration, control constructs, subprogram call, and/or I/O constructs. These constructs and format may be '"borrowed" from a high level programming language such as Ada, Pascal, C or C++. The PDL mixes them with English narratives. The name of a particular PDL may be corresponding to the basis of it. For example, PDL-Ada means that it is a Program Design Language using

Ada as its basis.

The advantages of using PDL during the design process, as opposed to actual code, are really three-fold [12,14]:

1. PDL program is more easily understood by all involved parties.

2. Criticisms, suggestions, and modifications can be obtained early in the software life cycle.

3. Accurate software size and effort estimates based on a PDL description ma\ be obtainable earlier in the life cycle than is typically the case. As mentioned before, there are two different types of PDLs: formal and semi- formal [12]. For the designer of a software system, the semi-formal PDL is the best choice, because it is close to natural language and there are less syntactic and semantic constraints. On the other hand, programmers who are in charge of implementing the system design may like formal PDL much more than semi-formal one. The reason is that pseudocode produced by a formal PDL can be easily understood and followed. The tradeoff between these two types exists. For the purpose of automated documentation and visualization, the formal PDL is preferred in this research.

4.2 Languages Dependencv of PDLs

PDLs can be divided into two catalogs: language-dependent and language-

independent PDLs. The former means that the PDL directly uses low-level constructs

from a particular programming language, while the latter adopts generic constructs which

are not "borrowed" only from one particular language.

Most of PDLs in use today are programming language-dependent, such as PDL-

Ada. The advantage of language-dependent PDLs is that it is easy and efficient to implement system design in a high level language if the implementing language is the same as the basis of the PDL. Designing a language-independent PDL is quite difficult and expensive. The other advantage of programming language-dependent PDL is that it will be easy to achieve module verification and metric estimates [12].

On the other hand, disadvantages of language-dependent PDLs are also obvious.

If the implementation language is different from the PDL used during systems design stage, some language-specific constructs in the PDL may be difficult to implement. The

10 cost of changing systems design could be high if a programming language-dependent

PDL is involved.

Similar to the discussion of semi-formal and formal PDLs, the programmer might find that it is much easier to implement a system design according to the pseudocode produced by a particular language-dependent PDL. The tradeoff between these two types exists.

4.3 Visual PDL

Visual programming is a hot research topic recently. Properly designed visual

notations allow "people to complete tasks faster than purely textual notations," because

"people perform better with organized and explicit information" [17]. Visual programming is good at expressing high-level structure, omitting much of the

implementation details.

Environments, such as [4,5,15,18], have empirically demonstrated how Visual

Programming Languages can be implemented.

PDL is a design tool which is usually used to write pseudocode when a software

system is being designed. The ideal requirement for writing pseudocode is that low-level details are totally omitted, only the structure, high-level data declaration and control constructs are described using a PDL.

Because the characteristics of Visual Programming and PDL, combming \'isual programming technology with a program design language is suitable. Visual PDL is a visualized PDL which visualizes almost all constructs in a PDL. It allows system designers to write pseudocode in a visual environment.

11 Advantages of Visual PDL are summarized as follows:

1. Syntactic and semantic constraints can be automaticall> checked. Because

PDL can not be compiled, error checking is a time-consuming and difficult procedure. In

Visual PDL, on the other hand, a set of reserved keywords and syntactic rules are

embedded in the system. When the designer performs visual PDL programming, the visual environment will take care of checking syntax errors.

2. A Visual PDL program is represented in a visual flow diagram which expresses the high-level structure of the program. This characteristic exactly fits the basic requirement of system design, and aids the designer to concentrate on high-level design.

3. In large software projects, designers are often not the persons who are in charge of implementing systems. This requires that communication between programmers and system designers should be very efficient and accurate. Visual PDL provides a visual expression of system design. It helps programmers imderstand and grasp design ideas quickly and correctly.

4. Visual PDL can produce a formal PDL program which has reserved keywords and syntactic rules. All information related PDL program is stored in a database which is the core of Visual PDL system. Visual PDL can be used as basis of other fimctions such as Dependency Diagram Generation and Pseudocode-Based Testing.

5. Software metrics is a popular means of measuring software quality. Obtaining accurate estimates of software metric values during the design process could be of great economic and managerial benefit. Visual PDL promotes our ability to compute software metrics during the design process [2,12].

12 As explained in the following chapters, a visual PDL might provide other significant benefits. Some PDL tools, such as [1] and [19], have been proposed, but they are not visual environments because writing pseudocode is performed in textual editors.

4.4 Visual PDL Environment

Several visual PDLs may be contained by one super environment. This holder can also be referred as to Visual PDL Environment. The purpose of the containing environment is to overcome some shortcomings associated with single visual PDL.

A visual PDL environment is similar to the PDL environment which was first proposed by [12]. The major difference between them is that the visual PDL environment allows the designers write pseudocode using visual programming technology. The visual

PDL environment will support a number of implementation languages.

For purposes of illustration, suppose that a visual PDL environment supports

Pascal, C-H- and Ada as implementation languages [12]. The following figure describes the visual PDL environment in this case (Fig. 4.1):

Visual PDL Environment

Visual Visual Visual Visual PDL/Pascal PDL/C++ PDL/Ada PDL/Generic

Figure 4.1 Visual PDL Environment

13 Visual PDL/Pascal, Visual PDL/C++ and Visual PDL/Ada in the environment are programming language-dependent. Constructs available in each of these languages are supported by the visual PDL environment. If the implementation language used in one project is determined and supported in the environment, one particular instance will be invoked. For example, C++ is selected as the implementation language in a software system, the designers now can invoke Visual PDL/C++ in the environment and use constructs supported by the Visual PDL/C-H-.

Sometimes, however, the implementation language is unknown or unsupported in the Visual PDL environment. If this is the case, a generic Visual PDL instance is adopted.

Visual PDL/Generic will be programming language-independent. It "enables the

specification of modules, data, and control flow constructs in a language-independent, but

formal manner" [12].

As a studying case, this research focuses on proposing a Visual PDL/C-

4.5 Major Fimctionalitv of a Visual PDL/C++

As mentioned in Chapter 3, the Visual PDL/C++ proposed by this research is a

complex design tool. It is not only a visualized Program Design Language, but also a user-friendly environment consisting of many usefiil fimctions besides the basic one:

Visual PDL/C++ Programming. Major functionality of Visual PDL/C-H- is briefl\ depicted below.

1. Visual PDL/C + + Programming is the important basic flmction of Visual

PDL/C++, which allows the designer to write pseudocode in a visual environment. Visual

14 PDL/C++ has a set of icons which are used to visualize major elements of PDL/C—.

(PDL/C++ is introduced in Chapter V.) Also it has a powerful \ isual editor for \'isual

programming.

2. Visual PDL/C-H- performs Automatic Syntactic Correction when the designer

performs Visual PDL/C++ Programming in the visual editor.

3. A syntactically correct PDL/C++ program (pseudocode) is generated

automatically from the visual expression and shown in Pseudocode Viewer. The s\ stem

keeps consistency between pseudoecode in the code viewer and visual diagram in the

visual editor at any time.

4. Visual PDL/C-I-+ can produce design graphs of the software system indicating

Object Dependency or Internal Dependency. The Object Dependency Diagram provides

designers and programmers with the whole picture of the software system which is being

designed, while a internal relationship between a function and the fimctions it calls is

given by the Internal Dependency Diagram.

5. Visual PDL makes it possible to automatically generate documents in a timely manner. The design document produced by Visual PDL/C++ may include an Object

Dependency Diagram, an. Internal Dependency Diagram, a Visual PDL/C++ Diagram,

Pseudocode, and so on. Such a document can guide the implementation and serve as the basis for software document during the debugging and maintenance processes. {This function is not covered in detail in this paper.)

6. Visual PDL/C-I-+ provides a tool which facilitates metric value estimates. For example, it is easy to implement that the system tracks the number of total pseudocode

15 lines. A reasonable estimate for the uhimate size of the eventual system ma\ be possible.

{This function is not covered in detail in this paper.)

7. Visual PDL/C++ produces formal PDL/C++ program which has reser\'ed keywords and fixed syntactic constrains. After the system design is implemented, the

PDL/C++ program (pseudocode) can be exploited as the basis to test consistency between source code and pseudocode. This flmction is referred to as Pseudocode-Based

Testing.

Before describing above functions in details, a formal PDL/C++ which serves as the beisis of Visual PDL/C-H- is introduced in the next chapter.

16 CHAPTER V

PDL/C-

5.1 Whv Propose A Formal PDL/C-

Software systems designers in C++ programming community usually use informal PDL to design systems which are going to be implemented in C++ programming language. For the purpose of creating a visual PDL environment, a formal

PDL/C++ is proposed by this research. It is necessary that visual PDL uses a formal PDL instead of semi-formal one as the basis, because visual PDL environment provides a set of icons for visual programming and performs automatic syntactic correction. This requires that the PDL visualized by Visual PDL should have a set of reserved keywords and syntactic constrains.

Semi-formal PDL provides a more flexible expressions and terms which are usually determined by the designer. Since there are almost no reserve keywords which have fixed syntactic and semantic constraints, semi-formal PDLs are not suitable to be visualized.

5.2 Characteristics of PDL/C++

PDL/C++ is aimed at providing the user with a constant format of writing pseudocode. Before introducing the components of PDL/C++ proposed by this research, its characteristics are depicted below.

17 1. First of all, PDL/C++ is a formal program design language and it is language- dependent. Most constructs in PDL/C++ are "borrowed" from C++ and have the similar meanings as in C

2. PDL/C++ is not strict. The purpose of proposing a formal PDL/C++ is to provides a basis to a Visual PDL/C++ environment. If we do not have a formal

PDL/C-H-, icons and syntactic constrains carmot be determined in Visual PDL/C++. In other words, a formal PDL/C++ is necessary, but the components may be modified before the corresponding Visual PDL/C++ is implemented, or the visual environment provides a flexible way to allow the user to change the icon and syntax definition.

3. PDL/C++ supports data declaration, control constructs, and subprogram call.

4. Because more and more software projects are developed using Object-

Oriented Design technology, PDL/C-H- should support OOD and OOP. The mechanism of class declaration and definition are provided.

5.3 Components of PDL/C

The proposed PDL/C++ is a formal PDL which has a set of reserved keywords and corresponding syntactic constraints. As mentioned above, components of PDL/C can be changed depending on the user's preference. It is not necessary to set very strict constraints on a PDL, because PDLs are not high level programming languages which can be compiled and executed. The PDL/C++ proposed by this research will serve as the basis of a Visual PDL/C++ environment that will be described in details in Chapter VI and VII.

18 Major components of PDL/C-H- are divided into several categories such as Data

Declaration, Control Constructs, and Function Call, which are depicted below, respectively.

5.3.1 Data Declaration

In PDL/C++, like in C-H-, there are two types of data items, which are constant and variable. Constant data item is simple. The following example illustrates how to declare a constant:

MAXSIZE As "100".

It means that "MAXSIZE" is a constant data item which stands for "100". "As" is a reserved keyword. In PDL/C++, constant data item does not have a data type associated with it. All constant values are included in a pair of quote marks.

The syntax for declaring a constant data item is as follows:

Name of constant data item As " constant value " .

The data type of a variable may be one of the following choices: Boolean, Integer,

Real, Character, String and "Classes". The syntax for declaring a variable is as follows:

Variable name As data type .

For example:

arraySize As Integer

It means that "arraySize" is a variable whose data type is "Integer".

"Classes" here means user-defined data types, such as struct and class in C++.

"Classes" can be those which are declared and defined by the designer when he/she is designing a software system and writing a PDL/C-H- program. Also "Classes" can be

19 from the standard library in C-H-, such as "iostream" or "fstream" which are defined in

and . "Classes" data types are very important in PDL/C++, because they distinguish PDL/C++ with PDL/C and they provides the possibility for a

Visual PDL/C++ environment to automatically generate Object Dependency Diagram that will be depicted in Chapter VII.

"Classes" actually is a collection of user-defined data types. When a variable which is an object of a class or struct is declared, the name of defined data type should be used to indicate the data type of the variable instead of "class" or "classes.' For example, the user defines a new data type which is a class called "car". Like in C++, "myCar" will be an object of class "car" if the following statement is adopted:

my Car As car.

If a variable is an array, the keyword "Array" or "Array of Size" should follow the variable data type. For examples:

incomeArr As Integer < Array >

incomeArr As Integer < Array of Size 100 >

incomeArr As Integer < Array of Size 100, 100 > .

The first example illustrates how to declare an array without specifying the dimension and the size. The second shows that "incomeArr" is a one-dimensional array with size of 100 and the data type is integer, while the last example declares a two- dimensional array.

"< ... >" is necessary in the above statements. It indicates that the expression inside "< >" is additional description of the variable. If there is no this clause in the above examples, it means the data item is a single variable, which is the defauh.

20 For convenience, the notation for array declaration in C++ is acceptable in

PDL/C++, because it is much easier to use if the code segment needs to go through all elements in an array. For example.

IncomeArr[100][100] As hiteger is equivalent to

incomeArr As Integer < Array of Size 100, 100 > .

A variable can be declared as Global or Local. The default scope of a variable is

Local. The following examples illustrate how to declare Global variables in PDL/C using the reserved key word "Global":

arratSize As Integer < Global >

incomeArr As Integer < Array of Size 100, 100 >< Global > .

The table below (Table 5.1) summarizes the characteristics of data items in

PDL/C-H- discussed above:

Table 5.1 Characteristics of Data Items in PDL/C

Item Type: Constant Variable

Data Type: Boolean Integer Real Character String "Classes"

Complexity: Single Array

Scope: Global Local

21 5.3.2 Control Constructs

Statements and control constructs constitute the PDL program bod>. All control constructs available in PDL/C++ are "borrowed" from standard C-I-+ programming language. They are listed below:

1. if... (then ) ... endif

The format of this construct is as follows:

If (Then) Endif

2. if... (then)... else ... endif

The format of this construct is as follows:

If (then) Else (then) Endif

3. while — ( do ) — endwhile

The format of this construct is as follows:

While (do) Endwhile

4. do — while

The format of this construct is as follows:

22 Do.... While

5. switch — case — default — endswitch

The format of this construct is as follows:

Switch Case: Case:

Default: Endswitch

The various formats of control constructs are almost self-explanatory form a programming point of view. They are actually similar to those in C-I-+, but the difference is obvious. Control constructs in PDL/C++ are much more flexible and the syntax requirements are not very strict.

Design Narratives [12] are supported by PDL/C-H-. It is allowed that almost any valid language constructs are replaced by text enclosed in curly braces delimited by underscores (i.e., _{text}_). This is known as the Design Narrative. The following segment of a PDL/C++ program illustrates how the design narratives are used.

SPEEDLIMIT As "75MPH" Speed As Integer If (_{ Speed is greater than SPEEDLIMIT }_) Then _{ Output a warning message }_ Endif

23 If the value of "SPEEDLIMIT" is unknown when the designer writes the PDL program, the design narrative can also be used to describe this constant data item in the following way:

SPEEDLIMIT As " _{ Speed limit in a certain region }_ "

5.3.3 Function Call

The notation of flmction call is as follow:

Call namel. name2 ( ) .

"namel" can be Standard or Global. "name2" is the name of the called fimction which may or may not take some parameters.

If the called function is declared and defined in the C++ standard library excluding classes library such as , ''Standard" is used in the place of

'namel " in the notation. The following example illustrates this situation:

Call Standard.time( _{variable to store time}_).

This statement will call the fimction called "time" which is declared and defined in to get current system time, then store it to the parameter.

If the called function is declared and defined by the designer as a global flmction,

''Global" is adopted. For example, if "calculateTax" is global flmction defined by the user in the current system design, the following code segment will call this function and assign the returned result to a variable.

Result As integer

Result = Call Global.calculateTax

24 If the called fimction is a method in one class, the corresponding object name is used. The following code segment illustrates how it works:

studentList As LinkedList //LinkedList is a user-defined class

Call StudentList.insertStudent( _{student list node }_ )

If "namel" is omitted, it implies the called function or method is local.

The notation of fimction call is very important for Visual PDL/C-H-. It provides the possibility to automatically generate Internal Dependency Diagram which will be depicted in Chapter VII.

25 CHAPTER \'I

VISLALPDLC-

6.1 Overview of Visual PDL C—

Visual PDL/C— is a visualized PDL C— environment, which is. above all. aimed at minimizing the effort required to produce a syntactically correct PDL C— program. This is, however, not the exclusive reason that why proposing a \'isual

PDL/C— is attractive and useful. The following figure (Fig. 6.1 j shows the major functionality of Visual PDL/C^^. As what the figure illustrates, the Visual PDL C— provides not only visual PDL programming ability, but also many other interesting benefits which will make contribution to improve productivity and quality of software design.

Visual PDL/C— Functionality

Visual Pseudocode PDL/C— -Based Programming Testing

Syntactic Internal Correction Dependency Diagram Object Pseudocode Dependency Generation Diagram

Figure 6.1 Major Functionalit>' of Visual PDL C-

26 6.2 Visual PDL/C++ Programming

The concept of visual PDL programming is similar to iconic C++ programming in

STRIDES project [18]. Visual PDL programming refers to writing PDL program through a visual PDL environment.

Because PDL/C++ is an object-oriented program design language, the Visual

PDL/C++ system should have ability to declare classes and global functions. Figure 6.2 illustrates an interface for class declaration.

Class Declaration

Base Class ^^s Nan« JRegistrationLinkedList f one

Methods Data M^nbers deleteCourse '/i. FisrlNode As StudentNode deletesludenl( _{ Student name }_ ) Message As _{ String }_ Insert Data Member insertCourse NumOfNode As Integer inserts ludent( student As StudentNode ) Delete Data Mentier

Insert Methxl

Del^e Method

Descrifrtion 1 OK 1 \

C&r\ce\

Figure 6.2 Class Declaration

Using above interface (Fig. 6.2), the designer can easily declare a class in Visual

PDL/C-H-. The class name is held in the edit control. If the class is inherited from another

27 class, the base class is identified in the combo box. The combo box holds all classes declared and defined in the current application and those which are part of C^- standard library. By clicking on the set of command buttons available in the interface, the user can add/delete data members and add/delete methods to/from the class which is being declared. All data members and methods are visual in the two list boxes. Other information such as inheritance type and access type (public, private, or protected) is not necessary to be specified during design stage.

The parameters of a method may be omitted if this is suitable. The second method in the Method list box in Fig. 6.2 illustrates how to specify the parameter(s) in a method using design narrative, while the last method shows "real" parameter declaration.

Similarly, the design narrative can be used to describe the variable's data type instead of giving a specified one as shown in the second line in the Data Member list box (Fig. 6.2).

Figure 6.3 is an example for declaring a global funtion.

Global Function Declaration

OK Return Tjiipe I _{String}_ Caicd Name GetWarningMsg

Parametef(s) j _{Error type}_

WP DescripHon This global function will return an appropriate warning message according to different error 31 type. A

Figure 6.3 Global Fimction Declaration

To declare a global flmction, the user should specify the function name and return data type. If the function does not return any value, the return type is empty or set to

28 "Void*" similar to the key word "void" in C^-. All parameters are listed in the third edit box in Fig. 6-3. If no value is given in the box, it means that the function does not take any arguments.

The following interface (Fig.6.4) is for class method definition.

Class Method Definition

•>Setect a class name aid a method. I Class Name: R eaistrationLinkedLis "3 ->Cfck 't)e$cfption" to comment I MetkjdName; jinsertStudent A •> Click "St^KTients" to infriemerrf

-M^tedlnfo- rEcft-

Return Tjpe: JVokJ Descripdai Paiaffletef(s) |stud»ilAsStud»#Jode DescripticHT Statements Insert a stuctert naje ir^o the kked isL A

OK

d Caicel

Figure 6.4 Class Method Definition

To implement a method using PDL/C++, select a class from the "Class Name" combo box in the above mterface (Fig. 6.4). This box contains all classes declared in the current project through Class Declaration tool (Fig. 6.2). After a class name is chosen, all methods available in it are listed in the second combo box (Fig. 6.4). The user can pick from the "Method Name" box a method which is supposed to be implemented in

PDL/C-Hh. Information about the selected method such as Return Type, Parameter(sj, and Description are shown in the interface.

29 To comment the selected rr.ethod. click on the Comme>:t -^uuor. The Description edit box now is set to be editable. The user car. enter comments about the method. This command facilitates to document the program. The foUow'r.z exam.ple illustrates hov. to comment a method in a class (Tig. 6.5).

Class Method Definition

->S^ct a c a« nr^^ ^z^ "&x.z^ Qass/iams: •ec_.-a d ->ucr "Descripdor":-: cturmer^ •^^h^iNat^. '$«ir:S".i-e^" • [ •>wi:k ^'^tacerre'i:' to sTp-e~«'i

:t: Vc«i Desc.'ipc^ 1 ru^AcStudei^cKfe S-a-e-e-'s Decct^z^cor- Insert a z^^ztn ^zzt "z "e i.-.kec i-^' 1 :'cc-''5 s'jdent node a -ea:,. e^^ c: --

0-;

1 Csice'

Figure 6.5 Comment a Method in a Class

To implement the selected method in PDL C—. chck on Statements button. The follo\\ing interface is popped up (Fig. 6.6).

The physical window is divided into three main parts: Tool Bar, Statement Editor and Pseudocode \'iewer. The tool bar consists of a set of icons which are used to visualize major elements in PDL C— depicted below.

;o 4* Visual PDL/C++ - (Statement Editor] g|x E3 £dit lools Melp -|g(x|

Cia»|Lir^edLis* T] Method |dele(eStuaer.' T]

Paiamelef |_{ $tuden« name }_ ' 3]

•

•*;»-:«.-».•»..'-

•• Stands for variable declaration in a method or fimction.

"• Stands for assignment statement.

"• Stands for fimction/method call.

Figure 6.6 Statement Editor Interface

31 % '9 * m -• Stands for "while" loop. eg -• Stands for "Do ... while'" loop.

•• Stands for "Switch" statement.

"• Stands for "case' • "• Stands for "if" statement.

break > Stands for "break'

-• Stands for "return" statement.

MEMO

"• Stands for comment. .\ ri Figure 6.6. Continued

The second part in the interface is the Statement Editor which can perform visual programming and visual editing. The original visual structure in the editor window is

Begin - Stmt - End (Fig. 6.6). The designer mainly performs the PDL/C++ programming

32 in this editor. By clicking on the icons, the user can insert the selected icon into the original structure.

The third part is the Pseudocode Viewer, which displays the PDL/C++ code in this special window. There are two combo boxes and one edit box in the top of the viewer. The current method or function and the corresponding class are shown. If the fimction which is being edited is global, the Class combo box will inform the user by displaying GLOBAL in it. Parameter edit box shows argument(s) of the selected method or fimction.

This tool can be coimected to Class Method Definition (Fig. 6.4) or Function

Definition which is similar. Also it will work very well as an independent tool if the method is already declared. The designer can switch to other methods or fimctions by selecting a suitable class and method from the top of the viewer. If the selected method is already defined completely or partially, the corresponding visual diagram will be retrieved from the database and displayed in the editor, the viewer will show the existing pseudocode. Otherwise the original structure {Begin - Stmt - End) appears in the editor instead. The starting code segment originally displayed in the Pseudocode Viewer is illustrated in Figure 6.6. In the way described above, users can define all methods or fimctions in the same interface if they have been declared. They even do not need to go back to the definition interface.

6.3 Code Generation and Svntactic Correction

Visual PDL/C++ environment can automatically generate pseudocode from the visual expression and prevent most syntactic errors. The visual editor used here obeys the

33 syntax rules of PDL/C++. The manipulation facilities of a general-purpose editor are sophisticatedly combined together with the syntax or error-checking functions of a compiler. Any kind of PDL/C++ language structure errors are impossible, because all reserved keywords visualized using icons are syntax-directed. For example, when the user selects the Switch icon by clicking on it, then add it to the editor, the Visual

PDL/C++ system will automatically add Case, Default, Stmt, Break and EndSwitch as well (Fig. 6.7).

i^:

^^J

*fMfc )t

Figure 6.7 Example of Visual Expression in Visual PDL/C

The ability of outlining the structures of language control constructs as illustrated in Figure 6.7 ensures syntactical correctness and allows the user to concentrate on the true design of the software system instead of being preoccupied constantly with clerical details.

34 Pseudocode is automatically generated and displayed in the Pseudocode \'iewer when the designer performs visual programming in the Statement Editor. If the designer only specifies the structure of the method or fimction and does not enter any statements associating with keywords, the outline of the method/function's body is shown in the viewer, as illustrated in Figure 6.8.

4* Visual PDUC++ - (Statement Editor] glx ra= Edit IooJ«--.Hetos-- - ^ft^apfer^K ^Jfilic

Cla«s lUnkedLisl ^j Method |deleteStijdenl ^_

P««iBtef |_{ studert name )_ *

//Comment

Switch (_NS_) Case NS : l((_NS_) then NS Else then_NS Endif Case NS : Call NS Default: Endswitch

lUUlUUjlULlillllUH -UWU-li. I-JXJ)JJ-.I

* _NS_ stands for "Not Specified".

Figure 6.8 Example of Visual Programming and Code Generation

Double clicking on the icon in the visual editor, a small dialog box is popped up to take the user's input which is the statement associating with the selected icon. For

35 example, when the user double clicks on the Declare icon, the dialog box shown in

Figure 6.9 appears in the screen.

Local variable name, data type and default value are required to specify. When the user clicks on OA^ button, the system will check data values. If they are suitable, store them to database, and disappear the dialog box. Then the system updates all necessary information. Visual PDL/C++ ensures the consistency between Statement Editor and

Pseudocode Viewer by automatically updating pseudocode in the code viewer at any time.

Local Variable Declaration

J^iSimm ^g^nttmmti^ Vanabie Name jflag v^A DataT3^e | Integer 11-, Cancel Default Value 0

I- ''mivv- '"•• "• "• '"•""'• ^'^•'•'".'

^g/ttttmtimiitmmiiStmSmitiim

Figure 6.9 Example of Local Variable Declaration Interface

Figure 6.10 (next page) shows the visual programming interface after the user specifies most statements in the visual editor. As illustrated in Figure 6.10, once the designer inserts/deletes an icon or enters a statement, the code viewer is updated immediately. This mechanism facilitates system design by providing suitable information on time.

36 ?^> Visual PDL/C++ - [Statement Editor] HEl ^iffjxj

Ciass\.'j'.tc-'J T] Method I cee.eS-

Paamrtaf I • stuoert name ;

nag As Integer llag = 1 Switch (flag) Case 0. If (_{ global ctxntef s less :i^^r ' CC ;_ ) Then _{recaJcute,_ Else 'tnen { set the cxMTfe-to be

«C

^ '.«%

Figure 6.10 Example of Visual PDL/C++ Programming ''•J

37 CHAPTER VII

DEPENDENCY DIAGRAMS

AND PSEUDOCODE-BASED TESTING

The chapter describes the other functions Visual ?DLIC— environment has:

Dependency Diagrams and Pseudocode-Based Testing, respecti\ eh

7.1 Dependencv Diagrams

Dependency Diagrams are divided into two categories: Object Dependency

Diagram and Internal Dependency Diagram. The former refers to the graphic diagram indicating object dependence relationship in one software system design. Relationship between a function/method and functions/methods it calls is shown b\ Internal

Dependency Diagram. All information needed to draw Dependency Diagrams are automatically produced during system design and stored in a database.

7.1.1 Object Dependencv Diagram

As mentioned before, Object-Oriented Technology is popularly adopted in the field of software engineering. The fundamental construct in 00 is the object, which combines both data structure and behavior in a single entity. This is contrast to conventional programming in which data structure and behavior are only loosely connected. From the viewpoint of object-oriented approach, software is considered as a collection of discrete objects.

38 Relationship between objects plays a ver> important role in object-oriented design and programming. Object Dependency Diagram in Visual PDL C— is the direct result of object-oriented Visual PDL/C-t-+ programming. It captures the static structure of a system by showing the objects in the system and relationships beU\'een the objects. Object

Dependency Diagram provides an intuitive graphic representation of a s\'stem and is valuable for communicating with other parties and documenting the structure of a s> stem.

In Visual PDL/C++, the designer outlines the system b\ declaring and defining classes (objects). When the designer declares a class, relationship between this particular class and another class is created by selecting one class as the base class or declaring an object of one class as its data member. All these information is stored in the database.

When Visual PDL/C++ produces Object Dependency Diagrams, it retrieves information from the database, then draws the diagram in a visual editor window.

Figure 7.1 gives an example of Object Dependency Diagram. It shows objects in the system and relationship between them.'" •" indicates that the class in the beginning of the arrow is inherited from the class in the end of the arrow. " %' stands for "has - a" relationship. It means that the class in the begmning of this special arrow has an object of the class which is located in the end of the arrow.

When an object in the Object Dependency Diagram is selected, the corresponding information is shown in the right wmdow, including class name, methods, data members and description. If the user wants to see the pseudocode of a particular method in the class, double clicking on the method in the list box. This operation leads to the Statement

Editor. The pseudocode and corresponding visual diagram is displayed.

39 Object Dependency Diagram can be easily implemented in Visual PDL C—. but it really plays an important role during system design stage. It gives the whole picture of

4-Visual PDUC++ - [Statement Editor] H S Edit loojs fc^tp ^Jfijjcj -f 1 CSsssNane ,C'~.Die'-_r'er_f L Jlil Registration — Method DataMeinbs IrtsettStudent FfjtNode InsertDxise Nimomode Deletes tudent DeteteCoLite SeachStudent SearchDxfte Si GetAKjxf information

Complex Linked : m List - s

j- Detciiption

M ^ This da$s ts used marttan a corvfiex Inked LS: ro couse re^stiatior system.

® « e * •«» i- « * ' i> ^

Figure 7.1 Example of Object Dependency Diagram

the system structure, and facilitates designers to communicate with programmers and customers. This diagram can be part of the design document. Also it can be used to check consistency between the system analysis and design. For example, if the system is analyzed using Object Modeling Technique fOMTj, there is an Object Model produced during system analysis to describe the real-world object classes and their relationships to

40 each other. After the Object Dependency Diagram is available, the designer can validate the system design by comparing with Object Model.

7.1.2 Internal Dependencv Diagram

A class usually has a set of methods which are used to perform certain tasks.

When a method is defined, it may calls other method(s) declared in the same class, global fimction(s), and/or standard fimction defined in C++ libraries. The kind of relationships between methods or functions can be clearly illustrated by an Internal Dependency

Diagram.

Similar to Object Dependency Diagram, all information needed to draw Internal

Dependency Diagram for a method or function is available in the database after the method/function is defined in Visual PDL/C++.

The notation used in Internal Dependency Diagram is introduced below, respectively (next page).

Figure 7.2 (P43) shows an example of the Internal Dependency Diagram. The interface is mainly divided into two parts. Class information is displayed in the right side.

When the user selects one method in the first list box, the Internal Dependency Diagram is shown in the diagram viewer on the left if the selected method is already defined. The first block in the diagram viewer stands for the selected method. Others are methods or functions called by the method. The vertical line indicates the order of function calls. If the user double clicks on one block, the system will show the PDL/C++ program

(pseudocode) associated with selected method or function.

41 Method Name -> method declared in the same class

Method Name -> method declared in the base class

Function -> Standard function defined in C++ libraries Name

f > Object Method -> method declared in the "object" which is a data member Name Name of the class. If "object name" is "GLOBAL", it means that is a global function in the system.

-> function call

-> recursive call

Object Dependency Diagram describes the whole static structure of a software

system and relationships between objects, while Internal Dependency Diagram shows

internal relationships between methods and/or fimctions. It can be an auxiliary tool,

which aids the user to design a good system.

7.2 Pseudocode-Based Testing

The last fimction of Visual PDL/C++ covered by this paper is a new software testing method called as Pseudocode-Based Testing.

42 rV Visual PDL/C++ - [Statement Editor] glx P Edit lools Help -|g|x| 1 OasiName jlnloimationChecker :d Check i I Basedas* JNone

Methoi OataMembet InsertTieeNode mjiTtee As BinaryTree DeleteTteeNode counter As Integei HiBBl GetAJUnlotmation

InsertTreeNode

i

GetAUInformation i De$cr«>tk>n

This class is used to do information checkrg based on the coming information and the tiinary tree.

.-^ 1^ ~ ^"^

f v J 1 L±. K ^ ' I /„ 1 H^sLmmmdmAm

Figure 7.2 Example of Internal Dependency Diagram

7.2.1 Overview of Pseudocode-Based Testing

In large software projects, as mentioned before, programmers in charge of implementation usually are not the designers of the system. The design documents including pseudocode are extremely important for effective communication between designers and programmers. Visual PDL/C++ facilitates this activity by providing visual expression of system design and a set of tools which are partially aimed at helping the programmer to imderstand the design ideas quickly and correctly and improving maintenance processes. This research also realizes that PDL program not only is useful

43 for helping programmers implement a system, but also can play an important role in software testing.

When a programmer writes source code for functions or methods according to

PDL programs, errors caused by inconsistencies between pseudocode and source code cannot be avoided completely even the compiler can catch most of code errors.

Performing a testing on source code based on pseudocode to find inconsistencies is useful and suitable. This method is referred to as Pseudocode-Based Testing (PBT).

PBT is performed after the source code is successfully complied by the compiler of the implementation language. It is supposed to catch logic errors caused by inconsistencies between pseudocode and source code only.

In the beginning of this research, the difficulties of creating mechanisms and criteria for PBT are overlooked. The idea of PBT is interesting but hard to be completed in this research. The following section discusses two mechanisms to perform \

Pseudocode-Based Testing.

7.2.2 Testing Mechanisms:

Because the errors caught by PBT mainly are logic errors and caused by inconsistencies between pseudocode and source code, the best candidate which can be exploited as the basis of PBT is the structure of code. Control Construct and Level

Diagram (CCLD) introduced below is used in Visual PDL/C++ to show the structure of both pseudocode and source code.

CCLD is a simple graphic representation of control constructs and control flow at

PDL/C++ program. Figure 7.3 illustrates how a Control Construct and Level Diagram

44 corresponds to a PDL/C++ program. From the viewpoint of control structure, it is almost self-explanatory.

When the Visual PDL/C++ performs pseudocode-Based testing, it first retrie\ es a CCLD from PDL/C++ code. (This procedure is straight forward, because Visual

PDL/C++ already has the similar visual diagram.) Then Visual PDL/C^- retrieves a

CCLD from C++ source code according to syntactic rules of PDL/C++. This means that when the Visual PDL/C++ creates the CCLD from C+^ source code, it will do some translafions. For example, because there is no "for loop" defined in PDL/C^^. "for loop" in C++ source code will be translated to a corresponding "while loop". This kind of translations makes CCLDs from PDL/C++ code and C++ source code comparable.

After the Visual PDL/C++ system has CCLDs, they are compared each other level by level. If all control constructs in each level of pseudocode CCLD are foimd in the same level of source code CCLD, the pseudocode CCLD is called the container of source code CCLD. If CCLD of source code is not a container^ usually errors have been occurred. These two CCLDs are visually displayed in the interface. The user, therefore, can modify the source code if necessary.

Figure 7.4, as an example, gives the source code corresponding to the pseudocode shown in Figure 7.3 and its CCLD. It is easy to find that CCLD in Figure 7.4 is a container of CCLD in Figure 7.3 by comparing them each other level by level. All control constructs in CCLD of pseudocode can be found in CCLD of source code, on the other hand, some control constructs in the latter one do not exist in the former one.

45 Level I Level II

V \f If ( _{ first parameter is less than 0 }_ ) f —• IF Then _{ output a warning message } Else —• ELSE • Switch (_{ first parameter }_ ) • SWITCH

Case 0: InsertNewNode • CASE Case 1: DeleteFirstNode • CASE _{display a message }_ • DEFAULT Default: DeleteLastNode _{ display a message }_ • ENDSWITCH 1 ^ Endif —• ENDIF if ( _{second parameter is true }_) —• IF Then GetAllInform Else —• ELSE _{ return }_ Endif i— • ENDIF

Figure 7. 3 Example of Control Construct and Level Diagram

CCLD is simpler than visual flow diagram of pseudocode and suitable for testing, while the visual flow diagram is the best choice for visual programming and editing.

Another mechanism for Pseudocode-Based Testing is to exploit Internal

Dependency Diagram discussed in previous chapter. It is easy to create an Internal

Dependency Diagram for source code, because methods and/or functions are completely declared and defined in source code. Comparing IDD of PDL/C^- pseudocode and that of C++ source code will let the Visual PDL/C++ know if there is inconsistency existing.

46 Level I Le\ el II

T T

if ( operationFlag<0 ) cout«''No suitable operation is found" IF «endl; else ELSE { switch ( operationFlay) -• SWITCH { Case 0: -• CASE InsertNevvN'ode(); break; Case 1: -• CASE DeleteFirstNode( j: Cout«"The first node is deleted.•'«endl; break; Default: -• DEFAULT DeleteLastNode() Cout«"The last node is deleted."«endl; break: ENDSWITCH V,-- } ENDIF if (needAllInformationFlag = = true) IF { bool success = GetAlLInform( ); -• IF if(! success) _, ELSE cout«"No information is available."«endl; ENDIF 4 return; ELSE

ENDIF

Figure 7. 4 Example of CCLD from Source Code

Pseudocode-Based Testing is a tool to help the programmer keep consistent between pseudocode and source code. Because there is no exact and direct wa> to map a

47 W.-.'

PDL/C++ program to C++ source code, it is impossible that all inconsistency errors are found and fixed through Pseudocode-Based Testing procedure.

A^?^

48 CHAPTER Vni

VISUAL PDL/C~ VERSUS STRIDES

Visual PDL/C++ is proposed based on the practice of developing STRIDES system. This chapter discusses the relationship between them and how to integrate \'isual

PDL/C++ with STRIDES.

8.1 hitroduction of STRIDES

STRIDES is an iconic C++ programming environment[18]. It is a detailed design

tool which allows the user to perform visual programming in Iconic C+- {Iconic C-~ is

©and TM"^ 1997 Texas Tech University). Similar to BACCIF^T' M^' [4, 18], another

Windows-based iconic, syntax-directed programming environment, STRIDES allows

users to supply detailed design information for a program in an iconic environment. Both

of them will create parse tree intemally, and represent the flow of the program in

flowchart. STRIDES is implemented more specifically for object-oriented modeling, and

at current stage it is language specific for C++. STRIDES is commercial-oriented.

STRIDES can be divided into two main parts: CASHY CASE tool and STRIDES

Visual Programming tool (STRIDESVPT). CASHY is an object-oriented CASE tool for

STRIDES system to design high level structure of software. The tool supports the

notations and strategies of the Object-Modeling Technique (OMT) as presented by James

Rumbaugh and co-workers. The basic behaviors of the system includes three major

functions:

49 1. A Librarian which acts like an automated catalog to keep track of both pre­ defined and user-defined classes that are available for reuses. It is ver>' easy to access to this librarian;

2. A Class Browser which allows users to examine the details of the classes and

functions;

3. A Graphic Design Tool which allows the users to specify relationship among

various classes and objects to reflect the software design model. It has a graphic user

interface.

STRIDES Visual Programming tool (STRIDESVPT) is used to do the detailed

system design. The relationship between CASHY and STRIDESVPT is illustrated in the

following figure (Figure 8.1).

STRIDES

CASHY STRIDESVPT

-^.v.

Architectural Design Detailed Design

Figure 8.1 Relationship Between CASHY and STRIDESVPT

50 8.2 Integrating Visual PDL/C++ With STRIDES

STRIDESVPT is considered as a detailed design tool because in STRIDES Visual

Programming tool, the structure of a program is defined and represented in a visual flow diagram. On the other hand, when the users use STRIDES to design a software s\ stem. they usually supply all detailed information for that program. Then STRIDES automatically generates C++ source code according to what the user inputs when he she performs visual programmmg in STRIDESVPT. Based on the fact that the final output of

STRIDESVPT actually is real C++ code, STRIDESVPT also can be considered as an implementation tool which has a very useful, user-friendly visual interface.

Visual PDL/C++ is also a visual programming environment. The different between STRIDES and Visual PDL/C++ is that the latter is developed as a design tool. It helps designers to outlme a software system in design stage, and allows the user to perform visual PDL/C++ programming. The main output of a Visual PDL/C++ is

PDL/C++ program (pseudocode). From the viewpoint of project life cycle, STRIDES is used in implementation stage, while Visual PDL/C++ is adopted during software design.

Visual PDL/C++ can be easily and seamlessly integrated with STRIDES system.

The resulting system can be also called STRIDES. Now the new relationship between

CASHY, Visual PDL/C++ and STRIDESVPT is revised as illustrated in Figure 8.2. The

STRIDESVPT in this new relationship diagram is considered as an implementation tool.

This is suitable because the output of STRIDESVPT is C++ source code and can be directly compiled in a C++ compiler such as Visual C++ or Borland C++.

51 CASE tool in the new system should be modified modestly because now what the

CASE tool output is forwarded to Visual PDL/C++. CASE tool should support

PDL/C++. This is a very simple requirement, because CASE tool only performs high

level design such as class/method declaration and relationship between classes.

According to PDL/C++ proposed by this research, two fimctions which should be added

to CASHY CASE tool are supporting "String" data type and "design narratives".

^ Architectural CASHY Design

High Level Structure V Visual S ^ Detailed T PDL/C++ Design R I D Pseudo code E S \ /

Implementation STRID ESVPI

C++ Source V C++ Compiler

Figure 8.2 Relationships between Parts in New STRIDES

52 The information flow in Figure 8.2 is realized through a uniform database behind

STRIDES system. All information in one tool is transparent to any other tools, therefore reverse engineering is also possible. Because both Visual ?DLIC— and STRIDESVPT have their own tools to declare classes and functions, when the users design and implement a software program, they may select to skip one or two tools. For example, the users can use CASHY CASE tool to do high level design, after that, directly use

STRIDESVPT to implement the design if the system is small and simple. In some cases, the user may start off with using Visual PDL/C++, then implement the system through

STRIDESVPT.

The other reason why integrating Visual PDL/C++ with STRIDES system is seamless is that STRIDESVPT can directly adopt the visual flow diagram produced b\

Visual PDL/C++. This is because all icons and corresponding reserved keywords in

Visual PDL/C++ is a subset of that in STREIDESVPT.

The following example illustrates how CASHY CASE tool. Visual PDL/C++ and

STRIDESVPT work together.

8.3 An Example

Here is a very simple example. The purpose of this example is to illustrate how all parts in STRIDES system can work together. Suppose now every employee has to pay a special tax which is dependent on the employment type. There are only three employment types: "owner", "manager", and "common". The user wants to write a simple program to calculate the special tax using Object-Oriented Technology.

53 8.3.1 Architectural Design Stage

First of all, the user designs the interfaces of two classes "Person" and

"Employee" using CASHY CASE tool. "Employee" is inherited from "Person", therefore, the latter is the base class of the former. Figure 8.3 shows one interface of

CASE tool.

"Person" has three data members "FirstName", "LastName". and '"SSN" and two methods which are the constructor and destructor of the class. "Employee" has two data members "Income" and "EmploymentType" and three methods which are

"CalculateSpecialTax", constructor and destructor of the class. The access types of data members and methods are not specifles at this moment. The relationship between two

classes is "inheritance".

8.3.2 Detailed Design Stage

In the detailed design stage, all information produced during the high level design

stage is automatically forwarded to Visual PDL/C++ tool. Because the constructor and

destructor are used to initialize all data members and to do house-keeping work,

pseudocode usually are not necessary for both of them. In this example, suppose the user

writes pseudocode for "CalculateSpecialTax" using Visual PDL/C++. Figure 8.4 shows

the visual flow diagram and corresponding PDL/C++ program.

54 /•CASHY CASE Tool Eile Actions yiew Tools Help iH wws^^ TBIf^'aS?

person Employee ^erson rsiName • irstName Income .astName Jame EmploymentType

CalculateSpecialTax Eeisuii ( Person ( Employee () -Kersort C) -Person -Employee ()

"^•_^'£J-t^ Be«CliL ,^^3 ia^fefe^i"---^-

Figure 8.3 Example Interface of CASHY CASE Tool

8.3.3 Implementation Stage

During implementation stage, STRIDESVPT will work based on the pseudocode produced by Visual PDL/C++ tool. Because that all icons used in Visual PDL'C-^ is a

subset of that in STRIDESVPT and all information in Visual PDL/C++ is transparent to

STRIDESVPT, the STRIDESVPT can directly read PDL/C++ visual diagram from the

55 1^ Visual PDL/C++ - IStatement Editorl •mi IP £drt Tools htelp -|g|x| "3 i^as. \m jaBt»|Emplpyee ^Method |C^*Uate5pec»alT _^ J

I '^"^^f:^ j_{ NS L //Comrr.enr: 71

resJt As Real r* \ SkiAch (EmploymentType) Case _{Emptoyee is a owner)_ tesiil = Income " 5J: Case _{Employee is a manager}_ GO tesiJt = Income " V/, Default resdt = Income • 0.2Ji EndSwitch letumresuft p- J

': fi

'/> ^ // ¥ V •n:' A ^ X^ A^.ti^^ ' .<*(

Figure 8.4 Example of Visual PDL/C++ Interface

uniform database and display it in the STRIDESVPT visual editor. Therefore the whole structure of the program is already there. What the user needs to do is to add or modify some icons if necessary and supply more detailed information. The only icon in Visual

PDL/C++ is not recognized by STRIDESVPT currently is "Declare" shown below.

This problem is easily to solve. In this example, another "Assign" icon is used instead of "Declare".

56 Figure 8.5 (next page) illustrates how the user can perform visual programming in

STRIDESVPT based on PDL/C++ visual diagram.

The source code generated by STRIDESVPT in this example is shown below.

double Employee: :CalculateSpecialTax() { double result; switch (EmploymentType){ case 0: //the employee is an owner result = Income * 0.05; break; case 1: //the employee is a manager result = Income * 0.01; break; default: //the employee is not an owner or manager result = Income * 0.002; break;

} return result;

Just as Figure 8.4 and 8.5 illustrate, integrating Visual PDL/C++ with STRIDES system is almost seamless. They can be used in different software development stage. For a large and complex project, writing pseudocode during system design stage is usually required. The benefits of detailed design using tools such as PDL have been discussed in

Chapter I and II. Visual PDL/C++ combined with STRIDES will be a usefiil tool to improve the system development procedure.

57 <^-STRIDES - IStatement Editorl tg|X [3 6f:iions tlefp .|g|x

•3 StatsoientWofiuhap — ^ GO Voi^iie F.rcUDrcs ~i7<]«Dyee ^ I^P nt EmploymentType l^akxiateS pecxafT a)" o • Employee -StatemertPalatte — ^ p Emting Statement ^gjj reiuiM^corre " 0 C3 ; #

<«; te |[tf/'ya!BB br*«li •*• R V^ue He)e if Hen's ' IP ^^ J e Save J Cw^ j

f««M«*4««i^»-.^X».!'.

Figure 8.5 Example of STRIDESVPT

58 CHAPTER DC

CONCLUSIONS AND FUTURE RESEARCH

9.1 Conclusions

This research proposed a Visual PDL/C-^ environment based on the author's experience of developing STRIDES project. As a complex design tool. Visual PDL/C— is aimed at help the designer design robust software systems. Besides its basic function -

Visual PDL/C~ - Programming, it also provides many other useful tools such as

Syntactic Correction, Pseudocode Generation, Dependency Diagram Generating, and

Pseudocode-Based Testing

As the basis of Visual PDL/C++ envhonment, a formal PDL/C++ is proposed b\ this research. Formal PDL/C++ provides the design with a set of reserved keywords, constructs and syntactic rules of them. Using this constant format of writing pseudocode, the designer will outline a system design which is easy to be tmderstood and implemented. Vistial PDL/C++ envirormient is a visualized PDL/C+^.

Visual PDL/C++ enviroimient allows the designer writes pseudocode in a user- fiiendly visual enviroimient. Its basic fimction - Visual PDL/C++ Programming combined with Syntactic Correction and Pseudocode Generation make it possible producing syntactic-correct PDL/C++ program, which is a very important part of detailed design docimients for system implementation and maintenance. The visual representation of pseudocode helps the programmer and other parties understand and grasp the system design quickly and correctly.

59 The Visual PDL/C— environment can produce Object Dependency Diagram and

Internal Dependency Diagram, which shows the static structures and relationships between objects or functions.

Pseudocode-Based Testing exploits the fact that pseducode not on]>' is ver\' important for system implementation, but also can play a significant role in softv^are testing. Two mechanisms using Control Construct and Level Diagram and Internal

Dependency Diagram are discussed in this paper.

Above all. Visual PDL/C+^ provides software designers with a useful tool which can produce formal PDL pseudocode. It will also help designers and other parties easil} grasp the whole structure of system design. The visual programming interface hides much of the implementation details, while it reduces the possibilit\ of syntax errors. .A.lso

Visual PDL/C+^ provides a good opportunity to perform Pseudocode-Based Testing and other functions.

Integrating Visual PDL/C-r+ with STRIDES is a ver\- interesting topic. This research explored the possibility and benefits of integrating.

Improving software productivity and reliability is alwa\ s an important goal of researches in the field of software engineering. This research tried to make a contribution in this area.

9.2 Further Research

Because Visual PDL/C++ is a new concept and this research focused on proposing its components and functions, lots of research works need to be bone.

60 The author will publish this paper on the Internet. After the proposal of \'isual

PDL/C++ is refined, complete implementation will be done.

More functions can be added to Visual PDL/C++ environment. As a complex design tool. Visual PDL/C++ promotes our ability to compute software metrics during the design process. Because all information about psedocode is kept intemalh in the

Visual PDL/C++ environment, adding a metric estimate ftmction is suitable.

Automatic Document Generation might be another candidate added to Visual

PDL/C++. Visualized PDL environment gives rise to an excellent design document to guide the implementation and maintenance.

In the beginning of this research, the difficulties of Pseudocode-Based Testing are overlooked. Many interesting research works can be done in this topic. More mechanisms will be necessary for good testing results, and criteria of testing need to be created.

61 REFERENCES

[I] Bassanino, A. P., & Walker. A. J., A syntax-directed PDL generator for soft\vare systems design; Transaction of the South African Institue of Electrical Engineers. Vol.77, No.2, 1986, PP.133-143.

[2] Boehm, B., Software Engineering Economics: Prentice Hall, Englewood Cliffs, XJ 1981.

[3] Caine, S., and Gordon, K., PDL-A Tool for Software Design; Proc. Natl. Computer Conference, AFIPS Press, 1975, pp. 271-276.

[4] Calloni, B. A., BACCII: An Iconic, Syntax-directed Windows System for Teaching Procedural Programming; M. S. Thesis, Dept. of Computer Science, Texas Tech University, 1992.

[5] Clinert, E. P., & Tanimoto, S. L., Pict: An interactive graphical programming environment; IEEE Computer, Nov. 1984, PP. 7-24.

[6] Costagliola, G., & Chang, S. K.. DR PARSERS: A generalization ofLR parsers; Proc. of IEEE Workshop on Visual Languages, Oct. 1990, PP.174-180.

[7] Costagliola, G., VLCC: An visual languages' compiler's compiler. IEEE Computer, March, 1995, PP. 56-66.

[8] Cross, J. H.. II, Sheppard, S. V., Carlisle, W. H., Control structure diagrams for Ada; Journal of Pascal, Ada & Modula-2, Vol.9. No.5. 1990, PP.26-29. 32. 33.

[9] Cross, J. H., II, Barowski, L. A., Hendrix, T. D.. Teate, J. C, Control structure diagrams for Ada 95; Proceedings TRI-Ada '96, PP.143-149.

[10] Medis, K. S., Quantifying Software Quality; Quality Progress, May 1982. ppl8-22.

[II] Nejmen, B., Dunsmore, H., A survey of Program Design Languages (PDLs): Proceedings of IEEE COMPSAC86, 1986.

[12] Nejmen, B., The design of a PDL software; Proceedmgs Focus on Software, 1988, pp287-298.

[13] Oman, P. W., & Cook, C. R, Design and code traceability using a PDL metrics tool; Journal of Systems and Software, Vol.12, No.3, 1990, PP.189-198.

[14] Pressman. R.: Software Enginnering; the Mcgraw-Hill Companies. Inc. New York, 1997.

62 [15] Rasure, J.R., & Williams, C. S., An Integrated Data Flow Visual Language and Software Development Environment; Journal of Visual Languages and Computing. February 1991.

[16] Stocks, P., & Carrington, D., A framework for specification-based testing; IEEE Transaction on Software Engineering, Vol.22. No.l 1. 1996, PP. 775-785.

[17] Whitley, L. N., Visual Programming Languages and the Empirical Evidence For and Against; Journal of Visual Languages and Computing, Aug. 1997, PP. 109-142.

[18] Zhang, F., Compiler Issues Related to Iconic Visual Language: M. S. Thesis. Dept. of Computer Science, Texas Tech University. 1997.

[19] Zheng, G., The design and implementation of the program design language PDL/M2; Chinese Journal of Computers, Vol.10, No.l2. 1987. PP.712-719.

63 PERMISSION TO COPY

In presenting this thesis in partial fulfillment of the requirements for a master's degree at Texas Tech University or Texas Tech University Health Sciences

Center, I agree that the Library and my major department shall make it freely available for research purposes. Permission to copy this thesis for scholarly purposes may be granted by the Director of the Library or my major professor.

It is understood that any copying or publication of this thesis for financial gain shall not be allowed without my further written permission and that any user may be liable for copyright infringement.

Agree (Permission is granted.)

Student's Signature Date

Disagree (Permission is not granted.)

Student's Signature Date