Metamorphosis: An Integrated Object Oriented Requirements Analysis and Specification Method

Transcription

1 Lancaster University Metamorphosis: An Integrated Object Oriented Requirements Analysis and Specification Method João Baptista da Silva Araújo Júnior M.Sc. (Hons) A thesis submitted for the degree of Doctor of Philosophy Department of Computing October

2 Abstract Despite all the advantages discussed by the requirements engineering community about the appropriateness of object oriented paradigm and formal methods for requirements specification, their large scale use by industry is still a utopia. The reasons for that are the immaturity of the object oriented paradigm, and the lack of guidelines to undertake formalisation. The aim of this thesis is to analyse the core concepts of object orientation and the integration of object oriented semiformal and formal methods in the requirements specification activity of the requirements engineering process. This thesis describes Metamorphosis, a formal object oriented method for analysis and specification. First, the method describes a unifying object oriented model, whose components are those widely accepted and adopted by the main current object oriented methods. These are enriched with new features to address issues which have been neglected by the current methods. The method incorporates an object oriented formal specification language (Object-Z - an object oriented extension of Z) whose purpose is to offer more precision to the specification. Furthermore, Metamorphosis defines how those two approaches are combined, providing a sound set of rules to transform from the object oriented semiformal representation into an object oriented formal framework. The transformation stage is the most important part of the method, and the reason for its name. The goal is to bestow more flexibility, reusability, modularity and reliability to the specifications, and to nourish both the employment of object orientation and formalisation by industry. Additionally, the method is designed to provide different levels of formalisation, conferring adaptability to the specification process. To make this practical, the Metamorphosis method provides a toolset, which supports both the modelling and the translation process. 2

3 Acknowledgements Many thanks to Dr. Peter Sawyer, my supervisor, for his impeccable supervision and inestimable support and guidance during the whole PhD course. Thanks to Prof. Ian Sommerville and Prof. David Budgen for the reading of this thesis and their suggestions. I would like also to thank Prof. Ian Sommerville for his support and interest in the development and integration of the group. Thanks to Dr. Gerald Kotonya, who has helped with his comments during the elaboration of this thesis. Thanks also to all the colleagues and staff of the department for making its atmosphere pleasant. Many thanks to all the friends that I have met during these years, particularly Célia, Cristina, Gertrud, Graça, Janda, Julian, Leena, Luisa, Otávia, Phillipe, Siew-Yee and Ramin for their dearest friendship. Finally, special thanks to Irini, Carlos, and my parents, for their inestimable support, and for keeping me motivated. 3

4 4 To my parents

5 Table of Contents Chapter 1 Introduction Requirements Engineering Principles Functional and Non-functional Requirements Requirements Changes State-of-the-Art in Requirements Engineering Objectives of the Work Structure of the Thesis...8 Chapter 2 Software Requirements Analysis and Specification Requirements Analysis and Specification Attributes of a Well-Written Requirements Specification Semiformal Requirements Analysis and Specification Approaches Function Oriented Approach Principles Methods Summary Data Structure Oriented Methods Principles Methods Summary Object Oriented Approach Principles Object Oriented Requirements Analysis and Object Oriented Design Advantages Pragmatics Difficulties Methods Booch Approach Rumbaugh et al Approach Coad and Yourdon Approach

6 Shlaer and Mellor Approach Other Approaches Summary of Object Oriented Analysis and Specification Methods Discussion Formalisation in Object Oriented Analysis and Specification Methods Summary...28 Chapter 3 Formal Methods and Their Integration with Informal and Semiformal Methods Formal Specification Principles Advantages Problems Formal Methods Sequential Property Based Sequential Model Based Specifying Concurrency Summary Object Oriented Formal Methods Classification Description and exemplification of the selected methods Discussion Summary Integration of Formal with Informal and Semiformal Methods Principles Advantages Methods Transitional Strategies Function Oriented Object Oriented Summary Summary...55 Chapter 4 Overview of Metamorphosis

7 4.1 Problems with Previous Work Overview of Metamorphosis The Architecture The Model The Formalisation The Tool Novel Aspects of the Research...61 Chapter 5 The Metamorphosis Method An Object Model for Object Oriented Requirements Analysis Structural Properties Classes Relationships Subsystems Behavioural Properties Object Behaviour Communication Process Sequences System Summary Derivation of Object-Z Framework Specifications Derivation of Structural Properties Classes Relationships Subsystems System Behavioural Properties Object Behaviour Communication and Process Sequences Conclusion Chapter 6 The Metamorphosis Toolset An Overview of the Toolset Windows Semiformal Specification Module System Structural Properties Classes

8 Relationships Subsystems Behavioural Properties Object Behaviour Formal Framework Generator Module Object-Z Components Framework Object-Z General Framework Implementation Issues Summary Chapter 7 Evaluation of Metamorphosis Summary of Metamorphosis Compared with Other Object Oriented Models Structural Properties Behavioural Properties Summary of Metamorphosis Compared With Other Integrated Object Oriented Methods Application of Metamorphosis - Case Study Semiformal Specification Structural Properties Class Association Aggregation Subsystem Dynamic Aspects Object Behaviour Object Communication Process Sequence Formal Framework Specification Structural Properties Class Association Aggregation Subsystem Dynamic Aspects Object Behaviour Process Sequence System

9 7.3.3 Refinement Notes on the Metamorphosis Toolset Summary Chapter 8 Conclusion Summary of the Objectives of the Work Novel Features Unifying Model Formalisation Mechanism Adaptability Limitations of Metamorphosis Further Work Method Tool Wider Issues Final Remarks References Appendix A Object Oriented Extensions of Z and VDM - Summary and Example A.1 Hyper-Z A.2 Z A.3 MooZ A.4 OOZE A.5 ZEST A.6 VDM Appendix B Proof of Temporal Logic Formula Appendix C Case Study: Partial Specification of the Metamorphosis Tool C.1 Semiformal Specification C.1.1 Structural Properties C Specification of Class Specification C Association Specifications C Aggregation Specifications C Subsystem Specifications

10 C.1.2 Behavioural Properties C Object Behaviour Specification C Object Communication Specification C Process Sequence Specification C.1.3 System Specification C.2 Formal Framework Generation C.2.1 Structural Properties C Object-Z Framework of Class Specification and Views C Association Object-Z Frameworks C Aggregation Object-Z Frameworks C Subsystem Object-Z Frameworks C.2.2 Behavioural Properties C Object Behaviour Object-Z Framework C Process Sequence Object-Z Framework C.2.3 System

11 List of Figures Figure 1.1 Requirements engineering activities...3 Figure 3.1 Axiomatic description for VECTOR...37 Figure 3.2 Schema for Edges...37 Figure 3.3 Schema for Parallelogram...37 Figure 3.4 Schema for Quadrilateral...38 Figure 3.5 Schema for Move...38 Figure 3.6 The class construct in Object-Z Figure 3.7 Class schema for Quadrilateral...40 Figure 3.8 Class schema for Parallelogram...40 Figure 3.9 Object diagram of Account Figure 3.10 Schema of Account...51 Figure 4.1 The Metamorphosis architecture...59 Figure 5.1 The Metamorphosis method in context...65 Figure 5.2 The Metamorphosis structural model for ATM System...67 Figure 5.3 Class template for Savings Account...68 Figure 5.4 Type template for Savings Account...69 Figure 5.5 Constraint template for Minimum Balance...70 Figure 5.6 Operation template for Get Balance...71 Figure 5.7 Constraint template for Valid Number...71 Figure 5.8 Constraint template for Initial...72 Figure 5.9 (a) Bank's view template on the class Savings Account...72 Figure 5.9 (b) Bank's view diagram on the class Savings Account...73 Figure 5.10 Association template for Cashcard Accesses Savings...74 Figure 5.11 Aggregation template for Consortium...75 Figure 5.12 (a) Subsystem template for Bank & Accounts...76 Figure 5.12 (b) Subsystem diagram for Bank & Accounts...76 Figure 5.13 (a) Subsystem view template for Accounts...77 Figure 5.13 (b) Subsystem view diagram for Accounts...77 Figure 5.14 (a) State transition diagram for Process Transaction...79 Figure 5.14 (b) State transition template for Process Transaction...79 Figure 5.15 (a) Communication diagram for Customer-ATM...81 Figure 5.15 (b) Communication template for Customer-ATM...81 Figure 5.16 (a) Process sequence diagram for Taking Cash...83 Figure 5.16 (b) Process sequence template for Taking Cash...83 Figure 5.17 System template for ATM System

12 Figure 5.18 Object-Z specification of the class Savings Account...86 Figure 5.19 Class schemas ClassPersistence and ClassConcurrency...88 Figure 5.20 State schema of SavingsAccount...90 Figure 5.21 Initial state schema of SavingsAccount...91 Figure 5.22 (a) Schema frameworks of CreditInterest and CreditInterestError...93 Figure 5.22 (b) Completed schemas of CreditInterest and CreditInterestError...93 Figure 5.23 Class schema framework of BankSavingsAccountView...94 Figure 5.24 Class schema framework of CashcardAccessesSavings...95 Figure 5.25 Class schema framework of ConsortiumAggregation...96 Figure 5.26 Class schema framework of Bank&Accounts...96 Figure 5.27 Class schema framework of Accounts...97 Figure 5.28 Generic schema framework of ExcSavingsAccount[X]...98 Figure 5.29 Class schema framework of ATMSystem...99 Figure 5.30 State schema framework of ProcessingTransactionObjBehaviour Figure 5.31 Initial state schema framework of ProcessingTransactionObjBehaviour Figure 5.32 Class schema framework of ProcessingTransactionObjectBehaviour Figure 5.33 Class schema framework of TakingCash Figure 6.1 The Metamorphosis toolset architecture Figure 6.2 Summary of the semiformal modelling process of using Metamorphosis Figure 6.3 Summary of the formalisation process of using Metamorphosis Figure 6.4 The toolset overview Figure 6.5 The Metamorphosis system window Figure 6.6 The System Specification window Figure 6.7 The Class Specification window Figure 6.8 The Class Template window Figure 6.9 (a) The Superclasses & Exc.Classes Specification window Figure 6.9 (b) The Superclass Visibility Specification window Figure 6.10 The Attribute Template window

13 Figure 6.11 The Type Specification window Figure 6.12 The Constraints Specification window Figure 6.13 The Constraint Template window Figure 6.14 The Operation Template window Figure 6.15 The View Template window Figure 6.16 The Association Template window Figure 6.17 The Participant Classes window Figure 6.18 The Aggregation Template window Figure 6.19 The Subsystem Template window Figure 6.20 The Subsystem Definition window Figure 6.21 The Subsystem View Template window Figure 6.22 The State Transition Template window Figure 6.23 The Object Communication Template window Figure 6.24 The Process Sequence Specification window Figure 6.25 The Process Sequence Template window Figure 6.26 The Class Formal Specification window Figure 6.27 The state schema framework window for SavingsAccount Figure 6.28 The class schema framework window for SavingsAccount Figure 6.29 Class schema framework window for TakingCash Figure 7.1 The Metamorphosis system Figure 7.2 The Class Template window for Class Specification Figure 7.3 Superclasses and Exc. Classes Specification window for Class Specification Figure 7.4 Attribute Template window for Class Specification Figure 7.5 Enumerated Types Specification window for Class Specification Figure 7.6 Constraint Template window for Valid Components Figure 7.7 Operation Template window for Specify Semiformal Components Figure 7.8 View Template window for Semiformal View Figure 7.9 Participant Classes Specification window for the Class Has State Transition Figure 7.10 Aggregation Template window for Subsystem Aggregation Figure 7.11 Subsystem Specification window for Structural Properties

14 Figure 7.12 Subsystem View Template window for Relationships Figure 7.13 State Transition Template window for Class Specification Figure 7.14 Object Communication Template window for Class- User Figure 7.15 Process Sequence Template window for Generating Formal Components Figure 7.16 Class Visibility List window for ClassSpecification Figure 7.17 Persistence and concurrency formalisation for ClassSpecification Figure 7.18 Free Types Definition window for ClassSpecification Figure 7.19 State schema framework window for ClassSpecification Figure 7.20 Initial state schema framework window for ClassSpecification Figure 7.21 (a) Operation schema framework window for SpecifySemiformalComponents Figure 7.21 (b) Exception schema framework window for SpecifySemiformalComponents Figure 7.22 Class schema framework window for SemiformalView Figure 7.23 State schema framework window for ClassHasObjectBehaviour Figure 7.24 State schema framework window for SubsystemAggregation Figure 7.25 State schema framework window for StructuralProperties Figure 7.26 Subsystem view schema window for Relationships Figure 7.27 History invariant framework window for ClassSpecificationObjectBehaviour Figure 7.28 Process sequence class schema framework window for GeneratingFormalComponents Figure 7.29 State schema framework window for Metamorphosis

15 List of Tables Table 3.1 Classification of methods Table 3.2 Comparison of formal object oriented methods...42 Table 5.1 Summary of the mapping of the modelling components into Object-Z...85 Table 7.1 Comparison of the methods structural properties Table 7.2 Comparison of the methods behavioural properties Table 7.3 Comparison with other integrated methods

16 Chapter 1 Introduction This work presents Metamorphosis, a formal object oriented requirements analysis and specification method. This method provides a new convergent model that integrates the main components found in the most popular object oriented models, and which provides a mechanism to generate a formal object oriented framework from the model, giving it more precision. This is the most important feature of Metamorphosis - the integration of object oriented and formal methods. The model is also enriched with some new features that give more semantics to the system modelling. A prototype tool has been developed to support the method. This chapter presents the context of the thesis. Afterwards, the objectives of the work are described. Finally, the structure of the thesis is drawn. 1.1 Requirements Engineering According to IEEE Standard Glossary of Software Engineering Terminology, software engineering has been defined as: the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software [IEEE90]. Its subactivity, software development, is the process by which user needs are translated into software requirements, requirements are transformed into design, design is implemented in code, and code is tested, documented and certified for use [IEEE90]. The term Software Engineering was created in 1968 by NATO (the North Atlantic Treaty Organisation), which organised a workshop to discuss the position and perspectives of software production. Thereafter, much work has been done and put into practice, with much attention being paid to analysis and design activities. The functional approach was 16

17 introduced and followed by the data structured approach with the object oriented paradigm becoming popular with the increasing complexity of the applications. In addition, the formal methods community advocates the effective integration of formalism into the development process. Requirements engineering is the phase of the software engineering process that defines the context of this work. More specifically, the part treated here is that part of requirements engineering concerned with software, that is, with software requirements engineering, rather than systems requirements engineering. The next section discusses the principles of the requirements engineering, followed by a description of the functional and non-functional requirements, and a configuration of requirements changes. Finally, the state-of-the-art of requirements engineering is discussed Principles A requirement is a need, a prerequisite for success or fulfilment of a system development. Requirements are precise assertions of need to bring understanding about a desired result [RO85] in the context of a software product. A requirement may be complex and must be broken into simpler requirements, usually through the process of decomposition. Requirements decomposition relies on the developer s skills to identify simple requirements within the more abstract requirements. For that, the developer needs to understand customer's application domain to derive requirements from this knowledge and the customer's statement of a need. Consider four definitions of requirements engineering: Requirements Engineering is a systematic approach to the development of requirements through an iterative process of analysing the problem, documenting the resulting requirements insights, and checking the accuracy of the understanding so gained [RO85]. Requirements Engineering is the systematic process of developing requirements through an iterative co-operative process of analysing the 17

18 problem documenting the resulting observations in a variety of representation formats and checking the accuracy of the understanding gained [Poh92]. Requirements Engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour, and to their evolution over time and across software families [Zav95]. Requirements engineering is the set of activities including (1) eliciting or learning about a problem that need a solution, and (2) specifying the external (black box) behaviour of a system that can solve the problem. The final product of requirements engineering is a requirements specification [Dav95]. These definitions reflect the main activities of the requirements engineering process, those being elicitation, specification and validation [Rze89, CK92]. These are started with a user need, for example, the need to implement an automatic teller machine system in a bank. Requirements elicitation consists of extracting requirements from several individual sources. It involves brainstorming, interviewing users and domain experts, with the aim of identifying all possible requirements of the problem s domain. Requirements specification consists of ensuring that the needs of all users are consistent and feasible, that is, ideas must be organised, conflicting views must be resolved and inconsistencies, incompletenesses, duplications and ambiguities must be discharged. Requirements validation consists of validating the requirements to derive an accurate reflection of the client and user needs. These activities generate a system model. This is a model of the application domain and not a design model. The requirements activities and the system model produce a requirements document that outlines the required external behaviour of the product. These activities are interconnected. The results of one may demand an iteration of another. For example, if during the analysis and specification activity it is found that there is a requirement missing, a return to the 18

19 elicitation activity is necessary. Figure 1.1 illustrates these activities, their interrelationships, their inputs and outputs. System Model User need Elicitation Analysis & Specification Requirements Document Req. Eng. Activities Validation Validation Design Figure 1.1 Requirements engineering activities. In particular, the work described in this thesis focuses on the requirements analysis and specification activity, which is discussed in detail in the next chapter Functional and Non-functional Requirements Requirements are frequently classified as functional or non-functional. Functional requirements describe in several ways what the system should do or what services it should provide. For example, if we have an art gallery system some of the functional requirements related to paintings could be procedures to catalogue a new painting according to its main attributes (school of painting (or style), title, artist s name, year of conclusion, description, etc.) or lend the painting to an exhibition. 19

20 Non-functional requirements can be defined as constraints on the services or functions offered by the system [Som96]. These requirements are realised through the description of conditions under which the system can operate. Roman [Rom85] presents a taxonomy for non-functional requirements, shown below. 1. Interface Constraints - These define the ways the component and its environment interact. They do not affect what the system does, but the way it does it. The syntax of the procedure invocation, the interrupt addresses, or the screen format are examples of interface constraints. 2. Performance Constraints - These comprise aspects of: Time/Space bounds: For example, response time, workload, and available storage space. Reliability: This is the ability of the software to respond concordantly in a user-acceptable way when subordinated to a certain environment [Dav93]. Security: This is related to threats and risks to privacy and is concerned with preventing malicious actions. This spreads physical considerations (emission standards) and logical issues (permissible information flows). Survivability: This is commonly associated with defence systems. For instance, mechanisms should be created to prevent loss in case of fire. Safety: This is a requirement that concerns about inadvertent actions against computer systems. This involves ensuring that the software will execute within a system context without resulting in 20

21 unacceptable risk (this must be defined considering political, moral and economical decisions) [Mar94]. Availability: This ensures that the resources of the system will be usable whenever they are needed by an authorised user. 3. Operation constraints - These include physical constraints (size, weight, power), personnel availability, skill level considerations, accessibility for maintenance, environmental conditions (temperature, radiation, humidity), spatial distribution of components, control, frequency and duration of the use of the system. 4. Life-cycle constraints - These include maintainability, enhanceability, portability, flexibility, reusability, development time limitations, resource availability, methodological standards. 5. Economic constraints - These consider immediate and long term costs. 6. Political constraints - These tackle policy and legal issues. A company s reluctance to use a competitor s device or its obligation to use a certain percentage of equipment from some foreign country are examples of political constraints. Non-functional requirements often tend to interact or to conflict with the functional requirements and with other non-functional requirements. Priorities must then be set to resolve the conflicts. It is important to separate functional and non-functional requirements. If this is not done it becomes more difficult to identify the correspondence between them and how to incorporate the non-functional requirements into the requirements process [JP94]. Notice that the requirements analysis and specification methods addressed by this thesis only apply to functional requirements. Very 21

22 few methods, for example, VORD [Kot93], explicitly model non-functional requirements to be modelled. 22

23 1.1.3 Requirements Changes Requirements can be classified as stable or changing. Stable requirements are requirements that do not change. They are also called Enduring Requirements [HED93]. They originate from the technical core upon which their business is based. Most systems analysis techniques depend on the enduring character of the central business to establish the core functionality required in future systems, for example, constructing buildings, treating patients, etc. Nevertheless, most requirements will probably change in the future. They can change according to needs of a particular user or customer in a given specification. Requirements can also change with time, people, markets, system use and evolution, government policies, legislation and new technologies. The one certainty in systems development appears to be the continuing uncertainty in the requirements. The requirements engineering process needs to be able to deal with changing requirements. Changes in requirements are expected during or after the analysis phase. It is important that the inevitability of change be recognised and anticipated when the documents of the requirements specification are being produced. These documents must be organised in such a way that the changes can be realised without too much effort, otherwise the maintenance will become unmanageable. Finally, methods and tools must support traceability so that when a design feature is changed, the requirements behind design feature are recoverable State-of-the-Art in Requirements Engineering There are three problem areas that would be faced by a requirements process in the development world [JP94]. A three-dimensional framework has been developed which addresses the major sources of problems in requirements engineering: 1. As a foundation for formal system development, requirements engineering moves along a representational dimension from informal to more formal representations, 23

24 ideally culminating in a formal specification that can be transformed into a program. 2. Another aim is to finish with an entire system specification. This is orthogonal to the previous problem because it is possible to mask poor understanding through complex formalism, and to describe an elaborated comprehension in informal terms. This dimension entails cognitive and psychological problems of requirements engineering. 3. The third dimension involves the social aspects of requirements engineering. This dimension is responsible for achieving the sufficient agreement on the specification to start building a system. This dimension has been investigated by social scientists. Requirements engineering, along with technical, cognitive and social problems, is also influenced by economic factors and the methods used. For example, the traditional requirements capture process starts with interviews, little system understanding and a complete informal representation; it should finish with agreement on a well-understood and formally described specification [Jar93]. However, before this can be achieved, a semiformal way of documenting requirements is needed. A semiformal model is the way of organising the analyst's understanding of the problem before transforming it into mathematical descriptions. Accurate problem domain knowledge, starting from a fuzzy initial idea to a precise specification, is critical to the success of a project [JP94]. Therefore, the concern here is on improving the representational dimension, and particularly in the transition between informal and formal representations. If software development was conducted with more precision, some of the errors frequently made (for example, duplicities, and omissions) would be avoided. However, this is still not a reality, needing more work as formal notations are still not properly integrated into the current requirements methods. Moreover, these methods do not provide sufficient facilities (rules, mechanisms) to transform informal to formal representations. 24

25 In summary, there seems to be a good chance of significant development for requirements engineering in the near future. However, it will not end up in a single formalism, but in a blending of intuitive or semiformal representations (graphical, multimedia) with formal representations. 1.2 Objectives of the Work This work addresses the major problem identified in the previous section. Its objective is to develop a method that provides a means to specify large systems semiformally and formally, and, crucially, integrate both the semiformal and formal aspects of the specification using the object oriented paradigm. Very little work has been done in the area and this approach introduces novel features. This method should contain the following aspects: 1. A unifying model - This model should have components to describe both the structural and behavioural properties of an application. Moreover, these components should be accepted among the requirements engineering community. 2. A formal notation - The importance of this formalisation is to give more precision to the specification. This notation should be powerful enough to represent the model components in a natural way. 3. A set of rules to transform semiformal into formal specifications - Rules should be provided to define exactly how to transform the semiformal specifications into formal specifications, facilitating, in this way, the formalisation process. 4. Flexibility of representation - The method should provide different levels of formalisation (semiformal, partially formal and formal). The most appropriate abstract level may be chosen depending on the application, the part of the application or the organisation restrictions. 25

26 5. A supporting tool - This toolset should provide support for the definition of the semiformal aspects of the system s specification and a mechanism to produce the framework for the formal specification of the system. 1.3 Structure of the Thesis The thesis is composed of eight chapters, three appendixes and references. The other seven chapters are summarised below. * Chapter 2 - Software Requirements Analysis and Specification. In this chapter, the main features of requirements specification, review the state-of-the-art of the semiformal techniques (function, data structure and object oriented approaches) are described. Finally, a summary of the chapter is presented. * Chapter 3 - Formal Methods and Their Integration with Informal and Semiformal Methods. This chapter reviews the state-of-the-art of the formal techniques. Afterwards, the main aspects of the integration between informal/semiformal and formal methods are depicted. Finally, a summary of the chapter is drawn. * Chapter 4 - Overview of Metamorphosis. This chapter summarises the problems with the previous work and shows an overview of the main features of the Metamorphosis method, including the semiformal model and the transformation mechanism. Finally, the novel aspects of the work are described. * Chapter 5 - The Metamorphosis Method. In this chapter, the Metamorphosis method is discussed in detail. Firstly, the descriptions of the semiformal model and its components are presented. Afterwards, the rules to convert the model components into 26

27 formal framework components are defined. Finally, a summary of the chapter is pictured. * Chapter 6 - The Metamorphosis Toolset. This chapter discusses the tool support integrated with Metamorphosis. The toolset is organised in two parts - one implements the semiformal model, and the other one derives this model into a formal framework. The two components of the toolset are presented with examples. Finally, implementation issues are discussed and a summary of the chapter is presented. * Chapter 7 - Evaluation of Metamorphosis. This chapter shows an evaluation of the method. First, the object model is compared to other object models. Second, the method is compared to other object oriented integrated methods. A case study is used to show the limitations and advantages of Metamorphosis. Finally, notes on the Metamorphosis toolset are presented and a summary of the chapter is drawn. * Chapter 8 - Conclusion. In this chapter, the objectives of the work are summarised, its novel features are presented, and the limitations of the method Metamorphosis are discussed. Moreover, further work is suggested. Finally, final remarks are presented. 27

28 Chapter 2 Software Requirements Analysis and Specification In this chapter, requirements analysis and specification are discussed in the context of requirements engineering. The function, data structure and object oriented approaches are then described. 2.1 Requirements Analysis and Specification Requirements analysis is the process of studying user needs to arrive at a definition of requirements in the form of a requirements specification. The requirements specification is a statement of what the system is expected to provide to users. Here, users embrace end-users, and, more generally, customers. This phase is the study of a problem before taking an action to solve it. Its aim is to identify, capture and organise key abstractions of the problem domain, and find mechanisms to examine that domain. The first step in establishing a specification of a system is to construct a conceptual model of the system that describes the entities of the real world that must be represented in the system. The conceptual model is the application domain as perceived by the users and the specifiers. It is incomplete if the environment with which the model components relate is not modelled. Without modelling the environment, it is unlikely that the requirements will reflect the actual user needs that the system must fulfil. The conceptual model is a common document with which users and the development team communicate. It enables the development team to have a better comprehension of the users needs. Moreover, it is used to validate the development team s understanding of the users problem 28

29 domain. It is a reference tool and it should be complete and consistent. Besides, it is a basis for design, prototyping, implementation and against which the design and implementation can be tested [Kun89]. During design, the conceptual model can be augmented, specifying as thoroughly as possible the semantics of the information being modelled. The conceptual model is described in the requirements documents. The requirements documents serve for both communication between users and developers, and documents specification (used also as the basis for contracts). The requirements document of a system should be easy for the analysts and for the users to understand. Furthermore, they must be organised in such a way that modifications can be made without extensive rewriting. Without this, the maintenance becomes difficult and it can result in inconsistency. Most methods which support requirements analysis use languages that are both textual and graphical because, in practice, it is difficult to express requirements using only text or only graphics. Automatic tools may be provided to consolidate the changes. Some typical problems introduced at this stage include omissions, contradictions, ambiguities, duplications, incorrectness, and irrelevant information in the identification of priorities. In addition, errors of comprehension are also common because users and analysts have different views of the role of the system in their environment. The most popular approaches to modelling systems are the functional and the more recent object oriented approaches. The former models the system through a set of interactive functions. The latter models the system through a set of interactive objects, which represent the entities comprising the system and encapsulate the operations that may be applied to those entities. These are examples of semiformal requirements methods and are explored in more detail in the next sections Attributes of a Well-Written Requirements Specification The key characteristics of a complete requirements specification document are listed below [Dav93]. 29

30 1. Correct: A requirements specification is correct if, and only if, every requirement represents something required of the system to be built. 2. Unambiguous: A requirements specification is unambiguous if, and only if, every requirement has only one interpretation. 3. Complete: A requirements specification is complete if everything that the software is supposed to do is included in the specification. 4. Verifiable: A requirements specification is verifiable if, and only if, every requirement is verifiable. A requirement is verifiable if, and only if, there is a process to check if software product meets the requirement. 5. Consistent: A requirements specification is consistent if, and only if, every requirement stated therein is not in conflict with other preceding documents, and no subset of requirements stated therein conflict. 6. Understandable by Customers: It must provide good communication and be well understood, because different groups must communicate among themselves. 7. Modifiable: A requirements specification is modifiable if its structure and style facilitate changes to the requirements completely and consistently. In other words, it must be easily modifiable to accommodate the changing nature of large scale systems. 8. Traced: A requirements specification is traced if the origin (earlier documents) of each of its requirements is clear. 30

31 9. Traceable: A requirements specification is traceable if it is written to facilitate the referencing of each individual requirement stated. 10. Design Independent: A requirements specification is design independent if it is not oriented to a specific software architecture or algorithm. 11. Annotated: A requirements specification is annotated if it provides guidance to the development organisation. 12. Concise: Simpler specifications are preferable to verbose ones. 13. Organised: A requirements specification is organised if its requirements are easy to locate. It must be noted that Davis concludes that a perfect software requirements specification does not exist. For example, if a complete specification is desired, the document becomes very large and difficult to read and loses conciseness. However, the requirements analysis and specification methods should be able to generate, at least, an acceptable requirements specification. Otherwise developers do not know what to construct, customers do not know what to expect and there is no means to validate the system [HDK93]. These methods should be design independent and provide structuring facilities to obtain more modifiable, traced, traceable, annotated and organised specifications. Additionally, they should have a notation that favours the communication with the customer. Moreover, they should integrate formal methods into the requirements process to obtain more correct, unambiguous, complete, verifiable and consistent specifications. Nevertheless, these two assertions are conflicting as formal specifications may not be the clearest way to communicate with the customer, for example, complex predicates are difficult to read. 2.2 Semiformal Requirements Analysis and Specification Approaches 31

32 Requirements analysis and specification methods can be informal, semiformal or formal [FKV94]. The informal techniques are characterised by the absence of a complete syntax definition to constrain the models that can be created. For instance, there are natural language and unstructured pictures. The semiformal techniques have defined syntax, but their semantics are not fully defined. For example, there are diagrammatic techniques like data flow and E/R diagrams. Finally, the formal techniques have rigorously defined syntax and semantics. For example, there are Petri-Nets, state machines and model based formal methods. Formal methods are described in detail in Chapter 3. Semiformal methods are mainly classified as function, data structure and object oriented. There are also other classifications such as event oriented and knowledge oriented [Kot93], but they have not yet proved to be as popular as the other approaches so they are not highlighted in this work. The function and data structure oriented approaches appeared during the 1970 s to improve the undisciplined practices of specifying systems. However, they exhibited limitations to the description of complex systems, inefficiency for system maintenance and restricted potential for reuse. Object orientation emerged to overcome these difficulties, enhancing the specification process. This work concentrates on the object oriented approach and its discussion follows the summary of the function and data structure oriented approaches Function Oriented Approach Principles In the function oriented approach, a system is modelled as functional transformations of a data flow. The aim is to obtain a system by mapping data flows and processes (or functions) onto software structures. In this approach, a system accepts an input, transforms this input, and produces outputs in a variety of forms. 32

33 Functional specification uses the divide and conquer approach, that is, the analyst decomposes the system showing its components in various levels of detail. The specification consists of a hierarchy of functions. The highest level of this hierarchy is the most abstract function. The lowest level consists of the least abstract functions. Functional specification mainly makes use of data flow diagrams, data dictionaries and process specifications. Data flow diagrams are the forte of structured (functional) analysis. They have few symbols, are learned rapidly and represent an efficient tool for interaction with the user. In general, data flow diagram symbols include transformations (or processes), data flows and data stores. Data dictionaries hold information of all data items that appear in the data stores and data flows. A process specification describes what happens in a process of a data flow diagram using decision tables and trees, and pseudo-code Methods Several structured analysis methods have been developed to assist the development of systems. Among the best known are SADT [Ros77], De Marco [DeM78], Yourdon and Constantine [YC79], Gane and Sarson [GS77], Cutts [Cut87], Peters [Pet88] approaches and Yourdon s Modern Structured Analysis [You89]. Other approaches extend the structured analysis concepts to allow the development of real-time systems, as it is the case of Mellor and Ward [MW85], and Hartley and Pirbhai [HP87] Summary The function oriented approach has been used successfully to specify many applications. It is suited to applications where the information is processed sequentially. For example, in applications of process controls and procedures of analysis of complex numbers [Pre87]. However, with the increasing complexity of applications, structured analysis methods have become insufficient to express this complexity because their topdown approach is too simplistic. Additionally, functional modifications can be hard to isolate and may require deep changes to the model as requirements evolve. 33

34 2.2.2 Data Structure Oriented Methods Principles The origins of the data structure oriented paradigm can be found in the technical discussions of the foundation of data structures in [Tre76] and [Hor78], and of data abstraction in [Gut77]. They have characteristics of both function and object oriented approaches. The data structure oriented methods represent the requirements of the system focusing on the data structure instead of the data flow. Data structure oriented methods present the static view of the data structures, whereas function oriented methods give a dynamic view of the data flow. The architecture of the system is derived from the specification of the architecture of the data. The implication of this approach is that data should be defined first and in detail. A consequence of it is that a change of the data structure normally determines a change of the program Methods The best known methods are those of Jackson (JSD - Jackson System Development) [Jac83] and of Warnier-Orr (DSSD - Data Structured Systems Development) [Orr77] Summary Although each method has distinct approaches and notations for the analysis phase, they share common characteristics [Pre87]: Each method helps the analyst in identifying key objects (or entities) and operations (or processes). Each method assumes that the structure of the information is hierarchical. Each method requires the data structure to be represented using sequence, selector and repetition constructors. 34

35 Each method provides a sequence of steps to map a hierarchical data structure onto a program structure. When these methods are applied to large systems they present the following deficiencies: Difficulty with the treatment of problems with multiple structures. Inability to represent non-hierarchical data structures. Inadequacy for database systems. Lack of means to verify the correctness and completeness of specifications [Pre87]. These restrictions limit severely the class of problems that this method can be applied to Object Oriented Approach Principles During recent years, the object oriented paradigm has become an important topic in computing research and its main concepts were popularised by the Smalltalk language. Object oriented analysis emerged basically from object oriented design to extend the paradigm to the beginning of software development as a way to keep its homogeneity. Shlaer and Mellor s method [SM88] was one of the pioneers of object oriented analysis. Some people consider JSD to be object oriented [Mar94]. However, the absence of the concepts of class and inheritance in its model prevents it from being classified as an object oriented method. Object oriented analysis is a method of analysis that investigates requirements from the viewpoint of objects, found in the informal description of the problem domain, and their interactions [Mar94]. The emphasis is on objects and the actions they can perform. 35

36 In software engineering, a method is object oriented if it supports the most popular concepts of this paradigm [Mey88, Weg90, Weg92, Boo91, Sny93, Rum91, Wir90]. These concepts include objects, classes, abstraction, relationship, inheritance, modularity, encapsulation, extensibility and reuse which are described below. Object: An object models an entity in the real world. It has a state, a behaviour and an identity. It is also an instance of a class. An object explicitly embodies an abstraction that is meaningful to its clients. Class: A class is a way of grouping all the objects that share the same set of attributes and operations. Classes enhance modelling power by describing behaviour explicitly and independently of its realisation in specific objects. Abstraction: Abstraction is the mechanism used in software engineering to deal with complexity considering only the essential aspects of the system. Abstraction appears at every level of a system. Higher level abstractions are implemented in terms of lower level abstractions. Relationship: An object by itself is not interesting. It is important that relationships among them be provided. It is not determined which relationships need to be provided in order for a method to be considered object oriented, but the kinds of relationships described below are largely used in system modelling since they are quite useful to capture the semantics of the system. * Classification: A kind of abstraction that an object collection is considered as a high level object class. Essentially, it represents the instance-of relationship. * Generalisation: A relationship between one class and one or more refined versions of it, called subclasses. The class being refined is called a superclass. With a 36