Results 1  10
of
17
Formal Specification and Prototyping of MultiAgent Systems
 IN ESAW ’00: PROCEEDINGS OF THE FIRST INTERNATIONAL WORKSHOP ON ENGINEERING SOCIETIES IN THE AGENT WORLD
, 2000
"... This paper presents a multi agentoriented prototyping approach. It is a generic approach, applicable to a wide range of multiagent systems. This approach relies on a few assumptions, the most important is that MAS must be described by an organizational model which semantics is given in term of ..."
Abstract

Cited by 24 (9 self)
 Add to MetaCart
This paper presents a multi agentoriented prototyping approach. It is a generic approach, applicable to a wide range of multiagent systems. This approach relies on a few assumptions, the most important is that MAS must be described by an organizational model which semantics is given in term of a formal framework. This model allows for a simple description of both individual and collective multiagent system aspects. The framework we use to give a formal description of this model is based on a multiformalism approach. We illustrate this approach through a case study.
Principles for Modeling Language Design
, 2000
"... Modeling languages, like programming languages, need to be designed if they are to be practical, usable, accepted, and of lasting value. We present principles for the design of modeling languages. To arrive at these principles, we consider the intended use of modeling languages. We conject that the ..."
Abstract

Cited by 14 (2 self)
 Add to MetaCart
Modeling languages, like programming languages, need to be designed if they are to be practical, usable, accepted, and of lasting value. We present principles for the design of modeling languages. To arrive at these principles, we consider the intended use of modeling languages. We conject that the principles are applicable to the development of new modeling languages, and for improving the design of existing modeling languages that have evolved, perhaps through a process of unification. The principles are illustrated and explained by several examples, drawing on objectoriented and mathematical modeling languages. 1 Introduction The key difficulty in producing quality software is specifying and designing the conceptual construct that underlies the software [2]. This conceptual construct is usually complex. Complexity is an essential difficulty that cannot be dealt with by using more powerful programming languages or tools, or by using modeling languages that abstract it away. Comple...
Developing BON as an IndustrialStrength Formal Method
, 1999
"... The emerging Unified Modelling Language has been touted as merging the best features of existing modelling languages, and has been adopted by leading companies and vendors as a universal software modelling language. Some researchers are also looking to UML as a basis for formal methods development. ..."
Abstract

Cited by 12 (8 self)
 Add to MetaCart
The emerging Unified Modelling Language has been touted as merging the best features of existing modelling languages, and has been adopted by leading companies and vendors as a universal software modelling language. Some researchers are also looking to UML as a basis for formal methods development. A less known approach is BON (the Business Object Notation), which is based on the principles of seamlessness, reversibility and design by contract, making it an ideal basis for industrialstrength formal methods development of objectoriented software. In this paper, we argue that BON is much more suited for the application of formal methods than UML. We describe the properties that an industrialstrength formal method must have, show how algorithm refinement can be done in BON (as an example of using BON for formal development), and contrast BON with other approaches, including UML, Z, B and VDM.
From Z to BON/Eiffel
 In Proc. Automated Software Engineering
, 1998
"... . It is shown how to make a transition from the formal specification notation Z [10] to the Business Object Notation (BON) [11], so as to be able to relate the former notation with objectoriented specifications and implementations. The transition is applied in a case study that shows how to move ..."
Abstract

Cited by 9 (7 self)
 Add to MetaCart
. It is shown how to make a transition from the formal specification notation Z [10] to the Business Object Notation (BON) [11], so as to be able to relate the former notation with objectoriented specifications and implementations. The transition is applied in a case study that shows how to move from Z to BON, and finally through to executable Eiffel programs. The translation lays the groundwork for a semiautomated tool that spans the semantic gap from abstract Z specifications to concrete Eiffel implementations. 1 Introduction The Z formal notation [10] is receiving growing attention: in industry, where it is being used for the formal specification of large systems [3, 6]; and in academia, where it is being taught for formal specification and development. Z is a mathematical notation, with a rich collection of idioms based on typed set theory for specifying systems. It has seen successful use in writing and analyzing specifications, and in proving properties about specificatio...
Comparing Extended Z with a Heterogeneous Notation for Reasoning about Time and Space
 In Proc. ZUM '98, LNCS 1493
, 1998
"... We contrast using a notation extension with using a combination of notations. Specifically, we compare the use of an extended dialect of Z with a combination of Z and predicative programming notation for algorithm refinement and for reasoning about time and space constraints on systems. We discuss t ..."
Abstract

Cited by 7 (7 self)
 Add to MetaCart
We contrast using a notation extension with using a combination of notations. Specifically, we compare the use of an extended dialect of Z with a combination of Z and predicative programming notation for algorithm refinement and for reasoning about time and space constraints on systems. We discuss the difficulty of using extended notations versus using heterogeneous notations, and consider when we might prefer to extend or combine notations. We conclude that there exist situations where a heterogeneous notation can be more appropriate to use than an extended notation.
When Are Methods Complementary?
 INFORMATION AND SOFTWARE TECHNOLOGY
, 1999
"... We address the issue of when software development methods are complementary, i.e., determining when a method is capable of a task that another method cannot perform. Our intent is to examine complementarity in order to help determine when to carry out method integration. We propose some factors for ..."
Abstract

Cited by 6 (4 self)
 Add to MetaCart
We address the issue of when software development methods are complementary, i.e., determining when a method is capable of a task that another method cannot perform. Our intent is to examine complementarity in order to help determine when to carry out method integration. We propose some factors for method complementarity, and suggest that contextdependent criteria, such as realworld domain and nonfunctional development requirements, may have a significant impact on method complementarity.
Heterogeneous Notations for Pure Formal Method Integration
 Formal Aspects of Computing
, 1998
"... We outline an extendible approach for combining formal methods  such as Z, Morgan's refinement calculus, and predicative programming  based on composing specifications written in similar formal languages. We discuss how algorithm refinement can be extended to such a setting, and outline some exa ..."
Abstract

Cited by 3 (3 self)
 Add to MetaCart
We outline an extendible approach for combining formal methods  such as Z, Morgan's refinement calculus, and predicative programming  based on composing specifications written in similar formal languages. We discuss how algorithm refinement can be extended to such a setting, and outline some examples of using integrated formal methods. We also provide justifications for why using combinations of similar methods might be helpful.
Integrating a program design calculus and a subset of UML
 The Computer Journal
, 1999
"... It has been suggested that a single software development method is insufficient for all situations [1]. This is due, in part, to the complexity of the problems being solved, the diversity of expertise among developers and the limitations of a single set of notations and processes. Method integration ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
It has been suggested that a single software development method is insufficient for all situations [1]. This is due, in part, to the complexity of the problems being solved, the diversity of expertise among developers and the limitations of a single set of notations and processes. Method integration [2] is a technique that can be used to abet multiplemethod use. Method integration has been studied in the context of combining specific methods [3, 4] and in settings where systematic approaches for integration have been constructed [2, 5, 6, 7]. Our intent with this paper is to follow the latter path and continue the work of [6], where a metamethod for formal method integration was first presented. This paper has two main goals. The first is to present an integration involving the program design calculus of predicative programming [8] and a representative objectoriented method that uses a core subset of the Unified Modelling Language (UML) [9]. The integration is car...
Formal interpreters for diagram notations
 ACM TRANSACTIONS ON SOFTWARE ENGINEERING AND METHODOLOGY  ACM PRESS, 14(1):42
, 2005
"... The paper proposes an approach for defining extensible and flexible formal interpreters for diagram notations with significant dynamic semantics. More precisely, it addresses semiformal diagram notations that have preciselydefined syntax, but informallydefined (dynamic) semantics. These notations ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
The paper proposes an approach for defining extensible and flexible formal interpreters for diagram notations with significant dynamic semantics. More precisely, it addresses semiformal diagram notations that have preciselydefined syntax, but informallydefined (dynamic) semantics. These notations are often flexible to fit the different needs and expectations of users. Flexibility comes from the incompleteness or informality of the original definition and results in different interpretations. The approach defines interpreters by means of a mapping onto a semantic domain. Two sets of rules define the correspondences between the elements of the diagram notation and those of the semantic domain, and between events and states of the semantic domain and visual annotations on the elements of the diagram notation. Flexibility also leads to notation families, i.e., sets of notations that share core concepts, but present slightly different interpretations. Existing approaches usually interpret these notations in isolation; the approach presented in this paper allows the interpretation of a family as a whole. The feasibility of the approach is demonstrated through a prototype generator that allows users to implement specialpurpose interpreters by defining relatively small sets of rules.
Specification and Refinement using a Heterogeneous Notation for Concurrency and Communication
, 1998
"... It is shown how to combine the Z formal specification notation with a predicative notation so as to be able to specify and reason about concurrency and communication. The integration is carried out so as to alleviate some of the limitations noted with previous integration approaches, such as the ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
It is shown how to combine the Z formal specification notation with a predicative notation so as to be able to specify and reason about concurrency and communication. The integration is carried out so as to alleviate some of the limitations noted with previous integration approaches, such as the inability to use Z proof rules and tools with the integrated notation. In the process, it is demonstrated that it is not necessary to combine Z with a very different behavioural formalism in order to reason about concurrency. 1 Introduction The Z notation [15] has proven to be useful and appropriate for specifying and reasoning about sequential software and hardware systems. The strengths of Z include its ability to construct specifications by parts, its growing tool support, and its proof system. Recent work on Z has studied its application to concurrent systems.Inthis growing body of work, there are two general classes of approaches: 1. Extension approaches, which apply Z, perhaps w...