Formalizing UML for Rigorous Software Development

Formalizing UML for Rigorous Software Development

D. Muthiayen

V.S. Alagar

Department of Computer Science

Concordia University

Montr´eal, Qu´ebec H3G 1M8, Canada

Phone: +1 (514) 848-3022

f

d muthi, alagar

@cs.concordia.ca

Abstract

Formalizing a modeling technique broaches issues including development of software specification, design, analysis, and synthesis. Software engineering methodologies should be grounded on rigorous principles and not on ad hoc approaches. Our approach is to integrate the recently published industrial standard graphic notation UML (Unified Modeling Language), for object-oriented modeling, and PVS (Prototype Verification System), for automated reasoning.

1

Introduction

This paper is an account of exploratory work on formalizing UML [3, 4], and embedding the notation in PVS [2]. We develop methods for consistency checking across design specifications and for verifying system properties in a design. The formalization of UML is undertaken to fulfill the need for a sound foundation for requirements modeling and rigorous design analysis in the context of safety-critical systems. The methodology provides a basis for the process model shown in Figure 1. In this iterative process, we develop a UML model from system requirements, translate the graphical design into PVS theories, analyze the design for consistency, simulate design specifications for validation, and verify desired system properties in the design, before proceeding to an implementation. The motivation for this work comes from two fronts:

 the wide acceptance of UML in industry, as a unified notation applicable to the development of objects

in a broad spectrum of domains, and

 the use of PVS for design analysis in industrial scale applications.

2

Research Directions

The primary goal of our research is to develop a methodology for rigorous software development. It is groundwork for a specification environment for modeling and analysis of objects and subsystems, and a ver-ification environment for provable deductions that design specver-ifications satisfy desired properties. Figure 2 shows aspects of the methodology. Formalizing the modeling technique involves the following steps.



Consistency Analysis Checking / Rose 98 UML Model Formal Verification Generation / Rational PVS Animation Tool Validation Code Formalization Specifications PVS Implementation Incompleteness Incorrect Design Debug / Redesign Inconsistency Augment Model Fix Time Constraints

Figure 1: Process Model for UML-based Software Development.

1. Select components of UML notation suitable for requirements specification. 2. Relate the components in a consistent way to fit in a formalism.

3. Provide formal semantics for the components and their relationships.

4. Develop a formalism incorporating the components for modeling objects and subsystems. 5. Institute mechanisms for checking design completeness and consistency.

The following steps are milestones in defining UML formal semantics.

1. Specify PVS type definitions for UML model elements, based on the abstract syntax available in UML class diagrams.

2. Specify PVS predicates and lemmas for

(a) constraints and well-formedness rules on UML model elements, available in OCL (Object Con-straint Language),

(b) UML semantics, available in natural language, and (c) relationships among components of UML notation.

3

Formalization Methodology

Our primary goal is to provide precise methods based on formal semantics to translate UML design models into PVS theories for rigorous analysis.

3.1

Subset of UML Notation

Translation UML-PVS

Formal Verification Design Validation

UML Model Modeling Specifying System Properties Requirements PVS Theories for Properties System PVS Design Theories Semantics in PVS System Static Structure Diagrams Use Diagrams Case Static Model Dynamic Model Statechart Diagrams Sequence Diagrams Collaboration Diagrams UML

Figure 2: Aspects of the Software Development Methodology.

 Static structure diagrams - object and class diagrams capture relationships between entities.  Use case diagrams - use cases abstract tasks; actors symbolize roles played by external objects.  Sequence diagrams - a sequence diagram captures sequences of messages exchanged in an interaction.  Collaboration diagrams - a collaboration describes associations among cooperating objects; messages

exchanged among the objects constitute an interaction that is superimposed on the collaboration.

 Statechart diagrams - a statechart diagram specifies the states of an object, transitions, and events.

3.2

PVS Specification and Verification Environment

The demand prevails on constructing provably correct systems in strategic areas, such as aerospace and NASA projects. The current status of formal method integration in industrial software development in-cludes application in areas such as avionics, telecommunications, and nuclear power plants. PVS is being groomed for use in the development process of mission critical systems. Experience gained from these stud-ies are compiled in two NASA guidebooks. PVS consists of a specification language based on higher-order logic, and an interactive proof checker using powerful arithmetic decision procedures. The language suits the requirements of a notation in which well-formedness rules, invariants, and constraints can be precisely specified. UML semantics described in PVS specification language serves the purpose for both a communi-cation mechanism allowing precise descriptions, and a proof mechanism supporting behavioral analysis.

3.3

Methodology for Formalizing UML Notation

Asynchronous Waiting Timed Balking Synchronization Pattern: Call Arrival Pattern: Periodic Episodic Flat

Predictable arrival time

Unpredictable arrival time

Flat flow of control

Procedure call or other nested flow of control Asynchronous flow of control

Synchronous Rendezvous Timeout Rendezvous Balking Rendezvous

Figure 3: UML Icons for Kinds of Message Flow.

3.3.1 Mapping UML Notation onto PVS Constructs

We adopt the following procedure in providing a formal semantics for UML notation.

1. Identify UML model elements described in UML class diagrams comprising metaclasses and their relationships.

2. Specify each model element in PVS using uninterpreted, tuple, and record type definitions. We flatten the class hierarchy to obtain all the attributes of a model element.

3. For each well-formedness rule of a model element, we formulate invariants and constraints on the model element as lemmas.

4. Translate the informal description of the semantics for each UML construct into PVS lemmas. 5. Specify relationships and constraints identified among components of UML notation as lemmas

in-volving predicates on instances of model elements.

3.3.2 Static and Dynamic Models

In modeling system requirements, we capture the static structure by abstracting objects, classes, and their relationships. For instance, entities may require complex data structures to describe their functionalities. Types of relationships include association, aggregation, composition aggregation, generalization and spe-cialization. These must be adequately specified before describing the dynamic behavior of entities.

Types of object interaction include sequential composition, and concurrency. We use UML icons [1] shown in Figure 3 to indicate different kinds of message flow between interacting objects. The icons are classified in two categories, arrival pattern and synchronization pattern. An arrival pattern icon can be combined with a synchronization pattern icon to capture two orthogonal dimensions. For instance, the

A collaboration represents a set of objects and associations that are meaningful to the purpose of the collaboration. We define a projection of a collaboration

C

C

and the associations in

C

diagram

C



C

C

C

 it can be proved that the effect of an interaction based on

C

3.4

Requirements Modeling and Design Analysis

When using a notation with interleaving components, achieving design consistency is a major issue. It is imperative that consistency is obtained within diagrams to determine the satisfaction of system properties, as well as across diagrams to ensure that components of the notation are compatible with each other. We iden-tify relationships among components of UML notation, and formally describe corresponding constraints, so that if a property exists at one level, we can conclude whether it exists at another level. Satisfaction of invariants capturing these relationships implies that semantics of constructs in different components of the notation are consistent with each other.

3.4.1 Completeness in Data Type Specifications

The PVS specification of an abstract data type is concise and succinct, with a set of constructors along with associated accessors and recognizers. A theory provides axioms relating the constructors, accessors, and recognizers, as well as induction principles for ensuring that the data type is the initial algebra defined by the constructors. For instance, extensionality and eta axioms are generated to define equality on instances of the data type. Other axioms define well-foundedness rules, and support well-founded subterm ordering relations and strong forms of induction. The functions every and some are generated to establish the truth value of a predicate in existentially and universally quantified formulas on the data type. Functions are included to define a generic map on the data type. These generated axioms and functions must often be augmented with others capturing properties of the data type to ensure completeness of the specification. A data type specification is complete if every intended property of the data type can be deduced from the axioms.

3.4.2 Consistency Checking in Design Specifications

Using the formal semantics, we formulate a corresponding PVS specification for each UML design speci-fication. A relationship R between two UML design components is stated in the form of a set of theorems in a parameterized theory TR. When TRis instantiated with two actual design specifications, these theorems must be proved in order to establish consistency between the two designs. This may not be possible without sufficient axioms capturing properties of data types in the specifications. Consequently, consistency cannot be assured without completeness of abstract data types.

Consistency: Let d1and d2 be two design specifications in UML; let p1 and p2be their corresponding

PVS specifications. There exists a parameterized theory TR, corresponding to the relationship R between the

designs d1and d2. If a proof can be constructed for every theorem in the instance TR(p1;p2)of the theory,

References

[1] B. P. Douglass. Real-Time UML - Developing Efficient Objects for Embedded Systems. Addison-Wesley, Reading, MA, 1998. [2] S. Owre, J. M. Rushby, and N. Shankar. PVS: a prototype verification system. In Proceedings of 11th International Conference

on Automated Deduction, CADE’92, volume 607 of Lecture Notes in Artificial Intelligence, pages 748–752, Saratoga, NY,

1992. Springer Verlag.