Spiral 1 Context

Stakeholder Win Conditions

Application Developers Specification includes all information required for decision making Adheres to standards

Usability of template and tools (e.g. XSLT) Well documented and extensible

Component Developers Clear documentation of how to use

Includes items specific to their developed product Component Brokers Adheres to standards

Objectivity of included information Quality Assurance Well documented

Able to be validated Academia Adheres to standards

Model is well designed

Inclusions and omissions are justified Survey is representative

Peer reviewed

Table 4.2: Win conditions for stakeholders (Spiral 1)

purposes. Developers of components may use a specification standard as a guide to documenting their products, rather than having to decide what to include case by case.

Brokers may extend the template to include ratings and other evaluations done on site, as at Component Source².

When using the specification in industry, QA personnel need to have documentation of the specification to audit the conformance of data to the schema. From the academic perspective, the specification standard adds to the existing literature, as does the survey of existing specifications.

4.2 Spiral 1 Context

The background information utilised in the development of this specification template has come from four main areas:

• Resource description

• Data representation

• Software specification

• Component characterisation (functional and non-functional).

2http://www.componentsource.com/

CHAPTER 4. SPECIFYING COMPONENTS

According to the topic map introduced in Chapter1 (Figure 1.2), along with the goals for Spiral 1 (Table 4.1), it can be seen that areas used in this phase are central to the topic map, drawing on views from multiple disciplines. This Spiral captures and formulates a pathway of study using conclusions drawn from the review of literature (Chapter 2).

Resource description

A number of standards exist for providing information about electronic resources. These standards, along with existing schemata for software components, have been considered when developing the swvML schema. Although standards and implementation are usually closely tied, they can be considered independently.

Dublin Core is a standard developed to facilitate the discovery of electronic resources over the Internet. Development of Dublin Core began in 1995 and aimed for simplicity and to ensure an international consensus on its contents and structure. Many other standard templates are built upon Dublin Core, including AGLS³, EdNA⁴and IMS⁵ (see Table 4.3). Dublin Core fields referenced in these schemata are indicated by ‘DC’: fields with no equivalent are blank, otherwise the local schema name is given. In keeping with the idea of interoperability, the swvML schema uses many of the Dublin Core fields where their intention is similar to the requirements for component specification. This is mainly in the identification and contact sections of the component description.

Electronic resource description and metadata are most commonly held in XML doc-uments. The intention when developing XML was to provide a class of data objects to support content such as: ‘industry-specific markup, vendor-neutral data exchange, media-independent publishing, one-on-one marketing, workflow management in collab-orative authoring environments, and the processing of Web documents by intelligent clients. It is also expected to find use in certain metadata applications.’ (Cover, 2011).

According to Hunter (2003), XML is the ‘de facto standard for representing metadata descriptions of resources on the Internet’.

XML lends itself to sharing and reuse of templates, which can be utilised to build a schema as well as make it available for others to build upon. Investigation of XML Schema documentation led to examples of methods for implementing currency descriptions in

3Australian Government Locator Service http://www.agls.gov.au/

4Education Network Australia http://www.edna.edu.au/edna/go/resources/metadata/edna metadata profile

5IMS Global Learning Consortium http://www.imsproject.org/metadata/

4.2. SPIRAL 1 CONTEXT

Item Dublin Core AGLS EdNA IMS

Identification

Table 4.3: Comparison of selected attributes in schema standards. Text in a column indicates the name used for that attribute in the standard. ‘DC’ is listed where the standard uses the Dublin Core name and format for an attribute.

XML, and for implementing type libraries (XML). Both of these approaches were adopted in the swvML schema, for the pricing information and for the structure of the various levels in the schema specification.

Data representation

There are a number of different categories of attributes in the specification. Some are ordinal, where the values have an inherent order and can be compared (e.g. price, date).

Others are textual (e.g. company name) and do not lend themselves to manipulation or reasoning. When an attribute is text based and gives a long or short description, other text processing can be applied. This includes keyword searching and generation of ranking measures for relevance of the text to the given search terms.

Faceted classification of software was considered as a possible method for categorising the subject areas of individual components. The classification is developed on a number of categories, allowing for more useful information to assist application developers when searching for components (Prieto-Diaz, 1991). These categories can include the program

CHAPTER 4. SPECIFYING COMPONENTS

size and complexity, quality of documentation, programming language and ratings from users. Using faceted classification would have resulted in a single attribute encoding a number of component attributes. However, the complexity of creating a classification system, encoding and ordering was prohibitive. An alternative became available with the uptake and implementation of ontologies, making it possible to adopt existing clas-sification schemes. The reuse of an existing clasclas-sification scheme would align one of the goals of the project, and a survey of available knowledge bases is required to see if a suitable one is available.

Software specification

Recording specifications can be done with varying levels of formality. When an informal approach is used, ambiguity is more likely and it can be difficult to automate the under-standing and processing of information. With a more formal approach, the specification will be less ambiguous but there may be issues with readability and learning of the no-tation used. As the aim of the functional specification is to allow for automated test generation, a formal approach is needed. Options for automated test generation from specifications include semi-formal UML diagrams (Yoon et al, 1999), Z notation (Stocks and Carrington, 1993), Vienna Development Method (VDM) (Dick and Faivre, 1993), and others. Each of these can be represented in XML, while literature exists for test generation from each. Z notation has advantages in the standardisation of the language, active development of tools for its use and prior familiarity of those involved in this project.

Component characterisation

In the time this project has been in progress, software repositories have become common to the point of being part of the general population’s vocabulary (e.g. the Apple App-Store). Some of these specialise in components, and have characterised components with practical data models and XML, similar to the swvML schema. Another common aspect of describing components considers non-functional assessment or certification. Some in-house repositories use formal methods to describe components and aid searching and matching (Fidge, 2002, Rao and Sarma, 2003, Nakkrasae et al, 2004, Stylianou and An-dreou, 2007). These were used by the developers (during development) and are available