Extreme programming and language prototyping

¶ … Programming & Language Prototyping

Extreme Programming

The field of software development on the basis of the values of plainness, communique, feedback and audacity is known as Extreme Programming or XP. (What is Extreme Programming?) Kent Beck introduced the methodology of Extreme Programming on the basis of his prolonged experience of being an object oriented software developer and specifically, in collaboration with Ward Cunningham using the Smalltalk programming language. Since the Smalltalk was considered to be the first widely accepted object oriented language, Ward and Kent where working with it considerably longer than just about anyone else. (Extreme Programming FAQ)

Extreme Programming is a frivolous software process that is aimed at small-sized teams in operation at an environment of little understanding and/or swiftly varying environment. It has two fundamental promises. Firstly, the Extreme Programming guarantees to concentrate every day on the things are most significant and those contributes towards the successful software development. Secondly, it assured the users and managers the accrual of the largest value from their investment on software generation and assured to expect tangible results that entail the objectives every few weeks and will be able to change the direction of a project as needed without unwarranted penalty. (Adopting Extreme Programming: Successful integration of XP into your organization requires the support and buy-in of senior management - Technology Information)

The Extreme Programming is in operational with uniting the whole team amidst prevalence of simple practices with sufficient feedback to become capable to visualize where they are and to adjust the practices to their specific situation. In case of Extreme Programming, each and every member constitutes an inseparable component of the 'Whole Team'. The team constitutes centering the business representative known as 'the Customer', who is also working with the team daily. The group associated with and practicing Extreme Programming utilizes a simple form of designing and monitoring to assess as to what should be done at the post development period and to forecast when the project will be completed. (What is Extreme Programming?)

Being concentrated on the business value, the team develops the software in phase manner each consisting of small fully integrated releases that pass through all the tests the Customer has defined. The Extreme Programming team ensures the team to be integrated and operating consistently. The programmers generate the production code in modules and all work together all the time. They encode the programs in a reliable style so that everyone can be aware of it and will be able to develop all the code as necessitated. The team engaged in developing Extreme Programming follows a general and simple design of the system that it appears to be. Each of the programmers continues to be at a speed that can be sustained indefinitely. (What is Extreme Programming?)

There are twelve primary features that are experienced through the Extreme Programming technique. They are the Planning Game: It is designed to integrate the business and formulation process so as to result in the maximum business value as quickly as possible. The planning game is attained at various ranges of development, however, the fundamental principle that the business emerges with a list of warranted features for the system. Each characteristic is written out as a User Story that fetches the characteristics a name and narrates the broad framework of the requirement. The user stories are coded peculiarly on 4 x 6 cards. The process of software development involves an estimate of the requirement of the efforts by each story and the estimate of the efforts that the team can exert within a time interval. (Extreme Programming FAQ)

The business then signifies as to which stories that is to be implemented and is which priority along with the time and frequency to produce a production release of the system. Small Releases: The program initially is introduced with the smallest possible features set. The frequency of subsequent releases is more with additional features at each time. System Metaphor: every project has a unique structural symbol associated with the principle of easy to remember naming tradition. Simple Design: The Extreme Programming always involves the simplest possible structure that reveals the job done. The requirements will differ tomorrow, so what is essential is to meet the present requirements. Continuous Testing: Prior to supplementing a feature, the programmers are involved in writing a test run for the same. With the successful running of the module the development process is completed.

The Extreme Programming Tests entail two basic ideas. They are referred to as Unit Tests and Acceptance Test. The Unit Tests indicate to the tests of effective functioning of the program generated automatically by the developers at the time of development. Each of the Unit test are peculiarly involved in assessing the functioning of an individual class or a small cluster of classes. The unit tests are peculiarly written using a unit testing structure like JUnit. The Acceptance Tests are also referred to as Functional Tests and are particularly tailored by the customer to assess that the program as a whole is performing in the desired direction. The acceptance tests peculiarly assess the entire structure or some large portion of the program. The program getting through all the acceptance tests for a particular user story is considered to complete the process of development. (Extreme Programming FAQ)

The acceptance tests at the minimum involves a script a user interface actions and the anticipated results that an operator can run. The norm is to automate the acceptance tests either with the use of the unit testing structure or a separate acceptance testing structure. Refactoring: the stage of refactoring involves screening out of the duplicity in code generation in a coding session. This is done with necessary assurance that you did not break anything since you have the tests. Pair Programming: The code generation process in the Extreme Programming technique involves writing by two programmers. Particularly, all code is reviewed as it is written. Collective Code Ownership: This ownership of the module rests collectively on the group. Any single programmer cannot claim ownership of the module. Any developer is assumes to be capable of working on any part of the code base at any time. Continuous Integration: all the variations are integrated into the code base with updating at least on daily basis.

The test run is required to be completely successful both prior to and after the integration. 40-Hour Work Week: The programmers have a definite schedule of their work. At emergencies only a week of overtime is permitted. However, frequency of the weeks of overtime is regarded as a symbol of the something at faulty. on-site Customer: The group developing the program is ensured to have a continuous interaction with the live customer at the development site, who is involved in running and using the system. With regard to the commercial software having a number of customers, the team uses a model of the customer known as the product manager. Coding Standards: there is a prescribed standard of coding stipulated to be followed by every body. Normally it is not possible to say at the very outset that a particular programmer has involved in developing a set of code. (Extreme Programming FAQ)

In order to implement the Extreme Programming effectively, it is essential to acknowledge as an all or nothing software process. If everything except the pair programming is resorted to the Extreme Programming is not considered to be formulated. Similarly, the Extreme Programming is not considered to have developed if a requirement document and program design model is not delineated much before initiation of the programming. Similarly, the Extreme Programming also is associated with the continuous assessment and integration of the code. If access to the knowledgeable users, having requirements and scoping decisions about the system, has not been ensured then the Extreme Programming is not being resorted to. Moreover, the support and subscribing to the ideas by the senior managers, users and the project team members are considered essential for effective integration of the Extreme Programming techniques into the organization. (Adopting Extreme Programming: Successful integration of XP into your organization requires the support and buy-in of senior management - Technology Information)

The implementation of principles of Extreme Programming like pair programming and writing the testing code first is required to have enough confidence by the developers, however, once the experience of these techniques are adopted it is likely that they never deserve to return to working in any other way. The team is also essential to necessitate fast compiling circumstances to cater to the persistent assessment of the techniques and integration of efforts. At last the team is required to be physically present in groups and also have the liberty to set up their working environment to support pair programming and effective team work. Irrespective of its several advantages the Extreme Programming suffers from some potential problems. First of all, even though it is concentrated on programming-related issues which is regarded as one of the greatest merit of the Extreme Programming Technique, consequentially it polish over many political and management issues that many projects must overcome to be successful.

The Extreme Programming is also tailored towards a single project to be developed and maintained by a single team, however, in real life many organizations prefer to keep the crucial aspects of software development like data management and release management concerns outside the purview of regulations of a single project manager. The Extreme Programming technique is quite susceptible to adversely affect the 'bad apple' developers that do not have necessary inclination to work well with others and knowing it all, and/or are not inclined to share their 'superior' code with others. Even though these developers are an obstacle to any project and sometime prove detrimental to the organization in the long run, the dependence of Extreme Programming on communication and teamwork simply bars them from the group activity. (Adopting Extreme Programming: Successful integration of XP into your organization requires the support and buy-in of senior management - Technology Information)

Irrespective of the fact that some managers are firm to attach themselves religiously to this approach, the Extreme Programming is not favorable for every team or every project. As per the advocators of the Extreme Programming, some factors make some projects better suited to this methodology than others. Determination of the size of the programming team is considered to be the first prime issue in this respect. Normally, the Extreme Programming is considered to be most effective in cases where small teams are associated particularly in two to twelve programmers. The small teams are considered to be more flexible and capable of adjusting themselves to change than involving the monstrous teams consisting of fifty or one hundred persons. In order to use this approach it is considered pairing up of the team with each sharing a single computer and each counterpart concentrating on a different dimension of the problem. (When eXtreme Programming Makes Sense)

Normally, writing and implementation of the code is done by one programmer while the other observes for syntax and spelling errors, along with the idea of place of the present piece into the whole work. The obligation to Extreme Programming is resorted to run throughout the organization from the top of the hierarchy flowing down to the programmers and even to the level of the customers. In order to use the Extreme Programming effectively, at least a small fraction of the customer base is required to be interested in and capable of being involved in developing and testing the application. It is suggested that one more customers are associated with the development teams and the representatives of the customers are also required to be experts who actually use the application, assuming them to have a deep enough insight into what it is that the product needs to be able to achieve for them. (When eXtreme Programming Makes Sense)

After accessing the user experts, they are required to make them write a short description of the user stories and the details of the feature that is desired. Once the team prioritizes the user stories for adoption and incorporation in the next edition of the program the customer chooses the features that will be worked out first. They then also assist in planning the acceptance tests those are considered to be the sequence of the automated tasks the program can be put through to ensure that it is doing what is supposed to be doing. The customers are also capable of visualizing the test scores and checking the matters themselves ensuring that the tests assess the things in a proper manner. The project in which the constraints are not stable and in which the requirements frequently vary, the Extreme Programming is considered to be the best alternative. The Extreme Programming is not considered however a good alternative for those who have a nice flat set of needs.

The other spheres where the XP is suggested as a methodology is the circumstances when the teams visualize itself treading into unfamiliar territory. Most of the programmers have established themselves working in companies where management is taken to be fanatical with the XP way that the Extreme Programming is considered solution to all problems; and resistance to this in any form over this approach is considered to be losing of ones job. Such an environment is not favorable to the employee situation even when they are not trying to investigate the way everyone works upside down. The change is considered to be risky. The presentation of the reasons in a constructive manner is highly essential. Besides it is required to adhere to the concerns of the people and anticipate that the first project is taking a longer time than anticipated. (When eXtreme Programming Makes Sense)

Since the Extreme Programming involves intense interaction, its efficacy is quite favorable in case of small and medium sized teams the most effective size being a maximum of 15 members. In case of large projects several smaller teams are conveniently joined together. The Extreme Programming depends upon the development into bite size chunks and relies on daily face-to-face team communication and lots of testing, the hypothesis that specifications will vary is built into the process. The projects are developed in augmentations with sufficient code generation for implementation of the desired features and everything is constantly assessed and adjusted to accomplish the desired result. (Munro, Extreme Programming)

To conclude, the Extreme Programming is a field of software creation mostly relying on the principles of the simplicity, communication, feedback and courage. The critics of Extreme Programming visualize that it merely incorporates best experience prevailing for years. The critics are considered true to the extent that the process of programming is Extreme in utilizing the best practices in every respect. The assurances of XP- a well designed and well tested code are always distributed on time and within the financial constraints. (Munro, Extreme Programming) it works by uniting the whole team together in the presence of simple practices with sufficient response to enable the team to be aware of their position and adjust their practices to their unique environments. (What is Extreme Programming?) Irrespective of the fact that the Extreme Programming is not considered to be for everyone, it is most likely for a lot of project teams that desires to effectively produce the software-which makes the strategy more attractive.

Language prototyping prototype can be considered as a depiction or imitation of a suggested answer to a design puzzle, irrespective of the medium. The usual application of prototypes is for utility assessments carried out in the design stage of an assignment. For such an assessment, the design team spots jobs characteristic of those that the users of the product will carry out, chooses a group of users to take part in the utility trial, and monitors how well the members carry out these jobs. If the participants have trouble carrying out the jobs, alterations are made to the design and further utility experiments may be attempted. Prototyping is an outstanding method of designing the user interface and it includes screen layouts, control labels, and other graphical user interface - GUI characteristics. (Extending prototyping)

Prototyping is an efficient technique to get awareness of the necessities, lessen the intricacy of the problem and offer an initial corroboration of the system design. For computer aided prototyping of quality domain-specific software, there has been no generally acknowledged executable specification language or high-level programming language. Available prototyping devices are either too focused to be helpful in a broad range of application domains, or too complex to utilize by non-computing professionals. Furthermore, some specification or prototyping languages or devices aid reusable prototyping. In the majority cases, an acknowledged prototype has to be re-used in a usual programming language. (Rapid Software Prototyping Using Visual Language Techniques)

Language prototyping refers to creating language implementations mechanically from high-level language descriptions. (Language Prototyping: An Algebraic Specification Approach) Any type of language, which is inclined towards power of expression, neatness of actual code, and quickness of development, with eventual efficiency taking a relative back seat, is Prototyping language. There is a squabble that proceeds like this: 80% of the code takes 1% of the CPU time; 10% takes 10% of the time; and the last 10% takes the rest. If you can substitute that 80% by 10% at the price of that part of the code running five times slower, your cost in operation is minor and you've removed 70% of the code. (Prototyping languages: www. home.tiac.net) language should be considered as a group of language bits, each bit defining a separate and reusable modular element. (Modular Attribute Grammars for Programming Language Prototyping) Program languages can be expressed as a language that expresses the alteration and power of an existing program. Program languages can be made from one or many basic programming languages, and actually can be applied as part of the functionality of the prototyping environment. This opinion is made on the insight that a setting is a means to help a programmer in making a working program, including planning the source text. There is no compulsory necessity that an environment be restricted only to working with raw source text. Another instance is that some systems contain many procedures communicating through channels. The formation of this part of the system can be graphic representation, with the result formed by the environment being a set of source code in several languages, build scripts, link directives, and operating system calls. As no single programming language includes the program language, one could call such a language an epilanguage. (Make Lisp the Premier Prototyping Language)

Based on this structure new language can be made economically by using different grouping of language fragments, using again many existing fragments. Cheap language implementation also makes it possible to do language oriented programming where application oriented languages are formed as concepts of problem domains allowing short solutions to be quickly built for particular problems. This gives details as to how to make language processors from language fragments. The study of the language oriented modular structure is in three stages: interpreters, parsers and attribute grammars. In the first case each language fragment is incarnated in an interpreter. The arrangement of the interpreters is modified to permit them to be united. A modular parsing system is built. The interpreters and modular parsers undergo some structure crash, which make some problems tricky to express. Modular attribute grammars help to conquer this. A modular attribute evaluator is formed by a lazy functional programming language as a medium for testing. The resultant system has exciting properties: it permits language fragments to be based on the semantic structure of the language as well as the syntactic structure and includes support for programming by plain modification. In conclusion, the execution of languages as group of component fragments may change our view of programming languages themselves. (Modular Attribute Grammars for Programming Language Prototyping) prototyping language must offer easy, but great means for dynamic creation and management of similar procedures, to support prototyping of parallel algorithms. When compared to sequential programming, parallel programming is apparently difficult to tackle and appreciate, as a programmer often has to concentrate on more than one procedure at a time. In addition, in most the present days' parallel machines, programmers are required to program at a low level to get the performance and easiness of use is given up for efficiency. Therefore, coming out with parallel algorithms is in general thought of as a clumsy mission. (Prototyping Parallel Algorithms in a Set-Oriented Language)

Hence, prototypes should be created and adapted quickly, precisely, and economically. The most basic prototyping devices are paper and pencil. After the advent of Computer-Aided Proto-typing -CAP, many computer systems have been built to aid the prototyping process. CAPS utilizes a specification language called Prototype System Description Language (PSDL), incorporated with a group of software gadgets that consists of an execution support system, a rewriting system, a syntax-directed editor with graphics capabilities, a software base, a design database, and a design management system. CAPS combine dataflow and control flow to create prototypes quickly. (Rapid Software Prototyping Using Visual Language Techniques)

Devices and procedures have been produced for mechanically making visual languages. The majority of them are dedicated to some features of visual language generation, e.g., for user interface generation, and for parsing. A small amount work has been done in mechanically generating preferred visual languages from demanding specifications. In a visual programming background, clients must be able to interactively build and control reusable modules in the visual language. The graphical necessities of a visual language consist of delineating the reusable visual modules of the language and the control and dataflow relations that must be uphold when these modules are linked together. Software engineers of intricate software systems normally employ diagramming methods, such as UML, as theoretical tools to theorize their architectural design.

Graphs can show semantic and structural information more naturally than text. As soon as a software engineer has supplied the specification by means of production guidelines, a VEPL - Visual Executable Prototyping Languages with its visual programming background will be mechanically created in the similar manner as making textual languages using Lex/Yacc. With no comprehension of the prototyping language syntax or the comprehensive specification, a programmer will be able to utilize the programming background to build prototypes visually on the graphical editor of the device and operate the prototypes to confirm their needs. When the essence of each software module is given, the system is able to produce the ultimate prototypical and executable programs. (Rapid Software Prototyping Using Visual Language Techniques)