Results 1 - 10
of
42
Carisma: context-aware reflective middleware system for mobile applications
- IEEE TRANS. ON SOFTWARE ENGINEERING
, 2003
"... Mobile devices, such as mobile phones and personal digital assistants, have gained wide-spread popularity. These devices will increasingly be networked, thus enabling the construction of distributed applications that have to adapt to changes in context, such as variations in network bandwidth, batt ..."
Abstract
-
Cited by 177 (5 self)
- Add to MetaCart
(Show Context)
Mobile devices, such as mobile phones and personal digital assistants, have gained wide-spread popularity. These devices will increasingly be networked, thus enabling the construction of distributed applications that have to adapt to changes in context, such as variations in network bandwidth, battery power, connectivity, reachability of services and hosts, etc. In this paper, we describe CARISMA, a mobile computing middleware which exploits the principle of reflection to enhance the construction of adaptive and context-aware mobile applications. The middleware provides software engineers with primitives to describe how context changes should be handled using policies. These policies may conflict. We classify the different types of conflicts that may arise in mobile computing and argue that conflicts cannot be resolved statically at the time applications are designed, but, rather, need to be resolved at execution time. We demonstrate a method by which policy conflicts can be handled; this method uses a microeconomic approach that relies on a particular type of sealed-bid auction. We describe how this method is implemented in the CARISMA middleware architecture and sketch a distributed context-aware application for mobile devices to illustrate how the method works in practice. We show, by way of a systematic performance evaluation, that conflict resolution does not imply undue overheads, before comparing our research to related work and concluding the paper.
A Framework for Multi-Valued Reasoning over Inconsistent Viewpoints
, 2001
"... In requirements elicitation, different stakeholders often hold different views of how a proposed system should behave, resulting in inconsistencies between their descriptions. Consensus may not be needed for every detail, but it can be hard to determine whether a particular disagreement affects the ..."
Abstract
-
Cited by 86 (27 self)
- Add to MetaCart
(Show Context)
In requirements elicitation, different stakeholders often hold different views of how a proposed system should behave, resulting in inconsistencies between their descriptions. Consensus may not be needed for every detail, but it can be hard to determine whether a particular disagreement affects the critical properties of the system. In this paper, we describe the # bel framework for merging and reasoning about multiple, inconsistent state machine models. # bel permits the analyst to choose how to combine information from the multiple viewpoints, where each viewpoint is described using an underlying multi-valued logic. The different values of our logics typically represent different levels of agreement. Our multi-valued model checker, # chek, allows us to check the merged model against properties expressed in a temporal logic. The resulting framework can be used as an exploration tool to support requirements negotiation, by determining what properties are preserved for various combinations of inconsistent viewpoints.
Inconsistency management in software engineering: Survey and open research issues
- in Handbook of Software Engineering and Knowledge Engineering
, 2001
"... The development of complex software systems is a complex and lengthy activity that involves the participation and collaboration of many stakeholders (e.g. customers, users, analysts, designers, and developers). This results in many partial models of the developing system. These models can be inconsi ..."
Abstract
-
Cited by 61 (4 self)
- Add to MetaCart
The development of complex software systems is a complex and lengthy activity that involves the participation and collaboration of many stakeholders (e.g. customers, users, analysts, designers, and developers). This results in many partial models of the developing system. These models can be inconsistent with each other since they describe the system from different perspectives and reflect the views of the stakeholders involved in their construction. Inconsistent software models can have negative and positive effects in the software development life-cycle. On the negative side, inconsistencies can delay and increase the cost of system development; do not guarantee some properties of the system, such as safety and reliability; and generate difficulties on system maintenance. On the positive side, inconsistencies can facilitate identification of some aspects of the system that need further analysis, assist with the specification of alternatives for the development of the system, and support elicitation of information about it. The software engineering community has proposed many techniques and methods to support the management of inconsistencies in various software models. In this paper, we present a survey of these techniques and methods. The survey is organized according to a conceptual framework which views inconsistency management as a process composed of six activities. These activities are the detection of overlaps, detection of inconsistencies, diagnosis of inconsistencies, handling of inconsistencies, tracking of inconsistencies, and specification and application of a management policy for inconsistencies. This paper also presents the main contributions of the research work that has been conducted to support each of the above activities and identifies the issues which are still open to further research. 1.
Recovery of traceability links between software documentation and source code
- International Journal of Software Engineering and Knowledge Engineering
"... An approach for the semi-automated recovery of traceability links between software documentation and source code is presented. The methodology is based on the application of information retrieval techniques to extract and analyze the semantic information from the source code and associated documenta ..."
Abstract
-
Cited by 38 (11 self)
- Add to MetaCart
An approach for the semi-automated recovery of traceability links between software documentation and source code is presented. The methodology is based on the application of information retrieval techniques to extract and analyze the semantic information from the source code and associated documentation. A semi-automatic process is defined based on the proposed methodology. The paper advocates the use of latent semantic indexing (LSI) as the supporting information retrieval technique. Two case studies using existing software are presented comparing this approach with others. The case studies show positive results for the proposed approach, especially considering the flexibility of the methods used.
Specifying monitoring and switching problems in context
- In: Proc. 15th Intl. Conference on Requirements Engineering
, 2007
"... Abstract Context-aware applications monitor changes in their operating environment and switch their behaviour to keep satisfying their requirements. Therefore, they must be equipped with the capability to detect variations in their operating context and to switch behaviour in response to such variat ..."
Abstract
-
Cited by 32 (6 self)
- Add to MetaCart
(Show Context)
Abstract Context-aware applications monitor changes in their operating environment and switch their behaviour to keep satisfying their requirements. Therefore, they must be equipped with the capability to detect variations in their operating context and to switch behaviour in response to such variations. However, specifying monitoring and switching in such applications can be difficult due to their dependence on varying contextual properties which need to be made explicit. In this paper, we present a problemoriented approach to represent and reason about contextual variability and assess its impact on requirements; to elicit and specify concerns facing monitors and switchers, such as initialisation and interference; and to specify monitoring and switching behaviours that can detect changes and adapt in response. We illustrate our approach by applying it to a published case study.
Requirements Interaction Management
, 1999
"... ion. Requirements may be distinguished based on the abstraction level of their description. A requirement may be further defined by add new details defined in more specialized subrequirements. Through specialization of abstract requirements, or generalization of detailed requirement, a requirement a ..."
Abstract
-
Cited by 31 (4 self)
- Add to MetaCart
ion. Requirements may be distinguished based on the abstraction level of their description. A requirement may be further defined by add new details defined in more specialized subrequirements. Through specialization of abstract requirements, or generalization of detailed requirement, a requirement abstraction hierarchy can be defined. . Development p roperties . Requirements may be distinguished based on their development properties. For example, a requirement may have just been proposed. Late r, it may be accepted or rejected. . Representational properties. Requirements may be distinguished based on their representation. A requirement may begin as an informal sketch, then become a natural language sentence (e.g., "The system shall ..."). Finall y, more formal representations, such as UML, Z, or predicate cal- Requirements Interaction Management - Definition and scope 6 1999 William N. Robinson Requirements Interaction Management GSU CIS 99-7 culus, may be used to express a requir...
Monitoring Software Requirements Using Instrumented Code
- In HICSS ’02: Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS’02)-Volume 9. IEEE Computer Society
, 2002
"... Ideally, software is derived from requirements whose properties have been established as good. However, it is difficult to define and analyze requirements. Moreover, derivation of software from requirements is error prone. Finally, the installation and use of compiled software can introduce errors. ..."
Abstract
-
Cited by 28 (1 self)
- Add to MetaCart
(Show Context)
Ideally, software is derived from requirements whose properties have been established as good. However, it is difficult to define and analyze requirements. Moreover, derivation of software from requirements is error prone. Finally, the installation and use of compiled software can introduce errors. Thus, it can be difficult to provide assurances about the state of a software's execution.
A Micro-Economic Approach to Conflict Resolution in Mobile Computing
- In Proceedings of the 10th International Symposium on the Foundations of Software Engineering (FSE-10
, 2002
"... Mobile devices, such as mobile phones and personal digital assistants, have gained wide-spread popularity. These devices will increasingly be networked, thus enabling the construction of distributed mobile applications. These have to adapt to changes in context, such as variations in network bandwid ..."
Abstract
-
Cited by 22 (3 self)
- Add to MetaCart
(Show Context)
Mobile devices, such as mobile phones and personal digital assistants, have gained wide-spread popularity. These devices will increasingly be networked, thus enabling the construction of distributed mobile applications. These have to adapt to changes in context, such as variations in network bandwidth, exhaustion of battery power or reachability of services on other devices. We show how the construction of adaptive and context-aware mobile applications can be supported using a reflective middleware. The middleware provides software engineers with primitives to describe how context changes are handled using policies. These policies may conflict. In this paper, we classify the different types of conflicts that may arise in mobile computing. We argue that conflicts cannot be resolved statically at the time applications are designed, but, rather, need to be resolved at execution time. We demonstrate a method by which these policy conflicts can be treated. This method uses a micro-economic approach that relies on a particular type of sealed-bid auction.
Do viewpoints lead to better conceptual models? An exploratory case study
- IN RE
, 2005
"... The use of viewpoints has long been proposed as a technique to structure evolving requirements models. In theory, viewpoints should provide better stakeholder traceability, and the ability to discover important requirements by comparing viewpoints. However, this theory has never been tested empirica ..."
Abstract
-
Cited by 21 (12 self)
- Add to MetaCart
(Show Context)
The use of viewpoints has long been proposed as a technique to structure evolving requirements models. In theory, viewpoints should provide better stakeholder traceability, and the ability to discover important requirements by comparing viewpoints. However, this theory has never been tested empirically. This paper reports on an exploratory case study of a key hypothesis of the viewpoints theory, namely that by creating separate viewpoint models to represent different stakeholder contributions, and explicitly merging them, important hidden requirements can be discovered. The case study compared two modelling teams using the i ∗ notation to capture requirements for new web-based counselling services for a large charitable organisation. One team used viewpoints; the other did not. The conclusions include that viewpoint merging improves the understanding of the problem domain, but is very time consuming. The process of merging was more important than the merged product. The study also indicates a need for better model management tools, as both teams encountered difficulty in managing large, evolving models.
Surfacing root requirements interaction from inquiry cycle requirements
- in Proc. 3rd Int. Conf. on Requirements Engineering (ICRE98), IEEE Computer
, 1998
"... ..."
(Show Context)
