EMBOSS supports a variety of standard and biological datatypes (Section 4.3, “Data Definition”). Datatypes for application inputs and outputs are defined in the AJAX Command Definition (ACD) file, which describes in detail the application parameters and command line interface. Datatype attributes allow an input or output to be specified in greater detail, for example by setting a default value or by defining the permitted type of an input sequence. Calculated attributes, such as the length of an input sequence, are available once the data has been read during ACD file processing but before the application proper starts, allowing for further fine control in the ACD file.

EMBOSS supports a wide range of file formats for input and output and is moving towards using standard report formats for application output. Biological sequences can be read and written using all common formats. EMBOSS detects the format of an input sequence automatically, but this can be specified for efficiency. Many other formats for sequence features, alignments, data files and so on are handled automatically. Any application you write will support these formats automatically too. Furthermore, when new input and output data formats are added to EMBOSS, your applications will automatically be able to use them; no application code needs to change. For information on supported file formats, see the EMBOSS Users Guide.

Database configuration is simple and flexible. A variety of databases (which can include remote data servers) and diverse access methods are supported. New databases and access methods are easily added. For more information see the EMBOSS Administrators Guide.

Your application will use the EMBOSS command line which is consistent across the applications. The ACD file defines the datatype and permissible values for all application options. The ACD file and all input at the command line is validated at startup, before the application proper starts. Command line behaviour, for example the production of a sensible prompt and reprompting for values that are out of range, is handled automatically. For more information, see the EMBOSS Users Guide.

EMBOSS includes various command line qualifiers which are not (typically) set in an ACD file. These include global qualifiers and various datatype-specific qualifiers. Global qualifiers are available to all applications and control general application behaviour. Datatype-specific qualifiers are used to specify particular inputs and outputs, for instance sequences, in more detail. For more information see the EMBOSS Users Guide.

Sequences are referenced on the command line by their Uniform Sequence Address (USA) which is a powerful and flexible specification for defining the location and format of sequence data. Similarly, sequence features are defined using a Uniform Feature Object (UFO). Any application you write will automatically support USAs and UFOs. For more information see the EMBOSS Users Guide.

There is a single major release of EMBOSS on St Swithun's day (15th July) each year. The version number usually, but not always, increases by 1 each year. Other versions are released in the interim as required. The EMBASSY packages do not have a fixed release date or formal version numbering scheme. To avoid confusion, version numbers for EMBASSY packages which wrap third party software are set to the same as the version number of the software that has been wrapped. Individual EMBOSS or EMBASSY applications do not have their own version stage or number. New programs are announced on the EMBOSS mailing lists to solicit feedback from users.

You should decide upon a general model for the development and release of your software. No model has been universally adopted however all projects begin with a pre-development stage, before coding starts, which is followed by one or more versions of the software reflecting the maturity of the code. The following stages are typical:

In practice, very often there is no formal software release corresponding to every stage. For example, the users might only see a beta version and the final release. Nonetheless it is helpful to bear these stages in mind as it helps when managing the expectations of your users. It should go without saying that, for instance, it would be foolish to distribute broadly code that had not been well tested in a beta version. In practice, early releases often contain many bugs and for this reason people are usually wary of software until it has matured over a period of months or even years.

Pre-development. The pre-development stage occurs before coding starts. Requirements are specified and expected work throughout the software lifetime is planned.

Pre-Alpha. Pre-Alpha software is still under active design and development. Usually it is a prototype for the version that might eventually be released. From the user's perspective a pre-alpha release is useful to get the gist of what's to come, from the developer's perspective it provides a means to get early feedback from users in order to inform the design and development.

Alpha. Alpha software is usually reasonably well developed but not ready for general release. There will be very limited, if any, deployment. Such deployment is often restricted to the primary user group or some other select group of users who are known to provide good feedback. Typically, most major features will be implemented and most major bugs removed, but there will be many missing minor features, bugs and other issues. The alpha release might be a complete rewrite or an evolution of the pre-alpha version.

Beta. Beta software is the first significant release. Its main purpose is to get the software tested by as large a group of users as possible and to solicit feedback. Beta software might not be perfect, it might not work under all circumstances, but it should be relatively bug-free. Typically, the majority, if not all, known major bugs should be fixed.

Release candidate. The release candidate is a refinement of the beta version in which all known bugs are fixed. It may have several new features if these were heavily requested during beta testing, but these should not be a major departure from its basic function. Such major requests should (ideally) have been caught earlier on. Major features are now "frozen", and only bug fixes or minor new features implemented from this point on. The release candidate can be thought of as a half-way house between versions used for testing and that which is deployed. Release candidates should be subject to heavy testing by the developer and in real use-case scenarios.

Release. The release software is fully developed and tested and should be ready for use in anger by your users. It is the final version of the software arising from testing and refinement of the release candidate. The release will normally have a number, for example, Version 1.0.

The EMBOSS developers use a combination of the "Code and Fix" and "Synchronise and Stabilise" models (see below). This has proved to be the most pragmatic way to keep users happy, especially balancing the requirements for new functionality with that for stability and consistency in the package as a whole.

The general approach is to fix bugs as soon as they are reported and provide bug fix files (see the EMBOSS Users Guide) as required. New features or applications are developed in close collaboration with the users, typically as requested, and are developed and released in a scheduled manner. This is done in as timely a manner as possible allowing for all bugs to be fixed and major issues to be addressed. All bug fixes and requests for features that cannot immediately be implemented are logged on the SourceForge website (see Section 1.5, “Contributing Software to EMBOSS”). In this way valuable contributions are not lost even if they cannot be acted upon immediately.

Many software life cycle models have emerged and all tend to focus on the development process itself. They are summarised below. It is up to you to adopt one of these models (or something else) that is most appropriate to your needs and situation.

Code and fix model. The simplest model iterates a cycle of coding and bug-fixing until the software is fit for purpose:

Waterfall model. In this model development proceeds in a linear series of definite management or development steps. The steps might be followed by testing, which must be passed before proceeding to the next step. Typically, return to a previous step is only allowed if a new problem is identified in the existing step. Thus development proceeds incrementally and logically. The drawback however is that such models are rather inflexible to changing requirements.

Spiral model. The spiral model attempts to address the inflexibility of the waterfall model by iterative cycles of development. This introduces more chances for user involvement but the drawback is that the model is rather cumbersome and therefore difficult to stick to in practice. Each cycle has four phases:

Prototyping. The prototyping models try to ensure that software meets user requirements by introducing definite evaluation points in the development process. At these points the user reviews the software, typically a prototype version, via a demonstration or by hands-on testing. The software under review might be a small part of a larger system. As development progresses the developers tend naturally to focus on design and implementation issues, whilst the users remain focused on their requirements. The prototyping models attempt to avoid any divergence of views through regular appraisal.

Rapid application development. This is a general approach to software development and a move away from inflexible formal models. Typically a series of prototypes are reviewed by the user and developer to ensure user requirements are met and fine-tuned in the face of the continuing developments. Analysis, design and implementation at each stage is usually limited to a definite time. The drawbacks to this approach are that, in the absence of a formal statement of a design up front, it can be difficult to agree when a project is finished and the software can evolve in an undesirable or uncontrolled way.

Synchronise and stabilise model. This model coordinates multiple developers who are working in parallel and attempts to quickly produce software that fits most needs, and to improve it in subsequent versions. It relies on frequent depositions of code which are synchronised to ensure compatibility. Testing occurs at all stages and in parallel with development and all reported bugs are fixed immediately. Features tend to be implemented incrementally, starting with those of highest priority to the user. The software is stabilised at key stages in its lifetime through extensive user testing and bug fixing.

Iterative and incremental models. Such models rely on a set of specific use-cases and a detailed software architecture. Each use-case describes what an individual or group of users want from the system, and together describe the complete functionality. The software architecture describes all significant components of the software and environments in which it will run. The use-cases drive the development whereas testing ensures that the use-cases are implemented correctly. Coding is usually divided to cover groups of related use cases which are tackled iteratively. Each iteration results in an increment of the software, i.e. one with more use-cases catered for. In this model a design may well evolve as required, especially in the early stages, with later iterations tending to add to, rather than modify, what has already been done.

The EMBOSS mailing lists (Section 1.4, “Project Mailing Lists”) allow discussions between the user community and developers. As a developer you should subscribe to the lists. Any new software should be discussed on the mailing lists before it's implemented, especially to establish whether it is really needed or already exists.

Software must fulfil the requirements of the intended users and use cases. It is therefore valuable, essential even, that your users are involved in the development of the software throughout its lifespan, especially these four stages:

Pre-development. It's essential to get as complete a picture as possible of the user or use-case requirements at the pre-development stage, before coding starts. Try to pin your users down to exact, specific requirements. The devil is in the detail as any misinterpretations can lead to wasted developments. The requirements must be balanced by the constraints on the developer and it might be that some features are planned for the first release and others are left for a later date, but are considered in the design. It is usually far harder to modify existing code for new features than to code (or at least consider) them from the start, so any effort here will be amply rewarded.

Development. Demonstrate your software to its intended users at all stages of development, but especially early on. This allows for confirmation that functionality is developing as planned. As implementation proceeds and becomes fixed on a particular approach, there can be a tendency for the developer's and user's notion of the software to diverge. This is mitigated if good communication is maintained. Inevitably, during implementation, issues arise and ideas evolve. By keeping in touch you avoid unnecessary developments and can fine-tune the user requirements in light of the continuing developments.

Testing and validation. A most valuable contribution of users is in testing software. They will find ways to use (and abuse) the software that you did not anticipate. Crucially, this should validate that the software works as required in real-case scenarios and meets the user's needs. Often, new bugs and requirements will arise from testing, which must be fixed or implemented as the beta software is refined. Testing should result in a release candidate in which major features are frozen. From that point on only minor bug fixes and features should be implemented for the release proper. Be organised so that suggestions can be incorporated at the appropriate time: suggestions for major new features are not appreciated the day before the release date! Try to get a maintain a clear picture of your users requirements and plan your work accordingly.

Evolution. Even software implemented to the very best design can only fulfil the requirements that were known at the time. In practice, your software must evolve to keep pace with your users, whose needs are often evolving. In some cases, when adapting software for changing requirements, it's necessary to move the software back into beta or even to start from scratch where a complete redesign is necessary. In such cases an appreciation of the current stage of the software helps to manage expectations.

EMBOSS includes many applications and it's likely that one exists which does something similar to what you need. Before you start coding you should therefore check the application documentation:

There is a guide on navigating the documentation in the EMBOSS Users Guide.

There are three basic types of application development:

If it seems that only a simple modification to an existing application is required, this might easily be achieved by modifying the ACD file without any new C coding at all. See ACD file development (Chapter 5, C Programming) and ACD syntax (Appendix A, ACD Syntax Reference).

In other cases an entirely new application is required. The AJAX and NUCLEUS libraries (see Appendix B, Libraries Reference) provide a comprehensive toolkit for developing applications from scratch. The existing application ACD files and C source code might provide a valuable starting point or offer clues as to how to proceed.

There are also cases where you either already have the source code for an application that you want to incorporate into EMBOSS, or you otherwise want to provide an EMBOSS-style command line interface to an existing application. The wrapping and porting of applications under EMBOSS is described later (Chapter 10, Incorporating Third-party Applications).

When considering a new application there are two basic rules (with a few exceptions):

Three areas in planning deserve special attention:

The AJAX and NUCLEUS libraries are easily extended, but might already contain the functionality you need. The first thing to do therefore is to check the documentation for AJAX and NUCLEUS (see Appendix B, Libraries Reference).

Library developments include:

When developing library code, be careful to avoid redundancy with the existing code. You should, if possible, modify existing objects or functions, or at least use the C source code as a starting point or for ideas on how to proceed.

Where the code is specialised (used by one application only) it should stay in the application C source code file until it is more generally used. Only code that is likely to be of general use should go into AJAX or NUCLEUS.

Where new code is in the area of an existing AJAX or NUCLEUS library file it should be added to that file. Where a new category of functionality is, a new library file should be created for it.

To ensure consistency in the EMBOSS code, all C code that you write should conform to a basic style. You should familiarise yourself with the standards (Appendix C, C Coding Standards) before coding.

The coding standards mostly concern the layout of code, but includes some general guidelines for C programming in EMBOSS and particularly programming datatypes and functions.

You will need to create (if necessary) a new application C source code (ApplicationName.c) file in the appropriate directory. The file should have a short meaningful name which, if possible, bears some resemblance to applications of similar function. Typically the EMBASSY myemboss package is used for individual developments. Alternatively the applications directory in another EMBASSY package or EMBOSS itself could be used:

A few basic steps are recommended when writing application C source code:

New C source code (*.c) and / or header files (*.h) may be created in the core AJAX or NUCLEUS directory as required:

The files should have a short, meaningful name. AJAX files must begin with the prefix aj, for example ajstr.h and ajstr.c are used for the string-handling library. NUCLEUS files must have the prefix emb, for example embaln.h and embaln.c are used for the alignment algorithm code.

To integrate large collections of code, for example third-party libraries, a new directory would usually be created under the main AJAX directory:

For example, files in the zlib library live in:

There are some basic steps when writing library code: