This study deals with a number of issues concerned with the derivation, use and interpretation of traditional software measures that are currently used as measures of program comprehensibility. One of the approaches that has been been suggested as a way of dealing with the software maintenance crisis is the use of software measures to assist in the management of software maintenance activities. The use of these measures has also been extended to the estimation of program comprehensibility - the level of effort needed to comprehend a program for maintenance purposes. In this thesis, it is argued that, despite the wide and continuous use of such program comprehensibility measures, they manifest a number of weaknesses that have been largely ignored despite their implications for both program comprehension and software maintenance activities. These concerns are inherent in the following characteristics of the measures: (i) inability to reflect the holistic nature of comprehension; (ii) insensitivity to the dynamic nature of the comprehension process, and (ill) insensitivity to software maintenance objectives. Furthermore, it is suggested that in order for these measures to become much more widely acceptable, valid and more representative of the phenomenon of program comprehension, these issues need to be addressed. This investigation talres the form of three studies. First, a survey of the literature and selection of measures currently used to estimate program comprehensibility. Second, a questionnaire survey of the impact of various factors on program comprehension. Finally, an observation and an experiment on programmers working on maintenance tasks, paying particular attention on the comprehension process and its outcome. The findings from these studies are discussed in the light of the weaknesses of traditional software measures as indicators of program comprehensibility. This thesis concludes by examining the wider implications of these findings and makes recommendations for further work in the area

No description available.

No description available.

Over the years the computing industry has enjoyed increasing levels of integration within the software which it employs: data integration; tool integration; human computer interface integration; etc. as well as the environment in which the software is used, ie. integration across a heterogeneous environment. In fact, it is the case that environments have been developed to further enhance the development of integrated software. 1bese are generally referred to as software development environments, or software factories. However, until recent years no comparable effort had been placed upon the achievement of similarly high levels of integration relating to the process by which that software is developed. Whilst environments offer the ability to share data, utilise the same tools, and present a common interface for using the tools, little regard had been given to how such integrated environments would be used by the members of the software development team in order to realise an integrated end product. It is now recognised that integration is required in the actual process of software development. Whilst software development methods such as SSADM and Yourdon go some way to achieve this, by specifying the tasks and activities required of a software development process, they are not sufficient to realise an integrated development process and hence an integrated end product. Achieving such integration within the process of developing software is the subject of the research reported in this thesis. Investigations into effecting Activity Integration, by which it is referred, reveal that current thinking is to model the activities of the software development process, providing an accurate representation of how the activities specified within that software development process would be carried out within a specific development environment. In doing so accurately depicting: tasks which depend on the completion of others; tasks which are independent of those around it; in addition to features such as iteration and selection. The product of this activity is generally referred to as a Software Process Model. Software process models have the capability of guiding members of a software development team through the activities of the software development process. It is thought that such guidance endows software process models with an advantage over existing techniques. Traditionally manuals are created to instruct developers in the use of a particular tool. Consequently in an environment consisting of many tools, many manuals are required. Additional guidance is required in the actual process of software development, method support. Again this is traditionally in the form of a manual, typically written for the purpose of instructing on all aspects of the complete method. In reality an organisation is likely to tailor the method of software development to meet the needs of an individual software development project. Accordingly what currently exists may be summed up as a 'ragbag' of manuals in addition to instructions on a general method. It is not surprising that activity integration is rarely achieved.In this work the analysis phase of the approach to software development advocated by SSADM will be represented as an informally specified software process model. To illustrate fully this modelling activity the environment is assumed to be one in which development takes place in a distributed fashion, necessitating modelling of the features inherent within such an environment, namely: sequence; selection; concurrency and iteration. Software process models will be shown to offer the capability of providing an accurate representation of how the activities of the analysis phase of SSADM may be executed within a distributed development environment. Furthermore, they will be shown to offer the flexibility to tailor a general method to meet the needs of a specific development project, in doing so providing the capability for the realisation of activity integration. However, this informal modelling technique will be shown to be inadequate for the realisation of activity integration. Although the resultant software process model is able to add considerable visibility and clarity to the 1Mb of the software development process, due to its informal nature it is not able to offer guarantees that the modelled process will be adhered to, a requirement for effecting activity integration. To overcome this issue, formal specification techniques are investigated. It will be shown that formal specification techniques, as a result of their rigorous, mathematical basis, when used to specify the 1Mb and activities of a software process model, are able to provide guarantees that the modelled process will be adhered to, and hence that activity integration will be realised. Furthermore, the ability to reason about a design and to prove properties of it, offered by formal techniques, enables guarantees to be made that the eventual implementation will be able to meet its intended aims.

No description available.

In recent years, natural language interface systems have been built based on the Front End and the Back End architecture which gives a guarantee of modularity and portability to the system as a whole. An Arabic Front End has been built that takes an input sentence, producing syntactic and semantic representations, which it maps into First Order Logic. Expressing the meaning of the user's question in terms of high level world concepts makes the natural language interface independent of the database structure. It is then easier to port the interface Front End to a database for a different domain. The syntactic treatments are based on Generalised Phrase Structure Grammar (GPSG) whereas the semantics are expressed in formal semantics theory. The focus is mainly to provide syntactic and semantic analyses for Arabic queries based on correct Arabic linguistic principles. The proposed treatments are proved and tested by building a prototype system. The prototype is implemented using one of the existing systems called Squirrel. An Arabic morphological analyser is also proposed and implemented to distinguish between two types of morphemes: internal morphemes which are a part of the word's pattern, and external morphemes which are independent words attached to the word but which are not part of the word's pattern. So, the system focuses on the extraction of morphemes from the various inflexions or forms of any Arabic word.

No description available.

No description available.

A major phase in the construction of Knowledge-Based Systems (KBSs) is the Knowledge Acquisition stage. It involves acquiring knowledge from experts, books, examples and from other relevant sources. Until recently, researchers assumed a simplistic view of knowledge which required it being 'extracted' or 'mined' from experts. It is now clear that this simplistic view ignored the rich epistemological, cognitive and perceptual basis of what we refer to as knowledge. This thesis set about to address this problem. It identifies domain analysis as an early stage in the knowledge acquisition process and argues that it should capture the expert's perception of the domain, rather than the knowledge engineer's view of the expert's perception. It puts forward the thesis that metaphors are invaluable cognitive devices for perceiving and articulating domains. This idea has been postulated by several other researchers but never, until now, tested. This thesis prescribes a novel method for exploiting metaphors for knowledge acquisition. The method is based on Black's interaction view of metaphors which has been merged with Kelly's personal construct psychology. We have implemented a tool, DAKUM, based on this new method and evaluated the usefulness of metaphors for knowledge acquisition. We conclude that metaphors are useful for constructing a domain's functions and structure. However, we note that metaphors are only useful, when describing Juzzy domains; their use in describing relatively organised domains could often lead to confusion. Metaphorically speaking, we conclude that using metaphors is analogous to using a walking stick. The latter is only useful when it is needed; otherwise its use is often a hindrance.

No description available.