Multiple Dimensions of Integrating Development ... - Semantic Scholar

Multiple Dimensions of Integrating Development Technology Betty H.C. Cheng Department of Computer Science and Engineering Michigan State University 3115 Engineering Building East Lansing, MI 48824 [email protected]

Abstract

Studies have shown that errors are most likely to be introduced in the requirements phase of a development eort. This problem is largely due to prose descriptions that are ambiguous or inconsistent. One potential solution to this problem is to capture requirements information in the form of formal speci cations that can be checked for consistency and completeness using automated techniques. However, during the initial phases of a project, it may be dicult to construct formal speci cations directly. In contrast, many developers nd it more intuitive to create diagrams to model their systems. As a means to bridge the gap between formal and informal approaches to software development, we have investigated the formalization of a commonly used object-oriented modeling notation, Object Modeling Technique (OMT). The formalization of OMT enables the automated generation of formal speci cations of the diagrams that can then be analyzed using simulation, model checking, and rewriting techniques. Lessons from this integration eort can assist in the development of strategies for integration techniques from the formal methods, fault tolerance, and security domains. One key factor to this type of collaboration will be the use of a speci c problem domain to focus the integration eorts. Another issue to be addressed is a common framework upon which the researchers from the three elds can build their integrated techniques.

1 Introduction It is clearly evident that the role of software is signi cantly increasing. Accordingly, the need to have high assurance in software's correctness increases for systems where correct operation is imperative. Recent studies have shown that the software quality problem is greatest during the This author is supported in part by NSF grants CDA-9700732,CDA-9617310, CCR-9633391, and DARPA grant No. F30602-96-1-0298, managed by Air Force's Rome Laboratories, and Eaton Corporation. 

1

early lifecycle phases of requirements and design, which can have a lasting impact on the reliability, cost, and safety of a system [1]. Also, requirements errors are between 10 and 100 times more costly to correct at later phases of the software lifecycle than at the requirements phase [2, 3, 4]. One approach to this problem is to document software requirements and design using a formal language; such a document is called a formal speci cation [5]. This approach is one of the basic elements of the software engineering disciplines referred to as formal methods. A formal method is characterized by a formal speci cation language and a set of rules governing the manipulation of expressions in that language [5]. While the advantages to using formal methods are signi cant, including the use of notations that are precise, veri able, and facilitate automated processing [5, 6, 7, 8], attempting to construct a formal speci cation directly from an informal, high-level requirements document can be challenging. Formal descriptions potentially involve considerable syntactic detail and require careful planning and organization on the part of the speci er in order to obtain modular speci cations. Minor changes in the natural language description, or the interpretation thereof, can require signi cant and tedious reorganization of the formal description. Using formal speci cation languages facilitates the early evaluation of a software design and veri cation of its implementation through the use of formal reasoning techniques [5, 6, 9, 8] or static analysis techniques [10, 11, 12]. A formal speci cation can be rigorously manipulated to allow the designer to assess the consistency, completeness, and robustness of a design before it is implemented. Each step in the development process can be supported by mathematical proof, thus reducing the number of errors due to misinterpretation and ambiguity. This type of approach is supported by many methods [6, 13, 14, 15, 16]. Currently, these methods presume the existence of a formal description of requirements. But, unfortunately, formal descriptions of requirements for large systems are not easy to obtain. Other approaches to requirements analysis and design include the numerous object-oriented 2

techniques [17, 18, 19, 20]. These \informal" methods enable the rapid construction of a system model using intuitive graphics and user-friendly languages. While such techniques have proved to be useful tools, the graphical notations used with these methods are often ambiguous, resulting in diagrams that are easily misinterpreted. In order to determine the correctness of systems developed with these informal approaches, complex validation procedures must be incorporated at every stage of development, and extensive testing methods must be used [21]. The lack of precise de nitions for the notations makes it dicult to combine this approach with rigorous, systematic software development methods. In order to take advantage of the bene ts of both approaches, there has been a general movement in the software engineering community towards integrating informal and formal techniques. Several bene ts motivate the integration, including the following items:    

Leverage existing technology, from both the informal and the formal languages. Leverage existing experience Gain bene ts from the integrated techniques Expand the user community

In short, the sum of the whole is greater than the sum of the individual parts. This paper gives a summary of a presentation that was given at the From Needs to Solutions Workshop, sponsored by the National Science Foundation and the Oce of Naval Research, held in

Williamsburg, Virginia in November 1998. The objective of the workshop was to bring researchers from academia and industry to discuss how their respective research areas could be integrated in order to address the correct development of critical systems. The three speci c elds that were brought together are: formal methods, fault tolerance, and security. The remainder of this paper is organized as follows. Section 2 gives background material on an approach to integration that we have developed for integrating OMT with formal speci cation languages. Section 3 describes the objectives of integration when applied to techniques from the three elds, formal methods, 3

fault tolerance, and security, and discusses dierent approaches to their integration. Tasks that are relevant to integrating techniques are discussed in Section 4. A summary and potential future investigations are presented in Section 5.

2 Background One commonly used object-oriented development approach, the Object Modeling Technique (OMT) [19], uses three types of models to express important domain-related concepts: object models, functional models, and dynamic models. Each model contributes to the understanding of a system, but the object model is of central importance. Those elements of a system that de ne its static structure are given by an object model using a notation similar to that used for entity-relationship diagrams. An object model determines the types of objects that can exist in the system and identi es allowable relationships among objects. As a result, the object model constrains the set of possible states that the system may enter. A dynamic model describes valid changes to system states and indicates the conditions under which a state change may occur. The notation used for dynamic models is a variation of Harel's Statechart notation [22] which, in turn, is an extension to the traditional notation for nite automata [23]. A functional model is a data ow diagram that describes the computations to be performed by the system. The main attractive feature of the OMT approach is that by using these three notations in a complementary manner, the system developer can express and re ne system requirements into a design and implementation. However, the lack of precise de nitions for the notations makes it dicult to combine this approach with rigorous, systematic software development methods. The original de nition for OMT [19] does not have a formal de nition of its syntax and semantics, thus preventing rigorous analysis of the modeling diagrams. For example, dierent aspects 4

of the software requirements are represented in the three dierent graphical languages mentioned above, but the concepts embedded in these diagrams are interrelated. The semantics of these three graphical notations must therefore be integrated in order to perform a rigorous analysis, but neither the syntax nor the semantics are rigorously de ned. Nevertheless, the OMT approach has been widely used because of its simple notation and its multiple views of software requirements, and it is fairly comprehensive in its (albeit informal) treatment of development issues. In previous investigations, we have developed a formalization of all three models of OMT, including a formal de nition of the integration of the three models. A speci cation depicts four aspects of a class: identity, interface, functionality, and behavior. Class name and essential attributes together contribute to the identity of classes and objects. Services describe the interface

of a class. Service speci cations delineate the functionalities that the services provide. Behavior speci cations, state names, and the starting state capture the behavior of a class. Except for the

algebraic speci cations that specify the properties of objects and the pre- and postconditions that are based upon the algebraic speci cations, all other components of the formal speci cations can be automatically generated from diagrammatic models according to our formalization rules. Figure 1 contains a high-level overview of the diagrams and their corresponding formal speci cations.

2.1 Multiple Dimensions of Integration In this particular project, integration was performed along multiple dimensions. First, we integrated informal and formal development techniques. OMT (and now its successor UML, the Uni ed Modeling Language [24]) has been a commonly used development technique among industry as well as in academic settings. Similarly, we identi ed commonly used speci cation languages that had similar semantics to the informal notations. Second, we integrated a number of formal techniques. When initially deciding on how to formal5

Dynamic Model

Functional Model

Formalization Rules

Object Model

Algebraic Specifications Objects as ADTs Process Algebras States as processes State transitions as process instantiations Algebraic and Predicate Specifications Data flows as sorts Services as operations Pre- and postconditions

Figure 1: An overview of the formalization rules

ize the OMT notations, we had several criteria for selecting the speci c target formal speci cation language, including reasonable size user community, easy to use, tool support, and how well the formal semantics matched the intended semantics of the informal notation. Given the complementary nature of the three OMT models, it was no surprise that it was more straightforward to identify dierent formal languages appropriate for each perspective. We started with the object model that lent itself to an algebraic formalization given its heavy emphasis on data abstractions and their interrelationships. The Larch Shared Language (LSL) was a good candidate given its support for modular speci cations and tool support, including syntax checker [25], Larch Prover [26], and graphical browsing and development environment [27, 28]. Next, we formalized the dynamic model. After looking at a number of speci cation languages, we identi ed the LOTOS process algebra as the target formal speci cation language. LOTOS has good support for representing states and events through processes and data transmitted on gates, dierent synchronization mechanisms, and integration with an algebraic data component (through the ACT ONE language). The support for integrating an algebraic component was important since a key part of our formalization (that 6

is, integrating informal and formal notations) was formalizing the integration between the three informal models. The nal piece was the formalization of the functional model, de ned in terms of data ow diagrams (DFDs). Because the DFDs depicted services of the objects, we needed a language that captured the observable behavior of the services. We selected a predicate logic-based approach since that provided the appropriate abstraction for the services. W e were able to use the Larch Interface Language (LIL) to represent this part of the formalization. We explored the LILs for C and C++, depending on the speci c application. The LIL approach worked well because it had a well-de ned integration with the algebraic component (LSL) that was used to formalize the object model, which in turn, was also integrated with the dynamic model through the process algebra component. In essence, we had developed a three-pronged approach to speci cation that combined algebraic (LSL and ACT ONE), process algebra (LOTOS), and predicate logic (LIL) speci cations. The third dimension of integration was in the area of tools. We were able to leverage the existing tools to assist in the development and re nement of the models and the corresponding speci cations. As mentioned previously, Larch has tool support for syntax checkers, theorem provers, and graphical browsers. LOTOS has tools for simulation, syntax and semantics analysis, and numerous state exploration techniques. In our investigations, we have found that many of the tools supporting formal methods have limitations, but they each also have their strengths. Through our integration eorts, we found that by using the dierent tools in a complementary fashion, we were able to overcome many of the shortcomings typically associated with analyzing formal speci cations. For example, simulation can be quite eective in validating behavior, but it is not necessarily good for nding the source of errors. In contrast, model checking is eective in returning a counter example if a constraint is not satis ed, but it can quickly run into the state explosion problem if it is asked to exhaustively explore the behavior of a system. In our tool integration eort [29, 30], 7

we have developed strategies for combining these kinds of techniques in order to perform high-level behavior validation, detection of syntactic and semantic errors, identi cation of source of errors, and the re nement of models to add design information.

3 Integration There are several dierent perspectives to consider when evaluating the bene ts gained from integrating informal and formal techniques. First, integration has immediate technical bene ts. Second, several bene ts exist from an economical standpoint. Finally, from a user's perspective, the resulting systems should be of better quality. By integrating techniques that each have merits on their own, the intent is that the combined use would give even greater bene ts. Informal methods are typically graphical in nature and easy to use, but it can also be easy for the developer to construct erroneous models since there is no systematic way to rigorously check the diagrams. In contrast, formal techniques are well-de ned and are amenable to automated analysis. Example analysis techniques that can be applied include simulation, syntax and semantics checking, and numerous constraint checking techniques, such as model checking, rewriting techniques, and theorem provers. Unfortunately, some formal methods may be dicult to use in that the formal speci cations may not be easy to construct from scratch. And modi cations to the speci cations may not be easy to eect. The integration of the two types of techniques will largely overcome the disadvantages to each approach and highlight the advantages. Formal speci cation techniques can enhance the application of informal techniques, by providing the means for rigorously analyzing properties that they informally represent. Rigorous analysis can uncover errors that are dicult to capture in reviews of informal models, which would otherwise allow errors to propagate to the later stages of development thereby increasing 8

the overall development costs. The analysis tools for the formal techniques enable developers to perform numerous types of analysis on the informal diagrams that would otherwise not be possible. Examples include intra- and inter-model consistency checking, speci cation veri cation and validation through the use of model checking and simulation techniques, behavior simulation, and rapid prototype development. From the development point of view, the formal techniques enable developers to explore rigorous and automated design re nement techniques, including code generation and test case generation. Formal techniques can reduce the burden currently placed on testing. From the economical point of view, several potential bene ts exist. \Integrated" techniques provide an evolutionary path to the use of formal speci cation techniques. There are user communities for both the informal and formal techniques. There are support tools for both types of methods. The integration enables the overall user community to increase, and the migration from a completely informal approach to one that is supported by formal techniques is supported by the existing tools. From management's point of view, the development team is not abandoning a known technology, rather, they are enhancing its capabilities. In addition, the cost savings that can be obtained by being able to rigorously check requirements and designs before a system is implemented, tested, or deployed to the eld will be signi cant, thus further motivating the integrative approach. The integration of informal and formal techniques also facilitates customer and developer interaction when dealing with requirements. The graphical models are easier for the customers to understand, and the simulation capabilities aorded by the formalization techniques enable developers to simulate the behavior of the requirements for validation purposes. In terms of the Laprie's Dependability tree (depicted in Figure 3), integrating informal and formal techniques enables us to address the attributes safety, con dentiality, and integrity. The means to address these attributes is through fault prevention and fault tolerance. The threats that are addressed by this approach are typically due to requirements and design errors. 9

Availability Reliability Attributes

Safety* Confidentiality* Integrity* Maintainability Fault Prevention*

Dependability

Fault Tolerance*

Means

Fault Forecasting Fault Removal

Faults Threats

Errors* Failure

* Denotes those items relevant to the integration of informal and formal development techniques

Figure 2: Laprie's Dependability Tree

10

4 General Integration Tasks This paper has thus far focused on how informal and formal techniques can be integrated, as well as the bene ts of their integration. For the purposes of the workshop, we can draw upon lessons learned from this type of integration when attempting to integrate analysis and development techniques from the three focus areas of the workshop: formal methods, fault tolerance, and security.

4.1 Domain Analysis and Engineering First, it is important to recognize that in order to make a signi cant impact with a speci c type of development technique, particularly one involving automated techniques, it is useful to perform a thorough domain analysis. The domain analysis enables us to identify the key development needs and constraints for a particular application domain. For example, in the embedded systems domain, we would need to identify development techniques that had strong support for capturing state-based modeling. In contrast, an information-management system would require a development technique that has good support for representing complex data abstractions. During this assessment, it should be noted as to what types of veri cation and validation tasks will be needed. Is behavior simulation more important than being able to establish de nitively the satisfaction of speci c properties, such as constraint checks, consistency checks, safety, fairness, liveness, and absence of deadlock. What fault-tolerance properties need to be checked? Which of the dependability attributes need to be evaluated? What is the objective for development and maintenance (i.e., fault prevention, tolerance, forecasting, or removal)? What are the threats to be considered? (see Figure 3). Based on this assessment, then we can proceed to make a formal methods evaluation. What types of formal methods will support the analysis needs? What tool support is available to support these types of analysis techniques? 11

4.2 Common Framework Before we can integrate analysis and development techniques from the three focus areas, we need to establish a universally recognized vocabulary and identify common areas of interest. In short, we need to develop a common framework. The Dependability tree can be used as a vehicle for determining universally understood vocabulary and identifying common goals. The common framework will facilitate communication between researchers from the dierent areas, as well as ensure that we are interacting with the customers in a consistent fashion.

4.3 Industrial-Strength Applications Another key task in the integration process is to identify a speci c application area as a target for the integration eorts. A speci c problem (area) can guide what will populate the common framework. For example, researchers can identify what speci c properties need to be speci ed and established for the area of electronic commerce, where it is clear that eort is needed from all three areas. Based on this assessment, appropriate analysis techniques and tools can be acquired and/or developed to be used within the framework. A speci c problem gives researchers real problem parameters to instantiate their respective analysis and development techniques/tools. In addition, a real problem gives researchers realistic constraints and demands that need to be handled in order to ensure that the techniques are feasible and scalable. By focusing the integrative eorts on a speci c problem, the researchers will have a tangible result to demonstrate the utility of their combined techniques. The common framework should serve as an evolving testbed for the integrative research activities. As results are obtained, the common framework can evolve to support re ned and/or additional techniques, handle more properties, provide dierent types of feedback, and so on.

12

4.4 Integration Strategy It is not practical to assume that researchers from all three communities will be able to instantaneously start working together and somehow make signi cant progress without some intermediate steps. For example, a pairwise approach to integration might be more feasible to determine if a common framework can be established between two areas. In many cases, eorts along these lines are already underway, such as formal methods and security and between formal methods and faulttolerance. A common application domain can be used to focus these pairwise integration activities. The results will facilitate an overall integration eort among the researchers. The common framework that supports all three areas should be validated by using the same analysis and development techniques applied to a dierent problem domain. Therefore, if the initial common framework was developed according to the speci cs of an electronic commerce domain, then attempting to apply the framework to a Command and Control system would force the researchers to handle potentially much more complex control logic issues, whereas applying the common framework to critical information systems, such as patient medical records, might require more complex data processing capabilities. The validation eort will guide the researchers to re ne the integrated techniques.

5 Summary In the past twenty- ve years, there has been signi cant research conducted in the areas of formal methods, fault tolerance, and security. Unfortunately, the majority of the software development workforce do not use nor are they familiar with much of the work that has been done in these areas. While many application domains are not critical, that is they are not life-threatening, the exponentially increasing demand for software has forced new interest in these three areas, individually and collectively. 13

This paper has reviewed a research project that has integrated informal and formal development techniques in an eort to facilitate the use of formal techniques by a larger community. The results of this type of research can be integrated with research in all three areas to generally increase the use of techniques from these areas. The Laprie Dependability Tree can be used to focus the integrative research activities. Identifying common problem domains of interest can be a driving force for the integrative as well as the individual research directions. The meeting has highlighted the need for integration, synthesis, and experimental research. Perhaps the Y2K issue has heightened our awareness of the potential impact of ad hoc approaches to software development. While there will continue to be a demand for \basic research", it is clear that in the areas of formal methods, security, and fault tolerance, there are exceedingly strong motivations to join eorts to address common problems and develop real solutions.

References [1] R. R. Lutz, \Targeting safety-related errors during software requirements analysis," in SIGSOFT'93 Symposium on the Foundations of Software Engineering, 1993. [2] J. C. Kelly, J. S. Sherif, and J. Hops, \An analysis of defect densities found during software inspections," Journal of Systems Software, vol. 17, pp. 111{117, 1992. [3] V. Basili and B. Perricone, \Software errors and complexity: an empirical investigation," Communications of the ACM, vol. 21, pp. 42{52, January 1984. [4] B. Boehm, \Software engineering economics," IEEE Transations on Software Engineering, vol. SE-10, pp. 4{21, January 1984. [5] J. M. Wing, \A Speci er's Introduction to Formal Methods," IEEE Computer, vol. 23, pp. 8{ 24, September 1990. [6] B. H. C. Cheng, \Synthesis of Procedural Abstractions from Formal Speci cations," in Proc. of COMPSAC'91, pp. 149{154, September 1991. [7] B. H. C. Cheng, \Applying formal methods in automated software development," Journal of Computer and Software Engineering, vol. 2, no. 2, pp. 137{164, 1994. [8] J. Rushby, \Formal methods and the certi cation of critical systems," Technical Report SRICSL-93-07, SRI International, Computer Science Laboratory, 333 Ravenswood Ave., Menlo Park, CA 94025-3493, November 1993. Available via anonymous ftp from ftp.csl.sri.com. 14

[9] B. H. C. Cheng, \Automated Synthesis of Data Abstractions," in Proc. of Irvine Software Symposium, pp. 161{176, June 1991. [10] M. P. Heimdahl and N. Leveson, \Completeness and Consistency Analysis of State-Based Requirements," in Proceedings of the 17th International Conference on Software Engineering, Apr. 1995. [11] C. L. Heitmeyer, B. L. Labaw, and D. Kiskis, \Consistency checking of SCR-style requirements speci cations," in Proceedings of the International Symposium on Requirements Engineering, March 1995. [12] J. Atlee and J. Gannon, \State-based model checking of event-driven system requirements," in Proceedings of the ACM SIGSOFT '91 Conference on Software for Critical Systems. Software Engineering Notes. Volume 16 Number 5, 1991. [13] C. B. Jones, Systematic Software Development Using VDM. Prentice Hall International Series in Computer Science, Prentice Hall International (UK) Ltd., second ed., 1990. [14] E. W. Dijkstra, A Discipline of Programming. Englewood Clis, New Jersey: Prentice Hall, 1976. [15] D. Gries, The Science of Programming. Springer-Verlag, 1981. [16] D. R. Smith, \KIDS: A Semi-automatic Program Development System," IEEE Transactions on Software Engineering, vol. 16, pp. 1024{1043, September 1990. [17] P. Coad and E. Yourdon, Object-Oriented Analysis. Englewood, New Jersey: Yourdon Press, Prentice Hall, 1990. [18] R. Wirfs-Brock, B. Wilkerson, and L. Wiener, Designing Object-Oriented Software. Englewood, New Jersey: Prentice Hall, 1990. [19] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-Oriented Modeling and Design. Englewood Clis, New Jersey: Prentice Hall, 1991. [20] D. Coleman, P. Arnold, S. Bodo, C. Dollin, H. Gilchrist, F. Hayes, and P. Jeremaes, ObjectOriented Development: The Fusion Method. Object-Oriented Series, Prentice Hall, 1993. [21] R. S. Pressman, Software Engineering: A Practitioner's Approach. McGraw Hill, third ed., 1992. [22] D. Harel, \Statecharts: A visual formalism for complex systems," Science of Computer Programming, vol. 8, pp. 231{274, 1987. [23] J. E. Hopcroft and J. D. Ullman, Introduction to Automata Theory, Languages and Computation. Addison-Wesley Publishing Company, Inc., 1979. [24] Rational Software Corporation, Santa Clara, CA 95051-0951, UML Semantics, 1.0 ed., January 1997. [25] J. Horning and J. Guttag, \Larch shared language checker." Private communication. [26] S. Garland and J. Guttag, \A guide to lp, the larch prover," Technical Report TR 82, DEC SRC, December 1991. 15

[27] M. R. Laux, R. H. Bourdeau, and B. H. C. Cheng, \An integrated development environment for formal speci cations," in Proc. of International Conference on Software Engineering and Knowledge Engineering, (San Francisco, California), pp. 681{688, July 1993. [28] M. Morin and B. H. C. Cheng, \Graphical Development Environment for Larch Shared and Interface Languages," Technical Report CPS-94-18, Michigan State University, Department of Computer Science, A714 Wells Hall, East Lansing, MI 48824-1027, April 1994. [29] W. E. McUmber and B. H. Cheng, \UML-based analysis of embedded systems using a mapping to VHDL," Tech. Rep. MSU-CPS-99-11, Department of Computer Science and Engineering, Michigan State University, East Lansing, Michigan, February 99. [30] L. Campbell, B. H. Cheng, and E. Y. Wang, \Enabling automated analysis through the formalization of object-oriented modeling diagrams," Tech. Rep. MSU-CPS-99-13, Department of Computer Science and Engineering, Michigan State University, East Lansing, Michigan, March 99.

16