Implementation  Issues

Implementation  Issues

Software engineering includes all of the activities involved in software development from the initial requirements of the system through to maintenance and management of the deployed system. A critical stage of this process is, of course, system implementation.

Implementation may involve developing programs in high- or low-level programming languages or tailoring and adapting generic, off-the-shelf systems to meet the specific requirements of an organization.

Aspects of implementation that are particularly important to software engineering are:

  1. Reuse:- Most modern software is constructed by reusing existing components or systems. When you are developing software, you should make as much use as possible of existing code.

  2. Configuration management:- During the development process, many different versions of each software component are created. If you don’t keep track of these versions in a configuration management system, you are liable to include the wrong versions of these components in your system.

  3. Host-target development:- Production software does not usually execute on the same computer as the software development environment. Rather, you develop it on one computer (the host system) and execute it on a separate computer (the target system). The host and target systems are sometimes of the same type but, often they are completely different.

Now let us understand about each of them in detail:-


Most new software is defined from scratch by writing all code in a high-level programming language. The only significant reuse of software uses is the reuse of functions and objects in programming language libraries.

  • However, cost and schedule pressure meant that this approach became increasingly enviable, especially for commercial and internet-based systems.

  • Software reuse is possible at several different levels-

    1. The abstraction level:-

      At this level, you don’t reuse the software directly but rather use knowledge of successful abstractions in the design of our software. Design patterns and architectural patterns are ways of representing abstract knowledge for reuse.

    2. The object level:-

      At this level, you directly reuse objects from a library rather than writing the code yourself. To implement this type of library discover if the object and methods offer the functionality that you need. For example, if you need to process mail messages in a Java program you may use objects and methods from a Java-mail library.

    3. The component level:-

      Components are collections of object classes that operate together to provide related functions and services. You often have to adapt and extend the component by adding some code on your own. An example of component-level reuse is where you build your user interface using a framework. This is a set of general object classes that implement event handling, display management, etc. You add connections to the data to be displayed and write code to define specific display details such as screen layout and colours.

    4. The system level:-

      At this level, you reuse entire application systems. This involves some kind of configuration of these systems. This may be done by adding and modifying the code or by using the system’s interface. Most commercial systems are now built in this way where generic COTS (commercial off-the-shelf) systems are adapted and reused. Sometimes this approach may involve reusing several different systems and integrating these to create a new system.

  • By reusing existing software, you can develop new systems more quickly, with fewer development risks and also lower costs. As the reused software has been tested in other applications, it should be more reliable than new software. However, there are costs associated with reuse:

    1. The costs of the time spent in looking for software to reuse and assessing whether or not it meets your needs.

    2. You may have to test the software to make sure that it will work in your environment, especially if this is different from its development environment.

    3. Where applicable, the costs of buying the reusable software. For large off-the-shelf systems, these costs can be very high.

    4. The costs of adapting and configuring the reusable software components or systems to reflect the requirements of the system that you are developing.

  • The costs of integrating reusable software elements (if you are using software from different sources) and with the new code that you have developed. Integrating reusable software from different providers can be difficult and expensive because the providers may make conflicting assumptions about how their respective software will be reused.

Configuration management:-

Configuration management is the name given to the general process of managing a changing software system. Configuration management aims to support the system integration process so that all developers can access the project code and documents in a controlled way, find out what changes have been made, and compile and link components to create a system. There are, therefore, three fundamental configuration management activities:

  1. Version management:- where support is provided to keep track of the different versions of software components. Version management systems include facilities to coordinate development by several programmers. They stop one developer from overwriting code that has been submitted to the system by someone else.

  2. System integration:- where support is provided to help developers define what versions of components are used to create each version of a system. This description is then used to build a system automatically by compiling and linking the required components.

  3. Problem tracking:- where support is provided to allow users to report bugs and other problems, and to allow all developers to see who is working on these problems and when they are fixed.

Software configuration management tools support various activities in software development. Alternatively, integrated development environments can use separate tools like Subversion for version management, GNU build system for system integration, and Bugzilla for bug tracking.

Host target development:-

Most software development is based on a host-target model. Software is developed on one computer (the host) but runs on a separate machine (the target). More generally, we can talk about a development platform and an execution platform. A platform is more than just hardware. It includes the installed operating system plus other supporting software such as a database management system or, for development platforms, an interactive development environment.

A software development platform should provide a range of tools to support software engineering processes. These may include:-

  • An integrated compiler and syntax-directed editing system that allows you to create, edit, and compile code.

  • A language debugging system.

  • Graphical editing tools, such as tools to edit UML models.

  • Testing tools, such as JUnit (Massol, 2003) can automatically run a set of tests on a new version of a program.

  • Project support tools that help you organize the code for different development projects.

Software development tools are often grouped to create an integrated development environment (IDE). An IDE is a set of software tools that supports different aspects of software development, within some common framework and user interface. Generally, IDEs are created to support development in a specific programming language such as Java. The language IDE may be developed specially or may be an instantiation of a general-purpose IDE, with specific language-support tools.

For distributed systems, you need to decide on the specific platforms where the components will be deployed. Issues that you have to consider in making this decision are:

  1. The hardware and software requirements of a component:- If a component is designed for a specific hardware architecture or relies on some other software system, it must be deployed on a platform that provides the required hardware and software support.

  2. The availability requirements of the system:-High-availability systems may require components to be deployed on more than one platform. This means that, in the event of platform failure, an alternative implementation of the component is available.

  3. Component communications:- If there is a high level of communications traffic between components, it usually makes sense to deploy them on the same platform or on platforms that are physically close to one other. This reduces communications latency, the delay between the time a message is sent by one component and received by another.

You can document your decisions on hardware and software deployment using UML deployment diagrams, which show how software components are distributed across hardware platforms. If you are developing an embedded system, you may have to take into account target characteristics, such as its physical size, power capabilities, the need for real-time responses to sensor events, the physical characteristics of actuators, and its real-time operating system.