An Empirical Study Using Z and UML for the Requirements Specification of an Information System Luiz Eduardo Galvão Martins
[email protected]
UNIMEP - Universidade Metodista de Piracicaba Abstract This article describes an empirical study where use cases and class diagrams (semi-formal modeling) and Z language (formal modeling) were used to make a requirements specification of an information system. The study presents some benefits of formal modeling for the quality improvement during the requirements specification of an information system. The empirical study was developed based on a real information system, which was a subset of a health plan information system. During the experiment we recognize the importance of a clear correspondence between these two modeling approaches (formal and semi-formal). This correspondence is discussed along the paper and the difficulties to get it are commented. Keywords System Modeling, Formal Modeling, Semi-Formal Modeling, Requirements Specification, Z, UML 1. Introduction The modeling of several aspects of a software system has become an important activity during the software development, mainly in the early phases when special attention is given to the requirements definition. Requirements usually are elicited, modeled, discussed and finally specified, in such a way that it is produced a document that specify in details what the software must do. This document is used as a guide for the next phases of software development. The most of software specification documents have specifications described in natural language and cognitive notations (semi-formal specification using diagrams), this second modality has been largely used by software development community. However, the semi-formal specification with diagrams, typically diagrams like ERD1, DFD2 and more recently UML3 diagrams [OMG01] frequently shows ambiguity and imprecision that can make mistakes in the software implementation. Several formal methods for software specification have been proposed in the last 20 years [Vie97], such methods offer precise notations and semantics for the software specification, in such a way that ambiguity and imprecision can be avoided, consequently decreasing the mistakes in the software implementation [Pot96]. However the formal methods have been used little within the software development community, compared with semi-formal methods. Some reasons for that are: (i) software developers have just a tiny contact with formal methods during their academic formation (undergraduate courses in computing); (ii) formal notations are difficult to understand at the first moment, because usually they require previous mathematics knowledge; and (iii) there are no "mature" software tools that generate effective 1
Entity-Relationship Diagram Data-Flow Diagram 3 Unified Modeling Language 2
source code for use during software implementation, keeping a gap between formal specification and program implementation. This article presents an empirical study in which a formal method (Z language) was used in a articulated way with a semi-formal technique (UML diagrams). These approaches were used to specify an information system for the management of a health plan system. This work intends to contribute to make formal methods more popular in the "everyday" software development, specially in the information systems segment [Sai97][Pal01]. The experiment put together formal and semi-formal specification approaches, which demonstrated that is possible and useful to use both approaches in the same software specification process. 2. Description of the Experiment The information system chosen was a subset of a health plan information system4. The goal of this subset was to manage the information about home care for the patients. This kind of treatment had 377 patients and 12 health professionals with 1,700 calls per month. The system's stakeholders were formed by three users, plus one section manager and two requirements engineers (one senior and one junior). 2.1 Semi-Formal Specification The software specification began with a semi-formal modeling of the information around the system in analysis. The information was obtained through several interviews with the people that worked with the information system (health professionals, clerks and section manager). Using the information obtained with the interviews the first model produced was the use case diagram. After the users had validated the initial requirements expressed by use case diagram, an application data model was built using the UML class diagram. The class diagram represents the distribution of the information present in the patient module5 of the information system. In this model the emphasize was on the data belonging to the patient module, without a concern for the distribution of operations around the classes, because the use case model was guiding the functional view of the initial modeling. After the class diagram was done, a validation process was conducted with the system's stakeholders. The semi-formal modeling could be understood by all stakeholders, allowing them to validate the documents produced without any problem. 2.2 Formal Specification The next step was to build the formal specification. This was done starting from the information captured in the semi-formal specification models (use case diagram and class diagram). The notation adopted by the formal modeling was Z language [Spi98][Mou01]. During this process the strategy adopted was: (1) to specify every class from the class diagram as a type in Z, using the schema notation (without the predicative part); (2) to specify every relationship between classes as functions or relations in Z; and (3) to specify every use case from the use case diagram as a schema in Z, showing in the predicative part of the schema the constraints and operations necessary for the effective work of the use cases. These steps are exemplified in Figures 1, 2 and 4 5
The health plan is called UNIMED, in Piracicaba -SP, Brasil. The information system was divided into three modules: patient, stock, and cost.
3. Figure 1 shows the class "patient" (paciente) specified as a type in Z. This class had several attributes that required the definition of additional types for the complete specification of the class, such as SEXO, DATA, FONE e ESTADO. These types also were used to specify attributes in other classes. Figure 2 shows all relationships presented in the class diagram, they were specified as relations in Z (most of them as functions).
Paciente Prontuário Nome Idade DataNascimento Sexo Endereço Bairro Cidade Estado T elefone Plano M édicoT itular T ipoPaciente CodUsuário
Figure 1 - Z specification of the "Patient class" ("classe Paciente").
Figure 2 - Z specification of the relationships presented in the class diagram. The relationship specification among the classes is an important aspect of the software modeling. During the experiment were identified correspondences between the relationship of classes in UML and the relationship of types in Z. Table 1 shows these correspondences. Figure 3 shows
the use cases "Including Patient" and "Scheduling Visit" specified as schemas in Z. This is an important articulation that can be done between use cases and formal specification in Z. The use cases were very useful for the initial specification of the software requirements, showing the functional requirements at a high level of abstraction [Coc00] making easy the communication among the system's stakeholders. But when it was necessary a detailed specification showing how the use cases would work, the requirements engineers needed to use more precise specification models, in such case a formal specification as Z was very useful, describing use case as schema and offering a more precise specification. Table 1 - Correspondences between relationships in Z and UML.
Relationships in the UML class Relationships in Z diagram Association 0..1 - 0..1 Partial Injection ( ) Association 1 - 0..1 Total Injection ( ) Association 0..1 - 1 Bijection ( ) Association 1 - 1 Bijection ( ) Association 0..n - 0..n Relation ( ) Association 1..n - 1..n Relation ( ) Association 0..n - 1..n Relation ( ) Association 0..1 - 1..n Partial Surjection ( ) Association 1 - 1..n Total Surjection ( ) Association 1 - 0..n Total Function ( ) Association 0..1 - 0..n Partial Function ( )
Figure 3 - Z specification of the use cases "Including Patient"(Cadastrar Paciente) and "Scheduling Visit" (Agendar Atendimento).
3. Discussion about the Results of the Empirical Study During the experiment the semi-formal modeling was the first approach adopted to model the information system. The diagrams produced were the first specification of the system, in a high abstraction level offering good conditions for communication among the stakeholders. After the semi-formal specification with the UML diagrams the next step was the formal modeling of the system. The document used as a groundwork to produce the Z types was the class diagram. The definition of the types in Z was the first part of the formal modeling of the information system. For each class from the class diagram a type in Z was created, every class had several attributes that required the definition of other types (the type STRING was an example of such situation). Because the classes represent data structure the correspondent types defined in Z were specified using the notion of schema that made easier the correspondence between UML classes and Z types. The next step was to specify the relationships among the classes formally. For such intention the concept of relation between sets was used, because Z offers good resources to model relations. For the "Patient Model" (Módulo Paciente) the following were identified: three relations, two bijections, one total function, one partial function, one partial injection, one total injection, one partial surjection and one total surjection (Figure 4). To find the correct correspondence between the relationship of classes in UML and relationship of types in Z was an activity that required a strong effort, because the requirements engineers were not so familiar with Z language and such correspondences were not so evident. Thus, the correspondence between these two relationships modeling approach, as presented in Tables 1 and 2, was very important to specify the relationships among the types in Z in a correct manner, that needed be equivalent to the classes modeling. The use cases express the functional requirements of a system. During the initial work with the requirements the use case diagram was very useful because it abstracted useless details at the first moment (during the requirement elicitation process), and this diagram could be easily understood by the users. However, after the functional requirements were elicited it was necessary to analyze them in a deeper way, exploring the relationships and dependencies among them and analyzing what data were relevant in the context of each requirement as well as their constraints. During the experiment the formal specification of the use cases brought important benefits helping to reach the desired refinement of the use cases. The precision of the formal modeling helped to identify new information about the requirements and brought a better view about them. The approach adopted was to specify use cases as schemas in Z. The declarative part allowed an effective view of the data necessary for the use cases working as well as the relationships among them. The declarative part helped to identify the pre-conditions and also allowed to specify the main operations inside the use cases. Several requirements mistakes could be identified and corrected after the formal specification with Z. As discussed above a clear correspondence between semi-formal and formal modeling techniques was necessary to articulate them in an effective way. During the experiment a correspondence was traced for several modeling elements from UML and Z (beyond the relationship correspondence cited before). Table 2 presents all correspondences identified during the experiment.
Table 2 - Correspondence between modeling elements of UML and Z
Modeling Elements from UML Class Object Object's attribute Association between classes
Use case Relationship of inclusion between use cases ("include" - UML stereotype) Object's operation
Modeling Elements from Z Type (defined using the notion of schema without the predicative part, just to define one data structure) Variable declared as a structured type (schema defined previously) Simple variable Relation or function, depending on the multiplicity among the objects represented by the classes (for details see Table 1) Schema Schema invocation Schema
Conclusion The experience reported has shown that for an initial requirements specification of system the semi-formal models are appropriate because they help to abstract unnecessary details for the early phase of requirements engineering facilitating the communication among the system's stakeholders and allowing that the requirements analysis process be fluent and productive. However, for the late phase of requirements engineering a detailed requirements specification is necessary and for such intention the semi-formal models are insufficient, because they don't have resources for a precise specification. This is the point where formal specification can be very useful and the empirical study reported in this article confirms such assertion. The requirements quality was improved with Z specification and consequently will contribute for the software development of the information system analyzed. At the end of the experiment we perceived that the following quality attributes of requirements specification were improved with formal specification: precision, completeness, correctness and non-ambiguity. Articulating the semiformal specification (UML) with the formal specification (Z) a better requirements specification document was obtained, because the models completed each other, building a robust documentation of what must be implemented in the software. Starting from this work we intend to explore other correspondences among the modeling elements of UML and Z, because the experiment put in evidence the importance of an articulated use of these software specification techniques. References [Coc00] [Mou01] [OMG01] [Pal01] [Pot96] [Sai97] [Spi98] [Vie97]
Cockburn, A., “Writing Effective Use Cases”, Addison-Weley, October/2000. Moura, A. V., “Especificações em Z: uma Introdução”, Editora da Unicamp, 2001. OMG – “Unified Modeling Language Specification”, Version 1.4, September/2001. Palshikar, G. K., “Applying Formal Specifications to Real-World Software Development”, IEEE Software, November/December 2001. Potter, B., Sinclair, J. and Till, D, “Introduction to Formal Specification and Z”, Prentice Hall, 1996. Saiedian, H., “Formal Methods in Information Systems Engineering” in Software Requirements Engineering, 2nd Edition, IEEE-CS Press, 1997. Spivey, J. M., “The Z Notation: A Reference Manual”, 2nd Edition Published 1998 by J. M. Spivey. http://spivey.oriel.ox.ac.uk/~mike/zrm/zrm.pdf. Vienneau, R., “A Review of Formal Methods” in Software Requirements Engineering, 2nd Edition, IEEE-CS Press, 1997.
