System testing is concerned with testing an entire system based on its specifications. In the context of object-oriented, UML development, this means that system test requirements are derived from UML analysis artifacts such as use cases, their corresponding sequence and collaboration diagrams, class diagrams, and possibly Object Constraint Language (OCL) expressions across all these artifacts. Our goal here is to support the derivation of functional system test requirements, which will be transformed into test cases, test oracles, and test drivers once we have detailed design information. In this paper, we describe a methodology in a practical way and illustrate it with an example. In this context, we address testability and automation issues, as the ultimate goal is to fully support system testing activities with high-capability tools.

This paper describes an empirical investigation of the cost effectiveness of well-known state-based testing techniques for classes or clusters of classes that exhibit a state-dependent behavior. This is practically relevant as many object-oriented methodologies recommend modeling such components with statecharts which can then be used as a basis for testing. Our results, based on a series of three experiments, show that in most cases state-based techniques are not likely to be sufficient by themselves to catch most of the faults present in the code. Though useful, they need to be complemented with black-box, functional testing. We focus here on a particular technique, Category Partition, as this is the most commonly used and referenced black-box, functional testing technique. Two different oracle strategies have been applied for checking the success of test cases. One is a very precise oracle checking the concrete state of objects whereas the other one is based on the notion of state invariant (abstract states). Results show that there is a significant difference between them, both in terms of fault detection and cost. This is therefore an important choice to make that should be driven by the characteristics of the component to be tested, such as its criticality, complexity, and test budget.

... is to make UML models more precise and unambiguous by providing a constraint language describing constraints that the UML diagrams alone do not convey, including class invariants, operation contracts, and statechart guard conditions. There is an ongoing debate regarding the usefulness of using OCL in UML-based development, questioning whether the additional effort and formality is worth the benefit. It is argued that natural language may be sufficient, and using OCL may not bring any tangible benefits. This debate is in fact similar to the discussion about the effectiveness of formal methods in software engineering, but in a much more specific context. This paper presents the results of two controlled experiments that investigate the impact of using OCL on three software engineering activities using UML analysis models: detection of model defects through inspections, comprehension of the system logic and functionality, and impact analysis of changes. The results show that, once past an initial learning curve, significant benefits can be obtained by using OCL in combination with UML analysis diagrams to form a precise UML analysis model. But, this result is however conditioned on providing substantial, thorough training to the experiment participants.

Abstract not found

We compare five industrial software architecture design methods and we extract from their commonalities a general software architecture design approach. Using this general approach, we compare across the five methods the artifacts and activities they use or recommend, and we pinpoint similarities and differences. Once we get beyond the great variance in terminology and description, we find that the 5 approaches have a lot in common and match more or less the “ideal ” pattern we introduced. 1.

checking are limited when it comes to the verification of complex distributed embedded real-time systems. Our approach addresses this problem and in particular the state explosion problem for the software controlling mechatronic systems, as we provide a domain specific formal semantic definition for a subset of the UML 2.0 component model and an integrated sequence of design steps. These steps prescribe how to compose complex software systems from domain-specific patterns which model a particular part of the system behavior in a well-defined context. The correctness of these patterns can be verified individually because they have only simple communication behavior and have only a fixed number of participating roles. The composition of these patterns to describe the complete component behavior and the overall system behavior is prescribed by a rigorous syntactic definition which guarantees that the verification of component and system behavior can exploit the results of the verification of individual patterns.

On the basis of some experience in the use of UML-based use casedriven methods, we believe and claim, contrary to a recent wave for allowing almost total freedom as opposed to disciplined methods, that a tighter and more precise structuring of the artifacts for the different phases of the software development process may help speed-up the process, while obviously making easier the consistency checks among the various artifacts. To support our claim we have started to investigate an approach, that, though being compliant with the UML notation and a number of UML-based methods, departs from them both in the basic philosophy, that follows the "tight and precise" imperative, and in the technical solutions for structuring the various artifacts.

On the basis of some experience in the use of UMLbased methods, we believe that a more refined and stringent structuring of the knowledge in the Requirement Specification may help the specification process and make easier the consistency checks among the various components. Thus we propose a way of structuring and representing the Requirement Specification artifacts that presents a number of novelties w.r.t. the best-known current methods. Our proposal is multiview, use case-driven and UML-based; thus also objectoriented. However, also benefitting of some earlier work, notably in the Structured Analysis, we take a rather abstract view, trying to avoid a preemptive decision on the classes structuring the system to build; that is achieved not only making a sharp distinction between business/domain modelling and the system, but also dealing with the system at the requirement level as a black box, providing only the minimal structure needed to express the interactions with the context.

Some of the most challenging tasks in building a software system are capturing, refining, and analyzing requirements. How well these tasks are performed significantly impacts the quality of the developed software system. The difficulty of these tasks is greatly exacerbated for the software of embedded systems as these systems are commonly used for critical applications, have to operate reliably for long periods of time, and usually have a high degree of complexity. Current embedded systems software development practice, however, often deals with the (requirements) analysis phase in a superficial manner, instead emphasizing design and implementation. This research investigates how an approach similar to the well-known design patterns, termed object analysis patterns, can be applied in the analysis phase of embedded systems development, prior to design and coding. Specifically, our research explores how object-oriented modeling notations, such as the Unified Modeling Language (UML), can be used to represent structural and behavioral information as part of commonly occurring object analysis patterns. This work also investigates how UML-based conceptual models of embedded systems, based on the diagram templates in the object analysis patterns, can be automatically analyzed using the Spin model checker for adherence to properties specified in linear-time temporal logic (LTL) using a previously developed UML formalization framework. We have applied these patterns to several embedded systems applications obtained from the automotive industry. This paper describes one of our case studies and illustrates how our approach facilitates the construction of UML-based conceptual models of embedded systems and the analysis of these models for adherence to functional requirements.

A number of strategies have been proposed for state-based class testing. An important proposal was made by Chow [5] and adapted by Binder [3]: It consists in deriving test sequences covering all round-trip paths in a finite state machine (FSMs). Based on a number of (rather strong) assumptions, and for traditional FSMs, it can be demonstrated that all operation and transfer errors in the implementation can be uncovered. Through experimentation, this paper investigates this strategy when used in the context of UML statecharts. Based on a set of mutation operators proposed for object-oriented code we seed a significant number of faults in an implementation of a specific container class. We then investigate the effectiveness of four test teams at uncovering faults, based on the round-trip path strategy, and analyze the faults that seem to be difficult to detect. Our main conclusion is that the round-trip path strategy is reasonably effective at detecting faults (87 % average as opposed to 69 % for size-equivalent, random test cases) but that a significant number of faults can only exhibit a high detection probability by augmenting the round-trip strategy with a traditional black-box strategy such as category-partition testing. This increases the number of test cases to run—and therefore the cost of testing— and a cost-benefit analysis weighting the increase of testing effort and the likely gain in fault detection is necessary.