LA COMUNA DE OYAMBARILLO Relaciones entre la ciudad y las comunidades

• The domain layer directly reflects the concept structure required in a meta model.

Concepts, properties and relationships are important constructs in modelling products of a method. Apart from adjustment of terminology, such as a structure may refer to a

fragment (a group of correlated concepts), the relationships between concepts are loosely defined. The properties of relationships, such as roles and cardinalities must also be defined specifically.

• The inference layer gives significant ideas about modelling activities. The knowledge source denotes operations in the process and the meta-classes describes the pre- and post­ conditions of the operation. However, it is found that the process of a method should lie between the inference layer and task layer, which respectively define the functional and control viewpoints of knowledge engineering. Therefore there is a direct connection from concepts as products to tasks as processes. Furthermore, the task decomposition (hierarchical task structure) in the KADS approach is not flexible enough to denote the creativity of software engineering that include iterative, recursive development processes. • The strategic layer concerns the problem analysis in method evaluation. This is not the

emphasis of this research, but is discussed as speculated work in chapter twelve.

• The knowledge acquisition of KADS involves three main activities: eliciting the knowledge in a formal (usually verbal) form, interpreting the elicited data using some conceptual framework, and formalising the conceptualisations in such a way that the program can use the knowledge. The activities require the direct involvement of domain expert(s), such as in structured interviews. In method engineering, this is found to be impractical, since it is difficult to identify ‘method experts’ apart from the ‘method founders’ themselves. In addition, interviewing software developers seems to be an ineffective way of method knowledge transfer due to the inclination towards their problem domain and/or work environment. Chapter ten addresses this issue by introducing a different set of method acquisition media and elicitation techniques.

From the description above, KADS is a KBS ‘development method’ rather than a set of conceptual ideas or techniques (refer to section 2.1). It is comprised of extensive method concepts, design activities and heuristic guidance. KADS also supports comprehensive graphical and textual notations, with the potential of developing automated CASE tools to manage and manipulate the compiled Prolog clauses. Besides, some database management systems (DBMS) have also started to provide development methods: the InfoDesigner tool is available for supporting Microsoft Access database development [Perschke 93]. Nevertheless, the main concern of this research is on software development methods rather than methods in general. Most other development methods are either poorly documented or too immature to discuss systematically, so they are left as future works for a wider scope of method investigation. Hereafter the term ‘method’ refers to ‘software development method’.

2.6 SUMMARY OF INVESTIGATION

From the investigation of software development methods, the following points are noted: • All methods incline towards a certain aspect of software development, such as functional

decomposition by levelled-DFDs (such as DeMarco SA, JSD) and abstract data types in most object-oriented methods (Booch OOD and OMT). Some methods focus upon message passing (OOA and OMT), some emphasise task structuring (Codarts/DA) and some process engineering (Ptech). There are even methods based upon a particular programming language (HOOD and Adarts for Ada development). In terms of modelling, some methods denote the structural view (CRC, OOA), some indicate the behavioural view (OMT, HOOD) and some only the functional view (JSD). No single method is perfect for all software purposes or even ideal for a particular application. Therefore, the best solution is to provide method integration and support multiple viewpoints on the problem domain. In addition, the advantages of a generic model for method evaluation and comparison are promoted (OOSE). These are the main aims of method engineering. • Each method has its own set of terminology. A single term may differ in various methods

and different terms may imply the same thing in a single method. For instance, object and

object-oriented have multiple meanings across methods (Booch OOD, HOOD and Ptech), whereas operation, function, procedure, service, process, method may be used interchangeably in a method (Booch OOD). This problem also occurs in the meta level, for example heuristics may be referred to as criteria (Codarts/DA), guidance (OMT) or

design rules (HOOD), whereas notation may be used to decribe a symbol (OMT), a method (OOSA) or a fragment (Fusion). This problem is addressed for the method level in chapter eight (method representation); and for meta level this thesis provides a glossary (appendix A) with definitions of the terms used.

• The presentation techniques in the methods provide significant points about meta modelling, for instance using DDL-like language in structuring concepts (KADS); using pre- and post- conditions in structuring tasks (SSADM); and using definitive clauses in structuring guidance (OOA). These techniques give important strategies in representing semantics of a method; they should be incorporated in the generic model.

• During the method description the three main components in the meta model, namely product, process and heuristic, can be induced. Product describes the method concepts or

what the notions are; process describes the method tasks or when to apply the notions, whereas heuristic describes the method guidance or how to deal with the notions. Each method can be identified by these three components, although some methods are strong in one aspect and weak in the others. The three components combine together to form method semantics as a whole. The ideas of these components will become clearer as each of them are described separately, later in this thesis (chapters five to seven).

• The investigation also helps to identify the scope of this research by defining ‘software development method’ (section 2.5.4) and the chosen methods (section 2.4). Moreover, it addresses the existence and importance of meta modelling (section 2.5.2 and 2.5.3). This point is discussed further in next chapter - investigation of method integration, meta modelling techniques and metaCASE tools.

2.7 CONCLUSION

This chapter investigated eighteen software development methods by classifying them into four categories: structured methods, object-oriented methods, chosen methods and other methods. The key notions of each method are described and comments are made from the meta modelling viewpoint. An overview and significant points are especially presented for five chosen methods. Some notable points are shown as a summary of the investigation. The chapter also identifies the focal point of this research.

3. INVESTIGATION OF METHOD