WOKE: A novel workflow model editor

WOKE: A novel workflow model editor Mikko Honkonen, Lauri Matilainen, Erno Salminen, Timo D. Hämäläinen Tampere University of Technology, Department of Pervasive computing, P.O. Box 553, 33101 Tampere, Finland Email: {mikko.honkonen, lauri.matilainen, erno.salminen, timo.d.hamalainen}@tut.fi Abstract— This paper presents a new work-in-progress tool, WOKE, to capture and present the workflow model in a novel way. A workflow model consists of linked steps to describe how actual work is done in a company and usually used for analysis and simulation. The complexity of modern System-on-Chip designs motivates applying such enterprise oriented models to the embedded design process domain as well. For example, UML Activity diagrams, YAWL, BPMN2.0, and flowchart descriptions have been used to capture the product design processes. They support very complex models, but that also leads to several different views that complicate the usability and comprehension. The key idea in WOKE is a very rapid creation and editing of the workflow by textual input, separate real-time graph visualization, comparison, and automatic summaries. User can select which details are visualized. Layout is automated and currently it uses a single column for all tasks and transitions. WOKE is implemented in C++/QT5 and is available as an open source tool. A proof-of-concept case study is shown for an FPGAbased SoC design. Index Terms—Workflow, WOKE, design process

I. INTRODUCTION The design of current many-core System-on-Chips (SoCs) is getting more complicated despite the progress in design methods. Tool frameworks typically include system modeling in several abstraction levels, re-use of repository components, and generators for exploration and model refinements. Several tools must be used to complete the design and each specific tool requires deep expertise. The combination of legacy, commercial, open source and self-made tools leads to many alternative paths and tasks that are difficult to even document and more difficult to learn and use. We found this problem also from a single tool usability point of view: every time our Kactus2 IP-XACT tool [1][2] gets new features, it is getting more difficult to decide what information should be offered to the user and when. To model the design process itself we are developing a tool called WOKE, loosely abbreviated from “WOrKflow Editor for kactus2”. However, it is not Kactus2 specific but a generalpurpose process modeling editor with new usability ideas. A recent survey about embedded system design projects interviewed over 2 000 experts [3]. Clearly the biggest technological challenge was integration of new technologies and tools (28%) in a set of 17 different choices. For comparison, IDEs and SoC interconnections both were only 2%, indicating matured technologies.

Desagent Ltd and Tampere University of Technology performed a similar survey for Finnish embedded system companies in 2013. A total of 102 companies were considered, ranging from LEs to SMEs. When asked how the development process is documented, only 3% mentioned a fully formalized process model whereas 65% uses only office documentation. About 30% used some models like BPMN2.0 for some part of the flow. Practically none explicitly measure the efficiency of the development process, mostly because it is too difficult or it takes too much time to figure out even the exact flow itself. Modeling of the design process is an important research topic also for the embedded systems development. We need to consider the efficiency of the process, not only the end results like SoC architectures. The key contributions and ideas of this paper are as follows:  Practical meta-model synthesized from the existing workflow modelling languages,  Single model view instead of multiple as usual,  Separation of editing and visualization of graphs,  Versatile control over which details are visualized,  Strictly constrained graph construction to prevent bloating the space and allowing model comparison. The paper is organized as follows. Section II presents related work and requirements. The meta-model of WOKE is given in Section III, which is followed by details of our graph construction method. After explaining WOKE implementation we give a comparison between UML, Graphviz and WOKE in a SoC design flow. We conclude the paper in discussion and proposals for future work. II. RELATED WORK By definition, a model is a simplification of reality intended to promote understanding. A workflow model describes the company’s processes and is used for documentation, analysis, simulation, or even controlling the real work. There are several meta-models and languages to capture the workflow, e.g. UML1.x (Statechart based) and UML2.x (Flowchart based) activity diagrams [4], BPMN2.0 [5], YAWL [6], and various process network and dataflow based descriptions. Most have graphical notation with textual annotations, or decoration of the graph. For example, steps can be marked as automated/manual or critical/non-critical. Statecharts have been the starting point for many UML based models, and Petri nets e.g. for YAWL and BPMN2.0. Despite the built-in activity diagrams, lots of domain specific UML profiles have been presented, e.g. in [12]. However,

UML suffers the problem of symbol overloading [4] even though the workflow modeling concepts are sufficient. YAWL is an impressive large, open source framework that can also control the processes [6]. It includes 20 elementary workflow patterns that cover practically all cases for transitions between tasks. YAWL is well suited also for our purposes, but its graphical modeling editor suffers from the same usability problems as any other link-node graph editors: it is quite laborious to draw the graph and browse in it when the graph grows large. In addition, we want a single comprehensive view to the model instead of several. However, we can use YAWL format to be compatible with our editor. A comparison of four other open source workflow frameworks is given in [7] that also present a thorough list of 34 attributes and 3 dimensions for the meta-model, user interface and other features for comparison. An example based on Java jBOSS is presented in [8]. It should be noted that the workflow editor is quite a small part of the whole in all of the above frameworks, since the focus is on execution environment. As far as we know, none of these have been applied to embedded system or MP-SoC design process, but e.g. web-based enterprise service workflows. Another extreme in complexity is Graphviz that is a wellknown suite for graph drawing from textual descriptions [9]. It determines the layout automatically which works well. However, controlling the layout manually is somewhat tedious. One alternative to our work was to implement a new graph constructing algorithm to Graphviz, but it would require too many modifications to input file format to include all objects and attributes from our meta-model. We require that the workflow model support specifying tool wizards or analyzing user interface with respect to process, i.e. huge number of small actions and often many alternative choices to proceed. Current graphical workflow models scale quite poorly despite the graph hierarchies and display guides like swim-lanes and other regions. Even more difficult requirement is to focus only on the essential properties, keeping in mind the idea of a single view.

III. WOKE METAMODEL Our goal is to derive on concise yet powerful meta-model (modeling style) for workflow descriptions. This simplified model is extracted from Petri Nets, YAWL, BPMN2.0 and UML2.x activity diagrams as summarized in Table 1. Most use process-based Model of Computation (MoC). The concepts of a static state and active work can both be explicitly expressed or either of them implicit. In all cases the relations are unidirectional arcs (edges) defining the causality. The two main types are flow arcs (move control between tasks) and data arcs (a task needs or produces some data object). Some arcs can be omitted for trivial moves, e.g. no event is required between two tasks in YAWL. Moreover, data arcs can be present. All process-based models recognize some token to trigger the flow at specific positions when certain conditions evaluate true, but many extend this to explicit conditions for splitting and joining the flow. A. Tasks in the proposed WOKE metamodel The WOKE meta-model has two basic elements that are Task (T) and tRansition (R). For example, a task could be “TLM modeling”, “Simulation”, and “Synthesis” whereas transitions describe the order and dependencies between tasks. In GUI, the tasks are displayed as boxes and arcs as arrows. Instead of single free-text field, the WOKE task has 12 attributes. Predefined attributes allow filtering and showing user-selectable amount of information in a user interface. Currently, most of the attributes are text strings and the user can freely select their exact use and meaning. YAWL formats can be used but they are not enforced. The reason is practical: while not limiting too much simplifies the usage since the users do not need to learn a complex meta-model formalism. It is planned that users could to create their own policies for summaries and simple type checking. Table 2 shows the attribute format and examples. Each task has a mandatory, unique IDentifier (ID) which includes a prefix and a running number, the default being simply T.1, T.2... The user can define a prefix string to the task

Table 1 Comparison of model elements and terms in different workflow modeling languages.

identification, but the numbering is automatic. There are 2 decorative attributes: Display Color (CO) and ICon (IC). To improve readability, the tasks can be colored individually or prefix-wise using HTML CSS notation, for example all tasks with prefix “SW-build” are cyan. Icons can be to distinguish, e.g. automated tasks from manual work. The task has 6 basic attributes. DEscription (DE) is freetext and LInk (LI) points to external more detailed documentation (HTML, pdf) or executable code. REsource (RE) and TooL (TL) are for listing persons responsible, required a simulator tool and such. Time Planned (TP) and Time Spent (TS) help in scheduling and time analysis. They can be expressed in time units or generic cycles. Moreover, transitions need 3 attributes: flow trigger TOken (TO), data consumed (Data Input, DI), and data produced (Data Output, DO). These are used as transitions parameters. B. Transitions and arcs in WOKE The second meta-model element, transition, defines one or more statements for the moving between the tasks. Transitions are braches, i.e. if-clauses with a condition and destination(s). In addition to mandatory flow arcs, we have also optional data dependency arcs when a task consumes, produces, or updates some specific data. We do not formalize “data” that can be a global parameter, file name or database item, for example. The simplest flow arc is of form “if T.1 then T.2” which makes transition from task one to two. A condition statement can include any task attribute as a binary variable (true/false or exists/does not exist). Transition always results only in a move to other task(s) without changing the attributes or producing data. The statements have reserved words {if, then, else, and, or, xor} for the logical relations. Splitting and joining the flow are like in the YAWL workflow patterns. Split operation simply occurs when a transition has more than one destination. Join operation occurs when condition includes attributes from many tasks. Hence, a WOKE graph consists of 12-tuple tasks and transitions defining their relations. The model is very simple when used in visualization and informal analysis. As mentioned, our tokens are binary valued.

Table 2 Task attributes in the WOKE meta-model. Attr ID CO IC DE LI RE TL TP TS TO DI DO

Description {String, default=T}.AutoNumbered #rgb CSS shorthand 3-hex digit RGB (12-bit color) .png icon picture (autoscaled) String (phrase describing the meaning) URI (e.g. HTML document for detailed instructions) String (e.g. person, group, department, UI element) String (name of object being utilized) {time [units], cycles} (e.g. 2d:2h:3min:6s:6ms, 57) (Same as above) List of Strings (token name without value) List of Strings (e.g. file, parameter name) List of Strings

IV. GRAPH CONSTRUCTION We attempt to avoid the problems of visual element semantics (see [4]) and define only moderate number of colors, shapes and other “decorations”. Thus, WOKE has only 2 different shapes: tasks (boxes, possible with icon or color) and transitions (rounded boxes). Arrows denote transitions. A key principle is construct visual graph automatically when the user types. This resembles Graphviz/dot but the graphics are updated in real time making WOKE more like a WYSIWYG tool. A. Browsing Massive graphs are not feasible for printing in general, and thus browsing in a tool must be very smooth. These features distinguish WOKE both from traditional drawing tools, such as MagicDraw or PowerPoint, and workflow tools. First of all, user can select which attributes are shown inside the task boxes (and editor area). Enabling more detail makes the boxes wider to have a fast overlook of the attributes in a list-like format. Search functionality would enable locating certain tasks, their attributes or transitions. Filters allow showing, e.g., only the task nodes using a specific tool or hiding certain transitions and task attributes to display only information relevant to a specific purpose. To help browsing, a branch can be hidden with all its subsequent tasks and transitions and the user can better concentrate on other parts. Another form of visibility control is grouping, so that multiple tasks are combined in a single collapsible item. This hides any arcs between the tasks in the collapsed group, showing only the arcs from and to the group. Common arcs, from example from one transition to multiple tasks in the collapsed group, are also combined. The main goal is analysis and therefore summaries are needed. The number of tasks, transitions, splits and joins are obvious but not available in many tools. Moreover, list of tasks requiring certain tool, tasks assigned to certain person, unique tools or persons and such are helpful in understanding the big picture and user gets an immediate sense of quantities. B. Comparison The grand goal in workflow modeling is to enhance productivity by removing bottleneck tasks, such as useless acceptance phases, over-regulation, complex feedback loops, and forced sequential execution. Therefore, comparison of models is needed to see the impact of organizational or methodological changes. List of changes helps somewhat but is tedious to interpret and therefore we are aiming at graphical comparison. Side-by-side comparison of code files, e.g. in Subversion, is an elegant way, as the tool highlights the modified, added, or deleted parts, and user can quickly navigate through differences. It is important to differentiate real structural changes from mere layout changes (beautifying). However, arbitrary layout would complicate this too much and therefore we selected column-based layout. Figure 1 drafts an example how differences could be visualized in one-column. Older version is on the left and newer on the right. We notice that task7 has been added after

task2, and feedback transitions from task5 to task4 has been removed. C. Automated Column-based Layout We have earlier found automated column-based layout beneficial in block diagrams of Kactus2 [13]. It poses certain restriction how user can place things, e.g. guides towards topdown drawing style. Moreover, diagrams created by different people more alike than with free 2D drawing area. WOKE uses automatic drawing principle is planned to spread the workflow into user defined number of columns, e.g. 1, 2 or 3. Decision which tasks belong to which columns is guided either by filtering (e.g. by assigned person) or aesthetic heuristics. Appropriate number of columns depends both graph structure (parallelism favors many columns) and purpose (comparison favors having just one column). The clarity of a graph can be estimated with three parameters (the smaller the better): node occlusion, arc crossing, and arc tunneling [10]. In our case, there no overlapping nodes. However, depending on the number columns arc crossing and tunneling occurs. More research is needed to determine appropriate goodness measures, e.g. based on total length of arcs perhaps weighing those longer than one unit. It may sound appealing to reorder nodes and arcs based on multiple criteria. However, this may easily cause lots of changes in layout as user types. This violates the aesthetic criterion known as “preserving the mental map”. For example, Graphviz sometimes produces a very different layout when just a single arc is added or removed, which confuses the user who is accustomed to certain layout. After all, visual recognition of shapes and overall look is a key concept when analyzing graphics. If layout changes all the time, the user finds it hard to distinguish the real changes in structure from those dealing merely with layout. Hence, small changes in the input should cause only small, local changes in the layout. Figure 1 also illustrates our idea of drawing the arcs behind the nodes to bypass. Since the goal is good usability, the graph constructing method should minimize the total area reserved by arcs and avoid long arcs across the graph, especially in

Figure 1. Visualizing the differences between graphs: task7 was added and transition 5  4 was removed.

opposite directions. Currently, the number of arcs is not considered in the node layout. The flow arcs are on the left and data arcs on the right (omitted from Figure 1 for simplicity). Arrows are drawn always so that they exit the source from the bottom and enter at top of the destination, even if the arrow goes upwards. To make splitting more readable, the arrow width is variable and color adjusted according to the root node. D. Single-column layout The current implementation utilizes only one long column, which has proved good in visualizing file dependencies in Kactus2 [13]. However, here it means that parallel branches are placed in series one after another. Despite restrictions there are also a couple of useful properties compared to 2D layout. For example, shown attributes can be easily read as they appear on top of each other. Constrained layout also simplifies visualizing the differences (see Figure 1). We wish to have rather deterministic layout based on graph structure (at least on most parts). Figure 2 shows 3 basic graph construction alternatives for a single column and 1 possibility for two columns. The leftmost is a traditional graph which offers lots of freedom in layout. When placed in one column, the graph can be traversed in two from the starting node: breadth-first (BF) or depth-first (DF). Breadth-first first places all the children of the root node (4 and 2 in the example) and their children recursively. This results in ASAP (as soon as possible) placements. Depth-first (DF) traverses as deep as possible starting from the root’s first child (4), places all its children until reaching a leaf node (3), and then rest of the children (node 2 only in this case). A variation of depth-first is based on schedulability. It seeks the longest path (from 1 to 3) and places the nodes in other branches in between as late as possible (ALAP) based on node’s mobility. For example, node 2 has mobility of 4 (places) since it can reside anywhere between 1 and 3 and ALAP algorithm places it just before 3. Currently, WOKE uses depth-first algorithm. Complexity of the DF and BF algorithms is roughly the same, and they can both be implemented in a straightforward manner. DF-ALAP,

Figure 2. The basic graph construction options for column-based layout.

however, requires a more complex algorithm, as it is required to determine the possible mobility of tasks. The user can have some influence on the final graph’s form by rewriting the transition statements. Rearranging the order of source (or destination) tasks in transition statements, changes the order in which they are added in the graph and hence laid out. Layout using two columns is closer to the original is seems clearer. However, data items and their dependencies are omitted from Figure 2and they probably appear clearer in the single column. E. Editing the graph Basic graph manipulation operations are inserting and deleting. A new task appears either following the previous one or makes a new branch. Deleting a task can be done by connecting its children to the previous task or leave them floating. Floating tasks do not have any connections and WOKE adds a connection from the start node to them automatically. Transitions can be easily added or deleted. When the user adds tasks and transitions for the first time, the display order and automatic numbering follow the order they were added. Often some new tasks are inserted or some deleted, which can make the original order and numbering inconvenient. Therefore, we have an automatic graph reconstruction that the user can run explicitly. Then the graph structure determines the numbering, display order, and layout. We are investigating if there’s a way to manually move the tasks in the graph, while still taking advantage of simple metamodel and automatic layout on other parts. The tool includes predictive text input that offloads remembering all the previously typed strings by heart and hence reduces typing errors. For example, it helps using exactly the same string in many tasks and transitions. When

the user starts typing for example a task prefix, WOKE presents a list of existing task names. The same method is used for token and data names. YAWL kind of data formalism can be used if desired. It is important to note that the graph is being constructed continuously when the user edits the workflow. This has performance issues compared to e.g. Graphviz that draws the graph as a batch operation. Not only longer UI response times, but also sudden radical changes to the graph appearance must be avoided. We discuss next the user interface of WOKE. V. WOKE UI AND IMPLEMENTATION One major requirement to WOKE was very quick adding, deleting, and editing of tasks and transitions. This is solved by entering the user input only in text and keeping the graphical notation separated. We next go through the WOKE user interface with the help of Figure 3. A. UI structure WOKE UI consists of three main window areas that are the ribbon, the text input area and the graph visualization. The ribbon includes icons to launch actions for common operations like saving, and specific actions for workflow editing and graph browsing. The input area is divided in two: the upper part is a table for tasks and attributes, and the lower for transitions. Scrolling of tables can be synchronized, which means that shown transitions match the selected task row. The transition list is moved according to the first task in the statement. The tasks and transitions can be added and deleted using keyboard shortcuts or clicking the corresponding icons. The most frequent operations can be done with minimal clicking and moving around the UI. For example, a new task is added

Figure 3. WOKE user interface is split into 3 sections. Ribbon menu on top has action buttons. Left part includes textual fields for defining tasks and transitions, whereas the right part visualizes the workflow.

below a selected task by hitting in the editor. The new task object copies the prefix and the ID number gets incremented automatically. The graph is constructed and displayed on the dockable window on the right. The graph can be independently browsed and zoomed, and tasks and transitions can be selected by a mouse click. If the editor and graph are synchronized, moving inside the table scrolls the visualization so that the corresponding node is in the middle of the window, and vice versa. B. Data Data flow is presented in similar way as the workflow, but data arrows are aligned to the right side of the graph. Data flow happens only between tasks, and as such these arrows are drawn between tasks instead of tasks and transitions. Data flow arrows are drawn from the task producing a specific data to the tasks that consume that data, as long as there is a workflow path between the tasks. C. WOKE implementation The current version 1.0 of WOKE is implemented in C++ and QT5.3 framework and the development environment is Visual Studio. Figure 5depicts the high-level architecture of WOKE implementation. It follows the model-view-controller principle to separate UI and handling of data. The main parts are models for the tasks, including task objects and their attributes, as well as a transition model including objects and their content (transition statements). A scene object takes care of graph visualization. Scene and delegate objects implement the user interaction with the models and views. WOKE uses a custom XML-based format for storing the workflow models. A plugin is required for

Scene Graph window

Task model Tasks, attributes Transition model Content

Delegate

Delegate

View Task table window View Transition table

Figure 5. WOKE high-level software architecture.

Figure 4. Example case visualized with YAWL without data dependencies.

importing and exporting models e.g. to YAWL. The current version of WOKE has 30 C++ classes. The source has about 7k LoC (Lines of Code) excluding the comments and has required this far 2 person years of the development effort in Constructive Cost Model (COCOMO) evaluated in Ohloh [11]. For comparison, Graphviz has 380k LoC, Activity 339k, jBPM 733k, Bonita 1,12M and YAWL 4,38M LoC that have been implemented in Java. As stated, WOKE is only an editor/browser and does not have an execution engine. It is currently missing some planned features, most notably visibility control. VI. CASE STUDY As a proof-of-concept we present an FPGA-based SoC design flow described in UML2.0 Activity Diagram presented in [14]. The model described tasks for HW, SW and system designers, order of task execution and only output data dependencies from the tasks. Not all data dependencies have been included to keep the diagram readable. Altogether the complete reference model includes 21 tasks, 2 splits and joins, 23 flow arcs and 25 data arcs. For evaluations, we measure the model creation and modification time and complexity. We also assess the comprehension and readability of the resulting graphs. In our comparison, YAWL represents a full-fledged but also a complex tool and Graphviz the simplest text-input graph tool. Table 3 summarizes the comparison between three formats. A. YAWL The case study used YAWL just for drawing, see Figure 4. A novice user created the graph in about 20 minutes without major difficulties and mimicking the swimlane layout of the original figure. All info is typed with keyboard but mouse is needed to create or copy-paste nodes which slows down a little. Horizontal layout was found more suitable in YAWL. Note that all data files and arcs are missing from the figure as well as task details. B. Graphviz Figure 6 depicts the Graphviz visualization. The model is created in a text editor and batch-processed for a graph. The basic layout principle is top-down as in our WOKE. Changes

are easy to do, but the graph layout can change dramatically upon editing. Consequently, the creation was easy took about 15-20 minutes whereas modifying it to get clearer layout took at least 45 min (most of it was studying the how to use of clusters). Textual input was very useful as the user can add comments or remove some tasks or connections momentarily. Moreover, find-replace operations work well. Batch processing for graphical view took few seconds. Tool allows using many shapes and arrow styles. Figure 6 shows two versions, scaled down to save space. However, when data files are added, the layout changes a lot, as seen Figure 6b. It is well readable most of the times, but certain dependencies between data files (e.g. those starting from HW component meta-data description) clutter the whole figure. C. WOKE Model creation with WOKE is fast, about 10-15 minutes for tasks and flow transitions, and about 10 minutes more for the data dependencies. Figure 7 shows the case study model including task arcs on the left and data arcs on the right side of the flow. Additionally, task roles and used tools are also presented. Currently data arcs show only the data dependency between tasks, e.g. SW upload needs the compiled binaries and upload script.. In the future, it will also visualize the dependent data object information as a tooltip. We note that single column layout enables tasks to contain multiple information fields in a compact and rather well readable form. VII. CONCLUSIONS We addressed in this paper a new viewpoint to the embedded SoC design. Instead of architecture creating tools, we focused on capturing the design process. The first new idea is to apply business process modeling methods to our domain. The second is the new editor, WOKE. It distinguishes from the current business process editors in its graph constructing method, and significantly decreases the workflow model creation time by its textual input. It is best utilized in large models that cannot be captured in office tools like Visio, or traditional 2D modeling tools like Bonita or YAWL editor. With WOKE even the smallest tasks can be included that otherwise would be left over, but which can significantly expose the real complexity of the design flow. For the future work, the graph should be optimized for the length, number and direction of the arcs for the best clarity. In addition, import/export plugins to standard formats like YAWL or WF-XML should be included for better interoperability to existing frameworks. REFERENCES [1]

L. Matilainen, A. Kamppi, J-M. Määttä, E.Salminen, T.D. Hämäläinen, "KACTUS2: IP-XACT/IEEE1685 compatible design environment for

Table 3 Summary of tool comparison. Property\tool Model creation time [min] Layout

YAWL 20 (excl. data)

Graphviz 15 (+45)

WOKE 10+10

Manual

Autom.

Single task creation complexity Overall view

Draw + test (XX dialogs and menus) Spread into many views

Autom. + tweaking Text

”Listed” in one view

Differences

Manual

Spread around one view Manual

[2] [3]

[4]

[5] [6] [7]

[8]

[9] [10]

[11] [12] [13]

[14]

Text

Manual., automation planned

embedded MP-SoC products", TUT Report 37, 2011, ISBN 978-952-152625-1. Kactus2, [Online], Available: http://sourceforge.net/projects/kactus2/. D. Blaza, A. Wolfe, “2013 Embedded Market Study”, presentation on Design West, San Jose, Ca, USA, April 22-25, 2013, [Online]. Available http://presentations.ubmdesign.com/events/san-jose/2013 (Visited May 4, 2013) D. Moody, J. van Hillegersberg, Evaluating the Visual Syntax of UML: An Analysis of the Cognitive Effectiveness of the UML Family of Diagrams, Lecture Notes in Computer Science, Vol. 5452, 2009, pp 1634 Yaonqiang BPMN editor, [Online]. Available: http://sourceforge.net/projects/bpmn/BMNP YAWL: Yet Another Workflow Language, [Online]. Available: http://www.yawlfoundation.org/ K. Baina and S. Baina, "User experience-based evaluation of open source workflow systems: The cases of bonita, activiti, jBPM, and intalio," in ISKO-Maghreb, 2013, pp. 1-8. Jian Hu, Zhiqiang Zhao and Zhongnan Lv, "Implementation of process management and control based on JBPM4.4," in ICNDC , 2011, pp. 218-221. Graphviz – Graph visualization software, [Online]. Available: http://www.graphviz.org/ C. Dunne and B. Shneiderman, Improving Graph Drawing Readability by Incorporating Readability Metrics: A Software Tool for Network Analysts, University of Maryland. Human-Computer Interaction Lab Tech Report No. (HCIL-2009-13), 2009, 9 pages. Ohloh open hub, Black Duck Software, Inc., [Online]. Avalailabe: http://www.ohloh.net/ J. Bruning and M. Gogolla, "UML metamodel-based workflow modeling and execution," in EDOC, 2011, pp. 97-106. J-M Määttä, M. Honkonen, T. Korhonen, E. Salminen, T.D. Hämäläinen, Dependency Analysis and Visualization Tool for Kactus2 IP-XACT Design Framework , Int’l Symposium on System-on-Chip, 2013, 6 pages. A. Kamppi, L. Matilainen, J-M. Määttä, E. Salminen, T. D. Hämäläinen, Extending IP-XACT to embedded system HW/SW integration, Int’l Symposium on System-on-Chip, 2013, 6 pages.

a)

b) Figure 6. Example case visualized with Graphviz, a) without any data dependencies and b) with all data dependencies.

Figure 7. Example case in WOKE.