Contextual problem detection and management during software execution in complex environments
| DOI | https://doi.org/10.1108/02635570610661615 |
| Date | 01 April 2006 |
| Pages | 540-561 |
| Published date | 01 April 2006 |
| Author | Jae Sun Kim,Sooyong Park,Vijayan Sugumaran |
| Subject Matter | Economics,Information & knowledge management,Management science & operations |
Contextual problem detection and
management during software
execution in complex
environments
Jae Sun Kim and Sooyong Park
Department of Computer Science, Sogang University, Seoul, South Korea, and
Vijayan Sugumaran
Department of Decision and Information Sciences, School of Business
Administration, Oakland University, Rochester, Michigan, USA
Abstract
Purpose – From the point of view of computing environments, the paper aims to present a
goal-based contextual problem detection and management (GCPDM) method whose core benefit in its
extendability of detection capability to deal with unpredicted problems.
Design/methodology/approach – Approaches the subject by designing a goal graph, designing
actions, designing achievable relations between actions and goals, defining contextual factors of each
action, defining CCGs and implementing the GCPD engine.
Findings – That self-managed, as opposed to traditional, software is designed to avoid runtime
failures by adapting to unpredictable situations.
Originality/value – This paper presents a GCPDM method.
Keywords Problem solving,Software tools
Paper type Conceptual paper
1. Introduction
Complexity of the software execution environment is increasing tremendously.
Software should be able to execute even with more complexity particularly in
ubiquitous computing environment (Seng and Yu, 2005; Iyer et al., 2005). A large
number of environmental computing entities can have innumerable interactions with
each other, and hence, software can hardly achieve robust execution. This new
computing environment poses new challenges for developers (Chalasani and Barber,
2004). Software should adapt without human intervention to achieve, what Weiser
termed, “calm computing” (Kindberg and Fox, 2002).
The traditional developm ent paradigm focuses on analy zing requirements
assuming a well-defined and fixed execution environment. However, unpredicted
situations could occur during software execution in a complex environment (Kim et al.,
2004). More over, it is difficult to predict, analyze and design all such situatio ns for
contextual complexity and uncertainty. The system, which is developed to operate in a
predefined environment, can easily fail (Laddaga, 1999). Especially, for embedded
The current issue and full text archive of this journal is available at
www.emeraldinsight.com/0263-5577.htm
This work was supported by grant No. R01-2003-000-10197-0 from the Basic Research Program
of the Korea Science and Engineering Foundation.
IMDS
106,4
540
Industrial Management & Data
Systems
Vol. 106 No. 4, 2006
pp. 540-561
qEmerald Group Publishing Limited
0263-5577
DOI 10.1108/02635570610661615
applications, the developers do not maintain the functionalities after deployment
(Park et al., 2004). Hence, it is critical that these systems maintain their operation over
time by themselves without human intervention.
We need an innovative software paradigm to solve the above problem. One
approach that has been discussed in the literature is self-adaptive software. Research
on adaptive software began with DARPA’s (1997) Broad Agency Announcement of
“self adaptive software” in 1997. IBM also proposed the autonomic computing concept
with a similar motivation in 2001 (Kephart and Chess, 2003). Autonomic computing
comprises of several areas such as self-configuring, self-healing, self-optimizing and
self-protecting. All of these research areas can be called as “self-management”
techniques because the software manages itself at runtime.
We have to solve several issues in order to successfully implement self-managed
software (Garlan and Schmerl, 2002): monitoring, analysis, plan, and reconfiguration.
This paper focuses on analysis issues. Monitoring and analysis are closely related
concepts, however, there are many differences. Monitoring is important to determine
how the software is functioning within the environment and a myriad of data collection
techniques exist to gather appropriate data to keep track of the state of software
execution. Analysis plays a more important role for self-managed software. We have to
analyze the monitored data to detect what problems could happen. Software can
diagnose the problem using the analysis result.
We divide the software problems into two types – internal problem and contextual
problem:
(1) Contextual problem. The problem’s causes are found in the context domain.
For example, a resource problem can make software’s performance poor.
(2) Internal problem The problem’s causes are found in the internals of the software
such as design errors.
We can monitor the software’s runtime execution using behavior models such as
statemachine. If the software does not follow the normal behavior routine in
the software’s statemachine, an internal problem can happen.
Contextual problem can be identified in an indirect way. We can observe the
software’s contextual situation by monitoring the computing resources and che cking
the contextual constraints for software execution. If a particular situation does not
satisfy the contextual constraints, a contextual problem can happen. However, this
detection process may be slightly inaccurate relative to the internal problem detection.
Both approaches complement each other. Especially, detecting the contextual
problem can prevent catastrophic problems beforehand. This research focuses on
developing a method for detecting and managing contextual problems.
Software’s complex execution environment has uncertainties (Norvig and Cohn,
1997) and poses issues for the contextual problem detection. Contextual uncertainty
means that the bounds of the contextual constraint, e.g. b
1
and b
2
in a constraint
“b
1
,contextvariable ,b
2
,” can vary at runtime. The environment is difficult to
analyze thoroughly because of the hidden input and the complex interaction between
contextual factors. Developers cannot define the precise bounds of contextual variables
in a contextual constraint. More over, a fixed contextual constraint is not appropriate
because the environment changes continuously. Therefore, it is difficult to design the
contextual constraints with fixed bounds.
Contextual
problem
detection
541
To continue reading
Request your trial