Towards a Semantics of Activity Diagrams with Semantic Variation Points

UML activity and state chart diagrams are the most frequently UML models used for testing a system based on its specifications. Testers may choose different UML diagrams based on comprehensibility criteria. Previous studies, however, highlighted the lack of experts’ evaluation of comprehensibility of activity and state chart diagrams in test case generation. Thus, the main objective of this study is to evaluate the comprehensibility of the UML activity and state chart diagrams based on perspectives of experts. This study generated manual test cases from activity and state chart diagrams and used comprehensibility’s evaluation criteria during interviews with several software testing experts. The results of this study revealed that activity diagrams are more comprehensible than state chart diagrams in test case generation by considering comprehension variables (perceived difficulty and subjective confidence). The results of this study aim to unify the practical efforts of testers to choose MBT diagrams in generating test cases.

Formal modeling and verification of UML Activity Diagrams (UAD) with FoCaLiZe

Because of their structural and semantic inter-dependency, UML diagrams describing a software product must be consistent to ensure the success of the development process. This inter-diagram consistency is often not easy to ensure considering the multi-views the diagrams cover, the different levels of abstraction they encode, and the different development phases during which they are produced. In this paper, we tackle the consistency problem between the functional and dynamic views in behavioral diagrams of software. We propose an approach to detect and localize inter-consistency errors among UML use cases and activity diagrams. This approach is composed of two phases: measurement phase (1) and controlling phase (2). This approach is illustrated and validated through a "Restaurant management system" case study. The proposed approach will help both software designers/developers and quality assurance/testing engineers identifying and localizing the causes of software errors at early phases (specification and design).

The Unified Enterprise Modelling Language (UEML) aims to become a hub for integrated use of enterprise and information systems (IS) models expressed using different languages. The paper explains how central constructs from UML's class and activity diagrams have been incorporated into UEML. As a result, the semantics of UML's central constructs for representing classes and activities have become more precisely defined in terms of the common UEML ontology. Through their ontology images, the two diagram types are also on the way to become interoperable with other enterprise and IS modelling languages in UEML.

This paper deals with a new technique for validating object-oriented software at design phase of project development. There are several modeling diagrams used at design phase of Software Development Life Cycle. But in this paper, we focus on UML Activity Diagram. In our work, first we construct the UML activity diagram for the given system using ArgoUML. Then, the XML (“EXtensible Markup Language”) code is generated for the constructed activity diagram. Next, this XML code is translated to XSD (“XML Schema Definition”) code. This XSD code is given as input to JAXB (“Java Architecture for XML Binding”), which generates the Java template. Then, this Java template is instrumented to a complete Java program with minimal manual effort. Next, we carryout concolic testing of this Java code using jCUTE. This tool generates test cases by taking the Java program as input. Then, the obtained test suite and generated Java source code are inputed into our in-house developed tool named COPECA (COverage PErcentage CAlculator) to calculate MC/DC (Modified Condition/Decision Coverage) score. We have achieved 56.31% MC/DC on doing experiment with fourteen activity diagrams, which is a fair (moderate) achievement compared to the existing work.

This paper presents a prioritization technique that prioritizes the test cases using different design attributes like cohesion, coupling, the number of database access, and non-functional requirements. First, the system requirements are modeled using UML activity diagram (AD). The AD is turned into activity diagram graph (ADG), and the ADG is traversed to find out the test scenarios that are identified by the linearly independent paths in the ADG. Depending upon the different design attributes, weights for each node in the graph are identified and a final priority value is assigned to each node. The nodes executed for every test are identified, the priority value (PV) of the nodes is summed up, and the test case is assigned with a final priority value. Finally, depending on the priority value, the test cases are prioritized. The efficiency of the suggested approach is evaluated using the APFD metric.

UML activity diagrams are the object-oriented equivalent of flow charts and data-flow diagrams from structured development (Gane and Sarson 1979). In UML 1.x, UML activity diagrams were a specialization of UML state machine diagrams, although in UML 2.x they are full-fledged artifacts. UML activity diagrams are used to explore the logic of ■ a complex operation, ■ a complex business rule, ■ a single use case, ■ several use cases, ■ a business process, ■ concurrent processes, ■ software processes. General Guidelines Place the Starting Point in the Top Left Corner A starting point is modeled with a filled circle, using the same notation that UML state chart diagrams use. Every UML activity diagram should have a starting point, and placing it at the top left corner reflects the way that people in Western cultures begin reading. Figure 41, depicting the business process of enrolling in a university, takes this approach. Another good option is to place it at the top center of the diagram. Include an Ending Point An ending point is modeled with a filled circle with a border around it. Some people's style is to make ending points optional—sometimes an activity is simply a dead end—but if this is the case, then there is no harm in indicating that the only activity edge (formerly known as a transition) is to an ending point. That way, when someone else reads your diagram, they know that you have considered how to exit these activities.

On formalizing UML state machines using ASMs

Model Based Testing is one of the most critical area to be addressed efficiently to ensure effective testing of the given project. The system implemented combines UML with FSM to cover all scenarios with all possible paths. As Finite Machine also works on the trigger where conditions are framed and if these conditions are satisfied then next action is executed; this phenomenon motivates to build a framework for generating the test cases automatically covering all paths (activity diagram in UML helps to cover all paths) and conditions ( Finite State Machine helps to frame set of conditions). Model Based Testing designed considering all paths and conditions to check all scenarios to generate detailed test cases for given project or application.

The correctness of business process models is of paramount importance for the application on an enterprise level. A severe problem is that several languages for business process modelling do not have formal execution semantics which is a prerequisite to check correctness criteria. In this context, soundness defines a minimum correctness criterion that a process model should fulfil. In this paper we present a novel approach to reason about soundness based on so-called causal footprints. A causal footprint represents a set of conditions on the order of activities that holds for every case of a process model. We identify three kinds of error patterns that affect the soundness of a process model, namely the deadlock pattern, the multiple termination pattern, and the trap pattern. We use event-driven process chains (EPCs) and Petri nets to demonstrate the applicability of our approach for both conceptual as for formal process modelling languages. Furthermore, it can easily be applied to other languages, such as UML activity diagrams or BPEL. Based on the trap pattern, we prove that the "vicious circle", that is heavily discussed in EPC literature, is unsound

Identifying differences among models is a crucial prerequisite for several development and change management tasks in model-driven engineering. The majority of existing model differencing approaches focus on revealing syntactic differences which can only approximate semantic differences among models. Significant advances in semantic model differencing have been recently made by Maoz et al [16] who propose semantic diff operators for UML class and activity diagrams. In this paper, we present a generic semantic differencing approach which can be instantiated to realize semantic diff operators for specific modeling languages. Our approach utilizes the behavioral semantics specification of the considered modeling language, which enables to execute models and capture execution traces representing the models’ semantic interpretation. Based on this semantic interpretation, semantic differences can be revealed.KeywordsModeling LanguageClass DiagramModel ExecutionExecution TraceSymbolic ExecutionThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

In real world, most business processes are subject to time constraints. Equally important as the execution of a process is the time in which it is to be performed. A time constrained business process can be defined as a process whose correct behavior depends not only on the results obtained, but also on the time it is carried out. UML has become an important tool for model-driven software development, perhaps partly thanks to its visually oriented modeling concepts, and it is increasingly being used in business process modeling too. In this paper, we extend UML 2.0 Activity Diagrams with time annotations and new modelling constructs inspired of the Timed CSP language. Furthermore, in order to overcome the lack of formal semantics that these diagrams suffer from, we introduce a set of mapping rules to derive formal specifications in terms of Timed CSP processes from models in the extended Activity Diagrams being proposed. Timed CSP has several features that make it well suited to give a formal semantics for extended Activity Diagrams (e.g., compositionality, well defined denotational and operational semantics, etc.). The proposed mapping rules enable checking whether the model described in an Activity Diagram satisfies such properties as timeliness, deadlock freeness, liveness, etc. In order to show the applicability of our approach, we present a case study from a manufacturing domain.

Business process modeling notations are used in requirements engineering to specify business processes that should be supported by the system under development. Comparisons of business process modeling notations with regard to their concepts do exist, but to our knowledge, little evaluation has taken place regarding their effectiveness and efficiency for typical requirements engineering tasks. Therefore, we set up experiments examining UML activity diagrams (ACTs) and event-driven process chains (EPCs) both from a requirements engineer's perspective with a focus on model creation and from a customer's or end user's perspective with a focus on model understandability. The experiments were conducted as a blocked subject-object study, where the participants had to solve several characteristic tasks. The results were then analyzed by means of statistical analysis methods. In the case of the requirements engineer, we were able to show that ACTs perform better than EPCs. In the case of the customer or end user, we cannot make a clear statement.

In order to realize the exception handling of workflow in UML activity diagram and avoid interruption which influences the running of workflow,this extended paper UML activity diagram firstly and adds the concepts about structural unit and functional unit.They ensure the consistency of workflow execution semantics.Meanwhile,they restrict recovery range and set recovery point automatically.Then a new method called T-workflow recovery strategy was proposed,which could base the principle of recovering the same layer and spreading and set recovery size to unit level.The results of experiment show that this method is feasible.It does not only reduce the execution of compensation task of every activity node by setting up the compensation tasks for different units,but also avoid maintaining to the executive history.

AGL: Incorporating behavioral aspects into domain-driven design