Component management seals software success
26 February 2010
Paul Allen of Perforce Software discusses how SCM is being used to manage component-based development more effectively.
The trend towards rapid prototyping and ever-shorter development cycles places considerable pressures on design departments to make frequent release and updates to their existing products.
In this environment, software reuse is vital, helping to save development time and increase confidence in the quality of the delivery. How, then, do you efficiently reuse part of the software from a different product without bloating the end product? The solution, as is almost always the case with an engineering problem, is to divide the problem into smaller pieces. These smaller pieces can be treated as components, with a defined set of interfaces and functionality.
A software component is an individual module or software package that encapsulates a set of related functions or data. In relation to a system, a software component communicates with other components via an interface. Much like a conventional electronic component, a software component has a set of defined behaviour characteristics and can be combined easily with other components in the system.
For example, an infotainment system might contain several components; some shared with other projects such as File system, Codecs and Device drivers, while others might be unique to the system, such as the Application, associated artwork and buffering solutions. Each component must provide an interface to allow it to communicate directly or indirectly (via a framework) to other components within the system.
The component-based approach does represent a new way of working and brings its own set of challenges. For instance, it is very difficult keeping track of which versions of components work together, so when one component‘s interface changes, the dependent components can be adapted. Likewise, using a dependent component in a project then requires the correct version of the underlying components. This is further complicated with the need to maintain different variants of the same component.
Components are separate entities and it is important that this is reflected in their lifecycle. Isolating their development and release cycles from that of other components or projects helps to enforce this separation.
Using a separate codeline to decouple the development activities of a component from the project or projects, allows the component development team to add to or improve features without impacting the release schedule of a project.
Likewise, a separate release codeline for each version of the component allows project team members to access a stable release of the component. The release codeline effectively conceals the component’s development activities from the project team members using that component release.
Project teams can periodically update the components used in their projects as new releases become available. These updates can be controlled by the project team and are not imposed, enabling the project teams to decide when an updated component can be integrated.
A good Software Configuration Management (SCM) system will not only help to track the specific set of files that make up the component, but also the version of each component used in a project. The SCM must also be capable of storing and mapping the correct versions of each component used in a project and populate the project’s build and release codelines with the correct configuration of components.
Each component must have an owner or maintainer that is enforced by the SCM. This prevents the accidental or sometimes deliberate changing of a component to ‘fit’ into a project. In much the same way that you would not try to cut open a transistor in order to change its gain, you should not try to alter a component to suit the design of a project.
How do you then make urgent changes to a component to fix a critical bug, and how do you deploy new component features to existing projects? It is important to distinguish between a stabilising change, such as a bug fix, and a potentially destabilising change, such as a feature enhancement. If the change is on a component, it is even more crucial to make the distinction, as the effect of the change can impact many projects. SCM records and reports on the status of all components and can provide a visual file history that ensures all features and bug fixes have traceability back to its source.
The component maintainer can submit the bug fix to the release codeline for the specific version of the component. The advantage of a per-component release codeline is that after the bug fix has been submitted, it is immediately available to all users of that component and helps to stabilise more than just one project. The stabilising effect of a bug fix can then flow down to softer codelines (codelines able to accept the change) within the component and the projects using the component.
The potentially destabilising effects of a new component feature can be thoroughly tested and released by the component maintainer on a separate release codeline. The separate release codeline helps to decouple the new feature and its associated risk from the projects that rely on the component. Project teams that choose to adopt the new component feature can merge the new version of the component into their project’s mainline and test their project before making the next release.
The above baseline protocol illustrates the difference between the two types of changes. A stabilising change (such as a released bug fix) is merged down into the project’s release codeline and then into the mainline. This contrasts with a potentially destabilising change (such as a new component feature), which is merged into the project’s mainline for testing before it is copied up into the projects release codeline.
In some situations, it might be necessary to maintain an older release of a component when a newer feature might be incompatible with the current phase of a project. Adopting a component-based development methodology provides this kind of flexibility. It is easier to change the project to make use of a new component version than to change a component and subsequently each project that employs the component. For example, a project team might decide to delay the adoption of a new version of a component if they are in a ‘feature freeze’ and are about to make a release. However, the adoption of the new component version should be prioritised for the next project release. SCM enables different user communities across the entire organisation to access this information, facilitating team interactions and ensuring adherence to the organisation’s development process.
If the project’s feature development has ended and it has entered a maintenance only phase then the old version of the component must be maintained for as long as the project or any other dependent project is using it.
Software variants (or component variants) are necessary to accommodate hardware differences. The challenges are how to track the divergences, integrate changes to all variants, and later merge bug fixes back into the variant.
A variant is a divergence from the main codeline and over time, if left unchecked, a variant can diverge so far that any new feature or bug-fix is impossible to integrate as the codelines will have almost no similarity. It is therefore essential to minimise the amount of shared code that is diverged.
Rather than maintaining hundreds or even thousands of variants as separate components with their own codelines, it is simpler and easier to group variants together as a family of components. SCM tools can ensure completeness and consistency among all components and intuitively organise the repository. The project team can then choose the family of components from the release codeline and specify the precise variant with either a build flag or selectively map the required files.
Components are best designed to keep their shared code ‘clean’ and use a thin API or abstraction layer to separate the variations. For example, if your project needs a serial port interface, the serial device driver may have several variants for different microcontrollers, where only the UART registers in the hardware vary. You only need to select the correct version of the serial device driver family for the version of the kernel, and specify the variant to suit your hardware.
Deciding when to make the split between component and variant is subjective, and often evolves with time. Components might grow with new functionality and variants, and in turn, might split into new components or new sets of component families. When a component grows too big to be reusable, the old divide and conquer adage applies and new boundaries are drawn up. These new boundaries form the interfaces for the new component or variant.
In summary, component design will help to keep projects lightweight and aid faster prototyping. Establishing the flow of change between components and project codelines will help to improve the stability of the component and the projects that use them; thus increasing confidence in the final software delivery. Minimising the divergence of components and adopting component changes early in the project lifecycle will ensure smoother project delivery and a faster development cycle. SCM technology is being increasingly used in the electronics sector to help facilitate faster product development, rapid prototyping, and improved design collaboration.
Paul Allen is a Technical Support Consultant with Perforce Software
Contact Details and Archive...
Related Articles...
Most Viewed Articles...