DOI QR코드

DOI QR Code

Y Block Diagram as a New Process Notation in a GPS Manufacture

  • Received : 2018.08.29
  • Accepted : 2018.12.30
  • Published : 2019.02.28

Abstract

Company A should maintain myriad conversion tools for the purpose of making a geometric compilation of navigation maps. Company A is already using complex compilation tools, which are tailored to geographical areas and various GPS models. However, due to frequent requirement and personnel changes, there is an endless challenge for perfect tool configuration and multiple map consolidation. To solve this problem, Company A launched a process automation project using Graphviz, which is an open source workflow graph visualization software. Before implementation, they had to document their current map compilation processes and then match it with the applicable conversion tool. For effective representation of process controls, a new graphical process notation is designed, i.e. Y Block diagram. The authors will compare Y Block diagram with other process notations and explain why Y Block diagram is more useful for tool based business processes such as digital map generation processes.

Keywords

1. Introduction

Company A, a GPS manufacturer, broadly, has two lines of development processes. One is for sequential digital map conversion and compilation processes. The other is forembedded discrete software development which uses the before mentioned digital maps for navigation application. Authors are focusing on map conversion and compilation processes. For map compilation, company A should maintaina large number of software conversion tools. They are using several hundreds of compilation tools tailored to world-widegeographical areas and various GPS models. The processing sequence of the map conversion should be synchronized batch job processes with applicable tools.

It is very critical to get error free intermediate and finaloutputs such as the characteristics of the chemical processindustry. However, due to frequent requirement and personnel changes, there is an endless challenge for perfect tool configuration and multi-layered map consolidation. To make matters worse, those conversion tools had been archived in the engineer’s personal desktop computers. As aresult, there were too many tool variances to managemultiple versions of geographical maps and GPS devices. That was the reason why company A had launched a processautomation project. Before project implementation, they had to document their multiple, step-by-step procedure formatching the right conversion tool with the map compilation batch processes. For effective representation of toolalignment with process control, a new graphical process notation is designed, i.e. 'Y Block notation (or diagram).'

Through our empirical research, we have found that the Y Block diagram model has been used successfully todocument standard conversion processes, especially concentrated on tool configuration which is matched forgeographical and GPS model specifications. Therefore it provides strong support to design the automated workflow management (WFM). Company A had selected Graphviz as the WFM platform. Graphviz is an open source workflow graph visualization tool provided by AT&T. The next section will explain some research background and literature review for comparing the Y Block diagram to major business process notation diagrams. The authors will compare the Y Block diagram with other process notations and explain why the Y Block diagram is more useful, especially for tool based business processes such as digital map application. This is followed by benefits for applying the Y Block diagram to Graphviz.

2. Background

The digital map compilation processes of company A includes over 200 job steps to make a set of final binary map files. There are multiple sets of map files on thirteen mapscales for each GPS devices. It means that the company usesseveral thousand map conversion tools. Usually, the government provides the original baseline map (1:5,000 scales) for the domestic market. And then, company Ashould manipulate the components of map elements includingline, shape, color, road link and put various physicalattributes like points of interest, buildings, cost values (i.e. speed limitation, average speed) on each link id and etc. Even when the whole map compilation process becomes extremely complex, it should still be error-free and completed in time to meet release deadlines. In order to avoid errors, engineers should align proper conversion tools for every step-by-step compilation process. However, thereare several barriers to reaching this stage of error-freeperfection:

  • Due to frequent engineer replacement, specific project knowledge and experience is not always transferred between old and new personnel. Lack of vital knowledge and experience transferred between personnel due to frequent engineer replacement.
  • Tool variance between standard conversion software and derivative versions archived in engineer’s desktop PC.
  • Insufficient time to maintain tools due to clients’ delivery pressure.

Ironically, the above issues worsened when company A hired outside partners to speed up the compilation process. Also, ad hoc requirements from customers created several non-standard compilation tools. Tool variance became the main source for compilation errors and delayed cycle time because novice engineers were not able to articulate the best tools to apply.

The foregoing reason moved company A management to consider developing a new map compilation process. So, the process automation by WFM tool was implemented according to multiple geographical regions and GPS models. FYI. Each GPS model is using different user interface and map shape for differentiation marketing policy according to the selling price. But, they are sharing the same node and link data structure.

Prior to the introduction of the process automation, it was necessary to document the as-built process model incompany A. The Y Block diagram was newly designed by R&D team because they believed legacy notations were not good enough for their tool based procedures. They redefined the requirement of the new schematic notation model with these features:

  • To describe the hierarchical abstraction according to process levels.
  • To mark the input and output filenames of each process.
  • To describe the exact tool name and its version per each conversion activity. (Most important requirement for company A management)
  • To identify the person responsible for carrying out each conversion process.

R&D team had selected Graphviz, an open source workflow graph process tool, as the process automation platform running on Apache Hadoop architecture. The newly designed Y Block diagram provided a valid benefit to implementing the automation of map compilation processahead.

3. Literature Study

From a cognitive point of view, diagrammaticrepresentation for the business process is easier to understand when compared to a textual or numerical only presentation [1]. Schematic models for implementing the business processon an information system are mainly being used by DFD (data flow diagram) and ERD (entity relationship diagram). DFD is proper to represent the flow of data through an information system. ERD focuses on the associations and dependencies between entities, not on business processes. Although both represent a model for expressing the datamodel of the entity, it is inappropriate for expressing the sequential steps of engineering or business processes.

Some other approaches related to the process notation are BPMN (business process management modeling notation), UML (unified model language) Activity Diagram (AD). BPMN is a de facto standard that is capable of representing nearly any conceivable business process. However, Fernandez insists that BPMN is still too complex for business domain people to represent business processes even if it is relativelyeasier than UML AD [2]. Likewise, UML AD is not easy to draw without understanding the Unified Model Language and it lacks the representational effectiveness needed for business processes.

Kock introduced the concept of communication floworientation (CFO). He ranked 7 CFO levels from the lowestlevel communication flow model, i.e. standard flow chart to Functional Flowchart, UML AD, UML Use Case Diagram, UML Communication Diagram, Data Flow Diagram, and the highest level communication flow model, i.e. Communication Flow Diagram. He explained that a higher communicationflow oriented model is more effective for IT systemimplementation rather than a functional flowchart. The key message is that an easier documentation model is also useful for understanding the concept of business models within the context of IT implementation [3].

According to Bibliowicz, correctness and comprehensibility are the two basic requirements for a system’s conceptual model [4]. He recommends OPD (Object Process Diagram), but OPD also has a higher level of semantic complexity fordescribing graphic symbols. Another approach, the Markov process, which is a transition system, uses a simplecombination of symbols like states and arcs. Though it iseffective in predicting the probability of process logicalerrors, it is not effective for aligning right resources (i.e. toollists). This is why company A considered designing another process notation model. While the Y Block diagram lackslogical node and link concepts that are common for general business process notations like Petri net or BPMN, this chartprovides a clear and efficient representation with tool configuration, especially for geometric element conversion or compilation on digital maps.

Workflow management systems use a large variety of process/visual languages and concepts based on different paradigms. Most available products use a proprietary visualand process language rather than a tool-independent language [5]. Aalst and Hofstede also mentioned that one of thereasons for the lack of consensus on the consolidated language was the variety of different specifications in which business processes are otherwise described. As a result, they proposed the following four different perspectives of workflow specification:

  • Control-flow perspective
  • Data perspective
  • Resource perspective
  • Operational perspective

Resource perspective is related to a human or a deviceresource, whereas the Y block diagram addresses s of tware resources, especially compilation tool resources in digital map application. Table 1 shows the key characteristics of major graphical and/or process languages including the above-mentioned tools. Thirteen graphical and/or processlanguages are presented in table 1. Table 1 does not showall the graphical and/or process languages, but most of the popular market notations are covered. These process notations mainly focus on process activities. But company Arequired a specialized notation scheme to verify and validatea sequence of conversion tools rather than a sequence ofactivities.

4. Y Block Diagram

4.1 Basic Notation

The Y Block diagram gets its’ name from its resemblance to hands above the shoulder posture of the letter Y. The diagram is composed with the Y Block and arc (arrow) only. The Y Block diagram has 5 parts as shown in figure 1. They are the following:

  • Process ID
  • Input filename
  • Output filename
  • Conversion job description (name) matched with corresponding process ID
  • Conversion tool name or list (or stored data)

The conversion tool name with version information is the most important piece of data for aligning map compilation processes. From the reader’s POV, the left arm identifies the input filename. Likewise, the right arm is used for the output filename. A drawing of the left or right arm corresponds to the physical location of the files. If the input and output files are located in the same physical storage, Y block can havedual arms. Each Y block diagram has only one process id. However, the other parts may have multiple entities, e.g. multiple input files, output files, conversion job names, and conversion tools. The arc connects the Y Blocks, directing from output to input. Multiple inputs and outputs are allowed. The arc shows the conversion processes only, and there is no specific drawing limitation for the arc. Either a line or curve is acceptable, but not both. The arc can be attached to either arms or the bottom of the body, but arm attachment is preferable.

OTJBCD_2019_v20n1_125_f0001.png 이미지

(Figure 1) Y Block Diagram Legend

4.2 Process Notation

The Y Block diagram adapted its schematic idea from IBM ’s HIPO (hierarchy plus input process output) chart. However, the Y Block represents input/out filenames, and at the very least, process description and conversion tool names. Figure 2 demonstrates a pseudo-conversion process with multiple Y Block diagrams. As a role & activity diagram, the Y Block diagram can be aligned by process owners. Each process owner is responsible for the integrity of data files and conversion tools. There is no feedback cycle in the Y Block process. The Y Block continuously runs from left toright and does step-by-step conversions. If errors develop, tool errors should be fixed, and then the conversion process should be restarted from the previous process breaking point.

OTJBCD_2019_v20n1_125_f0002.png 이미지(Figure 2) Y Block Role-Activity Chart

4.3 Configuration Table

The Y Block methodology has several complementary documentation formats. For example (1) process descriptiontables, (2) conversion tool tables, (3) input template, (4) output template are all compatible with Y Block. Table 2 shows the process description table and conversion tool table. The process description table explains the attributes of each process’s IDs. Most of the attributes can be described fully in the Y block diagram, but the table may have additionalinformation for standard work hour and quality level (e.g. 3.0 sigma). Conversion tool tables articulate the control number of conversion tools, tool name, execution filename, applicable process ID, process name, and initial build date, recent update date, current version, developer's name, and finally the runtime environment (or IT constraint).

Thanks to the Y Block diagram, company A can clearly define the configuration of conversion tools and theresponsibility of each process jobs. And they easily replicate the new conversion process with the given conversion process and reuse those tools with a lower error rate. Whenthe process conversion identifies a failure, engineers can locate the exact place of error break and analyze the geometry attributes relating to errors. Also with a configuration table like table 2, engineers can calculate the cycle time improvement and enhance other key performance indicators, including quality measures.

After finishing the above mentioned Y Blockdocumentation, company A can easily apply map conversiontoolsets to proper compilation procedures graphically enabled by Graphviz WFM.

5. Graphviz Implementation

5.1 What is Graphviz?

Graphviz(graphviz.org) is an acronym for the graph visualization software, an open source graphical process tool by AT&T. The user can use ‘dot’ script language to drawnodes and edges (directional or non-directional). Graph vizprovides various API and program libraries for C#, . Net, Java, Python, Ruby, R and etc. Company A selected Graph viz as the process control platform to get the following advantages:

  • To detect errors by the color change of nodes (job steps) while running the batch job for map conversion.
  • To restart batch jobs from the breaking point after the resolution of errors.
  • To support parallel processing of Windows or Linux Hadoop environment.
  • To get a best practice model to implement the multi-set for the map compilation processes.
  • To copy the error-free conversion process scenario for another map version.

Figure 3 presents a sample of dot script language and its interactive graphical presentation. When the code declares & ld quo;digraph&rd quo; syntax, it means the edge between nodes is directional. Most of the ‘dot’ script codes are easy tounderstand. In the drawing, you can understand the two subgroups, the syntax for the shape of nodes, as well as, the color of nodes, edges, and labels. The edge direction iscoded with "->” symbol.

OTJBCD_2019_v20n1_125_f0004.png 이미지

(Figure 3) tool mapping on Graphviz nodes(pseudo model)

5.2 Automated MAP Compilation Logic

Figures 4 and 5 are some diagrams for company A'ssystem architecture for the automatic MAP conversion process. You may see the sequence diagram for the program running and the block diagram of software architecture. The basic user interface is running on the standard HTML5 webbrowser, Java logic, which classifies interlock with Graph viz API. Conversion tools are integrated with Graphviz API. In order to reduce computing time, conversion logic and datamay run on Linux Hadoop platforms. Company A has multiple product lines of geometric maps. So, multiple batch job statuses are simultaneously displayed and managed on multiple HTML5 sessions.

OTJBCD_2019_v20n1_125_f0003.png 이미지

(Figure 4) Graphviz UI Sequence Diagram

OTJBCD_2019_v20n1_125_f0006.png 이미지

(Figure 5) Block Diagram for Software Architecture

Due to company A’s security policies, the actual UI images of the Graphviz map conversion process are notavailable for publication. However, the conceptual representation of the process diagram is very similar to figure 6. Company A has dozens of map conversion processes because they are providing many geographic maps for many different clients in the global GPS market.

In the past, there was a possibility that matters of quality control would occur, as an individual engineer performed his/her part of the map conversion job by step-by-stepprocedure randomly with his/her tools. After the introduction of Graphviz workflow, standard conversion tools with the correct configuration were integrated with control processes. As a result, the possibility of conversion errors was dramatically reduced when the whole process was checked and set up in advance. Also, a new conversion process for a new GPS system can be easily referred and replicated from the given error-free conversion process model. Visual representation of error occurrence on Graphviz platform is very useful for an engineer to check the progress of conversion work. There is no longer a need for engineers to be put on standby in the middle of the night to monitor the conversion process because engineering can monitor the progress remotely through a web console.

Authors utilized a simple pseudo diagram for depicting company A's map conversion process because the processhas a very similar diagram pattern to figure 6. But total nodes are about 200 in the real situation. In the drawing, thenode color may change to red if an error develops; otherwisea green color indicates normal operation. When an erroroccurs, engineers can check the error log by mouse click and review the functional process of breaking process.

OTJBCD_2019_v20n1_125_f0007.png 이미지

(Figure 6) Run-time workflow UI for automated map compilation (pseudo model)

6. Conclusion

The Y Block diagram in company A is a kind of mutant process diagram, but it is a relatively useful configurationtool for the map compilation application. In summary, the Y Block diagram is good for presenting the map conversion process in GPS Map company A. By using the Y Blocknotation, company A had smoothly implemented the automatic process control with Graphviz platform. Without the Y Block diagram, the engineer may find it difficult tomatch proper conversion tools per every conversion node on Graph viz. The Y Block diagram, another optimized notational model, is meaningful in the real world even if' state diagram' or BPMN, which were mentioned in the literature study, is still dominant in process notationdiscipline. Some methods of notation are best suited for process description, while other methods of notation are the better fit for resource (i.e. tools) configuration, such as the Y Block diagram.

Whenever the limitations of standard notation models areencountered, people’s creative endeavors to solve this short-coming by the development of new and relevant models should be respected as advancement. Of course, the Y Block diagram inherited a legacy from other process notation models, e.g. the HIPO diagram. The need fordeveloping Y Block diagram came from Graph vizimplementation at that time. By using Y Block notation, company A can shorten the Graphviz implementationlead-time for enumerating the sequence of above 200conversion tools per each map conversion process. I fengineers specified the tool sequence according to resourcematched with BPMN swim-lane, the process diagram mighthave a long spaghetti type drawing.

Graphviz-driven map compilation workflow increased the productivity for conversion process monitoring & control and shortened the modeling lead-time for new derivative map conversion processes. In the future, we will extend ourresearch topics for the theory of tool-based process modelsincluding other resource attributes.

Major Graphical and Process Language.

 

OTJBCD_2019_v20n1_125_t0001.png 이미지

Unit Process and Tool Specification

 

OTJBCD_2019_v20n1_125_t0002.png 이미지

References

  1. Nergiz Ercil Cagilay and et al., "Performing and analyzing non-formal inspections of entity relationship diagram(ERD)," The journal of Systems and Software, Vol 86, pp.2184-2915, 2013. https://doi.org/10.1016/j.jss.2013.03.106
  2. H. Fernandez and et al., "SBPMN - An easier business process modeling notation for business users," Computer Standards & Interface, vol. 32, pp.18-28, 2010. https://doi.org/10.1016/j.csi.2009.04.006
  3. Ned Kock and et al., "Communication flow orientation in business process modeling and its effect on redesign success: Results from a field study," Decision Support Systems, vol. 46, pp. 562-575, 2009. https://dx.doi.org/10.1016/j.dss.2008.10.002
  4. Arich Bibliowicz and Dov Dori, "A graph grammarbased formal validation of object-process diagrams, " Software System Model, vol. 11, pp. 287-302, 2012. http://dx.doi.org/10.1007/s10270-011-0201-4
  5. W.M.P. van der Aalst & A.H.M. ter Hofstede, "YAWL: yet another workflow language," Information Systems, Vol 30, pp.245-275, 2004. https://dx.doi.org/10.1016/j.is.2004.02.002
  6. Michele Chinosi, Alberto Trombetta, "BPMN: An introduction to the standard," Computer Standards & Interface, vol. 34, pp. 18-28, 2012. https://dx.doi.org/10.1016/j.csi.2011.06.002
  7. Antonio Garcia-Dominguez and et al., "A Comparison of BPMN 2.0 with Other Notations for Manufacturing Processes, ResearchGate, April 2012. https://dx.doi.org/10.1063/1.4707613.
  8. Seungchul Ha, Hyo-Won Suh, "A timed colored Petri nets modeling for dynamic workflow in product development process," Computers in Industry, vol. 59, pp.193-209, 2008. https://dx.doi.org/10.1016/j.compind.2007.06.016.
  9. http://yawlfoundation.org
  10. Anne Gross, Joerg Doerr, "EPC vs. UML Activity Diagram -Two Experiments Examining their Usefulness for Requirements Engineering, 17th IEEE International Requirements Engineering Conference. 2009. https://dx.doi.org/10.1109/RE.2009.30
  11. C-net: W.M.P. van der Aalst and et al, "Causal Nets: A Modeling Language Tailored Towards Process Discovery,"22nd International Conference, CONCUR, Sept. 2011. https://dx.doi.org/10.1007/978-3-642-23217-63
  12. J. Buijs, B. Dongen and et al., "A Genetic Algorithm for Discovering Process Trees," WCCI 2012 IEEE World Congress on Computational Intelligence, June 2012.
  13. Dan Pilone, UML Pocket Reference, 1st edition, O'Reilly, 2003.
  14. Object-Oriented Methods: A Foundation, UML edition(2nd edition), Prentice Hall PTR, Dec. 1997.
  15. Object-Oriented Methods: Programmatic Considerations, Prentice Hall, Jan. 1996.
  16. J. Ping and et al., "Research on business process simulation method of architecture based on IDEF3," IEEE(MSIE), 2011. https://dx.doi.org/10.1109/MSIE.2011.5707617
  17. 50Minutes.com, Value Stream Mapping: Reduce Waste And Maximise Efficiency, August 2017.
  18. D. Harel, "Statecharts: A Visual Formalism For Complex Systems," Science of Computer Programing, vol. 8, pp. 231-274, 1987. https://dx.doi.org/10.1016/0167-6423(87)90035-9
  19. J. Katoen and et al., "Three-valued abstraction for probabilistic systems," The Journal of Logic and Algebraic Programming, vol. 81, pp.356-389, 2012. https://dx.doi.org/10.1016/j.jlap.2012.03.007
  20. https://ibm.co/2wlEryU
  21. http://www.xpdl.org