Modeling and Verifying Business Processes with ... - Science Direct

Available online at www.sciencedirect.com

ScienceDirect Procedia Computer Science 44 (2015) 345 – 353

2015 Conference on Systems Engineering Research

Modeling and Verifying Business Processes with Monterey Phoenix Mikhail Augustona, Kristin Giammarcoa, W. Clifton Baldwinb*, Ji’on Crumpb, Monica Farah-Stapletona b

a Naval Postgraduate School, Monterey, CA, USA Federal Aviation Administration, Pomona, NJ, USA

Abstract Monterey Phoenix (MP) has been designed as a framework for system and software architecture modeling and verification with focus on modeling the system’s and the environment’s behaviors. With the development of more case studies, advantages in using MP for business process modeling and analysis applications are beginning to emerge. Models of business processes aim to capture high level operational activities and decision points of an organization, describing processes ranging from product lifecycle to government operations. Businesses and governments seeking to make improvements to their processes may model them for the purpose of seeking improvements in schedule and task execution, product quality, risk reduction, and lifecycle / operating costs. MP enables activities to be modeled as events with two basic relations: precedence and inclusion, making it a candidate modeling language for business process analysis. By offering high level abstractions for interaction behavior modeling and separating component behaviors from the component interactions, MP supports a multidimensional picture of concurrent behaviors, with overlapping threads of process phases and participating actors, including environment behaviors. MP models are executable and may be used to generate an exhaustive set of possible business process scenarios up to a given scope limit. © by Elsevier B.V. is anB.V. open access article under the CC BY-NC-ND license © 2015 2015 Published The Authors. Published byThis Elsevier (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the scientific committee of Stevens Institute of Technology. Peer-review under responsibility of the Stevens Institute of Technology. Keywords: Monterey Phoenix; behavior modeling; business process modeling, architecture; formal methods; scenario generation

1. Introduction An observation in a popular book on software architecture1 states: “Every system has an architecture, whether or not it is documented and understood.” The need for an abstract layer of system description is a well-accepted idea in the systems engineering community. System modeling approaches2,3,4,5,6 provide a multitude of views for the stakeholders. The set of concerns an engineer has to deal with (e.g., weight and balance constraints; reliability, * Corresponding author. E-mail address: [email protected]

1877-0509 © 2015 Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Stevens Institute of Technology. doi:10.1016/j.procs.2015.03.055

346

Mikhail Auguston et al. / Procedia Computer Science 44 (2015) 345 – 353

hardware/software performance) is typically different from those of a project manager (e.g., organizational performance, schedule and cost), yet there exists a set of concerns (e.g. overall system performance, meeting specified requirements), that is shared by both communities, and can indeed be captured at the architecture level of abstraction. This paper proposes the use of Monterey Phoenix (MP)7-11 as a business process modeling language to add analysis capabilities that exceed the scope of current business modeling notations and tools. Business (or operational) processes are "the logical organization of people, materials, energy, equipment, and procedures into work activities designed to produce a specified end result (work product)."12 They aim to capture operational activities and decision points of an organization. These may be systems or software engineering processes including: Vee, Waterfall and Agile; Government processes such as the Joint Capabilities Integration Development System (JCIDS) and those supporting Defense Acquisition; or military / civil service processes such as the Military Decision Making Process (MDMP) and operational mission execution processes such as Conduct Search and Rescue. There are many standard (and often complicated) processes described in government policies, instructions, directives, manuals and other documents specifying activities for a variety of tasks. Many of these process descriptions are described using natural language or flowcharts, are frequently incomplete, and contain serious deficiencies and even errors. It seems that Rozanski’s observation about system architecture is valid for process architecture as well, and process behavior can benefit from rigorous modeling and verification at an appropriate abstraction level. The MP modeling approach intended for system design and verification may be applied to these systems development processes as well. There are standard, repeatable patterns in these processes that can modeled and studied for possible improvements. Organizations seeking to make improvements to their processes may look for possible gains in efficiency of task execution and schedule, product quality, risk reduction, lifecycle / operating costs, and other high level concerns. The main research question addressed in this paper is the following: “how does MP advance modeling of business processes?” 2. Current BPM approaches There exist several mathematical modeling frameworks for the description of distributed systems, such as Petri nets13 with its Petri Net Markup Language14 and process algebras, like Pi-calculus15. Workflow specification languages often use one of these formalisms for precise semantics definitions. There is a semantic mapping of Business Process Execution Language (BPEL) on the Pi-calculus16. Along the same lines, there is the YAWL (Yet Another Workflow Language)17 with semantics based on Petri nets, and Little-JIL, a language for programming coordination.Error! Reference source not found. Our choice for executable behavior model semantics is based on the concept of grammar derivation: top-down and left-to-right, the event trace representing the instance of behavior is derived from the event grammar rules with some additional compositions. Grammars provide simple and easy to comprehend framework for many computing domains. Like the executable Discrete Event Simulation (DES) models of Business Process Modeling Notation (BPMN), Functional Flow Block Diagram (FFBD)3, and Enhanced FFBD (EFFBD)4, MP enables activities to be modeled as events with attributes like duration, cost, impact, and probability of occurrence. The Unified Modeling Language (UML)5 and System Modeling Language (SysML)6 also include activity and sequence diagrams that are reproducible with MP. Traditional business process modeling frameworks (BPEL, BPMN, UML, IDEF)19, however, are constrained by the “single flowchart” paradigm. These models attempt to capture behaviors of all interacting systems / components in one basket, with all the negative consequences (similar to the multi-actor approach using EFFBDs10). Keeping all process behaviors in a single flowchart makes it hard to read, modify, and maintain, and makes it error-prone, all of which are not conducive to analysis. Moreover, flowchart formalism does not provide sufficient support for specifying different kinds of interactions needed at this level of abstraction (some specification formalisms provide a restricted form of interaction modeling. For example, message passing in Specification and Description Language (SDL) for specification and description of the behavior of reactive and distributed systems).

Mikhail Auguston et al. / Procedia Computer Science 44 (2015) 345 – 353

3. Monterey Phoenix relevance to BPM MP offers a high level of abstraction for behavior modeling and separates the concerns of component behavior and component interaction, a significant distinction from the current single flowchart modeling paradigm. Separation of these concerns makes models more flexible, manageable, reusable, and supports multi-dimensional behavior models with interacting and overlapping phases and actors. Many BPMLs are executable, however: • In MP, we can provide immediate, visualized, and exhaustive feedback for model testing. Humans understand examples better than general formal models; typical BPM users are not professional mathematicians and need the analysis conducted and reported using familiar language and examples. • Environment behavior is as important for processes as it is for any system’s architecture. Traditional BPMLs do not account for the behavior of the environment as part of the model. • Assertion checking does not yet exist in available BPMLs. When the number of possible scenarios for the process grows large, browsing use cases (scenarios/event traces) can be prohibitively time consuming. Automation is needed to check each of the use cases extracted from the process model against a precise property specification (the formal assertion). • MP supports extraction of abstract views, a concept familiar to system architects but still foreign to business process modelers. • Event probabilities in MP models open the path to statistical process analysis. • Well-established, effective processes can be reused, and MP has composition operations supportive of the model reuse. • Modeling should support process cost/performance estimates, including the good old “critical path” analysis from PERT.20 MP is supportive of these techniques. 4. Cargo screening process (Example 1) This example shows how formalizing a flow chart using MP helped to test and debug the original flowchart. As it often happens with unstructured documentation, the mere attempt to formalize brings the discovery of potential errors and omissions. Figure 1 shows a flowchart that is typical of process documentation in the current practice.

Fig. 1. Flowchart of CSI Cargo Screening Process, from21

347

348

Mikhail Auguston et al. / Procedia Computer Science 44 (2015) 345 – 353

The need to organize the process description into larger phases in an enhanced flowchart is clearly evident. The omission found in this example, as revealed in the code that follows, is that the flowchart does not specify what happens if selection_has_not_been_accepted. In this case, PhysicalExamination and AnomalyResolution were added as a follow-up in the MP model. The following MP schema captures the updated process model. The schema uses text to express compositions regularly used in graphical notations in a form that is more compact and expressive. (A B C) is an ordered sequence of events, (A | B | C) represents alternative events from which a selection is made, (* A B C *) is ordered iteration (A B C repeated zero or more times), and composite events are used encapsulate other event sets. Root event in this case corresponds to the single independent thread of activities performed within the process. ^,DĂƌŐŽ^ĐƌĞĞŶŝŶŐ  dĂƌŐĞƚŝŶŐ͖ ZKKdĂƌŐŽ^ĐƌĞĞŶŝŶŐWƌŽĐĞƐƐ͗^ĐƌĞĞŶŝŶŐ  ^ĐƌĞĞŶŝŶŐ͗WͺKĨĨŝĐĞƌƐͺĂŶĂůLJnjĞͺƐŚŝƉƉŝŶŐͺŝŶĨŽƌŵĂƚŝŽŶͺƚŽͺŝĚĞŶƚŝĨLJͺŚŝŐŚͺƌŝƐŬͺĐĂƌŐŽ͖  dĂƌŐĞƚŝŶŐ͗WͺKĨĨŝĐĞƌƐͺƌĞǀŝĞǁͺƚŚĞͺƐŚŝƉƉŝŶŐͺŝŶĨŽƌŵĂƚŝŽŶ WͺKĨĨŝĐĞƌƐͺƐĞůĞĐƚͺŚŝŐŚͺƌŝƐŬͺĐĂƌŐŽͺƚŽͺďĞͺƉƌĞƐĞŶƚĞĚͺĨŽƌͺŝŶƐƉĞĐƚŝŽŶ   ;,ŝŐŚͺƌŝƐŬͺĐĂƌŐŽͺƐĞůĞĐƚĞĚ  /ŶƐƉĞĐƚŝŽŶͮ  EŽͺŚŝŐŚͺƌŝƐŬͺĐĂƌŐŽͺƐĞůĞĐƚĞĚ  >ŽĂĚŝŶŐ Ϳ͖  /ŶƐƉĞĐƚŝŽŶ͗;ƐĞůĞĐƚŝŽŶͺŚĂƐͺďĞĞŶͺĂĐĐĞƉƚĞĚ ƚŚĞͺĐĂƌŐŽͺŝƐͺƐĐĂŶŶĞĚͺƵƐŝŶŐͺůĂƌŐĞͺƐĐĂůĞͺE//ͺĞƋƵŝƉŵĞŶƚ   ŶŽŵĂůLJͺĚĞƚĞĐƚŝŽŶͺĂŶĚͺƉƌŽĐĞƐƐŝŶŐ   ͮ  ͬͬƚŚŝƐďƌĂŶĐŚŝƐŵŝƐƐŝŶŐŝŶƚŚĞŽƌŝŐŝŶĂůĚŽĐƵŵĞŶƚ͊   ƐĞůĞĐƚŝŽŶͺŚĂƐͺŶŽƚͺďĞĞŶͺĂĐĐĞƉƚĞĚ WŚLJƐŝĐĂůdžĂŵŝŶĂƚŝŽŶ   ŶŽŵĂůLJZĞƐŽůƵƚŝŽŶ     Ϳ͖  ŶŽŵĂůLJͺĚĞƚĞĐƚŝŽŶͺĂŶĚͺƉƌŽĐĞƐƐŝŶŐ͗ ŶŽŵĂůLJĞƚĞĐƚŝŽŶ     ;dŚƌĞĂƚ/ƐEŽƚ&ŽƵŶĚ >ŽĂĚŝŶŐͮ       ŶŽŵĂůLJ/Ɛ&ŽƵŶĚ      WŚLJƐŝĐĂůdžĂŵŝŶĂƚŝŽŶ      ŶŽŵĂůLJZĞƐŽůƵƚŝŽŶ Ϳ͖  ŶŽŵĂůLJĞƚĞĐƚŝŽŶ͗ WͺKĨĨŝĐĞƌƐͺŽƌͺŚŽƐƚͺĐŽƵŶƚƌLJͺŽĨĨŝĐŝĂůƐͺŝĚĞŶƚŝĨLJͺĂŶŽŵĂůŝĞƐͺŝŶͺƚŚĞͺdžͺƌĂLJͺŝŵĂŐĞ͖  WŚLJƐŝĐĂůdžĂŵŝŶĂƚŝŽŶ͗ WͺKĨĨŝĐĞƌƐͺŽƌͺŚŽƐƚͺĐŽƵŶƚƌLJͺŽĨĨŝĐŝĂůƐͺŽƉĞŶͺĐŽŶƚĂŝŶĞƌƐͺƚŽͺůŽĐĂƚĞͺĂŶŽŵĂůLJ͖  ŶŽŵĂůLJZĞƐŽůƵƚŝŽŶ͗ KĨĨŝĐŝĂůƐͺĚĞƚĞƌŵŝŶĞͺŝĨͺƚŚĞĂŶŽŵĂůLJͺƉƌĞƐĞŶƚƐͺĂͺƚŚƌĞĂƚ    ;dŚƌĞĂƚ/ƐEŽƚ&ŽƵŶĚ >ŽĂĚŝŶŐͮ dŚƌĞĂƚ/Ɛ&ŽƵŶĚ ZĞƐŽůƵƚŝŽŶͿ͖  ZĞƐŽůƵƚŝŽŶ͗ KĨĨŝĐŝĂůƐͺƚĂŬĞͺĂƉƉƌŽƉƌŝĂƚĞͺƐƚĞƉƐͺƚŽͺƌĞƐŽůǀĞͺƚŚĞͺƚŚƌĞĂƚ͖  >ŽĂĚŝŶŐ͗ dŚĞͺĐŽŶƚĂŝŶĞƌͺŝƐͺůŽĂĚĞĚͺŽŶƚŽͺƚŚĞͺĐĂƌŐŽͺƐŚŝƉ͖ While existing BPM languages may be used to find such omissions (just by the mere attempt to formalize the initial informal description), MP may be used to verify this model with automated tools in order to: • Generate all possible scenarios and inspect them manually. If not identified and corrected during the model building stage, the deficiency pointed out above would be obvious during such an inspection.

Mikhail Auguston et al. / Procedia Computer Science 44 (2015) 345 – 353

• Write assertions that may be verified, like: "is Loading event always preceded by ThreatIsNotFound or No_high_risk_cargo_selected event?" • Write queries, like: "show all scenarios when Loading event does not happen." 5. Segmented activities of a commercial flight operation (Example 2) In process modeling it is often useful to consider multidimensional threads of behavior. Modeling actors’ behavior by phase, as in different segments of the activity, as well as by decision point, adds dimensionality that is difficult to represent in a single flowchart diagram. This example shows how a complex process’ behavior presented by a Standard Flight SysML diagram can be split into separate overlapping and interacting behaviors. Consider an aviation scenario as depicted in Figures 2a and 2b, which provides a simplistic view of an uneventful Standard Flight through the National Airspace System (NAS). A commercial flight through the NAS is divided into phases that correspond to certain activities and require certain elements of air traffic control. For example, a flight at cruising altitude is in the En Route phase while over the continental United States and is monitored by the various Air Route Traffic Control Centers. However if the aircraft leaves the continental United States and travels over open waters, the phase of flight enters the Oceanic phase, which has some differences due to the lack of radar coverage over much of the oceans. There are other ways to describe the progression of a commercial flight, but the phases of flight adhere to our intention of remaining simplistic. The activity diagram in Figures 2a and 2b illustrates the interactions of the passenger, the pilot (or aircraft) and the air traffic controllers through each phase of flight, from Preflight through Landing (“single flowchart” SysML activity diagram). Notice how the phases along the top of this flowchart stretch the SysML formalism into a two-dimensional diagram. It would be challenging to add more sophisticated configurations of phases/actors if needed. Scenarios defined by this model include, for example, an alternate path for flights that leave the Continental United States and enter the Oceanic phase of flight. Oceanic is an alternate path as not all flights take this path. There are two additional alternate scenarios in this model, representing times when a controller may ask a pilot to hold the aircraft in queue (during the Takeoff phase, and again during the Approach phase). During Takeoff, the controller may issue a Hold in Queue request (possibly due to inclement weather conditions) after the aircraft has taxied to the runway. In this case the aircraft enters a departure queue and awaits clearance for takeoff. During Approach, the controller may direct the pilot to Hold at a set location until receiving clearance to land (possibly due to congestion at the airport). An actual flight would have many more alternate paths. The SysML activity diagram in Figures 2a and 2b served as the source to express the behaviors and interactions in the MP model. MP code is used to describe the behaviors and interactions of the main actors and phases, and in doing so, maps the SysML diagram into separate models of behavior for each component. Those behaviors are coordinated using SHARE ALL and COORDINATE composition and coordination operations in MP.

349

350

Mikhail Auguston et al. / Procedia Computer Science 44 (2015) 345 – 353

act Standard Flight 1st Half

Passenger

Preflight

Takeoff

Departure

Board Aircraft

Flight Check Pilot

Taxi

Hold in Queue

Liftoff

Change frequency

Controller

Pushback

Issue Ground Instruction

Departure Clearance

Clear for takeoff

Handoff to departure controller

Issue clearances

Handoff to En Route controllers

Fig. 2a. Standard Flight: Preflight, Takeoff, Departure Phases act Standard Flight 2nd Half

Descent

Approach

Landing

Passenger

En Route

Disembark

Oceanic extension

Pilot

Change frequency

Maneuver toward Airport

Hold

Enter approach line

Taxi to gate

Follow route Land

Controller

Taxi instruction Issue Instruction

Handoff to approach controllers

Clear descent

Handoff to Tower

Clears landing

Clear approach

Fig. 2b. Standard Flight: En Route, Descent, Approach, Landing Phases

The MP schema below illustrates the following: a) Each of the main flight phases and the main actors in the SysML diagram can be modeled separately. b) All behavior relationships in the SysML diagram are modeled as abstract interactions using the MP composition operations. c) It makes it easier to read/modify separate component behaviors within the process, and to change

Mikhail Auguston et al. / Procedia Computer Science 44 (2015) 345 – 353

interactions within a selected group of components without changing the rest of the model. All root events (or independent components of the process) in the MP model are concurrent threads of activities. ͬͬͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲ ͬͬ ŵĂŝŶƉŚĂƐĞƐ ͬͬͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲ ZKKdWƌĞĨůŝŐŚƚ͗  ;KĐĞĂŶŝĐdžƚĞŶƐŝŽŶͮ&ŽůůŽǁͺƌŽƵƚĞͿ  ŽĂƌĚŝƌĐƌĂĨƚ    ŚĂŶŐĞ&ƌĞƋƵĞŶĐLJϮ  &ůŝŐŚƚŚĞĐŬ  ,ĂŶĚŽĨĨͺƚŽͺdZŽŶϮ͖  ĞƉĂƌƚƵƌĞůĞĂƌĂŶĐĞ  ZKKdĞƐĐĞŶƚ͗   WƵƐŚďĂĐŬ  ůĞĂƌͺĚĞƐĐĞŶƚ  /ƐƐƵĞ'ƌŽƵŶĚ/ŶƐƚƌƵĐƚŝŽŶ   DĂŶĞƵǀĞƌͺƚŽǁĂƌĚͺŝƌƉŽƌƚ͖  dĂdžŝ͖ ZKKdƉƉƌŽĂĐŚ͗ ZKKddĂŬĞŽĨĨ͗   ;Ύ,ŽůĚΎͿ  ;Ύ,ŽůĚͺŝŶͺYƵĞƵĞΎͿ  ůĞĂƌͺĂƉƉƌŽĂĐŚ  ůĞĂƌͺĨŽƌͺƚĂŬĞŽĨĨ   ŶƚĞƌͺĂƉƉƌŽĂĐŚͺůŝŶĞ  >ŝĨƚŽĨĨ  ,ĂŶĚŽĨĨͺƚŽͺƚŽǁĞƌ͖  ,ĂŶĚŽĨĨͺƚŽͺdZŽŶ͖ ZKKd>ĂŶĚŝŶŐ͗ůĞĂƌͺůĂŶĚŝŶŐ ZKKdĞƉĂƌƚƵƌĞ͗  >ĂŶĚ  ŚĂŶŐĞ&ƌĞƋƵĞŶĐLJ  dĂdžŝͺŝŶƐƚƌƵĐƚŝŽŶ  /ƐƐƵĞůĞĂƌĂŶĐĞƐ  dĂdžŝͺƚŽͺŐĂƚĞ  ,ĂŶĚŽĨĨͺƚŽͺZd͖  ŝƐĞŵďĂƌŬ͖ ZKKdŶZŽƵƚĞ͗   /ƐƐƵĞ/ŶƐƚƌƵĐƚŝŽŶ ͬͬͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲ ͬͬ ŵĂŝŶĂĐƚŽƌƐ ͬͬͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲ ZKKdWĂƐƐĞŶŐĞƌ͗  >ĂŶĚ  ŽĂƌĚŝƌĐƌĂĨƚ  dĂdžŝͺƚŽͺŐĂƚĞ͖  /ŶƐŝĚĞĂďŝŶ ZKKdŽŶƚƌŽůůĞƌ͗  ŝƐĞŵďĂƌŬ͖  ĞƉĂƌƚƵƌĞůĞĂƌĂŶĐĞ ZKKdWŝůŽƚ͗   /ƐƐƵĞ'ƌŽƵŶĚ/ŶƐƚƌƵĐƚŝŽŶ  &ůŝŐŚƚŚĞĐŬ  ůĞĂƌͺĨŽƌͺƚĂŬĞŽĨĨ   WƵƐŚďĂĐŬ  ,ĂŶĚŽĨĨͺƚŽͺdZŽŶ  dĂdžŝ  /ƐƐƵĞůĞĂƌĂŶĐĞƐ  ;Ύ,ŽůĚͺŝŶͺYƵĞƵĞΎͿ  ,ĂŶĚŽĨĨͺƚŽͺZd  ůĞĂƌͺĨŽƌͺƚĂŬĞŽĨĨ   /ƐƐƵĞ/ŶƐƚƌƵĐƚŝŽŶ  >ŝĨƚŽĨĨ   ,ĂŶĚŽĨĨͺƚŽͺdZŽŶϮ  ŚĂŶŐĞ&ƌĞƋƵĞŶĐLJ  ůĞĂƌͺĚĞƐĐĞŶƚ  ;KĐĞĂŶŝĐdžƚĞŶƐŝŽŶͮ&ŽůůŽǁͺƌŽƵƚĞͿ  ůĞĂƌͺĂƉƉƌŽĂĐŚ  ŚĂŶŐĞ&ƌĞƋƵĞŶĐLJϮ  ,ĂŶĚŽĨĨͺƚŽͺƚŽǁĞƌ  DĂŶĞƵǀĞƌͺƚŽǁĂƌĚͺŝƌƉŽƌƚ  ůĞĂƌͺůĂŶĚŝŶŐ  ;Ύ,ŽůĚΎͿ  dĂdžŝͺŝŶƐƚƌƵĐƚŝŽŶ͖  ŶƚĞƌͺĂƉƉƌŽĂĐŚͺůŝŶĞ ͬͬͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲ ͬͬ&ůŝŐŚƚŵŽĚĞůʹĐŽŵƉŽŶĞŶƚŝŶƚĞƌĂĐƚŝŽŶƐĂŶĚŽǀĞƌůĂƉƉŝŶŐďĞƚǁĞĞŶĂĐƚŽƌƐĂŶĚƉƌŽĐĞƐƐƉŚĂƐĞƐ ͬͬͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲͲ WĂƐƐĞŶŐĞƌ͕WƌĞĨůŝŐŚƚ ^,Z>> ŽĂƌĚŝƌĐƌĂĨƚ͖ WĂƐƐĞŶŐĞƌ͕>ĂŶĚŝŶŐ ^,Z>> ŝƐĞŵďĂƌŬ͖ WŝůŽƚ͕WƌĞĨůŝŐŚƚ  ^,Z>> &ůŝŐŚƚŚĞĐŬ͕WƵƐŚďĂĐŬ͕dĂdžŝ͖ WŝůŽƚ͕dĂŬĞŽĨĨ  ^,Z>> ,ŽůĚͺŝŶͺYƵĞƵĞ͕>ŝĨƚŽĨĨ͖

351

352

Mikhail Auguston et al. / Procedia Computer Science 44 (2015) 345 – 353

WŝůŽƚ͕ĞƉĂƌƚƵƌĞ ^,Z>> ŚĂŶŐĞ&ƌĞƋƵĞŶĐLJ͖ WŝůŽƚ͕ŶZŽƵƚĞ  ^,Z>> KĐĞĂŶŝĐdžƚĞŶƐŝŽŶ͕&ŽůůŽǁͺƌŽƵƚĞ͕ŚĂŶŐĞ&ƌĞƋƵĞŶĐLJϮ͖ WŝůŽƚ͕ĞƐĐĞŶƚ  ^,Z>> DĂŶĞƵǀĞƌͺƚŽǁĂƌĚͺŝƌƉŽƌƚ͖ WŝůŽƚ͕ƉƉƌŽĂĐŚ  ^,Z>> ,ŽůĚ͕ŶƚĞƌͺĂƉƉƌŽĂĐŚͺůŝŶĞ͖ WŝůŽƚ͕>ĂŶĚŝŶŐ  ^,Z>> >ĂŶĚ͕dĂdžŝͺƚŽͺŐĂƚĞ͖ ŽŶƚƌŽůůĞƌ͕WƌĞĨůŝŐŚƚ ^,Z>> ĞƉĂƌƚƵƌĞůĞĂƌĂŶĐĞ͕/ƐƐƵĞ'ƌŽƵŶĚ/ŶƐƚƌƵĐƚŝŽŶ͖ ŽŶƚƌŽůůĞƌ͕dĂŬĞŽĨĨ ^,Z>> ůĞĂƌͺĨŽƌͺƚĂŬĞŽĨĨ͕,ĂŶĚŽĨĨͺƚŽͺdZŽŶ͖ ŽŶƚƌŽůůĞƌ͕ĞƉĂƌƚƵƌĞ ^,Z>> /ƐƐƵĞůĞĂƌĂŶĐĞƐ͕,ĂŶĚŽĨĨͺƚŽͺZd͖ ŽŶƚƌŽůůĞƌ͕ŶZŽƵƚĞ ^,Z>> /ƐƐƵĞ/ŶƐƚƌƵĐƚŝŽŶ͕,ĂŶĚŽĨĨͺƚŽͺdZŽŶϮ͖ ŽŶƚƌŽůůĞƌ͕ĞƐĐĞŶƚ ^,Z>> ůĞĂƌͺĚĞƐĐĞŶƚ͖ ŽŶƚƌŽůůĞƌ͕ƉƉƌŽĂĐŚ ^,Z>> ůĞĂƌͺĂƉƉƌŽĂĐŚ͕,ĂŶĚŽĨĨͺƚŽͺƚŽǁĞƌ͖ ŽŶƚƌŽůůĞƌ͕>ĂŶĚŝŶŐ ^,Z>> ůĞĂƌͺůĂŶĚŝŶŐ͕dĂdžŝͺŝŶƐƚƌƵĐƚŝŽŶ͖  KKZ/Ed ΨĂ͗dĂdžŝ&ZKDWƌĞĨůŝŐŚƚ͕Ψď͗ůĞĂƌͺĨŽƌͺƚĂŬĞŽĨĨ&ZKDdĂŬĞŽĨĨ     KΨĂWZ^ΨďK͖ KKZ/Ed ΨĂ͗,ĂŶĚŽĨĨͺƚŽͺdZŽŶ&ZKDdĂŬĞŽĨĨ͕Ψď͗ůĞĂƌͺĨŽƌͺƚĂŬĞŽĨĨ&ZKDĞƉĂƌƚƵƌĞ      KΨĂWZ^ΨďK͖ KKZ/Ed ΨĂ͗DĂŶĞƵǀĞƌͺƚŽǁĂƌĚͺŝƌƉŽƌƚ&ZKDĞƐĐĞŶƚ͕Ψď͗ůĞĂƌͺĂƉƉƌŽĂĐŚ&ZKDĞƐĐĞŶƚͺƉƉƌŽĂĐŚ     KΨĂWZ^ΨďK͖ The two-dimension SysML shape of this model can be extended and enhanced as needed in MP by adding new orthogonal phases, new actors, and new interactions. Since the model is executable, each modification can be immediately tested and debugged using automatically generated graphical representations of behavior instances that are straightforward to read and interpret, minimizing the cognitive load on the analyst. A prototype MP simulator, Eagle622, executes the above model† and produces directed acyclic graphs (event traces or instances of behavior). The resulting output (a sample of which is shown in Figure 3) provides an exhaustive, within the selected scope, set of all possible scenarios (a.k.a. use cases), with ability to expose some unanticipated yet feasible behaviors permitted by the design.

Fig. 3. First three phases of one of 32 scenarios generated by Eagle 6, at scope 3. Elements have been positioned to show the overlapping swim lanes from the original SysML model. Solid arrows represent precedence, dashed arrows represent inclusion.

Support for COORDINATE compositions is not implemented in the current version of Eagle6, so they are simulated with SHARE ALL compositions.

Mikhail Auguston et al. / Procedia Computer Science 44 (2015) 345 – 353

6. Summary and way ahead The mere attempt to formalize unstructured business models exposes potential errors and omissions. By formalizing processes using high level abstractions for interaction behavior modeling and separating component behaviors from the component interactions, MP supports a multidimensional picture of concurrent behaviors in business processes, with overlapping threads of process phases and participating actors, including environment behaviors. The MP approach enables a human to comprehensively model various scenarios in business processes, so that many possible behaviors are factored into the expected outcomes of process models. MP is easy to understand, modify, and verify, extending existing BPM tools with the capability to separate actors and activities through process phases. MP’s event grammar allows for high level process modeling out-of-the-box. Future work will attach durations, costs, probabilities and other attributes to events in order to provide schedule estimates, cost estimates, and performance estimates, and explore integration opportunities with current executable BPM languages and visualizations in widespread use to amplify their existing capabilities. Monterey Phoenix is a more complete method for the analysis of business processes and system behavior in general. More examples (including Example 2) and supporting information for Monterey Phoenix can be found at https://wiki.nps.edu/display/MP. References 1. Rozanski, N., Woods, E., 2012. Software Systems Architecture, 2nd Edition, Addison-Wesley. 2. National Institute of Standards and Technology, Draft Federal Information Processing Standards Publication 183: Integration Definition for Function Modeling (IDEF0). Gaithersburg, MD, December 21, 1993. 3. NASA, 2007, Systems Engineering Handbook, NASA/SP-2007-6105 Rev1. Washington, D.C., December 2007. 4. Long, J.E., 2000, Relationships between Common Graphical Representations Used in System Engineering, Proceedings of the SETE2000 Conference (Systems Engineering and Test and Evaluation), Brisbane, Queensland, November 15-17, 2000. 5. Booch, G., Jacobson, I., Rumbaugh, J., 2000, OMG Unified Modeling Language Specification, http://www.omg.org/docs/formal/00-0301.pdf 6. Object Management Group, 2012, Systems Modeling Language Specification, version 1.3, http://www.omg.org/spec/SysML/1.3/PDF 7. Auguston, M., 2009, Software Architecture Built from Behavior Models, ACM SIGSOFT Software Engineering Notes, 34:5. 8. Auguston, M., Whitcomb, C., System Architecture Specification Based on Behavior Models, in Proceedings of the 15th ICCRTS Conference (International Command and Control Research and Technology Symposium), Santa Monica, CA, June 22-24, 2010. 9. Auguston, M., Whitcomb, C., Behavior Models and Composition for Software and Systems Architecture, Proceedings of the 24th ICSSEA Conference (International Conference on Software and Systems Engineering and their Applications), Paris, France, October 23-25 2012. 10. Giammarco, K., Auguston, M., “Well, You Didn’t Say Not to! A Formal Systems Engineering Approach to Teaching an Unruly Architecture Good Behavior,” Complex Adaptive Systems Conference, Baltimore, MD, November 13 - 15, 2013. 11. Farah-Stapleton, M., Auguston, M., “Behavioral Modeling of Software Intensive System Architectures,” Complex Adaptive Systems Conference, Baltimore, MD, November 13 - 15, 2013. 12. Pall, G.A, Quality Process Management, Englewood Cliffs, New Jersey: Prentice-Hall, 1987. 13. Wolfgang Reisig. 1991. Petri Nets and Algebraic Specifications. Theoretical Computer Science 80(1), pp.1-34. 14. Hillah, L.M. et al., 2009. A primer on the Petri Net Markup Language and ISO/IEC 15909-2. Petri Net Newsletter, 76, pp.9–28. 15. R. Milner. Communicating and Mobile Systems: The Pi-Calculus. Cambridge University Press, Cambridge, UK, 1999. 16. R. Lucchi and M. Mazzara. A pi-calculus based semantics for ws-bpel. Journal of Logic and Algebraic Programming, 70 (2007), pp.96-118 17. Van der Aalst, W.M.P. & ter Hofstede, A.H.M., 2005. YAWL: yet another workflow language. Information Systems, 30(4), pp.245–275. 18. Cass, A.G. et al., 2000. Little-JIL/Juliette: A Process Definition Language and Interpreter. In Proceedings of the 22nd International Conference on Software Engineering. 22nd International Conference on Software Engineering. Limerick, Ireland, pp. 754–757.  *URVVNRSI'HFNHUDQG:HVNH)HE 7KH3URFHVV%XVLQHVV3URFHVV0RGHOLQJXVLQJ%3010HJKDQ.LIIHU3UHVV  )D]DU:3URJUDP(YDOXDWLRQDQG5HYLHZ7HFKQLTXH7KH$PHULFDQ6WDWLVWLFLDQ9RO1R$SULO S 21. Department of Homeland Security, Office of the Inspector General, OIG-10-52, “CBP's Container Security Initiative Has Proactive Management and Oversight but Future Direction Is Uncertain.” Letter Report, February 2010 22. Rivera Consulting Group, Eagle 6 Modeling, http://eagle6modeling.riverainc.com/, retrieved August 15, 2014.

353