By Dr.Thomas J Mowbray Chairman - iCMG

Software Patterns

Software patterns comprise a common body of software knowledge which can be applied across all component infrastructures. The most famous category of software patterns, called design patterns, comprises proven software design ideas which are reused by developers. [3] Other important categories of patterns include analysis patterns and antipatterns. [1] Analysis patterns define proven ways of modeling business information; that can be directly applied to the modeling of new software systems and databases.

Software patterns are a necessary element of componentware. The development of new, reusable components requires expert-level quality of design, specification, and implementation. Proven design solutions are necessary to establish successful component architectures and frameworks for families of applications. Often, there are too many variables to take chances on unproven design concepts.

The popularity of software patterns can be explained as a response to the practical shortcomings of object-orientation. Antipatterns explain the common mistakes that people make when developing object-oriented software systems (as well as other types of systems). Much more is needed than basic object-oriented principles to build successful systems. Design patterns explain the additional, sophisticated ideas that are required for effective software designs. Analysis patterns present the sophisticated ideas necessary for the effective modeling of concepts and data.

It is still commonplace in software development, to reinvent design ideas, incurring the risks and delays of trial and error experimentation. If fact, most software methods encourage reinvention as the normal mode of development. Considering the challenging forces of requirements change, technology innovation, and distributed computing, we consider reinvention to be an unnecessary risk in many circumstances. This comment is especially applicable to the development of components, where the costs of defects and re-designs can affect multiple systems.

Altogether, software patterns can be described as knowledge reuse. It is interesting to note that most patterns are considered as simple as common-sense by expert-level developers. However, for the majority of developers, patterns are a necessary part of technical training that can help them to achieve world-class results.

Software Architecture

Software architecture concerns the planning and maintenance of system structure from earliest system concept, through development, and operations. Good architectures are stable system structures which can accommodate changes in requirements and technologies. Good architectures ensure the continuous satisfaction of human needs (i.e. quality) throughout system lifecycles.

Reusable components are examples of good architecture. They support stable interface specifications, which can accommodate changes due to reuse in many system contexts.

Software architecture plays an important role in component design, specification, and use. Software architecture provides the design context, within which, components are designed and reused. Components have a role in predetermining aspects of software architecture. For example, a component framework may predefine the architecture of a significant portion of a system.

One of the most exciting aspects of software architecture for componentware is supporting distributed project teams. A software architecture comprises a system specification that enables parallel, independent development of the system or its parts. A proper software architecture defines computational boundaries (i.e. API) that divide the system into separate testable subsystems. These subsystems can be outsourced to one or more distributed project teams.

Component-Based Development

Component-based development is software development with a difference. Many process aspects are reused, such as iterative, incremental development. The primary componentware difference is the specialization of technical roles. [2] Three key componentware roles are software architect, component developer, and application developer. These differ from object-oriented approaches which promoted notions of all-purpose programmers, committee-based design, and architecture after-the-fact.

A typical leadership team for a project comprises a software architect and a project manager. The architect works in conjunction with management to make key technical decisions, those with system-wide impact. The architect is responsible for technical planning of the system, and communicating these plans with developers. Since the architect coordinates system-wide design decisions, many other technical decisions are the responsibility of developers. To be effective, the architect must have the highest levels of experience and technical training; with outstanding skills in design, specification-writing, and spoken communication.

The best component developers are also the most talented programmers. They design and program the building blocks from which the application will be constructed. The architect defines the major boundaries behind which component-based services will be provided. Reuse of pre-existing components is evaluated with respect to an organizational software repository. For new component requirements, the component-developers design and construct new software, updating the organizational repository. Typically, components will implement the horizontal functions and lower-level aspects of the system, reducing the need for application developers to reinvent these capabilities. Component developers make intensive use of software patterns, applying several overlapping patterns to each component design and implementation.

Application developers are responsible for integrating components and implementing the vertical requirements of the system, including user interfaces. They apply pre-existing components to the solution of application-specific problems. Application developers must communicate with end-users have some domain expertise.

Generally, component developers use systems programming languages, such as C++ and Java, while application developers use scripting languages, such as Javascript, TCL, Python, and Visual Basic. Systems programming languages allow more control of low level issues, but are more difficult to use for application-building. Scripting languages provide a higher level of abstraction, with a corresponding reduction of up to 8:1 in lines of code needed to implement a given requirement, compared to systems programming languages.

Summary

The Componentware Revolution is the next major software technology trend. In many ways, it has already arrived, and is readily available for commercial exploitation. This revolution is actively supported by major vendors, including Microsoft, Sun, IBM, and the CORBA vendor consortia.

The most important aspects of componentware are not the choice of technologies, but how these are applied. Successful adoption of componentware must include the reuse of software patterns, the planning of software architecture, and the establishment of component-based development teams.

The Componentware Revolution is an exciting opportunity to avoid the inadequacies of outdated software approaches. Componentware enables you to survive and thrive when facing the challenges of requirements change and rapid commercial innovation. Componentware delivers the benefits of software reuse and enables outsourcing to distributed project teams.