Traceability and AOSD - From Requirements to Aspects

The traceability question is addressed through the development of a framework to go from requirements to aspects using the Design by Contract methodology. It is demonstrated that by starting at the requirements stage, and specifying an early aspect in the same semi-formal language as the system's existing requirements, we have the basis from which to design the aspects at the implementation stage. The language of pre- and post-conditions is shown to match closely that of aspects, in that pre-conditions match the aspect's pointcut, and the post-condition matches the advice part of the aspect. This thus gives us traceability from 'early aspects' to 'late aspects'. This approach will shed some light on the relationship between requirements and their refinements to pre- and post conditions, and the traceability of requirements in the face of reuse over time. The addition of a new crosscutting requirement is investigated in terms of the framework, demonstrating the relationship between early and late aspects and traceability. The framework promises to help with the design of the late aspects. We propose the concept of relevancy: information in a requirement beyond its specification as pre- and post-conditions, as a way of identifying join points

Controlling Concurrent Change - A Multiview Approach Toward Updatable Vehicle Automation Systems

The development of SAE Level 3+ vehicles [{SAE}, 2014] poses new challenges not only for the functional development, but also for design and development processes. Such systems consist of a growing number of interconnected functional, as well as hardware and software components, making safety design increasingly difficult. In order to cope with emergent behavior at the vehicle level, thorough systems engineering becomes a key requirement, which enables traceability between different design viewpoints. Ensuring traceability is a key factor towards an efficient validation and verification of such systems. Formal models can in turn assist in keeping track of how the different viewpoints relate to each other and how the interplay of components affects the overall system behavior. Based on experience from the project Controlling Concurrent Change, this paper presents an approach towards model-based integration and verification of a cause effect chain for a component-based vehicle automation system. It reasons on a cross-layer model of the resulting system, which covers necessary aspects of a design in individual architectural views, e.g. safety and timing. In the synthesis stage of integration, our approach is capable of inserting enforcement mechanisms into the design to ensure adherence to the model. We present a use case description for an environment perception system, starting with a functional architecture, which is the basis for componentization of the cause effect chain. By tying the vehicle architecture to the cross-layer integration model, we are able to map the reasoning done during verification to vehicle behavior

Metamodel for Tracing Concerns across the Life Cycle

Several aspect-oriented approaches have been proposed to specify aspects at different phases in the software life cycle. Aspects can appear within a phase, be refined or mapped to other aspects in later phases, or even disappear.\ud Tracing aspects is necessary to support understandability and maintainability of software systems. Although several approaches have been introduced to address traceability of aspects, two important limitations can be observed. First, tracing is not yet tackled for the entire life cycle. Second, the traceability model that is applied usually refers to elements of specific aspect languages, thereby limiting the reusability of the adopted traceability model.We propose the concern traceability metamodel (CTM) that enables traceability of concerns throughout the life cycle, and which is independent from the aspect languages that are used. CTM can be enhanced to provide additional properties for tracing, and be instantiated to define\ud customized traceability models with respect to the required aspect languages. We have implemented CTM in the tool M-Trace, that uses XML-based representations of the models and XQuery queries to represent tracing information. CTM and M-Trace are illustrated for a Concurrent Versioning System to trace aspects from the requirements level to architecture design level and the implementation

Why and How Your Traceability Should Evolve: Insights from an Automotive Supplier

Traceability is a key enabler of various activities in automotive software and systems engineering and required by several standards. However, most existing traceability management approaches do not consider that traceability is situated in constantly changing development contexts involving multiple stakeholders. Together with an automotive supplier, we analyzed how technology, business, and organizational factors raise the need for flexible traceability. We present how traceability can be evolved in the development lifecycle, from early elicitation of traceability needs to the implementation of mature traceability strategies. Moreover, we shed light on how traceability can be managed flexibly within an agile team and more formally when crossing team borders and organizational borders. Based on these insights, we present requirements for flexible tool solutions, supporting varying levels of data quality, change propagation, versioning, and organizational traceability.Comment: 9 pages, 3 figures, accepted in IEEE Softwar

Agrifood logistics and food traceability

Traceability systems are recordkeeping systems designed to track the flow of product and/or product attributes through the production process and throughout the supply chain from producers to consumers. The aim of this study is to review the current status of traceability systems in food companies, compare different traceablity systems applied by food companies, and analyse the sources of variation in their efficiency. A traceability system is characterized by its breadth, depth, and precision. Differences in efficiency are attributed to the costs and benefits of traceability’s implementation to these three traceabiligy characteristics. Three case studies were conducted during the period April-May 2005. All cases were large food companies, with more than 250 employees, and operating for more than 20 years in Greece. All companies had a traceability system in operation. All companies had implemented a traceability system not because legislation required, but because they found it was a valuable business tool. In the operation level, the main problem was whether or not suppliers could provide traceability information in a useful format. All companies reported the same benefits from the traceability system: Better control of supply chain as well as better quality assurance –higher levels of food quality & safety

Designing Traceability into Big Data Systems

Providing an appropriate level of accessibility and traceability to data or process elements (so-called Items) in large volumes of data, often Cloud-resident, is an essential requirement in the Big Data era. Enterprise-wide data systems need to be designed from the outset to support usage of such Items across the spectrum of business use rather than from any specific application view. The design philosophy advocated in this paper is to drive the design process using a so-called description-driven approach which enriches models with meta-data and description and focuses the design process on Item re-use, thereby promoting traceability. Details are given of the description-driven design of big data systems at CERN, in health informatics and in business process management. Evidence is presented that the approach leads to design simplicity and consequent ease of management thanks to loose typing and the adoption of a unified approach to Item management and usage.Comment: 10 pages; 6 figures in Proceedings of the 5th Annual International Conference on ICT: Big Data, Cloud and Security (ICT-BDCS 2015), Singapore July 2015. arXiv admin note: text overlap with arXiv:1402.5764, arXiv:1402.575