STAIRS - Understanding and Developing Specifications Expressed as UML Interaction Diagrams

STAIRS is a method for the step-wise, compositional development of interactions in the setting of UML 2.x. UML 2.x interactions, such as sequence diagrams and interaction overview diagrams, are seen as intuitive ways of describing communication between different parts of a system, and between a system and its users. STAIRS addresses the challenges of harmonizing intuition and formal reasoning by providing a precise understanding of the partial nature of interactions, and of how this kind of incomplete specifications may be consistently refined into more complete specifications. For understanding individual interaction diagrams, STAIRS defines a denotational trace semantics for the main constructs of UML 2.x interactions. The semantic model takes into account the partiality of interactions, and the formal semantics of STAIRS is faithful to the informal semantics given in the UML 2.x standard. For developing UML 2.x interactions, STAIRS defines a number of refinement relations corresponding to basic system development steps. STAIRS also defines matching compliance relations, for relating interactions to real computer systems. An important feature of STAIRS is the distinction between underspecification and inherent nondeterminism. Underspecification means that there are several possible behaviours serving the same overall purpose, and that it is sufficient for a computer system to perform only one of these. On the other hand, inherent nondeterminism is used to capture alternative behaviours that must all be possible for an implementation. A typical example is the tossing of a coin, where both heads and tails should be possible outcomes. In some cases, using inherent nondeterminism may also be essential for ensuring the necessary security properties of a system

A Model-Based Approach To Requirements Analysis

A major task in designing embedded systems is the systematic elaboration of functional system requirements and their integration into the environment of the complete technical system. The main challenge is to handle the versatile tasks of coordinating a definition of behavior, which is appropriate to the problem. The problem- and design-specifications of the customer related product definition have to be adjusted with and integrated into the manifold requirements of the technical system design. Accordingly, the model-based requirements analysis and system-definition presented here defines a well-structured modeling approach, which systematically aids the goal-oriented formulation and adjustment of the different stakeholder-requirements with the aid of views onto the system and descriptive specification techniques. Thus it allows a clear specification of a consistent and complete system design. The central steps of this approach are implemented in a requirements management (RM) tool prototype called AutoRAI

Towards the Model-Driven Engineering of Secure yet Safe Embedded Systems

We introduce SysML-Sec, a SysML-based Model-Driven Engineering environment aimed at fostering the collaboration between system designers and security experts at all methodological stages of the development of an embedded system. A central issue in the design of an embedded system is the definition of the hardware/software partitioning of the architecture of the system, which should take place as early as possible. SysML-Sec aims to extend the relevance of this analysis through the integration of security requirements and threats. In particular, we propose an agile methodology whose aim is to assess early on the impact of the security requirements and of the security mechanisms designed to satisfy them over the safety of the system. Security concerns are captured in a component-centric manner through existing SysML diagrams with only minimal extensions. After the requirements captured are derived into security and cryptographic mechanisms, security properties can be formally verified over this design. To perform the latter, model transformation techniques are implemented in the SysML-Sec toolchain in order to derive a ProVerif specification from the SysML models. An automotive firmware flashing procedure serves as a guiding example throughout our presentation.Comment: In Proceedings GraMSec 2014, arXiv:1404.163

Refinement and variability techniques in model transformation of software requirements

Tese de Doutoramento em Tecnologias e Sistemas de InformaçãoThis thesis begins with analyzing user functional requirements (as use cases) from the perspective of detail. In that sense, it investigates the applicability of the UML (Unified Modeling Language) «include» relationship to the representation of use case refinement and proposes another relationship for that purpose. It also clarifies the process of modeling use cases with UML when refinement is involved and provides for some guidelines in order to conduct that process. Afterwards, the work of this thesis on use case modeling is expanded to the field of SPLs (Software Product Lines) by means of exploring the UML «extend» relationship. It talks about alternative, specialization and option use cases as the representation of the three variability types this thesis proposes to be translated into stereotypes to mark use cases. Then, this thesis incorporates the refinement of logical architectures with variability support from use cases also with variability support in the 4SRS (Four Step Rule Set) transition method for model transformation of analysis artifacts (use cases) into design artifacts (logical architectures represented as UML component diagrams). The model transformation the 4SRS guides in a stepwise way, from use cases into logical architectures, is based on a software development pattern that addresses architecture. This thesis yields a multilevel and multistage pattern classification that grounds the use of that pattern to generate system functional requirements (as logical architectures). Lastly, the 4SRS transition method is modeled with the SPEM (Software & Systems Process Engineering Metamodel) and formalized as a small software development process dedicated at transitioning from the analysis to the design of software. After that, this thesis presents a case study on the automation of the 4SRS and thoroughly elaborates on the transformation rules that support the model transformations of the 4SRS.Esta tese começa por analisar requisitos funcionais de utilizador (enquanto casos de utilização) sob a perspectiva do detalhe. Nesse sentido, esta tese investiga a aplicabilidade da relação UML (Unified Modeling Language) «include» para a representação do refinamento de casos de utilização e propõe outra relação para esse fim. Esta tese também clarifica o processo de modelação de casos de utilização com a UML quando esse processo envolve refinamento e fornece algumas diretrizes para a condução desse processo. De seguida, o trabalho desta tese em modelação de casos de utilização é expandido para o campo das linhas de produtos de software através da exploração da relação UML «extend». Esse trabalho fala de casos de utilização alternativos, de especialização e opcionais como a representação dos três tipos de variabilidade que esta tese propõe que sejam traduzidos em estereótipos para a marcação de casos de utilização. Depois, esta tese incorpora o refinamento de arquitecturas lógicas com suporte à variabilidade a partir de casos de utilização também com suporte à variabilidade no método de transição 4SRS (Four Step Rule Set) para a tranformação de modelos de artefatos de análise (casos de utilização) em modelos de artefatos de design (arquitecturas lógicas representadas como diagramas de components UML). A transformação de modelos que o 4SRS guia por passos, de casos de utilização em arquitecturas lógicas, baseia-se num padrão de desenvolvimento de software que visa arquitetura. Esta tese produz uma classificação multinível e multietapa de padrões, que sustenta a utilização desse padrão na geração de requisitos funcionais de sistema (enquanto arquitecturas lógicas). Por fim, o método de transição 4SRS é modelado com o SPEM (Software & Systems Process Engineering Metamodel) e formalizado como um pequeno processo de desenvolvimento de software dedicado a transitar da análise para o design the software. Depois disso, esta tese apresenta um estudo de caso sobre a automatização do 4SRS e elabora minuciosamente acerca das regras de transformação que apoiam as transformações de modelos do 4SRS