Abstract
An UML profile describes lightweight extension mechanism to the UML by defining custom stereotypes, tagged values, and constraints. They are used to adapt UML metamodel to different platforms and domains. In this paper we present an UML profile for models supporting event driving simulation. In particular, we use the Arena simulation tool and we focus on the mining process domain. Profiles provide an easy way to obtain well-defined specifications, regulated by the Object Management Group (OMG). They can be used as a presimulation technique to obtain solid models for the mining industry. In this work we present a new profile to extend the UML metamodel; in particular we focus on the activity diagram. This extended model is applied to an industry problem involving loading and transportation of minerals in the field of mining process.
1. Introduction
The literature on formal use of Unified Modeling Language (UML) [1] is huge and growing rapidly. This tool becomes a modeling standard in 1990 to follow what changed the world of software [2]. UML makes it possible to model any system from different perspectives. Modeling a system from different perspectives allows to clearly picking the vision of what you want to do. This is because UML is a language that holds its own specific rules, semantic, and syntax.
UML can be used as documentation of code, but it is also intended as a means of specifying a system. Model Driven Architecture (MDA) [3] calls for complete systems to be generated automatically from UML models. If the language is not precisely defined, the generated system may not be what the model creators intended.
UML has an abstract syntax which is processed by model transformation and code generation. The relation in UML between concrete diagrammatic syntax and the abstract syntax it represents is complicated enough to be a potential source of error. Precisely defining this relationship could simplify the creation of graphical model editors and facilitate animations [4] and reverse engineering. The definition should clearly delineate concrete syntax, abstract syntax, and semantics, and it should also specify the relationships between these parts.
UML defines several types of diagrams to view the dynamic aspects of a system. One of these diagram types is the activity diagram [5] which is used in this work to document the workflow in a system. UML Diagrams are suitable for system analysis, design, and development. However, UML and its diagrams cannot accurately specify concepts for particular domains. That is why UML embodies the concept of profiles. Profiles are defined by the Object Management Group (OMG) in its specification [1], as a predefined set of stereotypes, tagged values, constraints (by using Object Constraint Language (OCL)), and notation icons that collectively specialize and tailor UML to a specific domain or process. When these elements are introduced the model can be clearly visualized and software developers can improve communication and establish a common vocabulary. Also profiles allow adding information to the model to transform it to other models. Object Constraint Language (OCL) constraints are semantic restrictions added to UML elements. The advantage of profiles is that most UML tools can easily apply them. When using profiles it is not necessary to define neither a special notation nor special tools (UML tool is used).
The UML metamodel (which consists of entities and relationships) of the domain is a process-oriented tool. It is graphically structured for the construction of diagrams or flowcharts. These diagrams show the number of steps required by an entity as it moves into the system.
Another powerful tool for system analysis and design is simulation. Its benefits are applicable to almost all kinds of industry. It involves designing a model of a particular system to solve it by means of a numerical technique (algorithm) and the subsequent execution of a series of experiments with the aim of understanding the behavior of such system under certain conditions [6]. The model should be able to reproduce the actual process behavior as accurately as possible. There are many simulation softwares of general purpose [7–10]; in this work we focus on the Arena [10] simulation because it has become the market-leading discrete event simulation software.
To reconcile the two ways of approaching the same subject, namely, UML and simulation, in this work we propose to model a system of loading and transportation of material in the field of the mining industry. In particular, we propose to extend the UML metamodel using profiles. The objective is to adapt the UML metamodel to be able to represent the basic modules of Arena.
The advantage of the proposed profile is that (a) it allows reusing the stereotypes created for the Arena simulation software. Moreover, those stereotypes can be applied to any other process-oriented simulation software. We can also use them or integrate them as part of any other process-oriented simulation software.
This paper is organized as follows. Section 2 presents related work. The Arena simulation software is briefly described in Section 3. Section 4 presents our mining process case of study. Section 5 presents the proposed profile implementing a simulation environment and its OCL constraints. Conclusions are included in Section 6.
2. Related Work
Modeling and simulation techniques provide the possibility of studying new strategies and to predict the effect of new policies, new designs, and new strategies which would otherwise be too expensive or even impossible to implement and test on real cases. Both the UML modeling and the simulation approach model from two different communities (or point of view) but they can be used for similar purposes.
Some recent methodologies and techniques for modeling and simulation have been presented in [11–13]. In particular, the authors in [11] use genetic algorithms to improve component analysis. This technique is applied to simulated data collected from the Tennessee Eastman chemical plant. The work in [12] evaluates basic data-driven methods for process monitoring and fault diagnosis. Also in this case the benchmark of Tennessee Eastman (TE) process is utilized to illustrate the efficiencies of the discussed methods. Finally, in [13] the authors present a fault tolerant control architecture which can be reconfigured online. The proposed scheme is evaluated with the TE benchmark model.
In this work we focus on UML modeling and simulation techniques which are widely used in systems engineering. Although these two methodologies have evolved separately, there are some works [14–17] that integrate modeling tools with specific simulation software.
The works presented in [14, 15] show how the UML-Arena combination is used to create a model. Then this model is reused into the simulation environment of the Arena software. In [14] the authors describe the use of activity diagrams to automatically generate simulation models and propose the use of an algorithm as a solution to automatically transform UML models (only activity diagrams) into simulation models. Similarly, the authors in [15] show the use of UML activity diagrams as the basis for building simulation models, which are then run on the Arena simulation software.
In other words, these studies show a methodology to transform activity diagrams into simulation models for Arena. However, they do not take advantage of the UML profiles. A profile created for a specific situation can be reused into other environments with similar characteristics, thus saving time and increasing the versatility of the profile created.
As explained in [18], OMG defines two possible approaches for defining domain specific languages. In the first one, a new alternative language is defined [19]. A new tailor-made language will produce suitable specific notation that will match the concepts of a specific application domain. However, as the new language does not respect UML semantics, it will not allow the use of commercial UML tools for drawing diagrams, generating code, and so forth [18]. The second approach (named Profiles) uses the UML metamodel respecting the original semantic of the UML elements (classes, attributes, etc.). But new constrains are added to the definition and to the relationships of those elements.
The works in [20–22] show the versatility of profiles to define different environments (application domains), which extend the UML specification (not only the syntax but also the semantic through formal OCL constraints). In particular, the work in [20] shows the way for defining design patterns with profile, proposing architecture in levels. It shows how the definition of a profile for a particular pattern, and how an UML tool can be enough to introduce profile for patterns. It analyzes the advantages of using profiles to define, document, and visualize design patterns.
The work in [22] shows the definition of the C&K metrics applied to Aspect Oriented Design (AOD) using UML profiles. A new definition of metrics using profiles without modifying the OMG metamodels is specified. An OCL formal specification is developed. The defined profile allows applying methodologies which use AOD and allows measuring the design. The calculation of the resources is an activity that can improve the software development. The engineers can import this profile to any UML tool and measure the quality of its AOD. They do not need to build a specific tool for AOD. They can use any UML tools and thereby improve the quality of aspect oriented developments.
In [21], the creation of components of the Java EE 6 business platform from technical business processes modeled with Business Process Model Notation (BPMN) 2.0 is proposed. This generation was achieved by performing three transformations in the context of Directed Model Architecture (MDA). First, a technical model BPMN 2.0 is transformed into an UML class model. Then the class model is transformed into a model with Enterprise Edition (Java EE) profiles. Finally the last generated model is transformed through Meta Object Facility Script (MOFScript) into Java EE components. The transformations are performed with Query View Transformations (QVT) Relations and MOFScript. This work contributes with transformations between profiles generated with Java EE business components related to business processes, so it helps in improving the development productivity and in reducing design errors.
In [16], UML is proposed as an effective structure for building simulation models of hybrid manufacturing systems, where machines communicate through a network or using buffers. The model is implemented with the MATLAB language [23]. UML is used for modeling, but UML profiles are not considered.
The work in [24] presents research results related to the main steps of the modeling and simulation process (e.g., design of simulation experiments), as well as to the application of simulation for solving different problems, inherent to the operation of complex systems (e.g., analysis, optimization, and management). In particular, the authors describe a tool which integrates simulation methodologies that incorporate simulation with other scientific approaches for the analysis, optimization, and management of complex systems. This tool allows for transforming UML models into a simulation environment; in particular the Arena simulation environment is used.
UML has also been used in collaboration with other simulation softwares like DEVS [25] or Petri Nets. In [26], the authors present UML diagrams that are extended with stochastic attributes. This provides possibilities for further simulation of a developed model using a simulation tool called DEVS [25]. The authors generate UML models using use case and activity diagrams. On the other hand, the work in [17] proposes a methodology for transferring knowledge to students. The authors propose to combine the use of Petri Net and UML to model a business process as a system of discrete events. None of these papers create UML profiles.
In this paper we focus on the use of UML activity diagrams such as a presimulation techniques, because they allow capturing dynamic aspects of the behavior of a system. We extend the UML metamodel by defining profiles for a particular domain. Unlike previous work, like described in [14, 15], our work ensures that the UML metamodel is not modified and it also meets all the semantic. Moreover, our proposed profile is specified with the formality given by the OCL [27] language, allowing (1) to reuse the proposed stereotypes with any other simulation software and (2) to reuse the simulation model with any tool that includes profiles.
3. Simulation with Arena
Modeling and simulation provide the basis for the efficient solving of various problems related to the operation of complex systems like analysis, optimization, and management and industry problems like mining process, and so forth. Simulation is considered to be one of the most effective technologies for the analysis and planning of logistics systems.
Using simulation, you can include randomness through properly identified probability distributions taken directly from study data. For example, in this work we consider the loading and transportation of material in the field of the mining industry. In this case, there may be intersections on roads or narrow paths that only allow a truck to move at a time. Simulation also allows including the analysis and evaluation of the system when failures occur.
Other techniques such as spreadsheet analysis or linear, goal, and dynamic programming are useful to maximize or minimize a single element (e.g., cost, utilization, or wait time). But these techniques limit the analysis to only one element, often at the expense of secondary goals. They do not allow randomness. In particular, spreadsheet analysis forces to use the average time and will not be able to accurately capture the variability that exists in reality.
Arena simulation software [10] is a general propose simulation tool enabling the construction of models over a series of modules or basic components organized hierarchically. The Arena simulation software has high level of modeling supporting graphical design. It also includes a lower level of modeling including specific details as arrival times, service times, scheduling of processes, and so forth.
A model is developed using modules that are part of the basic processes. In Arena, modules are the flowchart and data objects that define the process to be simulated. All information required to simulate a process is stored in modules. The dynamics associated with the processes can be viewed as nodes in a network by which entities circulate causing a change in the system state. The entities with attributes and variables compete for the services provided by the resources. Entities are items (like trucks, mineral, etc.) that are being served or produced.
Figure 1 shows a simple model build with Arena. The CREATE module is the starting point for entities in a simulation model. Entities are created using a schedule or based on a time between arrivals. Entities then leave the module to begin processing through the system. The entity type is specified in this module. The PROCESS modules are intended as the main processing method in the simulation. They include the resource by which entities compete. A resource retained by an entity must be released at some point in the model. Otherwise, a deadlock can occur. The DECIDE module allows for decision-making processes in the system. Finally, the DISPOSE modules are ending point for entities in a simulation model.
After the model is built, we can run simulations to obtain different metrics and statistics like resources utilization, waiting times, and so forth.
4. Case Study: Mining Process
A real system model is fundamental when making crucial decisions. A system model offers the possibility of planning with less error. But more importantly, it is possible to investigate new operating procedures that can be used repeatedly without interfering in the operational and daily activities of the system.
The profile proposed in this work is applied to a system of load and transportation of minerals. During the mining process, once the rock or mineral has been removed from its extraction site, it needs to be transported immediately to its final destination. Generally, the transport system consists of a set of trucks.
Several factors are considered for the selection of trucks, the most important factor is the capacity of the vehicle in the mine. To meet daily production requirements is necessary: (a) a good performance of the equipment, that is, to achieve the perfect match “shovel-truck” to obtain maximum extraction and transportation of minerals and (b) the road conditions should be well maintained.
The tasks performed in the daily cycle of a mining process [28, 29] start with the definition of a drilling mesh (according to height, quality, and quantity of the field to be explode). Then, holes are drilled into the field. Then the explosives are introduced into the hole for blasting. The aim is to detach the rock out of the field and crush it. Then blasted material is loaded on the trucks and transported to a discharge area.
4.1. Mining Process Simulation with Arena
In this section we explain how to perform the design of load and transportation of minerals in the field of mining process using the Arena simulation tool. However, we emphasize that the focus of this paper is not the simulation design/evaluation of the mining operations but the profile design for discrete event simulations applied to the field of mining projects.
We model a transportation system for a limestone quarry. The trucks move between their loading points to their discharge points using default routes. The cycle begins with the release of trucks (≪Create≫) to operating fronts. Trucks are distributed among three different zones (using the module ≪Decide≫) to load the mineral. The distribution percentage of the ≪Decide≫ module is based on the quality and quantity of material. Once in the loading zone (≪Process≫), if the blade (≪Resource≫) is free then the truck is loaded without delay. Otherwise, it should be queued (≪Queue≫) until the resource is released.
When the loading process ends, the truck is directed to the discharge zone (≪Process≫), which may be inside the plant or in the sterile area, according to the specific material being transported. This cycle is repeated according to the scheduled work.
Tables 1 and 2 present time involved in a limestone quarry to move trucks from/to the treatment plant to/from the operating fronts. Trucks unload the mineral into a chute in the treatment plant. At the operating fronts we find shovels to load the trucks. Unloaded trucks move faster than loaded trucks. Then the time required to move unloaded trucks from the treatment plant to the operating fronts is smaller than the time required to move the loaded trucks from the operating fronts to the treatment plant as shown in Table 1. In Table 2 we show that the time to load/unload a truck follows an exponential distribution.
Figure 2 shows the simulation design implemented with Arena. In this particular case, we evaluate the transportation system of a limestone quarry with tree operation fronts. We set the maximum number of trucks to 5. The number of trucks has been chosen to avoid long queuing times. From each operation front the trucks are loaded with minerals with different “low values,” namely, with different quality of the mineral. In each operation front there is a shovel in charge of putting the mineral in the truck. To decide the route for each truck we use an “N-way by chance” ≪Decide≫ module and we set the percentage of each route to 33%.
Table 3 shows results obtained after we run the simulation for 20 days (each day has 16 working hours). As we said before the number of trucks is set to avoid long queuing times. Therefore results show that the average number of waiting trucks in each ≪Resource≫ (treatment plant, shovels 1, 2, and 3) is less than 1 and the queuing time in the worst case is less than 1 minute.
5. UML Profile Definition for Mining Process Simulation
UML uses a mechanism called profile [1] to adapt a model to a particular domain. A profile includes three elements: stereotypes, tagged values, and constraints. Stereotypes extend the vocabulary of UML and it is possible to associate tagged values (attributes associated with extended elements) and restrictions [20, 22]. These extension mechanisms allow to adapt a particular domain to an existing metamodel.
The main builder of the profile is the stereotype, indicated as ≪stereotype≫ [1]. It has the same structure or elements (attributes, associations, and operations) of the UML metamodel. So, it is not allowed to modify the semantics, structure, and original concepts [30] of the standard UML.
The proposed stereotypes are related to the components of the activity diagram [5], because they easily adapt themselves to characterize the simulation model [31, 32]. This diagram already has established appropriate notations and concepts showing the steps (activities), decision points, and bifurcations that occur in a transaction so that makes it easier to display. In particular in this work we used the Rational Software Architect (RSA) tool [33] which has the advantage of supporting OCL restrictions. But any tool supporting UML profiles can be used.
The semantic analysis performed to obtain the corresponding equivalences allows identifying the classes of the activity diagram that are necessary to extend through stereotypes. The simulation software has a greater number of modules, besides those mentioned here, some of which are identified with other classes of UML. The elements that are part of the profile are a subset of the UML metamodel applied to a simulation environment. Therefore, the profile presented in this work extends the base classes: InitialNode, Action, DecisionNode, ActivityFinalNode, JoinNode, and ObjectNode ForkNode belonging to the activity diagram.
Although, every stereotype has its own properties, the user can edit the values of those properties. Figure 3 shows a slice of the loading-transportation cycle, which highlights the properties of the stereotype ≪Create≫ and its corresponding values.
The stereotype ≪Create≫ extends the InitialNode metaclass. An InitialNode is a starting point for the implementation of an activity. In the UML specification, Superstructure v2.1.2 [5], the InitialNode is defined as a generalization of a control node where an object begins to flow through the system when an activity is invoked. This package belongs to the Basic Activities defined in the abstract syntax of UML Kernel Metamodel of OMG [5]. The Create module has attributes that define the input parameters, which must be defined by the user when starting the simulation. Figure 4 shows the stereotype and the extended metaclass. At the starting point of a simulation model we consider the (a) incoming flow rate generated (random or programmed constant) as well as the (b) number of entities that arrive to the system per unit time. In the mining process described in this work, every truck that enters into the system is a starting point.
Figure 5 shows the metamodel corresponding to the OMG specification. In this figure we show the metaclass named InitialNode which is a generalization of the metaclass named ControlNode.
The stereotypes ≪Process≫, ≪Assign≫, and ≪Register≫ have a base class named Action [5] in the UML metamodel. For example, if we use an element of type ≪Process≫ in the UML model, it means that the stereotype ≪Process≫ behaves similarly to its base class. Additionally, it has to satisfy the semantics specified with OCL. Figure 6 shows the metaclass named ≪Action≫ and its corresponding stereotypes. For our particular case of study about mining processes related to load and transportation, the ≪Process≫ stereotype represents the load operation by means of the shovel.
The UML class named JoinNode [5] is extended through a so-called ≪Group≫ stereotype as shown in Figure 7. In a simulation model, this class should specify the number of entities to be clustered as well as how these entities will be grouped (refers to whether to use random groups or, on the contrary, the entities should be grouped according to a specific attribute).
The class named ObjectNode is extended through four stereotypes ≪Entity≫, ≪WaitingQueue≫, ≪Resource≫, and ≪Set≫ as shown in Figure 8. The base class named ActivityFinalNode of the UML metamodel [5] was extended by a stereotype called ≪Dispose≫. The base class named ForkNode is extended through a stereotype called ≪Divide≫ [5]. This is shown in Figure 9.
The stereotype ≪Decide≫ [5] extends the UML metaclass named DecisionNode. Figure 10 shows this relationship.
The basic modules that integrate the simulation model of Arena are related to each other through connectors [10]. These connectors indicate how entities flow within the model. These connectors are represented with the metaclass of the activity diagram named ControlFlow. It is not necessary to extend this base class because there is a bilateral matching of the semantics.
Stereotypes defined above integrate the simulation profile that is applied in a mining process. The extended metaclasses were obtained as a result of observing the behavior of the basic modules of the simulation process. This analysis showed that while they share similarities in semantics, these modules have specific attributes that are not specified in the UML base classes, which is why we extended those classes, as described in the previous paragraphs.
5.1. OCL Restrictions
A model is an abstraction of a system. In particular in this work we model a mining process. It should be as accurate as possible. In order to find an unambiguous and consistent model, it is necessary to reformulate the restrictions to the developed profile.
The language proposed by UML to specify the restrictions of the diagrams is the so-called OCL (Object Constraint Language) [27]. OCL offers a convenient way of getting models with a high degree of consistency, because it is a formal language used to describe keywords in the model [34], making them more accurate and less ambiguous.
OCL is fully integrated into UML. We can check the values of the model elements and set restrictions on them. An example of a restriction on the profile element, in this case the stereotype ≪Decide≫, is especify in Algorithm 1.
| ||
The restrictions fulfill the purpose of validating the model where the proposed stereotypes apply. If an error occurs, it is immediately observed. In this case, we can introduce corrections so that the model complies with the preestablished conditions and reconcile with the expected results.
6. Conclusions
UML allows expressing specific concepts of discrete event simulation in the field of mining, through the extension of its basic classes. In particular, simulation software modules like CREATE and PROCESS are easily identified with the elements of the activity diagram. This feature provides high functionality to the proposed extended model, because its behavior is similar to the simulated system. System validation which was obtained by applying the profile to the mining process, where the load-transport cycle is a key part of a reservoir, satisfied the requirements imposed by the daily production.
Having a standard language like UML implies that it is possible to obtain a model with stereotypes with well-formed rules without ambiguous concepts. In this paper we presented an extension of UML for the basic elements of the Arena simulation software, which provides a higher level of abstraction. The integrated vision of these two languages (UML and simulation) helps build a consistent model for the process being simulated. Therefore, combining both tools facilitates the development of a system.
The proposed profile presents advantages at two levels.
Metamodel Level. At this level, any UML tool supporting profiles can be used to import the mining profile defined in this work. In this way, any engineer can use any UML tool for building their mining models using the same modeling language (UML profile). The second advantage is that if using a simulation language, other than Arena, or if the same Arena is extended with new characteristics, those characteristics can be easily included into the profile. The engineers use a modeling language (UML profile) independent of the simulation language (Arena, Simula, GPSS, etc.). The mining UML profile can be included with the specific semantic of any simulation language. Finally, using formal languages supporting mathematic specifications such as OCL (first order logic, theory of set and theory of bag) ensures much more accurate models than the ones used by other traditional modeling languages such as ERD (Entity Relationship Diagram), DFD (Data Flow Diagram) as general modeling language or ExtendSim Suite, Arena Blocks as specific modeling languages. The mathematic specifications are incorporated as OCL specifications in the metamodeling level of the profile. Therefore, the proposed UML profile can be reused with any UML tool that includes profile definitions with OCL.
Model Level. At this level, the engineer builds its standard models using the proposed profile, and these models can be used in any mining environment. The stereotypes can be applied with any mining process simulation software (not only Arena). Moreover, any UML tool that allows incorporating the standard profiles according to the OMG can be used to modify these models. Finally, we obtained models verified mathematically with OCL. Those are more accurate models according to the restrictions that are specified in the profile level.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.