SEKE 2012 Proceedings - Knowledge Systems Institute

A. Step S1 – Define the Business Process having in mind
Communication Analysis Principles
According to the principles of Communication Analysis, a
Communicative Event Diagram provides a notation to
indicate the Communicational Level of a business process. At
this level, it is assumed that business processes are immune to
changing technologies and present the essentials of the
business behavior. Event triggers an activity that receives an
incoming message, processes it and provides an output.
Communicational Level is an important abstraction level in
our approach which can present the critical events that must be
monitored and refined. It supports the modularization of
Autonomic Business Process by providing a level which presents
critical events that must be refined. In this sense, we extended
Communicative Event Diagram to incorporate an annotation of
Critical Events. Figure 5 presents the Communicational Level of
Business Process of CAGED, where we highlight the critical
event “CAG2 - Declarant submits declaration”.
MTE CGET STAFF
DECLARANT
MTE CGET STAFF
MTE CGET STAFF
OPERATIONAL STAFF
OPERATIONAL STAFF
LEGEND
ACTOR
COMMUNICATIVE
EVENT
COMPETENCE
CAGED MOVEMENTS
CAGED RECEIPT
COMPETENCE
STATISTICAL
PROCESSING
PARAMETERS
INGOING
COMMUNICATIVE
INTERACTION
CAG1
MTE OPENS
COMPETENCE
MTE
CAG2
DECLARANT
SUBMITS
DECLARATION
DECLARANT
CAG3
MTE OPENS
PROCESSING
RECEIPT FILES
MTE
CAG4
MTE CLOSES
COMPETENCE
MTE
CAG5
STAFF CLOSES
PROCESSING
MTE
CAG6
STAFF STARTS
STATISTICAL
PROCESSING
OPERACIONAL STAFF
OUTGOING
COMMUNICATIVE
INTERACTION
PREVIOUS DATA
OPERATIONAL DATA
CAGED EXTRACT
STATISTICAL DATAS
PRECEDENCE
RELATION
“OR”
MERGE
MINISTER
MTE STAFF
DECLARANT
MINISTER,
RESEARCHERS,
MTE STAFFS
START
END
CRITICAL
EVENT
Figure 5. S1 - Communicational Level of Business Process of CAGED
B. Step S2 - Defining Autonomic Business Processes
In order to specify mission-critical events according to
the logical level of business process model
(Communicational Level), we defined a new level, named
Technological Level. It expresses different activities that
reflect the system behavior and the Operational Level to
present the operationalizations related to NFR and
Autonomic Computing Principles (see Figure 6, S2 box).
The necessary steps to build the technological and
operational level of critical events are explained as follows.
1) Define Technological Level: Technological Level
represents the sub-division of an event processing to indicate
important aspects that impact on software adaptation, such as:
Present different alternatives to perform an activity:
It is n ecessary to in dicate possible reconfiguration, i.e.
changes in business flow, as a result of deviation to certain
metrics values. In our example, the operation of capture a
CAGED file can be done in different manner: (i) Generate
CAGED File; (ii) Generate Analyzed CAGED File; and (iii)
Generate Short Analyzed CAGED File. If one of these activities
became unavailable, another alternative can be e xecuted to
guarantee the system operability until all processes return to an
optimum state.
Indicate external dependences:
External dependences are important to be expressed as
they can lead to interoperability problems and impact on
self-healing principle. Figure 6 presents that the task
“Receive CAGED Receipt” is impacted if “Receive CAGED
File” is unavailable.
Highlight monitorable activities:
Some events are too complex and have to be processed by
different kind of components. Hence, some are monitorable
and others not. For example the “Generate analyzed CAGED
File” task is executed out of MTE dominium by an offline
desktop tool that is not expressed in SLA as m onitorable
module. In our example the monitored tasks, such as
“Receive CAGED File” are depicted in gray.
Define the autonomic characteristics and symptoms
of monitorable activities:
Indicate the autonomic principles that will be considered to
monitor the activities. The SLA document is a good source of
information. In the running example, we only consider the selfoptimization
(SO) principle to all monitorable activities.
2) Define Operational Level: Operational Level must
express all t he tasks that must be performed if some
deviation in the NFR defined in SLA occur:
Operationalizations according to NFR
Characteristics:
In our running example, we defined Self-Optimization
(SO) as the desired autonomic principle. As previously
noted, SO is related to the efficiency NFR, which in turn can
be decomposed into others characteristics such as Response
Time and Space Utilization. In this example, we deal only
with Response Time attribute.
In order to treat Response Time deviations that may be
related to the performance of the “Receive CAGED File”
activity, we defined in Figure 6 (S2 box) three different
activities (operationalizations): (i) Increase resource; (ii)
Decrease Resource; and (iii) Analyze deviation.
C. Step S3 - Linking Autonomic Business Processes and
Services
When providing software adaptation we define the link
between Business Processes with their respective services,
presented in the Service Level (Figure 6, box S3).
534