Fundamentals of Algebraic Specification 2

Ehrig, Hartmut; Mahr, Bernd

doi:10.1007/978-3-642-61284-8

Cited by 343 publications

(82 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…What is unique is the simplicity of the method and the freedom it offers the practitioner to choose for each problem an appropriate combination of concepts, notations and techniques, which are integrated by the framework in a coherent way as elements of a uniform mathematical background. Among the examples we will discuss are the following: abstract states, which can be richly structured, possibly unbounded or even infinite, as known from the theory of abstract data types and algebraic specifications [85,78,61,9,10], VDM [66], Z [103], COLD [65], abstract instructions for changing states (high-level operational definition of state changes by guarded assingments), as familiar from pseudo-code notation, Virtual Machines 2 and later RAISE [73], synchronous parallel execution model, including conditional multiple assignments as present also in UNITY [86] and COLD [64], locality principle as known from programming languages, functional definitions, as in mathematics and functional programming, declarative (axiomatic) definitions, as known from logic and declarative programming and specification languages, refinement concept, generalizing the method which has been introduced by Wirth [112] and Dijkstra [58] and adapted to numerous formal specification methods [11,89,12,53], including Z [113,57] and B [1], decomposition and hierarchy concepts, as familiar from automata theory and layered architectures, function classification into monitored, controlled, shared etc., as known from programming and Parnas' SCR method [94,80], verification of model properties by proofs at the needed level of precision: sketched, detailed, machine assisted (interactive or fully automated), simulation by model execution, e.g. for model checking invariants, runtime verification of properties, testing of runs (scenarios).…”

Section: Introductionmentioning

confidence: 99%

The Abstract State Machines Method for High-Level System Design and Analysis

Börger¹

2009

Formal Methods: State of the Art and New Directions

283

518

View full text Add to dashboard Cite

Section: Introductionmentioning

confidence: 99%

The Abstract State Machines Method for High-Level System Design and Analysis

Börger¹

2009

Formal Methods: State of the Art and New Directions

283

518

View full text Add to dashboard Cite

“…In SDL-2000, following constructs are available to define data [Loe03]: Data types are defined by means of abstract data types. SDL is based on the concept that is equivalent to the ACT ONE [EM85] and LOTOS notation. In addition to the Z.100 standard, a detailed introduction to the data type concept can be found in [EHS97,Sch03a,Loe03].…”

Section: Data Typesmentioning

confidence: 99%

A UML Profile for Communicating Systems

Werner

Kraatz

Hogrefe

2006

System Analysis and Modeling: Language Profiles

View full text Add to dashboard Cite

This thesis presents a new Unified Modeling Language 2 (UML AcknowledgmentsI am grateful to my supervisor Prof. Dr. Hogrefe for many fruitful and helpful discussions in the stimulating atmosphere of his research group. I also thank my co-supervisor Prof. Dr. Grabowski for accepting the task of examining this thesis.Many thanks go out to all my colleagues from the Institute of Informatics at the University of Göttingen. Especially, I am grateful to my colleagues Michael Ebner, Rene Soltwisch and Xiaoming Fu for useful and valuable discussions on formal modeling techniques.I also thank my students Julia Woch and Sebastian Kraatz for contributing to this work with their considerable efforts. This thesis would not be in its current shape without the comments of numerous people. I thank Omar Alfandi, Mohammed Alfandi, Andrea Hellner, Ingo Juchem, Helmut Neukirchen, Katharina and Peter Samow for reading this thesis, finding errors and providing helpful suggestions for improving this thesis. List of Figures IntroductionDue to the huge complexity of modern software systems, it is required to specify precisely what a software component should do and how it should behave. If the final implementation deviates from the expected behavior, its use or its communication with other software components may fail. In a software development process, the specification describes the expected behavior of the software; the description describes the actual behavior of that software. The actual behavior is the implementation. A specification is a technical contract between developers and users or clients. It is mainly intended to provide them with a mutual understanding of the software and is used to guide the development and the use. This also applies for the development of communicating protocols as they are merely implemented in software.Today, most protocol specifications are carried out in natural, informal language because it is easy to understand. However, experience has shown that specifications in natural languages can be vague, verbose and ambiguous. That means they can be interpreted in more than one way. A specification is formal if its meaning (its semantics) is unambiguous. Special languages, known as formal description techniques (FDTs), have been developed for the unambiguous specification and description of software. Hence, FDTs are distinguished from formal languages by having a formal syntax and a formal semantics. This stands in contrast to (semi-)formal languages such as Java or C++ which only have a formal syntax. FDTs are based on rigorous formal methods and offer the means for defining unambiguous specifications of network services and protocols in a more comprehensive and precise way than those done in natural language. In addition, they provide a basis for analysis, verification and validation of a specification before protocols are implemented. They can be used at the requirement stage to capture the user requirements. During the stage of analysis and design, FDTs can be used to describe abstract...

show abstract

“…The notion of institutions owes much of its importance to the fact that several languages for modularizing specifications are generic over an underlying institution [11,12,13,18,27,33]. Furthermore, institutions form the basis of heterogeneous frameworks such as heterogeneous Casl [25,26].…”

Section: Definition 1 An Institution I = (Signmentioning

confidence: 99%

Type Class Polymorphism in an Institutional Framework

Schröder

Mossakowski

Lüth

2005

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Higher-order logic with shallow type class polymorphism is widely used as a specification formalism. Its polymorphic entities (types, operators, axioms) can easily be equipped with a 'naive' semantics defined in terms of collections of instances. However, this semantics has the unpleasant property that while model reduction preserves satisfaction of sentences, model expansion generally does not. In other words, unless further measures are taken, type class polymorphism fails to constitute a proper institution, being only a so-called rps preinstitution; this is unfortunate, as it means that one cannot use institution-independent or heterogeneous structuring languages, proof calculi, and tools with it.Here, we suggest to remedy this problem by modifying the notion of model to include information also about its potential future extensions. Our construction works at a high level of generality in the sense that it provides, for any preinstitution, an institution in which the original preinstitution can be represented. The semantics of polymorphism used in the specification language HasCasl makes use of this result. In fact, HasCasl's polymorphism is a special case of a general notion of polymorphism in institutions introduced here, and our construction leads to the right notion of semantic consequence when applied to this generic polymorphism. The appropriateness of the construction for other frameworks that share the same problem depends on methodological questions to be decided case by case. In particular, it turns out that our method is apparently unsuitable for observational logics, while it works well with abstract state machine formalisms such as state-based Casl.

show abstract

Fundamentals of Algebraic Specification 2

Cited by 343 publications

References 0 publications

The Abstract State Machines Method for High-Level System Design and Analysis

The Abstract State Machines Method for High-Level System Design and Analysis

A UML Profile for Communicating Systems

Type Class Polymorphism in an Institutional Framework

Contact Info

Product

Resources

About