This page contains the Supporting Online Material for the BPM’14 submission:
“Strategies for Specifying Flexible Human Behavior in Interaction-Intensive Process Environments” Christoph Dorn, Schahram Dustdar, Leon J. Osterweil
Abstract: Fast changing business environments characterized by ill-predictable variations call for flexible process-aware systems. Over the past 15 years, research in the BPM community addressed this challenge through various approaches that range from activity-centric ad-hoc techniques, to case-based and declarative specifications, to flexible work-flow systems. These efforts predominately address flexibility at the process, artifact, and resource level.
Little focus has been on how to specify (respectively constrain) flexible human involvement: how human process participants may collaborate on a task, how they may obtain a joint decision that drives the process, or how they may communicate out-of-band for clarifying task-vital information. Experience has shown that pure process languages are not necessarily the most appropriate technique for specifying such flexible behavior. Hence selecting appropriate modeling languages and strategies needs thorough investigation. To this end, this paper juxtaposes the capabilities of representative human-centric specification languages hADL and Little-JIL, as well as outlines three concrete modeling strategies for specifying human behavior. Two real world use cases evaluate the different outcomes for each strategy and provide insight into when and why to apply a particular language type.
For sake of clarity, we provide the complete Section 4 including all figures (also those available in the paper).
Section 4: Evaluation
In this section we introduce two case studies for exemplifying the differences of the modeling strategies. We evaluate to what degree the complementary capabilities of hADL and Little-JIL successfully manifest as synergies in each use case with respect to the chosen strategy, what qualities the respect strategies foster as well as what limitations emerge. Due to page limitations, figures non-vital to understanding are available as supporting online material (SOM) at http://wp.me/P1xPeS-5a only.
Use Case 1: Monitoring Critical Infrastructure
Use Case 1 focuses on monitoring and safety systems which range in scope from a small security team handling an office building to thousands of personnel in back offices and on site at geographically distributed locations to secure critical infrastructure. Back office operators dynamically subscribe to a plethora of information sources such as high definition video streams.
Occasionally, video server become overloaded and operators have to decide on dropping a particular stream or reducing its quality as typically autonomic approaches cannot establish the correct relevance of individual streams. Various procedures variations exist that govern how system users may mutually identify those streams, who approves those decisions, and who becomes notified. In the following paragraphs, we demonstrate what specifications the designer may potentially arrive at when applying the proposed strategies.
First, the process designer decomposes the high-level goal (selecting one or more streams) into a task hierarchy exhibiting individual leaf steps which directly map to user behavior (Fig.SOM-B). When AutomationFailed, GroupUsersPerStream divides users into groups for each stream hosted by the overloaded streaming component. In the subsequent CoordinateDrop step, for each identified group, each member is asked whether the associated stream may be dropped or reduced quality-wise (AskGroupToDrop). Simultaneously, all members are invited to discuss the selection options (InviteToDiscuss). Thereafter, the process starts ListenForDecision, checks for sufficient selections, and if so continues with checking whether the team leader needs to confirm the decision (see subprocess in Fig.SOM-C). If the leader declines or insufficient selections were available, the InsuffSelection exception handler causes the SelectionCheck step to be repeated. In case of a valid decision, all participants receive notifications of the selection outcome (and the parent process obtains the decision for actual execution).There are four steps where the process assumes a collaboration connector role for interacting with users (see Fig.SOM-D). The hADL model specifies the type of interaction: a task for asking to drop a stream, a discussion stream (e.g., ChatRoom) for exchanging preferences, a decision from users that have identified a low-priority stream, and a message for notifying users on the decision outcome. Note that the leader’s involvement can be directly specified in Little-JIL via the agent resource definition.
Following the interaction-centric methodology, the designer elaborates the various user roles and collaboration connectors that coordinate the interaction among users and between users and the adaptation process. Fig.SOM-E depicts DecisionMaker, ChatUser, and TeamLeader roles, including the adaptation process assuming the role of TaskClient. In addition, the hADL model features four distinct collaboration connectors. Upon receiving a SelectionTask, the SelectionCollector assigns SelectionJobs to all DecisionMakers and receives their individual SelectionDecisions. Internal logic determines when it needs to publish the current status to a CurrentSelectionStream, subsequently updated whenever new incoming decisions mandate so. The DecisionChecker connector consumes selection decisions, checks whether the team leader needs to confirm, and if so, invokes a RequestReply pattern. An accepted decision becomes the TaskResult (part of the SelectionTask subpattern, see Fig.SOM-E} inset). The ModeratorConnector retrieves SelectionTask details simultaneously, sets up a ChatRoomStream and adds ChatUsers. Available TaskResults signal the connector to tear down the chat room. The same signal also triggers the OutcomeNotifyer connector (featuring basic observer logic) to notify all decision makers on the final Outcome.
With most logic being event driven, the process designer restricts the application of Little-JIL to specifying the SelectionCollector connector’s internal logic. Fig.SOM-F outlines the specific steps. A selection task triggers the connector. It first sends out selection jobs then loops for collecting decision input, aggregates decisions and publishes them when required. Simultaneously, the connector listens for task changes such as additional or removed decision makers, required decision count, or task cancelation.
The process designer converges on the central artifacts. In the underlying scenario, the three major, distinct artifacts are the SelectionTask, the Decision pattern, and the DiscussionArtifact around which DecisionMakers coordinate (Fig.SOM-G). Besides the artifacts, the designer, also identifies the manipulating participants, i.e., the AdaptationProcess as client, self-coordinating DecisionMakers, and the confirming TeamLeader. The decision pattern refinement reflects the complexity and coming about of the desired selection procedure outcome. The pattern substructure provides further details how the active model participants become involved to ultimately arrive at the final decision (Fig.SOM-G inset). The DecisionConnector turns the decision pattern into an active artifact. The connector (i) receives individual decisions as messages, (ii) updates the progress in an internal DecisionStatus artifact thereby enabling DecisionMakers and TeamLeader to monitor status and outcome, (iii) processes decision confirmations (or rejections), and (iv) finally notifies the selection task client of the outcome.Again, a Little-JIL process defines the internal DecisionConnector logic (Fig.SOM-H). First, the connector listens for user decisions, updates the status upon each decision, and determines if the leader needs to be involved. The UpdateStatus step throws an Exception handled by the InsufficientDecision step to indicate that more decision need to arrive. With sufficient individual decisions available, the WrapUp step involved checking with the leader or automatically confirms the selection, sets the status to complete, and notifies the selection client of the outcome. In case the leader does not agree, the whole process repeats (i.e., waits for more user decisions).
Use Case 2: Hospital Patient Handling
In the second use case, we analyze the potential for human flexibility in emergency department (ED) processes. Efficient and effective ED processes rely on optimal resource usage through adaptation. This includes determining the optimal number of personnel such as Physicians, Nurses, Triage Nurses, or Clerks, their activities, and constraints on the combination of activities and personnel. In prior work, Raunak and Osterweil investigated dynamic resource modeling and resource constraints for improving ED processes. Example evaluations demonstrated the effect of requiring the same doctor conducting the initial and final patient assessment compared to having any available doctor carrying out final assessment.
Typically, a hospital determines a-priori the specific assessment strategy and constraint thresholds which remain unchanged during operation. The applicability of such rules and strategies, however, is highly dependent on the dynamically changing ED context and highlights the potential benefit for ad-hoc involving actual humans in the dynamic resource allocation procedure. Clerks and nurses observe the number of waiting patients and may coordinate with doctors on when to switch away from the same-doctor assessment constraint in order to maintain short patient Length-of-Stay (LOS). Triage nurses may agree on switching upcoming patient-to-bed assignments depending on last minute changes in patient acuity. Triage nurses may also obtain permission from supervisors to assist in nurse activities and thereby briefly violate resource allocation constraints. We build upon the ED processes detailed in  and show the human involvement specifications result when applying the three modeling strategies.
Given that flexible human coordination actions in this domain are typically tightly interwoven with regular activities, Strategy 1 naturally lends to modeling the human-centric adaptation steps as part of the main ED process. The PatientInsideEDScope step assumes registered patients that first need placement in a bed (see Fig.SOM-J) . The HighNurseLoadHandler becomes active when available nurses are overloaded and thus unable to carry out PlacePatientInBed and resource allocation rules yet keeping triage nurses from substituting. In this situation, triage nurses can volunteer upon coordination with the ED supervisor and subsequently engage in the AltPlacePatientInBed step. In case no triage nurse volunteers or the supervisor declines the substitution, the ReqDeclined step executes a blocking PlacePatientInBed step. If a bed is unavailable, a nurse may initiate a swap or, upon failure, will simply wait for a bed blocking. After successful BedAssignment and AssessAndTreat, the EvalLoad subprocess (see Fig.SOM-K) checks whether the overall patients acuity and resource load level demands a switch from FinalAssessmentSame to FinalAssessmentDiff strategy or vice versa. The subprocess notifies physicians of the potential change, and obtains their objections (including a supervisor overrule decision). Hospital-specific rules ultimately determine the conditions when to SwitchStrategy, which includes informing all relevant personnel.hADL-encoded interaction between the ED process and personnel only involved in the flexible regions is depicted in Fig.SOM-L. All communication with Physicians, Supervisor and TriageNurses occurs via messages. Coordination for switching bed-patient assignment can be completely modeled within Little-JIL.
The main ED process remains unaffected when following Strategy 2. The hADL model (see Fig.SOM-M) focuses on the coordination among Physicians, Supervisor, TriageNurse, and regular Nurses when to switch assessment strategies, and when to volunteer for role substitution. The ResourceManager monitors the assignment of Nurses to process steps and issues NurseLoadAlerts as required. In this case the TaskAllocator connector creates a VolunteerSelection artifact, invites TriageNurses, observes who indicates their availability, waits for Supervisor confirmation and only then returns a ResourceSubstitutionConfig message to the ResourceManager. Similarly, the StrategySwitcher observes ResLoadStatusUpdates, collects Physicians‘ opinions on whether to switch, considers a Supervisor’s overruling, and informs ED Process instances of the agreed StrategyChange.In addition to hADL, Little-JIL specifies the StrategySwitcher’s behavior (see Fig.SOM-N). The connector listens to updates and processes them until reaching a particular threshold on resource utilization. After it NotifiesPhysiciansAndSupervisor regarding the switch plan, it processes all changes to the StrategySwitchPlan artifact within the ObservePlanChanges step before continuing with setting the new strategy. The TaskAllocator connector features almost identical behavior.
The artifact-centric Strategy 3 primarily identifies shared artifacts that describe resource status and resource strategies (Fig.SOM-P). Personnel coordinate around those artifacts. Specifically, Physicians and Supervisors have a shared view on the current AssessmentStrategy. The ResourceMonitor monitors PatientWaitingList, BedOccupancyList, and the NursePool for deciding when to trigger checking of the current AssessmentStrategy‘s adequacy. The NursePool provides an up-to-date view of nurses’ task load and thus enables TriageNurses to volunteer for substitution. The Supervisor observes these changes and confirms any volunteering offer.The NursePool becomes an active, complex artifact with a Little-JIL process specifying its behavior (Fig.SOM-Q). Three highlevel parallel steps take care of (i) processing nurse status updates, (ii) processing volunteering offers and their confirmation, as well as (iii) handling the retirement of triage nurses from resource substitution. Each of these three sub-processes completes by publishing artifact update notifications.
Strategy Analysis and Comparison
As a process-centric language, Little-JIL unfolds its full potential by providing rigorous, detailed specification of task dependencies, process artifact flow, and exception handling (Fig.SOM-B & SOM-J). In Use Case 1, we can thus handle leader disagreement differently than leader agreement. In Use Case 2, we can react to overloaded nurses or unavailable beds. On the downside, it’s extremely tedious to express explicitly that multiple users (i.e., agents) interact directly. Little-JIL step descriptions such as InviteToDiscuss in UC1 or ObtainVolunteer in UC2 only imply such coordination.
For each use case, Strategy 1 results in a single, central process which maintains control over the complete work scope. The process foresees only user involvement (e.g., step execution, message dispatching, discussion) that is initiated by the process engine at runtime. Users may provide input asynchronously but only upon earlier process initiated request. hADL assists in further detailing any Little-JIL leaf steps that involve simultaneous communication with multiple users, their direct coordination mechanisms, and their returned input (Fig.SOM-D & SOM-L). hADL thereby highlights interaction-centric dependencies among Little-JIL steps.
Utilizing hADL as the primary modeling language results in emergence of several collaboration connectors with distinct coordination tasks. In Use Case 1 (Fig.SOM-E), the OutcomeNotifying monitors the SelectionTask and ultimately issues a notification, the SelectionCollector distributes jobs and collects their results, the ModeratorConnector manages the chat room, and the DecisionChecker ensures that the TeamLeader only becomes involved for confirmation when required. The initial automatic AdaptationProcess may only issue the SelectionTask and observe its progress, respectively final result. It’s completely decoupled from the logic governing the SelectionCollector. Similarly, in Use Case 2 (Fig.SOM-M), the StrategySwitcher and TaskAllocator connectors manage the user feedback and confirmations on shared artifacts. Interaction with the ED Process occurs only through the StrategyChange messages and implicitly through reconfiguration of the ResourceManager.
With a structure-centric language such as hADL, we gain a good understanding how user may interact through which shared artifacts, messages, and streams. Yet, there is no central process coordinating the user involvement in either use case, which leaves the effect of complex connectors on the overall model under-specified. Little-JIL reduces this ambiguity by specifying connector internal logic. It then becomes clear, for example, that the SelectionConnector first receives a SelectionDecision, and only then updates the CurrentSelectionStream (Fig.SOM-F). In contrast to process-driven specifications emerging from Strategy 1, here the resulting Little-JIL-based connector specifications will primarily react to events from the surrounding hADL model.
The hADL model primarily specifies users interaction around complex artifacts, where connectors assume only auxiliary roles. Connectors surface inside refined patterns (e.g., the DecisionConnector in Fig.SOM-G) or assist in artifact management (e.g., the ResourceMonitor in Fig.SOM-P). Such hADL-based pattern refinement and/or Little-JIL centric behavior specification (Fig.SOM-Q) turns otherwise passive artifacts into active elements. As a consequence, behavior, which Strategies 1 and 2 would have placed inside dedicated connectors at the top most modeling level now become tightly integrated with the artifact definition.
The two use cases have highlighted hADL and Little-JIL’s synergies. Different strategies, however, yield different model qualities. Note that these properties primarily emerge from these languages’ basic nature and features; and not because of their exact representation.
Strategy 1 primarily targets situations that require tightly controlled and unambiguous human adaptation involvement. Little-JIL provides the rigorous step and constraint specification, exception handling, and resource specification. hADL complements the Little-JIL process specification when interactions cannot sensibly be described and thus would otherwise remain under-specified.
Strategy 2 takes the inverse approach to Strategy 1. It applies to environments with extensive user-driven interaction and coordination where the outcome cannot be easily be described in the form of a single overarching process. Hierarchical refinement cannot adequately capture task dependencies within complex connectors. Here Little-JIL mitigates the hADL-inherent ambiguity.
Strategy 3 addresses environments where neither a single process describes the overall adaptation scope nor a human component and collaboration connector approach would adequately reflect the artifact complexities. The third strategy also serves well to specify simultaneous user involvement in multiple, distinct processes (i.e., a process becomes a shared artifact) and thus enables modeling of hidden dependencies not expressible in Little-JIL.
In short, the designer chooses the language(s) that support specifying the kind of details about which she would like to reason upon and understand. If control is desired, she tends towards a Little-JIL-style language. If flexibility and human initiative is to be emphasized and understood, then she opts for hADL.
As mentioned in the introduction, previous research demonstrated the independent applicability of Little-JIL and hADL. Replying on a single language only, however, risks stretching it beyond its comfort zone.
Modeling detailed processes in hADL quickly becomes tedious while still not completely achieving Little-JIL’s rigor. A process in hADL comprises of dedicated CollaborationConnectors for each non-leaf step, a HumanComponent for each leaf step, and separate Messages for every input and output artifact. Ultimately, the process flow is implicitly defined through the message actions’ CRUD privileges. Fig. SOM-R depicts the pure hADL version of the [UC1-S2] SelectionConnector’s internal behavior (compare to the Little-JIL process in Fig.SOM-F).
Likewise, Little-JIL could describe the unstructured interaction occurring in a chat room. The corresponding process exhibits two types of agents: the human participants and software agents that take care of message persisting and routing. For the simple sequence of chat message sending, approving, and reading, a Little-JIL-based specification needs to pair every participant step (incl. moderator) with an software agent step that sends and receives the message. Thus it quickly becomes tedious to model all explicit message exchanges between HumanComponents and the CollaborationConnector’s moderation. Fig.SOM-S depicts the pure Little-JIL version of the [UC1-S2] Moderator, ChatRoomStream, and ChatUser excerpt (compare to the hADL model in Fig.SOM-E).
The evaluated use cases provide preliminary evidence on the strategies’ validity. We cannot claim that these three strategies yield the same qualities under any circumstances. The use cases, nevertheless, exhibit real world challenges that are generally valid beyond their domain.
Similarly, modeling according to one strategy doesn’t guarantee an appropriate adaptation behavior specification for the underlying problem. We strongly recommend integrated analysis of the produced hADL and Little-JIL specifications for desired properties such as expected duration, resource usage, termination conditions etc.
We need to stress that at no point are we suggesting that Little-JIL or hADL should replace any of the existing flexible process languages. This paper’s purpose is identifying language concerns and appropriate usage conditions for specifying human behavior in interaction-intensive processes environments.
 Raunak, M.S., Osterweil, L.J.: Resource management for complex, dynamic environments. IEEE Trans. Software Eng. 39(3), 384–402 (2013)