Results 1 - 10
of
15
Composing Requirements Using Problem Frames
- IN PROCEEDINGS OF THE 2004 INTERNATIONAL CONFERENCE ON REQUIREMENTS ENGINEERING RE’04, IEEE CS
, 2004
"... Problem Frames are a systematic approach to the decomposition of problems that allows us to relate requirements, domain properties, and machine specifications. Having decomposed a problem, one approach to solving it is through a process of composing solutions to sub-problems. In this paper, we contr ..."
Abstract
-
Cited by 22 (8 self)
- Add to MetaCart
Problem Frames are a systematic approach to the decomposition of problems that allows us to relate requirements, domain properties, and machine specifications. Having decomposed a problem, one approach to solving it is through a process of composing solutions to sub-problems. In this paper, we contribute to supporting such a process by providing a way to compose multiple Problem Frames. We develop a systematic approach to composing inconsistent requirements. We introduce Composition Frames, a requirements construct that models relevant aspects of composition and thus deals with unwanted effects, such as interference of overlapping reactions to events. Throughout the paper we use a simple case study to illustrate and validate our ideas.
A structural proof of the soundness of rely/guarantee rules
- Journal of Logic and Computation
, 2007
"... Abstract. Various forms of rely/guarantee conditions have been used to record and reason about interference in ways that provide compositional development methods for concurrent programs. This paper illustrates such a set of rules and proves their soundness. The underlying concurrent language allows ..."
Abstract
-
Cited by 11 (6 self)
- Add to MetaCart
Abstract. Various forms of rely/guarantee conditions have been used to record and reason about interference in ways that provide compositional development methods for concurrent programs. This paper illustrates such a set of rules and proves their soundness. The underlying concurrent language allows fine-grained interleaving and nested concurrency; it is defined by an operational semantics; the proof that the rely/guarantee rules are consistent with that semantics (including termination) is by a structural induction. A key lemma which relates the states which can arise from the extra interference that results from taking a portion of the program out of context makes it possible to do the proofs without having to perform induction over the computation history. This lemma also offers a way to think about expressibility issues around auxiliary variables in rely/guarantee conditions. 1
Constructing a Tractable Reasoning Framework upon a Fine-Grained Structural Operational Semantics
, 2008
"... The primary focus of this thesis is the semantic gap between a fine-grained structural operational semantics and a set of rely/guarantee-style development rules. The semantic gap is bridged by considering the development rules to be a part of the same logical framework as the operational semantics, ..."
Abstract
-
Cited by 5 (4 self)
- Add to MetaCart
The primary focus of this thesis is the semantic gap between a fine-grained structural operational semantics and a set of rely/guarantee-style development rules. The semantic gap is bridged by considering the development rules to be a part of the same logical framework as the operational semantics, and a set of soundness proofs show that the development rules, though making development easier for a developer, do not add any extra power to the logical framework as a whole. The soundness proofs given are constructed to take advantage of the structural nature of the language and its semantics; this allows for the addition of new development rules in a modular fashion. The particular language semantics allows for very fine-grained concurrency. The language itself includes a construct for nested parallel execution of statements, and the semantics is written so that statements can interfere with each other between individual variable reads. The language also includes an atomic block construct for which the semantics is an embodiment of a form of software transactional memory. The inclusion of the atomic construct helps illustrate the inherent expressive weakness present in the rely/guarantee rules with respect to termination properties. As such, two development rules are proposed for the atomic construct, one of which has serious restrictions in its application, and another for which the termination property does not hold.
Determining the specification of a control system: an illustrative example
- Proceedings of the Workshop on Rigorous Engineering of FaultTolerant Systems (REFT 2005), volume 4157 of LNCS
, 2006
"... Creating the specification of a system by focusing primarily on the detailed properties of the digital controller can lead to complex descriptions that are nearly incoherent. An argument given by Hayes, Jackson, and Jones provides reasons to focus first on the wider environment in which the system w ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
Creating the specification of a system by focusing primarily on the detailed properties of the digital controller can lead to complex descriptions that are nearly incoherent. An argument given by Hayes, Jackson, and Jones provides reasons to focus first on the wider environment in which the system will reside. In their approach are two major ideas: pushing out the specification boundaries, and carefully distinguishing between the requirements of the system and the assumptions about the environment. Pushing out the boundaries of the system specification to include the pragmatic intent of the system being specified allows the specification to be understood relative to the environmental context, rather than remaining a mysterious black box in isolation. Clarifying the distinction between assumptions about the environment and requirements that the specification must meet increases the clarity of the specification, and has the potential to seriously reduce the complexity of the final specification. The example of a gas burner is explored in depth to illustrate this approach to system specification.
The Agent Environment in Multi-Agent Systems: A Middleware Perspective
"... In this paper, we reflect on the notion of agent environment in multiagent systems from a middleware perspective. We observe a strong connection between the agent environment in multi-agent systems and middleware, both with respect to their role and evolution. Whereas middleware was initially consid ..."
Abstract
-
Cited by 1 (1 self)
- Add to MetaCart
In this paper, we reflect on the notion of agent environment in multiagent systems from a middleware perspective. We observe a strong connection between the agent environment in multi-agent systems and middleware, both with respect to their role and evolution. Whereas middleware was initially considered as a blackbox providing a set of higherlevel programming abstractions and services, today middleware supports application-specific composition of components and services and dynamic adaptation according to the requirements of the system at hand. Reflecting on the agent environment yields the following observations: (1) multi-agent system engineers consider distributed middleware (RMI, CORBA, etc.) as the basic platform for developing multi-agent systems, (2) common middleware services (security, persistency, etc.) are only minimally considered in multi-agent systems, (3) domain-specific middleware for multi-agent systems such as communication services and support for
Better Abstractions for Reusable Components & Architectures
"... Software architecture (SA) is a crucial component of Model Driven Engineering (MDE), since it eases the communication and reuse of designs and components. However, existing languages (e.g., UML, AADL, SysML) are lacking many needed features. In particular, they provide rudimentary support for connec ..."
Abstract
-
Cited by 1 (1 self)
- Add to MetaCart
Software architecture (SA) is a crucial component of Model Driven Engineering (MDE), since it eases the communication and reuse of designs and components. However, existing languages (e.g., UML, AADL, SysML) are lacking many needed features. In particular, they provide rudimentary support for connectors, a first-class element in the components and connectors (C&C) architectural view and one of the most reusable architectural elements. This is unfortunate, since the difficult properties that need to be guaranteed for complex systems are mainly the non-functional properties, like throughput, security and dependability, which are greatly influenced by the employed connectors. This work reviews the basic abstractions of the C&C view of SA and examines extra architectural elements which can support the detailed, explicit and separate description of behaviour, interaction and control logic. 1.
Stepwise development of Simulink models using the refinement calculus framework
, 2007
"... Simulink is a popular tool for model-based development of control systems. However, due to the complexity caused by the increasing demand for sophisticated controllers, validation of Simulink models is becoming a more difficult task. To ensure correctness and reliability of large models, it is impor ..."
Abstract
- Add to MetaCart
Simulink is a popular tool for model-based development of control systems. However, due to the complexity caused by the increasing demand for sophisticated controllers, validation of Simulink models is becoming a more difficult task. To ensure correctness and reliability of large models, it is important to be able to reason about model parts and their interactions. This paper provides a definition of contracts and refinement using the action systems formalism. Contracts enable abstract specifications of model parts, while refinement offers a framework to reason about correctness of implementation of contracts, as well as composition of model parts. An example is provided to illustrate system development using contracts and refinement.
The Need to Revisit Architectural Connectors
"... Composing and analysing COTS-based critical systems depends on a great degree on the interaction patterns among the components and the strategies used by them to guarantee that the overall temporal, security and dependability requirements will be met. However, the element which naturally describes t ..."
Abstract
- Add to MetaCart
Composing and analysing COTS-based critical systems depends on a great degree on the interaction patterns among the components and the strategies used by them to guarantee that the overall temporal, security and dependability requirements will be met. However, the element which naturally describes this system aspect- an architectural connector- is being continuously mistreated and underemployed. We believe that the notion of connectors needs to be revisited and we should built upon it, if we want to be able to faithfully describe complex critical systems in a manner which easily allows to identify the design problems and opportunities available to us for meeting the system requirements. 1
From Problem Frames to HJJ (and . . .
, 2009
"... This paper traces the evolving ideas of an approach to “open systems" that interact with the physical world. Such systems nowadays almost always include computers. The design in the simplest cases has a control computer connected to sensors that receive information about the physical world and to ac ..."
Abstract
- Add to MetaCart
This paper traces the evolving ideas of an approach to “open systems" that interact with the physical world. Such systems nowadays almost always include computers. The design in the simplest cases has a control computer connected to sensors that receive information about the physical world and to actuators that can cause some aspects of that world to change. Jackson's "Problem Frame Approach" is to think about the computer system with respect to the requirement of the desired overall system behaviour; the “Hayes/Jackson/Jones" (HJJ) approach introduces sufficient formalism to support the derivation of the specification of the computer control system. This is a pre-publication version of a paper top be printed in a Festschrift in honour of Michael Jackson. The talk was given at the related event held at ICSE in Vancouver in May 2009. Please cite the final publication (editors Bashar Nuseibeh and Pamela Zave)

