Spiral 1 Approach

for use in the repository. Although formal specification is used for components in this project, this is only for the description of the ideal component (functional requirements), the expected data for a repository entry is more basic: the context and interface meta-data. Characterisation is also discussed in Section 2.2.1.

4.3 Spiral 1 Approach

As the initial Spiral of the development, Spiral 1 had no existing artefacts on which to build. The work to be done is based on literature, industry applications of similar type and preferences of the research program. At the time of the first Spiral, XML was gaining popularity as an interchange format for the description of documents and electronic resources. Dublin Core was becoming standardised and utilised widely, along with other standards.

The component specification template was derived from surveying existing work, in-dustry usage (not just components), document standards and the research aims and delimitations. A compiled list of all component attributes was developed and consoli-dated. Each attribute was considered for inclusion. This was then modelled in UML (Figure 4.2) to abstract the concepts, identify gaps, and crystallise the expected usage.

The resulting data model was compared with existing document templates to create a mapping between common attributes in order to add any that were missing. The UML was converted to XML schemas following conventions in the XML and document stan-dards communities and concepts of modularity and reuse.

The motivation for developing a schema to describe components is to assist in the distribution and discovery of components available electronically. The tasks of finding components, and of making information about components available, is simplified by having a standard format for describing the component. This schema provides a structure for component specification, including contact information and technical details. By using a documentation standard, component developers will not need to modify their documentation for each brokerage site, and prospective component users will know what information they can expect to find when selecting candidate components. The added benefit is that some aspects of component discovery and selection can be automated with a machine-readable component description.

CHAPTER 4. SPECIFYING COMPONENTS

Figure 4.2: Original class diagram for the component specification schema

This schema has been developed to be put forward as a possible standard for compo-nent specifications. The approach has been to survey existing specifications and expected requirements to determine what should be in the specification. Object-oriented develop-ment techniques have been applied to assist in viewing the ‘big picture’ and the template is documented using W3C standards as a model.

Guidelines considered in the approach to the specification included: adhering to exist-ing standards; matchexist-ing attributes to user needs; includexist-ing context and behaviour; and, supporting classification schemes (implemented in Spiral 4). These address the overall goals of reuse, usability, intelligence and dynamics.

4.3. SPIRAL 1 APPROACH

Adhering to Existing Standards

The schema is designed to make use of existing standards for electronic resource docu-mentation where possible. This adherence to standards makes it possible to seamlessly include information specific to software components, while maintaining a standard (e.g.

Dublin Core) across the organisation’s information stores.

Once a list had been compiled from component broker sites and papers, related at-tributes were grouped into six categories: identification, description, contact, commercial, technical and authentication. Because components can be viewed as electronic resources, the specification extends Dublin Core. Twelve of the attributes refer to Dublin Core.

The specification is detailed in Tables 4.4 to 4.5.

Matching Attributes to User Needs

Use cases were developed for the specification to identify the many ways that the template may be used (Figure 4.1). It was important to make the attributes comprehensive, pro-viding a component with an accompanying document that includes information needed for various stages of its life.

Object-oriented techniques were used to model the data, with an awareness that the implementation may not be object-oriented. Use case diagrams provide a model from which to consider the perspective for the various users (actors). The original class diagram for the component specification is in Figure 4.2. This was the data model as at the end of Spiral 1.

Including Context and Behaviour

The context of the component refers to the environment in which it operates, with devel-opment context unlikely to be the same as the target context. This information is held in the technical section of the schema, along with the behavioural specification. Context is highly important when assessing the suitability of a component and the amount of coding required for adaptation into a new context. Context comes into play at two main points of the selection process: when shortlisting the candidate components, and when testing and evaluating the candidates. In Spiral 1 we need to consider both of these, with the details for testing and evaluation to come in later Spirals.

CHAPTER 4. SPECIFYING COMPONENTS

The target context for a component includes the operating system, framework, re-lated components and development language. These are included in the technical section of the template. Additional non-functional information may include certification and authentication. The support for behaviour is through attributes for interface in-formation, again within the technical part of the template. This allows each interface to be recorded, including inputs, outputs and errors.