In this chapter, we aim to highlight how fuzzy logic can be a valid expressive tool to manage the software development process. We characterize a software development method in terms of two major components: artifact types and methodological rules. Classes, attributes, operations, and inheritance and part-of relations are examples of object-oriented artifact types. Each type is characterized by a set of properties whose values determine the membership of an artifact to other types.
The relation between the property values and the membership values is defined by the heuristics that are typically expressed informally using textual forms in a natural language. The causal order among artifacts identifies the software process. Especially in the early phases of the development process, property values correspond to software engineer’s perceptions [28, 29]. For instance, when defining a tentative class in object-oriented analysis, the software engineer is required to evaluate the relevance of an entity in the requirement specification. To automate
the software development process, we need a tool to express perceptions and reason on them. As claimed by L.A. Zadeh, fuzzy logic provides a unique foundation for a computational theory of perceptions: a theory which may have an important bearing on how humans make perception-based rational decisions in an environment of imprecision, uncertainty and partial truth . This is the typical environment which the software engineer has to cope with especially in the first phases of the development process.
We model properties of artifacts as linguistic variables and define the methodological heuristics in terms of fuzzy rules. Artifact types are represented as fuzzy categories. The application of each rule collects property values and infers a value of membership of an artifact to an artifact type. Artifacts can be instances of multiple (possible conflicting) artifact types at different extent. For instance, in objectoriented methods, an entity in the requirement specification can be considered slightly a class and strongly an attribute. These multiple design alternatives can be automatically and concurrently managed along the overall software development.
The membership of an artifact to an artifact type can be considered as a measure of the alternative: this measure is updated whenever a new property of the artifact type is investigated. When a product has to be released, appropriate conflict resolution strategies are applied.
Finally, we describe our CASE environment which, on the one hand, allows method engineers to define easily the methodological rules using their natural language and, on the other hand, guides software engineers to develop their software applications. The CASE environment is basically a fuzzy expert system: during the development process, the fuzzy inference engine decides the rules to be investigated and whether instances of artifact types can be created. A repository is associated with each artifact type and contains all the instances of the type. A same artifact
can belong to different types with different membership values. Following the sequence of instantiations is possible to trace the story of the artifact evolution.
Methodological rules are implemented as objects. This allows storing the evolution of an artifact using the same paradigm with which the artifact will be implemented, so as to improve software maintainability.
|Title of host publication
|Soft Computing in Software Engineering Series: Studies in Fuzziness and Soft Computing
|Ernesto Damiani, Lakhmi C. Jain, Mauro Madravio
|Place of Publication
|Number of pages
|Published - 17 Aug 2004
|software engineering series