Integrating UML, MARTE and SysML to improve requirements specification and traceability in the embedded domain

Transcription

1 Integrating UML, MARTE and SysML to improve requirements specification and traceability in the embedded domain Milena Rota Sena Marques, Eliane Siegert, Lisane Brisolara Centro de Desenvolvimento Tecnológico - CDTec - Universidade Federal de Pelotas (UPFel) Pelotas, Brazil {mrsmarques, esiegert, lisane}@inf.ufpel.edu.br Abstract This work presents a model-driven requirement engineering approach for the embedded software domain. This approach is based on UML, MARTE and SysML standard notations, which are integrated in order to improve requirements specification and traceability. MARTE stereotypes are mainly used to specify non-functional requirements, exceptionally imperative in this domain, while SysML notations integrated to UML models support requirements management. The management is based on traceability matrixes, which are automatically generated from SysML requirements diagrams. Furthermore, we illustrate the effectiveness of our approach by means of a case study. Keywords- Requirement Engineering; Embedded Software; Embedded Systems; Requirements Management; Traceability I. INTRODUCTION Embedded systems are dedicated computational systems, composed by hardware and software components. The complexity of embedded devices grows and, consequently, enabling more complex applications. Nevertheless, embedded software engineers have face many challenges and difficulties in their work thanks mainly to specific characteristics like mobility, safety or real-time [1]. These include several non-functional requirements (NFR) related to performance, memory size and energy consumption to be considered by engineers. These hard restrictions allied to the increased complexity, and hard time-to-market has motivated the investigation of strategies to successfully support the development of complex embedded software. The complexity is usually managed using abstraction through models, while automation is the solution for fast product delivery. This scenario motivates the use of Modeldriven Engineering (MDE) [2] approaches that provides both abstraction and automation. According to Ameller et. al. [3], in general, NFRs are not addressed in Model-driven development methods. These methods usually are based on UML, which is the most popular language for software modeling. However, UML does not support specific aspects of embedded systems, as for example, the specification of non-functional requirements as power and energy consumption, and real-time constrains. To solve these limitations, the MARTE profile [4] was created, which provides stereotypes to define specific aspects for the embedded domain, including NFRs [5] [6] [7]. Non-functional requirements affect different activities on the software development process [3], influencing several software artifacts [8]. Therefore, being a market-driven software development, the flow of the embedded software requirements is not limited to one project, and the requirements are generated from internal (e.g., engineers) and external (e.g., customers) sources [9]. It indicates the necessity of a procedure to model / specify functional and non-functional requirements and ensure that these requirements have been satisfied. To support it, a requirement engineering process should be adopted, which allows to identify, control and monitor requirements and its changes in each project step [10]. This requirements tracing is based on relationships between requirements and between a given requirement and a design artifact [11]. SysML [12] offers resources for requirements modeling, including these relationships and for that reason it has also been used in the embedded domain [11]. Available solutions propose extensions of standard notations and focus on subdomains as automobile or telecommunication. This paper presents a model-driven approach for requirement engineering targeted to the embedded software domain, named MDEReq (Model Driven Engineering for Requirement Management). Our approach integrates UML, MARTE, and SysML models to improve and facilitate requirements specification and management during the embedded software development process. To automate our proposed approach, we develop a tool, which automatically generates traceability matrixes and allows identify possible inconsistencies when changes in the requirements are made. The remaining of this paper is organized as follows. Section 2 discusses the state-of-art in requirement engineering for the embedded systems domain. In Section 3 the proposed approach is presented, while Section 4 demonstrates it through a case study. Section 5 concludes and point out directions for future work. II. RELATED WORK Recently, the combination of UML, SysML and MARTE has been investigated on the embedded domain in order to support a complete specification of requirements [11] [13] [14] [15]. Espinoza et. al. [14] only discuss strategies to combine these notations for the specification of embedded systems, while [13], [11], and [15] investigate also strategies

2 for requirements traceability based on models, but focusing on subdomains of embedded systems. The investigations presented in [13], and in [11] are related to the project Memvatex, which proposes a modelbased methodology for expressing and tracing requirements in the field of automotive applications. This methodology defines three independent flows (requirement model, solution model and V&V model) and is based on several profiles EAST-ADL2 [16], AUTOSAR [17], MARTE and SysML. To support this methodology, a metamodel called DARWIN4Req was proposed in [11], which establishes a link between the three flows and affords requirements traceability for these heterogeneous models. Since the EAST-ADL2 was defined for vehicle embedded electronic systems development, these approaches are specific for this application domain. Another weakness of these works is the use of different tools to support their approaches such as Microsoft Word, DOORS [18], as well as an UML/SysML modeling tool as TopCased-TRAMWAY [19]. It turns more difficult the definition of a single support tool to handle a complete traceability. Therefore, these works cannot be considered based on an integrated model. Another scenario could be to have one single model for whole system, and then the same modeling tool provide different views of the model. This way, the consistency maintenance becomes an easier task, which can be supported by the modeling tool. More recently, in [15], UMLsec is proposed as a profile to model security requirements on the telecommunication domain. This profile is combined with MARTE and SysML in order to support requirements specification and management in this domain. These research works propose extensions for the standard modeling notations. Differently from them, we propose to use the OMG standards, as they were specified, avoiding extensions that will difficult the support of our approach by already available modeling tools. Further, it makes our approach unrestricted for a specific sub-area or sub-domain and facilitates the definition of a mechanism for traceability that indicates model inconsistencies. III. PROPOSED APPROACH Our approach integrates facilities from Model Driven Engineering, and Requirements Management into the embedded software engineering process, and is named MDEReq. This approach is based on an integrated model composed of UML, MARTE and SysML notations. MDEReq supports modeling and management of functional as well as non-functional requirements. Since high-level abstract models are used, more complex application can be handled. Moreover, this integrated model guides all design decisions. At the same time, our approach contributes giving for designers an effective control of requirement changes, and its impacts on other requirements or design artifacts in whole development process. As usual, in any engineering process, the first activity is the definition of requirements. This step is part of the Requirement Engineering procedure, which includes activities as conception, elicitation, negotiation, specification, validation, and management of requirements [10]. Simplifying this procedure, we propose the workflow illustrated in Fig. 1, which is composed of four activities: Elicitation, Analysis and Specification, Validation, and Requirements Management. We have chosen to represent the Requirements Management as an activity that occurs concurrently to the sequential flow (from the Elicitation to Validation), as indicated by the fork notation. Although, at beginning of the process, while the Elicitation activity is not finalized, requirements management is not feasible. Our choice is based on the fact the sequential flow can be repeated, when a problem on requirements elicitation is found. To automate and fully support our approach, we developed a tool, which generates traceability matrixes from the software model, and allows determine possible model inconsistencies when changes in the requirements are made. Figure 1. Workflow of the MDEReq approach Following our approach, firstly, the designer should create a list of requirements in the Elicitation activity. Each requirement is classified as functional or non-functional, and each one can have an associated priority. A SysML requirements diagram (rd) is used for starting the requirements modeling. Requirements are represented in this diagram using the generic <<requirement>> stereotype or using specific SysML stereotypes. We suggest the use of <<functionalrequirement>> for functional requirements (FR) and specific stereotypes to represent non-functional requirements or NFR (e.g. <<performancerequirement>> for timing requirements). The requirements diagram also models relationships between requirements using SysML stereotypes. On this activity, <<derive>> and <<composite>> stereotypes are used to represent requirements derivation and requirements hierarchy, respectively. The <<composite>> relationship enables a complex requirement to be decomposed into its containing child requirements. In the Analysis and Specification activity, UML models are used to build a functional, structural and behavioral view of the system, using respectively, use case, class and sequence diagrams. For this activity, we follow the COMET method proposed in [20] as an object oriented approach for designing real-time and distributed applications. This method is based on the use case concept. According to this, firstly use cases are defined in terms of actors and use cases. After that, each use case can be refined describing the objects that participate in the use case and their interaction. A class

3 diagram (cd) represents the object classes evolved on the interactions, while the interactions are detailed by sequence diagrams (sd). Sequence and class diagrams are decorated with MARTE stereotypes in order to define specific aspects from the embedded domain as deadlines, and period for tasks or yet modeling the interaction with physical components implemented in hardware. Stereotypes from the MARTE packages were selected with this objective. From the MARTE Foundations, we used resources from two sub-packages: Time and GRM. From the GRM, <<deviceresource>> is used to indicate classes that represent the interaction with external devices. From the Time, we use stereotypes to represent timing aspects. Between them, <<ClockType>> and <<timedconstraint>> are used to represent a clock and delay, respectively. From the MARTE design model, focused on the design specification of a real-time and embedded software, the HLAM sub-package is used. From this, we use the <<Rtunit>> stereotype to indicate that a class represents a concurrent unit as well as the <<rtfeature>> and <<rtspecification>> stereotypes to detail timing aspects into a sequence diagram. The <<rtfeature>> is used to indicate an active object with real-time constraint, and the <<rtspecification>> can be associated to an <<rtfeature>> in order to detail it. To complement this timing specification, we use the VSL language (from the MARTE annexes) to represent temporal expressions used to factorize different kinds of time related expressions, including instants, durations, and jitters. This language extends the UML simple time model, allowing for instance to specify a task that has a variation (delta) in its duration through a jitter expression. Further, the rd built in the previous activity is updated as the requirements are refined. This updating allows associate requirements to the design artifacts like use cases or a behavioral diagram. Nowadays, we consider only sequence diagrams as valid behavioral diagram. Then, these artifacts are related to the requirements using <<satisfy>> and <<refine>> SysML relationship. Refine is used to indicate that a requirement is detailed by a use case, while satisfy identifies that an artifact must satisfy the associated requirement. We use a sequence diagram to satisfy a requirement behavior. During the Validation activity, test cases are defined and related to requirements through <<verify>> relationships. During this activity, the requirements diagram is modified again to include these elements. Finally, the Requirements Management activity occurs in parallel to the other MDEReq activities and uses information from the SysML rd to build tracing matrixes. Our approach proposes three different matrixes, as detailed in Table I, which allow tracing requirements in different abstraction levels and in different design phases. During the Elicitation activity, a traceability matrix is generated in which relationships between two requirements can be traced according to derive and composite relations. These requirements can be functional or non-functional and this matrix supports the requirements change management, when a requirement is derived or decomposed from another one. In these cases, this matrix indicates which requirements are impacted for changes in a given base requirement. TABLE I. PROPOSED MATRIXES FOR EACH MDEREQ ACTIVITY Stereotype Activity Tracing Matrix derive /composite refine /satisfy Verify Elicitation Analysis and Specification Validation Requirements Traceability Matrix Design Traceability Matrix Test Traceability Matrix The matrix relating requirements to design artifacts is generated during the Analysis and Specification activity through refine and satisfy relationships, indicating that an artifact refines or satisfies a given requirement. In this case, we consider use cases and sequence diagrams as valid design artifacts. In this way, when a requirement is modified is possible to identify which artifacts should be modified or checked in a graphical view. Finally, the tracing matrix built during the Validation activity indicates which test cases are used to verify each requirement. When a requirement changes, related test cases should be checked. MDEReqTraceTool, a tool under development in our group, generates automatically the proposed matrixes. In the generated matrixes, symbol represents a dependency between requirements or between a given requirement and a design artifact or a test case, while the X symbol indicates a possible inconsistency in the model. The inconsistency indication is also generated when a requirement is modified to suggest that the related design or test artifacts, as well as the derived requirements, should be checked. These matrixes offer several views of requirements and its life cycle. Further, these support requirements, design, and test traceability in several abstraction levels and during whole development process. IV. CASE STUDY To demonstrate our approach, we conducted a case study, which includes the partial modeling of the control software embedded into an anti-lock braking system (ABS), and its requirements management. The integrated model (UML/MARTE + SysML) was built using Papyrus. To demonstrate the MDEReq effectiveness concerning to requirements management, we present the traceability matrixes generated by our tool for the ABS model. The ABS is a break system that prevents wheel lock-up, avoiding loss of traction and control during an emergency stop. More specifically, ABS automatically modulates the brake fluid pressure at each wheel to maintain optimum brake performance. In normal brake situations, the ABS is not activated and the regular brake is used. ABS is used when it detects a wheel rotating significantly slower than the others, which indicates a risk of wheel locking. In this case, it actuates the valves to reduce hydraulic pressure to the

4 brake at the affected wheel, thus reducing the braking force on that wheel, and consequently, the wheel turns faster. There are several different projects for ABS systems. The system used in this study has four speed sensors and four actuators, one for each wheel. The sensors are responsible to monitor the wheel rotation, while the actuators for the pressure under each wheel. A. Elicitation Following the MDEReq, during the Elicitation activity, the ABS software requirements were elicited and classified in functional (FR) and non-functional (NFR). Yet during this activity, the rd from Fig. 2 was built, representing these requirements and the relationships among them. In this diagram, timing requirements are decorated with <<performancerequeriment>> stereotype to differentiate them from the functional requirements (decorated with <<functionalrequirement>>). an rtunit element. IdealClock is stereotyped with <<ClockType>> stereotype and defines attributes necessaries to specify timing requirements. The complete system behavioral view is composed of several sequence diagrams. Because of lack of space, we have selected a single sd to present in this case study. This diagram demonstrates how to use MARTE stereotypes to detail timing aspects related to method invocations. Figure 3. ABS system class diagram Figure 2. Requirements diagram Elicitation activity B. Analysis and Specification In the Analysis and Specification activity, firstly, the system functional view was represented using the UML use case diagram, which was omitted because of lack of space. After the functional view has consolidated, the software analysis and design starts with the definition of a class diagram and several sequence diagrams. Fig. 3 illustrates the software structure, composed of the following classes: ABS, Sensor, Actuator, Pedal and IdealClock. The software main class is ABS, which encapsulates the control algorithm of the ABS software defined by the methods check_speed(), compute_speed(), and compute_pressure(). MARTE stereotypes are used in some application classes. ABS class is characterized as <<rtunit>>, because it represents a realtime task. The Actuator and Sensor classes are stereotyped with <<deviceresource>> from MARTE GRM package, since they represent interfaces for external devices that are manipulated by the control software. In this case study, the IdealClock class is used to define temporization aspects required by the ABS class, since it is Fig. 4 details the Read sensor use case, in which the ABS checks the wheel speed through the get_speed() and compute_speed() methods. The get_speed() method execution should be executed within 0,5 ms. This requirement is represented by the jitter, which is one way to represent a variable duration using VSL. Through the compute_speed() method, the ABS maintains the wheels speed actualized. This method must occur in a period of 3ms and with variation of 2 ms. To model it, this method is stereotyped with <<rtfeature>> and a <<rtspecification>> note is added to detail this timing requirement. Figure 4. Read sensor sequence diagram The diagram from Fig. 2 was updated on this activity, generating the version illustrated in Fig. 5, which includes relationships between requirements and design artifacts. In this diagram, the Check speed use case is linked to the requirement of same name by a <<refine>> relationship and the Read sensor sd is related to the Read wheel speed

5 requirement using a <<satisfy>> relationship. This information is used to support the design traceability. C. Validation In this activity, the rd is updated in order to represent requirements and its related test case. Fig. 6 depicts the diagram built for this case study, in which a test case was associated for each requirement (both FR and NFR), except for ABS composition that represents the ABS structure. In our model, test cases are identified as TC followed by the test name and related to a given requirement through the <<verify>> SysML relationship. the Read sensor sd, consequently when this requirement changes, the tracing will indicate that the related sd must be checked. Fig. 8 illustrates the design traceability matrix generated based on the rd from Fig. 5. It is important to highlight that this matrix is not complete since the complete behavioral diagrams are not presented in this case study. This way, this matrix is based only on the artifacts detailed in our model. Because of lack of space, we omitted the test traceability matrix generated from the rd illustrated in Fig. 6. Figure 6. Requirements diagram Validation activity Figure 5. Requirements diagram Analysis and Specification activity. D. Requirements Management The management activity is supported by the proposed traceability matrixes, which are automatically generated from the requirements diagram (rd) by our supporting tool. From that diagram, dependencies between requirements and links from requirements to design artifacts or to test cases should be captured for matrixes generation. Following the proposed approach, from the rd produced at each activity, traceability matrixes were automatically generated for the ABS case study using our support tool. In these matrixes and X symbols are used to represent a dependency and a possible inconsistency, respectively. Firstly, we generate the requirements traceability matrix depicted in Fig. 7, which was based on <<derive>> and <<composite>> relationships defined on the rd from Fig. 2. In this matrix, the symbol, indicates dependency between two requirements. For example, Read wheel speed depends on Check speed, so when the first is modified, the other must be checked. Our supporting tool, when generating a matrix, captures the modified requirements and indicates a possible inconsistency to be checked using the X symbol. An example of this can be observed in Fig. 7 where the X relationship indicates that the Alleviate pressure requirement was modified and thus, the Delay in updating should be verified, since it is derived from the other. Our approach also supports the design traceability, which traces modifications on a given requirement and indicates that the related design artifacts should be checked. In our ABS case study, the Read wheel speed FR is satisfied by Read wheel speed Check speed Read wheel speed Alleviate pressure Check speed Alleviate pressure ABS composition Sensor timing Delay in updating ABS composition ABS timing Sensor timing Figure 7. Requirements Traceability Matrix. Read wheel speed Check speed Alleviate pressure ABS composition Sensor timing Delay in updating ABS timing UC Check speed Diag. Seq. Read Sensor Figure 8. Design Traceability Matrix. X Delay in updating Diag. Seq. ABS timing

6 V. CONCLUSIONS AND FUTURE WORK We have proposed MDEReq as a model-driven requirement engineering approach for the embedded software domain. The proposed approach integrates UML models (standard software modeling), with MARTE and SysML notations. MARTE is used to allow model domainspecific non-functional requirements, thus, improving the software specification. On other side, SysML is combined to UML/MARTE models to support requirements management in whole development process, allowing to embedded software designers keep track of requirements changes. We have developed MDEReqTraceTool to capture and analyze models and generate the proposed matrixes for supporting requirements, design and test traceability. Our approach is demonstrated through a hypothetical case study, which includes the requirements modeling and management of the control software embedded on an ABS system. This case study demonstrates that our approach can be applied for specifying a real embedded application as well as for managing its requirements. Most consumer electronics contain embedded software and this dynamic market requires approaches to support fast develop and deliver complete families of products. However, our approach does not handle variability, a key concern for software product family engineering. As future wok, we plan to study how deal with product lines on MDEReq. ACKNOWLEDGMENT The authors acknowledge financial support received from CNPq (483464/2013-9) and FAPERGS (process10/0043-0). REFERENCES [1] P. Koopman, Better Embedded System Software, Pittsburgh: Drumnadrochit Education, [2] B. Selic, "UML 2: A model-driven development tool," IBM Systems Journal, vol. 45, no. 3, pp , [3] D. Ameller, C. Ayala and X. F. J. Cabot, "How do software architects consider non-functional requirements: An exploratory study," in 20th IEEE International Requirements Engineering Conference (RE 12), Illinois, [4] OMG, "MARTE," [Online]. Available: [5] M.-A. Peraldi-Frati and S. Yves., "From high-level modeling of time in MARTE to real-time scheduling analysis," in Model Based Architecting and Construction of Embedded Systems (MoDELS'08), Toulose, [6] L. Brisolara, M. E. Kreutz and L. Carro, "UML as front-end language for embedded systems design," in Behavioral Modeling for Embedded Systems and Technologies: Applications for Design and Implementation, Hershey, IGI Global, 2009, pp [7] S. Määttä, L. S. Indrusiak, L.Ost, L. Moller, M. Glesner, F. G. Moraes and J. Nurmi, "Characterising embedded applications using a UML profile," in International Symposium on Systemon-Chip, SoC 09, Tampere, [8] M. A. Werhmeister, "An aspect-oriented model-driven engineering approach for distributed embedded real-time systems," in PhD Thesis Universidade Federal do Rio Grande do Sul, Porto Alegre, [9] R. B. Svensson, T. Gorschek and B. Regnell, "Quality Requirements in Practice: An Interview Study in Requirements Engineering for Embedded Systems," in 15th International Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ '09), Berlin, [10] R. Pressman, Software Engineering: a Practitioner s Approach, 7th ed., New York: McGraw-Hill Companies, [11] H. Dubois, M.-A. Peraldi-Frati and F. Lakhal, "A model for requirements traceability in an heterogeneous model-based design process: Application to automotive embedded systems," in Engeneering of Complex Computer Systems, Oxford, [12] OMG, "SysML," [Online]. Available: [13] A. Albinet, S. Begoc, J.-L. Boulanger, O. Casse, I. Dal, H. Dubois, F. Lakhal, D. Louar, M.-A. Peraldi-Frati, Y. Sorel e Q.-D. Van, The MeMVaTEx methodology: from requirements to models in automotive application design, em 5th European Congress ERTS Embedded Real Time Software, Toulouse, [14] H. Espinoza, D. Canila, B. Selic and S. Gérard, "Challenges in Combining SysML and MARTE for Model-Based Design of Embedded Systems," in 5th European Conference on Model Driven Architecture - Foundations and Applications (ECMDA-FA '09), Enschede, [15] M. Saadatmand, A. Cicchetti and M. Sjödin, "UML-Based Modeling of Non-Functional Requirements in Telecommunication System," in The Sixth International Conference on Software Engineering Advances (ICSEA 2011), Barcelona, [16] EAST-ADL, The EAST-ADL Architecture Description Language, ITEA Project, [17] AUTOSAR, "AUTOSAR AUTomotive Open System ARchitecture," AUTOSAR: [18] IBM, "Requirements management for systems and advanced IT applications," IBM, [Online]. Available: [19] F. Forge, "Fusion Forge," Fusion Forge, [Online]. Available: [20] H. Gomma, Designing Concurrent, Distributed, and Real- Time Applications with Uml, Boston: Addison-Wesley Longman Publishing Co, 2000.