781 research outputs found

    Verifying service continuity in a satellite reconfiguration procedure: application to a satellite

    Get PDF
    The paper discusses the use of the TURTLE UML profile to model and verify service continuity during dynamic reconfiguration of embedded software, and space-based telecommunication software in particular. TURTLE extends UML class diagrams with composition operators, and activity diagrams with temporal operators. Translating TURTLE to the formal description technique RT-LOTOS gives the profile a formal semantics and makes it possible to reuse verification techniques implemented by the RTL, the RT-LOTOS toolkit developed at LAAS-CNRS. The paper proposes a modeling and formal validation methodology based on TURTLE and RTL, and discusses its application to a payload software application in charge of an embedded packet switch. The paper demonstrates the benefits of using TURTLE to prove service continuity for dynamic reconfiguration of embedded software

    Mastering Heterogeneous Behavioural Models

    Full text link
    Heterogeneity is one important feature of complex systems, leading to the complexity of their construction and analysis. Moving the heterogeneity at model level helps in mastering the difficulty of composing heterogeneous models which constitute a large system. We propose a method made of an algebra and structure morphisms to deal with the interaction of behavioural models, provided that they are compatible. We prove that heterogeneous models can interact in a safe way, and therefore complex heterogeneous systems can be built and analysed incrementally. The Uppaal tool is targeted for experimentations.Comment: 16 pages, a short version to appear in MEDI'201

    Introduction to the ISO specification language LOTOS

    Get PDF
    LOTOS is a specification language that has been specifically developed for the formal description of the OSI (Open Systems Interconnection) architecture, although it is applicable to distributed, concurrent systems in general. In LOTOS a system is seen as a set of processes which interact and exchange data with each other and with their environment. LOTOS is expected to become an ISO international standard by 1988

    Rigorous object-oriented analysis

    Get PDF
    Object-oriented methods for analysis, design and programming are commonly used by software engineers. Formal description techniques, however, are mainly used in a research environment. We have investigated how rigour can be introduced into the analysis phase of the software development process by combining object-oriented analysis (OOA) methods with formal description techniques. The main topics of this investigation are a formal interpretation of the OOA constructs using LOTOS, a mathematical definition of the basic OOA concepts using a simple denotational semantics and a new method for object- oriented analysis that we call the Rigorous Object-Oriented Analysis method (ROOA). The LOTOS interpretation of the OOA concepts is an intrinsic part of the ROOA method. It was designed in such a way that software engineers with no experience in LOTOS, can still use ROOA. The denotational semantics of the concepts of object-oriented analysis illuminates the formal syntactic transformations within ROOA and guarantees that the basic object- oriented concepts can be understood independently of the specification language we use. The ROOA method starts from a set of informal requirements and an object model and produces a formal object-oriented analysis model that acts as a requirements specification. The resulting formal model integrates the static, dynamic and functional properties of a system in contrast to existing OOA methods which are informal and produce three separate models that are difficult to integrate and keep consistent. ROOA provides a systematic development process, by proposing a set of rules to be followed during the analysis phase. During the application of these rules, auxiliary structures are created to help in tracing the requirements through to the final formal model. As LOTOS produces executable specifications, prototyping can be used to check the conformance of the specification against the original requirements and to detect inconsistencies, omissions and ambiguities early in the development process

    Attribute Grammar Applications in Prototyping LOTOS Tools

    Get PDF
    What is the practical applicability of attribute grammars? As we show in this paper, attribute grammars are at least good enough for the prototyping of fully functional interactive tools. Going from a definition of a language and the functionality of its tools to an attribute grammar is a discipline in need of a systematic approach, for which we give some initial material. As is inevitable when a system is extensively used (in our case the Cornell Synthesizer Generator), this paper also proposes extensions to the attribute grammar formalism and its supporting systems. 1 Introduction This paper represents, in some way, a view from the trenches. How we prototyped tools contributing to a specification environment for LOTOS is the main topic here. Attribute grammars were chosen because they promised to be a good prototyping approach to language based software development, and the close relation between attribute grammars and the description of tool functions helps ensure the correctness of..

    Specifying and Refining Internal Operations in Z

    Get PDF
    Abstract An important aspect in the specification of distributed systems is the role of the internal (or unobservable) operation. Such operations are not part of the interface to the environment (i.e. the user cannot invoke them), however, they are essential to our understanding and correct modelling of the system. In this paper we are interested in the use of the formal specification notation Z for the description of distributed systems. Various conventions have been employed to model internal operations when specifying such systems in Z. If internal operations are distinguished in the specification notation, then refinement needs to deal with internal operations in appropriate ways. Using an example of a telecommunications protocol we show that standard Z refinement is inappropriate for refining a system when internal operations are specified explicitly. We present a generalization of Z refinement, called weak refinement, which treats internal operations differently from observable operations when refining a system. We discuss the role of internal operations in a Z specification, and in particular whether an equivalent specification not containing internal operations can be found. The nature of divergence through livelock is also discussed. Keywords: Z; Refinement; Distributed Systems; Internal Operations; Process Algebras; Concurrency
    corecore