Software Prototyping using Scripting Languages and Two language Approach

News

Books

Recommended Links

Tutorials

Programming Abilities

Etc

Scripting language are ideal for software prototyping. Included among these benefits is the ability to address rapidly changing software requirements. In addition, the efficiency gained from user-centered design, which consists of constant user feedback impacting the software design, has received significant attention recently [Landauer95]. Fast compile-debug-test cycles, and high programming flexibility make dynamically typed languages such as Perl, Python, PHP and Tcl ideal for the rapid creation of prototypes both on compoment and system levels

Ousterhout was the first to argue that a two language approach is both feasible and practical for software development [Ousterhout97] and created the scripting language (TCL) that has a transparent interface with C and can be extended using C modules. Python also provide consistent interface to C to allow developers to move performance critical methods and procedures into C without modification of the calling code.

Supporting prototyping requires a language which can support transformation of components previously written in cscritping langue into low level statically typed compiled language (C or C++) and vise versa. Currently, few scripting languages allow for this type of flexibility.

If developers choose to use a statically typed language (for example Java) they often encounter problems in the early prototyping and development phases.

They are inclined to define programming module interfaces prematurely which can cause delays for other developers when modules are redefined and require recompilation of part or all of the system.
They are forced to sped more time of development of a usable prototype due to long compile-test-debug cycles typical for static languages
Determining the cause of an error can be difficult due to the inability to directly query the running program for information other than through the use of a debugger.
Debugging incomplete programs is almost impossible since the compiler will not allow the program to run until all of the compile-time errors are corrected.

These limitations often make it difficult to use statically typed languages for rapid prototyping of all or part of an application.

On the other hand, if developers choose to use a single dynamically typed language they often encounter problems in the latter phases of development when performance, scalability, and maintainability become critical issues. They often encounter performance problems when writing computationally intensive code and tend to spend an unordinary amount of time optimizing code. They may also suffer scalability problems related to CPU and memory usage typical for scripting languages. The detection of all coding errors is delayed until the actual line of code containing the error is executed meaning that complex tests must be written in order to check the validity of code. Despite the benefits of a scripting languages, these limitations increase the cost of maintaining a large codebase.

Notes:

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
The site contain some broken links as it develops like a living tree... Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.

Google Search
Open directory	Research Index

News

Software Tech News 2-1 Importance of Software Prototyping

Modern software development demands the use of Rapid Application Prototyping. Professor Luqi at the Naval Postgraduate School coined the term "Computer Aided Prototyping" to describe this work. Her leadership showed its effectiveness in gaining understanding of the requirements, reducing the complexity of the problem and providing an early validation of the system design. For every dollar invested in prototyping, one can expect a $1.40 return within the life cycle of the system development.

Dr. Barry Boehm's experiments showed that prototyping reduces program size and programmer effort by 40%. It is the technology that is the foundation for his Spiral development method. Prototyping is being used successfully to gain an early understanding of system requirements, to simplify software designs, to evaluate user interfaces and to test complex algorithms. It is a best-in-class software approach.

Fully 30 to 40% of system requirements will change without prototyping. Rapid Application Prototyping provides a look at the dynamic states of the system before we build it, whereas most other software engineering focuses on the source code. The special problems of reliability, throughput and response time as well as system features are addressed in the best prototypes. A new field of study, Software Dynamics, will emerge once Rapid Application Prototyping is widely practiced. It will focus on quantitative analysis of how software performs under various loads and include a set of design constraints that will make it possible for us to build components that can be hooked together without exhaustive coverage testing.

Software is hard because it has a weak theoretical foundation. Most of the theory that does exist focuses on the static behavior of the software, analysis of the source listing. There is little theory on its dynamic behavior, how it performs under load. To avoid serious network problems software systems are over-engineered with plenty of bandwidth for two or three times the expected load. Without analysis of the dynamic behavior, application designers have no idea of the resources they will need once their software is operational. Software has the awful propensity to fail with no warning. Even after we find and fix a bug, how do we restore the software to a known state, one where we have tested its operation? For most systems, this is impossible except with lots of custom design that is itself error-prone. Software prototyping has proven its mettle in helping designers avoid these problems in their production systems.

Much has been written about the best way to develop software applications. But there is no "best way." Both prototyping and requirements are necessary. The tried and true process of synthesis and analysis is used to solve Software Engineering problems. Bottom-up is synthesis. Top-down is analysis. Bottom-up is prototyping. Top-down is developing requirements. Prototyping is the best way to encourage synthesis. Prototyping also eases communication with the customer and with the designer. Formal written requirements are needed to establish a clear definition of the job, to control changes and to communicate the system capabilities between the customer and the developer.

So where does this leave us?

Start with an English language written statement of a problem and broadly outline its solution. Now build a prototype for the elements where you need insight. Analyze the prototype using computer aided prototyping technology and synthesize a new solution either by refining the prototype or building a new one. Once you and the customer agree on the workings of the prototype, write requirements that include features, performance goals, product costs, product quality, development costs and schedule estimates.

What do I mean by prototype?

Prototyping is the use of approximately 30% of the ultimate staff to build one or two working versions of various aspects of a system. It is not production code but it may eventually become pre-production code or it may be completely discarded. In the prototyping effort, we are not concerned with the maintainability of the code nor are we concerned with formally documenting it. Code resulting from prototyping is often used to train the programmers. Only after we have written specifications resulting from the experience with the prototype should we start the formal development process. If we are fortunate enough that some of the code that was developed for the prototypes can be carried forward, that's great, if not, there is no loss.

A prototype produces "running" software and the production development produces "working" software.

Recent project experience has led to the widespread acceptance of the concept that early prototyping is fundamental to the success of operations supporting software products.
The reasons why prototyping is fundamental include:

The prototype provides a vehicle for systems engineers to better understand the environment and the requirements problem being addressed.

A prototype is a demonstration of what's actually feasible with existing technology, and where the technical weak spots still exist.

A prototype is an efficient mechanism for the transfer of design intent from system engineer to the developer.

A prototype lets the developer meet earlier schedules for the production version.

A prototype allows for early customer interaction.

A prototype demonstrates to the customers what is functionally feasible and stretches their imagination, leading to more creative inputs and a more forward-looking system.

The prototype provides an analysis test bed and a vehicle to validate and evolve system requirements.
About the Author

Mr. Bernstein is president of the Center of National Software Studies and is a recognized expert in Software Technology. He provides consulting through his firm Have Laptop - Will Travel and is the Executive Technologist with Network Programs, Inc. building software systems for managing telephone services.

Mr. Bernstein was an Executive Director of AT&T Bell Laboratories where he worked for 35 years.

lberstein@worldnet.att.net