Deriving UML Logical Architectures of Traceability Business

Deriving UML Logical Architectures of Traceability Business Processes Based on a GS1 Standard* Rui Neiva1, Nuno Santos2(), José C.C. Martins1, and Ricardo J. Machado1,2 1

Centro de Investigação ALGORITMI, Universidade do Minho, Guimarães, Portugal 2 CCG - Centro de Computação Gráfica, Campus de Azurém, Guimarães, Portugal [email protected]

Abstract. A good traceability business process (BP) regards a powerful tool for industrial and manufacturing organizations to pursuit effective productivity. However, there is a lack of a common understanding among its key stakeholders on implementing a proper traceability BP. In this paper, we propose the use of software engineering approaches, namely the design of a process-level logical architecture for the traceability BP. This logical architecture captures the main activities, responsibilities, boundaries, and services involved in the traceability BP. The logical architecture was derived based on a use case model that arose from the requirements elicitation of activities as the ones proposed by the GS1 standard. Keywords: Traceability · Business process · Industrial · Logical architecture · Use case model

1

Introduction

Manufacturing organizations increasingly strive to maximize productivity and reduce costs, which means producing more, faster, more efficiently and with higher quality, in order to increase profits. Traceability business processes (BP) [1-3] play an important role on assisting manufacturing organizations improving their performances regarding those concerns. One of the major goals of traceability BP is to ensure the persistence of relevant information related to the main activities of an organization [4]. Thus, traceability BP allows locating and recalling defective products throughout the supply chain. The fast recall of these products helps reducing the potential negative economic impact of their defects, and preserving consumers’ trust on the quality of their favorite brands, as well as their confidence in the systems that are designed to protect their safety [5]. The recalling of defective products is as more important as the physical integrity of their users is com-promised. The contribution of traceability BP to more efficient production processes lies in identifying stages in the production process that cause defects on the products [1-3]. Such identification supports continuous improvement of the production process, responding to demands for more efficiency [4]. This research is sponsored by the Portugal Incentive System for Research and Technological Development PEst-UID/CEC/00319/2013 and by project in co-promotion nº 36265/2013 (Project HMIExcel - 2013-2015). © Springer International Publishing Switzerland 2015 O. Gervasi et al. (Eds.): ICCSA 2015, Part IV, LNCS 9158, pp. 528–543, 2015. DOI: 10.1007/978-3-319-21410-8_41

Deriving UML Logical Architectures of Traceability Business Processes

529

In logistics, traceability data can be used to optimize routes (of traceable items – shipments like truckloads, vessels, certain amounts of pallets of various items, logistic units like pallets or containers, or trade items, which are further on defined in this paper [5], and to improve planning and management, primarily due to improved links with other organizations with which there is collaboration [4]. In accounting, this data can be used for inventory, or by monitoring applications to identify process inefficiencies [4]. According to [5], obtaining an integrated and holistic view of traceability requires all stakeholders to systematically connect the physical flow of traceable items (the physical flow may be a truck with bulk goods or a truck containing big bags of seeds [6] with the flow of information about them (traceability data). Such view is best attained through a common process language. The GS1 global standard for traceability [6] is thus the starting point for this research and was used as input for the execution of a requirements elicitation approach. The use of the global standard allows that the elicited activities encompass all phases and activities of the traceability BP, where it is assumed that every standard results from consensus and validation from the entities regarding the given industry and that key requirements are addressed. The main purpose of this research is to design a non-fragmented traceability BP view for software modeling in the industrial context of full supply chain traceability, which means that this view suits the purpose of supporting further development of full supply chain traceability process automation (software) tools. This view also includes the functional requirements of a global traceability BP for full supply chain traceability, which allows contributing with an understanding on the meaning of traceability process concepts Martins and Machado referred in [4] and the common process language mentioned in [5]. This common understanding (i.e., process language) is obtained by creating and transforming a model that captures functional requirements a general traceability process for full industrial supply chain traceability shall meet to satisfy its user needs. This paper is structured as follows: section two addresses some related work and describes one of the main traceability standards for the industrial context; section three identifies functional requirements of the traceability BP for the industrial context and presents their modeling in a UML use cases diagram; section four illustrates the transformation of standard-based business process requirements for full supply chain traceability into a logical architecture of the traceability BP; and section five presents the conclusions of this research.

2

Related Work

In general, traceability can be understood as the ability to trace the history, application or location of what is under consideration [7]. In manufacture, traceability regards the process to track a product batch and its history throughout the whole or a part of a production chain from raw material to consumer (chain traceability), or internally in one of the steps (non-continuous operations performed at a particular location) in the chain (internal traceability) [8]. Traceability allows: (i) identify the source of all materials and parts of a product (materials, intermediate and finished products) [6]; (ii) processing the entire history of the life cycle of the product [8] ; and (iii) the distribution and location of the product after delivery [7, 8]. Thus, traceability must be

530

R. Neiva et al.

ensured throughout all stages of the supply chain, like transport, storage, processing, distribution and sales [8]. According to [8], traceability is only achieved through the unique identification of the products. Traceable items can be located at places of production, handling, storage and sale, each of which represents a traceable item location [5]. Different types of traceability can be found in the literature, as for example: forward and backward traceability, active and passive traceability [9], vertical and horizontal traceability [10], and internal and external traceability [6]. External traceability is particularly relevant for this research. In [11] it is specified a mapping technique and an algorithm for mapping business process models, using UML activity diagrams, and use cases, so functional requirements specifications support the enterprise’s business process. In [12] business process models are derived from object-oriented models. KAOS, a goal-oriented requirement specification method, provides a specification that can be used in order to obtain architecture requirements [13]. On other perspective, Tropos [14] uses notions of actor, goal and (actor) dependency as a foundation to model early and late requirements, architectural and detailed design, and [15] models business goals and derives system requirements, but it outputs a UML state chart. In [16], a methodology is proposed where a business process reference models is used in the first phase of software development. Then, the business model is modified in order to fulfill customer’s and organization’s needs, and ends with an implemented software system. The Four-Step-Rule-Set (4SRS) method [17] allows the transformation of user product requirements into an architectural model representation. The method is traditionally applied in a product-level perspective including variability, recursive mechanisms and class diagrams generation. In its process-level perspective, the method is traditionally applied for creating context for product design in ill-defined contexts and specifying participants in service-oriented contexts. In this research, we issue logical architectures for a representation of standard-based activities instead of using them in context of product design. Thus, we use the same rationale as in [17] but the use case model used as input are standard-based activities rather than user process requirements. Terzi [18, 19] address the interoperability and lack of knowledge problem. Knowledge problem was tackled through the “development of a reference meta model for product traceability”, focused on product data structure requirements. He also pursued the interoperability along the diverse enterprise applications, in particular at a manufacturing stage, for managing the product traceability along the entire product life cycle. Jansen-Vullers [9] relies on case studies to create a traceability reference model. As a result an approach to design IS solutions for traceability is proposed. Starting with a model of the goods flow. This model depicts the processes that transforms manufacturing products, through a sequence of operations. The model is then translated into a reference data model that is the basis for designing an information system for tracking and tracing. The intention of Gampl's study is to approach a typology for traceability systems. To achieve that, he surveyed traceability systems, on German food industry, and create a detailed description for traceability systems in terms of dimensions and aspects [20]. Panetto [21] maps the “IEC 62264 standard models to a particular view of Zachman framework in order to make the framework concrete as a guideline for applying the standard and for providing the key players in information systems design with a methodology to use the standard for traceability purposes”. On this study Panetto was able to rely on a standard to obtain a abstract


531

model of traceability. Sobrinho on his research modeled an information system aimed at the maintenance of traceability data in the Brazilian wine industry, according to the principles of a service-oriented architectures [22]. The research in [23-25] describes domain-specific implementations of traceability processes in healthcare and in food industry, respectively. Manikas in [26] presents an activity-oriented web application for supply chain traceability for agricultural industries that relies on the Traceability Data Pool (TDP) model. In [27], a framework based on event-driven process chains (EPCs) methodology, the entity-relationship model (ERM) and activity-based costing (ABC) is used to define and analyze the current state of a supply chain and design a future system to develop business process reengineering for a supply chain of fourth range vegetable products.

3

Modeling Traceability with Use Cases

This research was divided in three main phases. This research began by identifying the key requirements of the global traceability BP. The requirements elicitation was based on the GS1 global traceability standard [6] and on literature review. Initially, we used the set of subprocesses from the GS1 global traceability standard previously described. However, the standard is highly generic and does not provide detail about some of the main activities of a generic traceability process. Thus, requirements elicitation was also supported by the domain knowledge and strengthened by the professional experience of the authors namely from the automotive industry. In the end of this phase, the requirements of the traceability BP were gathered and represented in the form of use cases, using the Unified Modeling Language (UML) [28]. UML use cases are mandatory input for the 4SRS method. The 4SRS method has proven successful in the design of Information Systems to represent the requirements for process execution, thus chosen to be executed to the standard-based logical architecture design. The activities were organized by their detail level where, as in [29], functional refinement of use cases was the used strategy to provide different levels of abstraction to modeling (in the case of the present research, the traceability BP modeling). This strategy allows adding requirements incrementally and facilitates their interpretation. The first phase of our approach was to model the GS1 global traceability standard’s subprocesses and steps by using use cases diagrams. This model allows to develop a first draft of the standard subprocesses and steps’ representation. Additionally, another main contribution regards the identification of insufficient information to develop an adequate and complete use case model. The identified use cases are depicted in Table 1. These use cases can be used as the starting point for the development of any use case model. It must be pointed out that in [6] one of the presented subprocesses is called Recall Product. In early versions of the global standard, this subprocess was included in the Use Information ({UC5}) subprocess. At the time of this research, Recall Product was not a subprocess that the interviewed stakeholders wished to address because their concerns regarded other subprocesses. For this reason, Recall Product subprocess was not included in the model. However, our proposed approach may easily include Recall Product subprocess within the use case model and use it in the logical architecture derivation in future works.

532

R. Neiva et al. Table 1. Identified use cases from the GS1 global traceability standard Use Cases with Full Information

Use Cases with Insufficient Information

Plan and Organize

─ Manage traceability data ─ Link traceability phases

─ Create traceability plan

Align Master Data

─ Identify Traceability Partner ─ Identify Physical Locations ─ Identify Assets ─ Identify Trace Items ─ Exchange Master Data

─ Assign Traceability Partner Data ─ Assign Physical Locations Data ─ Assign Assets Data ─ Assign Trace Items Data ─ Send Master Data Request ─ Respond to Master Data Request

Record Traceability Data

─ Apply the identification to the identification carrier ─ Capture the identification of the traceable item ─ Collect traceability data ─ Store traceability data

─ Assign identification to traceable item ─ Collect traceability data ─ Share traceability data

Request Trace

(no use cases were direcly used)

─ Send a trace request ─ Reply to a trace request

Use Information

(no use cases were direcly used)

─ Monitor the traceability process

(was not included yet in the approach)

(was not included yet in the approach)

Standard Subprocess

Recall Product

Based in the insufficient information from subprocesses and steps that were identified, new inputs are required that are directly related to the real industrial case study where the approach was adopted. We present the applicability of the approach in a real industrial case study, namely in automotive industry. Thus, it is presented a use case model in Fig. 1 that represents the applicability of our approach to the automotive industry (and ultimately to the organization that regards the presented real industrial case). This use case model captures the functional requirements of all phases and main activities of the global traceability BP. This model also relates these phases with the corresponding stakeholders. The first-level use cases model (sometimes called level zero) of the traceability BP directly corresponds to the 5 sub-processes proposed by the GS1 global traceability standard (see Fig. 1). All these use cases were decomposed in order to organize them hierarchically in activities at the same level of abstraction. Each use case from this model was textually described as well. If, for this level of abstraction, modeling of use cases was performed directly from the global standard subprocesses, refining these use cases was not possible to derive

Deriving UML Logical L Architectures of Traceability Business Processes

533

directly from standard subp processes and steps. The refinement was initially perform med as directly as proposed by the global standard, but the information from the subpprocesses and steps soon was insufficient i and too generic to enable a proper use casee refinement. The global standaard was directly modeled in the first-level use cases, butt its steps were able to be direcctly modeled in second- and in third-level use cases. Thhus, there was not a direct corrrespondence between global standard steps and the low werlevel use cases from the model. The use case model mainly included actors from higgher hierarchy, and actors from lower l hierarchy were only assigned to use cases originaated from refinements where theeir specialization to the given activity was identified. So, such insufficiency was com mpensated by some literature. This was not however enouugh, and the next step was to inccorporate workflows from the industrial context where this research was conducted, nam mely the electronics and automotive industry.

Fig. 1. GS1 G global traceability standard subprocesses

{UC1} Plan and Organizee {UC1} Plan traceability {UC1.1} Understand business area

Tracea ability partner

{UC1.2} Manage traceability data

{UC1.3} Link internal traceability phases

{UC1.4} Create traceability plan

Fig. 2. {UC1} Plan traceability use case model

534

R. Neiva et al.

The refinement of this use case gave origin to use cases {UC1.1}, {UC1.2}, {UC1.3} and {UC1.4} (see Fig. 2) and all of them were also refined (except for {UC1.3}), i.e., a third-level of abstraction was modeled. Use case {UC1.1} Understand business area (included additional lower-level use cases regarding its functional decomposition) was completely modeled and specified based on interviews with some stakeholders from the specific industrial context and literature review, which is to say, no input at all from the global traceability BP subprocess. Some of the use cases from the decomposition of {UC1.2} Manage traceability data and {UC1.3} Link traceability phases were modeled entirely based on the steps from the subprocess and others from interviews and literature review inputs, which is to say that overall {UC1.2} was partially based on the standard. Use case {UC1.4} Create traceability plan was based on the standard, but its specification was strengthened with interviews and literature. {UC2} Align Master Data The refinement of this use case gave origin to use cases {UC2.1}, {UC2.2}, {UC2.3}, {UC2.4} and {UC2.5} (see Fig. 3) and all of them were also refined, i.e., a third-level of abstraction was modeled. Use cases {UC2.1}, {UC2.2}, {UC2.3}, {UC2.4} and {UC2.5} were entirely based on the standard subprocess, but refinements from all of them were partially or not at all specified based on the standard steps, thus interviews and literature were input for all of third-level use cases. {UC2} Align master data {UC2.1} Identify traceability partner

{UC2.2} Identify physical locations

Brand owner

{UC2.3} Identify assets Traceability partner

Traceability data creator

{UC2.4} Identify trade items Traceability data source

{UC2.5} Exchange master data Traceable item creator

Fig. 3. {UC2} Align master data use case model

{UC3} Record Traceability Data The refinement of this use case gave origin to use cases {UC3.1}, {UC3.2}, {UC3.3}, {UC3.4}, {UC3.5} and {UC3.6} (see Fig. 4) and only {UC3.4} Collect traceability data required additional refinements. Use cases {UC3.2} Apply the identification to


535

the identification carrier, {UC3.3} Capture the identification of the traceable item, {UC3.4} Collect traceability data and {UC3.6} Store traceability data were entirely based on the standards subprocesses. Use cases {UC3.1} Assign identification to traceable item and {UC3.5} Share traceability data were based on the standard subprocesses, but its specification was strengthened with interviews and literature. This was the case (but regarding standard steps) for all the use cases from the refinement of {UC3.4} Collect traceability data as well. In conclusion, in {UC3} all the use cases were at least partially based on the global standard.

{UC3} Record traceability data {UC3.1} Assign identification to traceable item

{UC3.2} Apply the identification to the carrier Traceability recipient {UC3.3} Capture the identification of the traceable item

Traceable item creator

Traceability data creator

{UC3.4} Collect traceability data Transporter

{UC3.5} Share traceability data

{UC3.6} Store traceability data

Traceability source

Traceability partner

Fig. 4. {UC3} Record traceability data use case model

{UC4} Request trace {UC4} Request trace {UC4.1} Send a trace request

{UC4.2} Reply to a trace request

Traceability partner

{UC4.3}Consult the state of trace requests

Trace request initiator

F9

Fig. 5. {UC4} Request trace use case model

Brand owner

536

R. Neiva et al.

The refinement of this use case gave origin to use cases {UC4.1}, {UC4.2} and {UC4.3} (see Fig. 5), where in this case no additional refinements were required. Use cases {UC4.1} Send a trace request and {UC4.2} Reply to a trace request were based on the aggregation of two standard steps, but its specification was strengthened with interviews and literature. This aggregation of steps implied changes on the use case actor, since the assigned role had to be analyzed for addressing both use cases that were aggregated. Use case {UC4.3} Consult the state of trace requests was completely modeled and specified based on interviews with some stakeholders from the specific industrial context and their explicit identified need for monitoring traces, which is to say, no input at all from the global standard. {UC5} Use information The refinement of this use case gave origin to use cases {UC5.1} and {UC5.2} (see Fig. 6) where in this case no additional refinements were required. Use case {UC5.1} Monitor the traceability process was partially based on the standard subprocess and steps, where its specification was strengthened with interviews and literature. Use case {UC5.2} Consult trace requests with reply was completely modeled and specified based on interviews with some stakeholders from the specific industrial context and literature review, which is to say, no input at all from the global standard. {UC5} Use information {UC5.1} Monitor the traceability process Traceability partner {UC5.1} Consult trace requests with reply Trace request initiator

Fig. 6. {UC5} Use information use case model

The overall use case model is composed by 64 use cases. Within these use cases, the model included 49 leaf use cases and they were used as input in the 4SRS execution. In summary, 18 of the elicited use cases were directly obtained from the standard, 22 were partially obtained from the standard (i.e., with additional inputs from other sources like literature and stakeholder’s needs) and 24 were obtained only from literature and meetings with stakeholders. Additionally, it is easily depicted that the standard (in this case, GS1) is too generic to be modeled in use cases and its use is input mainly within higher-level use cases from the model.

4

Deriving a Logical Architecture for Traceability

In this section is presented the logical architecture derived from the use case model from the real case study in industry presented in the previous section. A transformation method, the process-level 4SRS [17], is used in order to derive a logical architecture for the traceability BP. The 4SRS method receives as input a set of functionally


537

decomposed use cases (also called leaf use cases) that describe the process requirements. These use cases are refined through successive iterations of the 4SRS method and in the end a logical architecture of that process is obtained. Consider an AE (Architectural Element) as the elementary piece of a logical architecture (a logical architecture is also composed of associations between the AEs and packages, nevertheless associations cannot exist without AEs and packages are not expressive unless they contain AEs). Each AE should have a well-defined set of responsibilities, well defined boundaries and a well-defined set of interfaces, which define the services the architectural element provides to the remaining AEs [30]. The 4SRS is composed of 4 steps (with 10 micro-steps), briefly described as follows [17]: Step 1 – Architectural Element Creation: In this step, three types of AEs (interface – i-type, control – c-type, and data – d-type) are created for each use case; Step 2 – Architectural Element Elimination: In this step, it is decided which AEs created for each use case are maintained or eliminated, taking into account the entire system, This step is divided into eight micro-steps, Micro-step 2i – Use Case Classification, Micro-step 2ii – Local Elimination, Micro-Step 2iii – Architectural Element Naming, Micro-step 2iv – Architectural Element Description, Micro-step 2v – Architectural Element Representation, Micro-step 2vi – Global Elimination, Microstep 2vii – Architectural Element Renaming, Micro-step 2viii – Architectural Element Specification; Step 3 – Packaging and Aggregation; The AEs that were maintained after the execution of step 2 should give origin to packages (or aggregations) semantically consistent; Step 4 – Architectural Element Association This last step supports the introduction of associations between AEs. This step is divided into two micro-steps (optional): Micro-step 4i – Direct Associations and Micro-step 4ii – Use Case Model Associations. The main output of these four steps is a logical architecture, which captures the main responsibilities and boundaries of a traceability process. This model provides a non-fragmented view of the main activities that make up the traceability BP. The specification of traceability process requirements and the logical architecture of this process are described in detail in the following sections. The execution of the 4SRS over the 49 leaf use cases from this real case study resulted in a logical architecture composed of 79 AEs and 390 associations between them. The logical architecture of the standard-based global traceability BP for industrial supply chains comprises a set of abstractions supporting the functional requirements of that process or the activities that comprise that process. AEs were aggregated according to their semantics, which means a package aggregates AEs that cooperate for the execution of the same activity from the traceability BP. For instance, the AEs related to the activity represented by the use case {UC3.4} Collect traceability data are contained by the package with the same name ({P4} Collect traceability data). If the use cases in Fig. 1 (representing the GS1 global traceability standard subprocesses) correspond to the highest abstraction level of business process functional requirements, the use cases in Figs. 6 (representing the GS1 global traceability standard activities) through 10 correspond to the second highest abstraction level. Overall, we obtained 41 AEs of i-type, 19 AEs of c-type, and 19 AEs of d-type, which implies that this process is extremely dynamic. Such was expected from the nature and purpose of traceability itself. An interesting fact of this result is that 19 AEs are of d-type, and therefore have no computer support. This means that there are plenty of traceability key activities that depend on human decision.

538

R. Neiva et al.

Fig. 7. Subset of the information model regarding package {P4}

The set of AEs contained by each package determines the detailed scope of package {P4} Collect traceability data, represented by means of the contained AEs. Hereupon the execution of the 4SRS allows identifying the responsibilities of high abstraction level activities (in this case the activity of collecting traceability data,


539

previously represented by the use case {UC3.4} Collect traceability data) and their association with other traceability process activities and subprocesses. For instance, in package {P4}, these responsibilities are: (i) the decision about the traceable item identification; (ii) the identification carrier creation; (iii) the capture of the traceable item identification; (iv) the decision on how maintain the traceability data, among others. The package {P4} Collect traceability data is perhaps the most complex of this architecture, although all are irreplaceable. It consists of 17 AEs. Besides the number of AEs, the complexity of this package lies in the significant number of associations between other packages, which increases their dependency of this package on the proper functioning of the outer AEs. Referring to the premise for the clustering of AEs into packages, the execution of the 4SRS method managed to conceptualize a big picture of the group of activities, and thus identify some challenges related to this abstraction. In the particular example of package {P4} Collect traceability data, those challenges are: (i) the need for interoperability between data collection mechanisms; (ii) the need for orchestrating traceability data collection at all stages of the BP; and (iii) the need for determining the life-cycle of the trade item in real-time. As mentioned in the description of the 4SRS, there are two types of associations between two AEs: direct association and use case model association. The first type (solid line) indicates that two AEs are originated from the same use case. The second type (dashed line) indicates that two AEs are somehow related. These relations are detailed in the textual description of use cases that originated them. Considering the example of package {P4} (see Fig. 7) it is possible to clearly identify the roles of the different associations. An example of these associations is depicted in Fig. 8.

Fig. 8. Direct associations and use case associations

Considering the example presented in Fig. 8, there is an activity deciding which traceability data to include on the identification carrier of the traceable item (performed in {AE3.2.c} Decide data to Include in the identification carrier). Additionally, there is an activity regarding the creation of the respective identification carrier of that item (performed in {AE3.2.i} Create identification carrier). Both activities originated in the same use case. Another required activity regards collecting data about the transformation of a traceable item (performed in {AE3.4.3.i2} Calculate trade item path (lifecycle)). The latter has an association with {AE3.2.i}, requiring the result of the activity of {AE3.2.i} to perform its activity. All associations within the architecture should be thoroughly analyzed, because the existence of anomalies in one AE may imply anomalies in the AE associated with it. Therefore, all identified dependencies must be assured in of the traceability BP implementation, guaranteeing communication between the various parts of the process.

540

R. Neiva et al.

In conclusion, the proposed process modeling approach allows identifying the traceability process key elements. Through the creation of AEs, it is possible to capture a well-defined set of responsibilities, the boundaries of each element of the process, and a set of well-defined interfaces that define the services that this AE provides to other AEs. Thus, it is possible to promote interoperability between the traceability BP subprocesses, including internal and external traceability. This is essential to get a holistic view of the traceability BP. Without such view, any attempt to implement the BP is likely to fail.

5

Conclusions

This paper highlights the potential of traceability to support the sustainability of industrial organizations. Currently, the traceability process implementation presents many challenges particularly in regard to the common understanding among key stakeholders. To address this problem a logical architecture that supports the functional requirements of the traceability BP was proposed. This architecture is the main contribution of this research. This architecture resulted from the application of 4SRS, which is a new and systematic approach in the area of Industrial Engineering. On the one hand, it is aligned with the GS1 global traceability standard. On the other hand, it captures the traceability BP main activities allowing either an alignment among stakeholders about the main activities either a common vocabulary for understanding the scope and the traceability responsibilities. In this research work, an approach was proposed to improve the overall vision and knowledge about the traceability BP in an industrial environment. The literature review (in particular, the works of [4, 5, 31]) allowed realizing that many of the gaps and constraints of the traceability BP reside in the lack of a common understanding among its key stakeholders. Facing such perception, this work proposed the development of a logical architecture that captures the main activities, responsibilities, boundaries, and services involved in the traceability BP. The 4SRS method was used to derive this architecture. This method is typically used in the design of Information Systems to represent the requirements for process execution. The requirements elicitation involved a detailed analysis of the GS1 global traceability standard, where a set of key use cases that capture the functional requirements of traceability BP were presented. The use of this standard was useful only in a very embryonic moment of the requirements elicitation phase, since its high degree of generalization did not allow a proper functional refinement, so we other sources of information were used (case studies, the authors' experience, among others). The inclusion of an industrial traceability standard promotes the use of best practices that result from consensus and validation of various industry bodies. This is certainly an added-value in our approach. Also during modeling, high complexity was found within the main activities that comprise the traceability BP. The use cases' functional refinement proved to be a useful exercise to minimize this constraint, which includes the detailed description of the 64 use cases to help in this matter. The use of the standard (in this case, GS1) is input mainly within higher-level use cases from the model, although our model was composed by use cases directly obtained from the standard regarding first-, second- and third-level use cases.


541

The logical architecture inherits the benefits of the proposed use cases. The 4SRS had never been used for this particular context. However, this method has proved very useful since it has formalized and guided the development of our architecture. Some subjectivity can be pointed to the application of 4SRS. To minimize this subjectivity we made some iterations and revisions. A logical architecture of the traceability BP composed by 79 AEs was proposed, promoting an object-oriented vision. These AEs are the fundamental elements in order to enable this architecture addressing the original problem. What distinguish an AE of any other are mainly three aspects: (i) each AE has a well-defined set of responsibilities; (ii) each AE has well-defined boundaries; and (iii) each AE has a set of well-defined interfaces, which define the services that the AE provides to the remaining AEs. By capturing the behavior of the traceability BP, this approach reduces the process ambiguity. Knowing the AEs (and logical architecture as a whole) is useful both for organizations without a formalized traceability BP as for organizations with mature and well established traceability BP. Thus, this architecture could serve as a guide for new traceability BP implementations and/or as an element to assess how well established is a traceability BP. In summary, our systematic approach offers an integrated, comprehensive and holistic overview of the traceability BP that allows to delineate and also detailing the scope of traceability. With the use of the 4SRS we assure a scalable and reusable logical architecture. This method allows adding other activities to the logical architecture. In the proposed model, Recall Product subprocess was not included. However, our proposed approach may easily include Recall Product subprocess within the use case model and use it in the logical architecture derivation in future works. In the future we intend to evaluate the logical architecture proposed based on the behavior of a traceability BP already implemented. This study should help align the logical architecture with some traceability organizational practices.

References 1. Cognex, Traceability for the Automotive Industry (2011). http://acrovision.co.uk/wpcontent/uploads/2011/07/Expert_Guide__Traceability_for_the_Automotive_Industry.pdf 2. Eckert, W.: Traceability In Electronics Manufacturing. Onboard Technology (2005). http://www.onboard-technology.com/pdf_ottobre2005/100510.pdf 3. Lima, R.C.G.: Indústria Automobilística. Desafios na Cadeia Produtiva (2013). http://www.ibm.com/midmarket/br/pt/articles_general_industry_3Q3.html (retrieved July 22, 2013) 4. Martins, J.C., Machado, R.J.: Ontologies for product and process traceability at manufacturing organizations: a software requirements approach. In: 2012 Eighth International Conference on the Quality of Information and Communications Technology (QUATIC). IEEE (2012) 5. GS1, The GS1 Traceability Standard: What you need to know (2007). http://www.gs1.org/docs/traceability/GS1_tracebility_what_you_need_to_know.pdf 6. GS1, GS1 Standards Document - Business Process and System Requirements for Full Supply Chain Traceability GS1 Global Traceability Standard (2012). http://www.gs1.org/sites/default/files/docs/gsmp/traceability/Global_Traceability_Standar d_i1p3p0_November_2012.pdf 7. International Organization for Standardization (ISO), Quality management systemsFundamentals and vocabulary, vol. 2000 (2005)

542

R. Neiva et al.

8. Moe, T.: Perspectives on traceability in food manufacture. Trends in Food Science & Technology 9(5), 211–214 (1998) 9. Jansen-Vullers, M.H., van Dorp, C.A., Beulens, A.J.: Managing traceability information in manufacture. International Journal of Information Management 23(5), 395–413 (2003) 10. Gotel, O., et al.: Traceability fundamentals. In: Software and Systems Traceability, pp. 3–22. Springer (2012) 11. Dijkman, R.M., Joosten, S.M.: Deriving use case diagrams from business process models (2002) 12. Redding, G., et al.: Generating business process models from object behavior models. Information Systems Management 25(4), 319–331 (2008) 13. Jani, D., Vanderveken, D., Perry, D.E.: Deriving architecture specifications from KAOS specifications: a research case study. In: Morrison, R., Oquendo, F. (eds.) EWSA 2005. LNCS, vol. 3527, pp. 185–202. Springer, Heidelberg (2005) 14. Castro, J., Kolp, M., Mylopoulos, J.: Towards requirements-driven information systems engineering: the Tropos project. Information Systems 27(6), 365–389 (2002) 15. Ullah, A., Lai, R.: Modeling business goal for business/it alignment using requirements engineering. Journal of Computer Information Systems 51(3), 21 (2011) 16. Duarte, F.J., Machado, R.J., Fernandes, J.M.: BIM: a methodology to transform business processes into software systems. In: Biffl, S., Winkler, D., Bergsmann, J. (eds.) SWQD 2012. LNBIP, vol. 94, pp. 39–58. Springer, Heidelberg (2012) 17. Santos, N., Machado, R.J., Ferreira, N., Gašević, D.: Derivation of process-oriented logical architectures: an elicitation approach for cloud design. In: Dieste, O., Jedlitschka, A., Juristo, N. (eds.) PROFES 2012. LNCS, vol. 7343, pp. 44–58. Springer, Heidelberg (2012) 18. Terzi, S., Cassina, J., Panetto, H.: Development of a metamodel to foster interoperability along the product lifecycle traceability. In: Konstantas, D., et al. (eds.) Interoperability of Enterprise Software and Applications. Springer Science & Business Media (2006) 19. Terzi, S., et al.: A holonic metamodel for product traceability in product lifecycle management. International Journal of Product Lifecycle Management 2(3), 253–289 (2007) 20. Gampl, B.: Traceability systems in the German food industry–towards a typology. Department of Agricultural Economics. University of Kiel (2003) 21. Panetto, H., Baïna, S., Morel, G.: Mapping the IEC 62264 models onto the Zachman framework for analysing products information traceability: a case study. Journal of Intelligent Manufacturing 18(6), 679–698 (2007) 22. Gogliano Sobrinho, O., et al.: Modeling of an information system for wine traceability based on a service oriented architecture. Engenharia Agrícola 30(1), 100–109 (2010) 23. GS1, GS1 Global Traceability Standard for Healthcare (GTSH) - Implementation Guide (2009). http://www.gs1.org/docs/gsmp/traceability/Global_Traceability_Implementation_Healthca re.pdf 24. GS1, Traceability for Fresh Fruits and Vegetables Implementation Guide (2010). http://www.gs1.org/sites/default/files/docs/gsmp/traceability/Global_Traceability_Implem entation_Fresh_Fruit_Veg.pdf 25. Smith, I., Furness, A.: Improving traceability in food processing and distribution. Woodhead Publishing (2006) 26. Manikas, I.: A web application for supply chain traceability. In: Graham, D., Manikas, I., Folinas, D.K. (eds.) E-Logistics and E-Supply Chain Management: Applications for Evolving Business. IGI Global (2013)


543

27. Bevilacqua, M., Ciarapica, F.E., Giacchetta, G.: Business process reengineering of a supply chain and a traceability system: A case study. Journal of Food Engineering 93(1), 13–22 (2009) 28. UML, O.: 2.4. 1 superstructure specification. 2011, document formal/2011-08-06. Technical report, OMG 29. Azevedo, S., et al.: The UML «include» relationship and the functional refinement of use cases. In: 2010 36th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA). IEEE (2010) 30. Rozanski, N., Woods, E.: Software Architecture Systems Working with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley (2005) 31. Ashford, P.: Traceability. Cell and Tissue Banking 11(4), 329–333 (2010)