Application of an Extended SysML Requirements Diagram to Model Real-Time Control Systems

Transcription

1 Application of an Extended SysML Requirements Diagram to Model Real-Time Control Systems Fabíola Goncalves C. Ribeiro 1, Sanjay Misra 2, and Michel S. Soares 1 1 Federal University of Uberlândia, Uberlândia, Brazil, 2 Covenant University, Ota Nigeria fgcr.ufg@gmail.com, ssopam@gmail.com, mics.soares@gmail.com Abstract. Most techniques for modeling requirements present many problems and limitations, including modeling requirements at a single level of abstraction, and are specific to model functional requirements. The objective of this article is to perform a study on modeling requirements of Real-Time Systems through an extension of the SysML Requirements Diagram focusing on the traceability of non-functional and functional requirements. The proposed approach has demonstrated to be effective for representing software requirements of real-time systems at multiple levels of abstraction and classification. The proposed metamodel represents concisely the traceability of requirements in a high abstraction level. Keywords: SysML, Requirements Engineering, Modeling of Software, Traceability of Requirements 1 Introduction Requirements Engineering is often characterized in the literature as the most critical and complex process of the software development life cycle [1]. The process of requirements engineering has dominant impact on the capabilities of the resulting product [2]. According to Brooks [3], knowing what to build, which includes requirements elicitation and technical specification, is the most difficult phase in the design of software. The increasing complexity of software systems makes the Requirements Engineering activities both more important and difficult. This assertion is easily verifiable when developing Real-Time Systems (RTS) which are highly dependent on restricted timing requirements. Real-time systems must respond to externally generated stimulus within finite and specifiable period. Therefore, efforts must be expent to analyze, design and validate systems for real-time targeting, providing greater reliability and security to them. In order to minimize the complexity of the development of RTS, graphical models can be applied. Modeling is an important activity in the development of RTS, because it contributes to decrease the complexity and to improve the understanding of these systems.

2 II UML has been frequently applied for modeling requirements in the RTS domain. For instance, in [4], UML is used to represent the modeling of design decisions and non-functional requirements by extending the language with attributes of stimulus, source of stimulus, environment, artifact, response and response from measures. These new attributes are incorporated into the class diagram for modeling non-functional requirements. In [5] a method for specifying software requirements using UML with the addition of stereotypes is presented. The shortcomings of UML are widely described in the literature. The language is considered too informal and ambiguous. Behavior diagrams, such as the Sequence diagram, cannot represent time constraints effectively [6], as they are essentially untimed, expressing only chronological order. As discussed in [7], UML presents difficulty in expressing non-functional properties of the system, very important requirements for real-time applications. Proposals to address the problems of UML in relation to modeling realtime software were created. These include the profiles SPT [8] and MARTE [9]. These profiles extend UML and add elements that model time requirements, system requirements and non-functional properties. SysML (Systems Modeling Language), a new language derived from UML, was proposed recently. SysML [10] allows the modeling of various types of applications in systems engineering, enabling the specification, analysis, design, verification and validation of complex systems. The language has been successfully applied to model requirements. The work presented in [11] refers to the application of the SysML Requirements diagram for the specification of system requirements. In another article [12], the focus is on user requirements. The main aim of this article is to extend the metamodel of the SysML [10] Requirements diagram by adding new properties and relationships to enable the representation of requirements of real-time software at different levels of abstraction, and then demonstrating explicitly the tracing of each requirement in each level of representation. This article is organized as follows. The proposed metamodel for representing requirements at multiple levels of abstraction and classification, and to describe tracing between requirements is presented in Section 2. Sections 3.1 and 3.2 are about the set of requirements to be modeled in the case study. Finally, the discussions are presented in Section 4 and the contributions and conclusions of this research are described in Section 5. 2 Metamodel for Requirements Modeling and Tracing SysML is a highly customizable and extensible modeling language [10]. It allows the creation of domain-specific models through stereotypes and other extensions. Profiles may specialize language semantics, provide new graphical icons and domain-specific model libraries. When creating profiles, it is not allowed to change language semantics. The original SysML Requirements model is shown in Figure 1. The SysML Requirements diagram is a stereotype of the UML Class diagram extended with new attributes. The SysML Requirements diagram can

3 III be used to standardize the requirements documents with a specific pattern to be used. Fig. 1. Basic node for SysML requirements diagrams The SysML Requirements diagram allows several ways to represent requirements relationships. These include relationships for defining requirements hierarchy, deriving requirements, satisfying requirements, verifying requirements and refining requirements. The relationships can improve the specification of systems, as they can be used to model requirements. Additional relationships were proposed in this article and are briefly explained as follows. SysML allows splitting complex requirements into more simple ones, as a hierarchy of requirements related to each other. The advantage is that the complexity of systems is treated from the early beginning of development, by decomposing complex requirements. For instance, high-level business requirements may be gradually decomposed into more detailed software requirements, forming a hierarchy. The derive relationship relates a derived requirement to its source requirement. New requirements are often created from previous ones during the requirements engineering activities. The derived requirement is under a source requirement in the hierarchy. In a Requirements diagram, the derive relationship is represented by the keyword derivereqt. The created attributes for the extended requirements take into account many of the specifications contained in the IEEE standard for describing software requirements [13]. An extended requirement (represented by the stereotype << ExtRequirement >>) is proposed in this article, including additional attributes. In addition, derived from this extended requirement, an extended requirement for non-functional requirements is proposed (represented by << ExtRequirementN RF >>) with additional attributes. Three types of non-functional requirements were proposed in the metamodel, as can be seen in Figure 2. The new defined attributes for ExtRequirement are: priority, abstractlevel, constraint, scenario, creationdate, modificationdate, and versionnumber. The priority attribute defines the relevance of a requirement in relation to the other, i.e., indicating the order that the requirements should be addressed. Values are of type String, including for instance, priority of type must, should, could, and won t. The requirement level indicates classification level in the hierarchy. The constraint attribute enables to show requirements that have some type of restriction. This attribute is of type Boolean. In case it is set to true, the identifier (ID) and the detailed description of this restriction are contained in a

4 IV Fig. 2. Metamodel for SysML Requirements Diagram table of restrictions. Scenario is an attribute of type String which basically identifies the scenario to which the requirement is related. The attributes creation- Date and modificationdate indicate the requirements version, which is useful to keep track of multiple versions of the requirement. The attribute versionnumber allows to determine the version of creation/elaboration of a requirement. The stereotype ExtRequirementNFR is used to describe non-functional requirements of software. The proposed attributes are externalfac, cost, and levelqos. ExternalFac determines whether a requirement is dependent on an external factor in order to be developed. The cost attribute allows to establish criteria of costs to satisfy a requirement that infuences directly in decisions about the viability of its development. Possible values to be assigned include High, Medium, or Low. The levelqos demonstrates the level of quality required for the requirement. The timing type of non-functional requirement relates to the description of time of a software. Its attributes are typetime, which can assume values physical time or logical time, minresponsetime and maxresponsetime, which are used to describe timing constraints of a requirement. The performance type has three attributes. RespTime indicates the maximum response time associated

5 V Fig. 3. Metamodel of Extended Relationship with a requirement. Its value allows to establish which level of performance is associated or is to be guaranteed by the requirement. The capacityop attribute indicates the possible number of simultaneous operations that are allowed in a given time period (e.g., number of reports generated for storage, operations per second, and so on). The attribute recoverytime describes the maximum time required for recovery from a failure. The safety type of non-functional requirement has attributes integrity (level of integrity that must be guaranteed), acesslevel (establish the level of access of stakeholders to a function), and limitedc (enables to demonstrate whether communication should be limited between this requirement and other functions/modules of the system. The extended model is able to represent requirements at different levels of abstraction, correlated requirements at the same level and, also, synchronism between requirements as shown in Figure 3. The << linkage >> stereotype represented by an arrow and a circle with an internal cross on both ends has the purpose of improving the activity of tracing requirements to the design models. Its graphical representation can be visualized in Figure 6. The << aggregate >> stereotype (Figure 5), was elaborated in order to explicitly demonstrate correlated requirements (in the same classification level) with a requirement/function one level up, i.e., requirements that are represented with this stereotype will together provide functionality expected by a higher requirement and are strongly bonded together. Finally, the new stereotype << synchronized >> should be used for nonfunctional requirements that in addition to performance constraints of nonfunctional requirements should be processed in parallel with other requirements. Its graphical representation is shown in Figure 4. Fig. 4. The << Synchronized >> relationship

6 VI Fig. 5. Relationships << aggregate >> Fig. 6. The linkage relationship 3 Case Study In this section, a subset of a list of requirements for a Road Traffic Management System (RTMS) is presented, using natural language to be further modeled and analyzed. The list of requirements given below is a subset from a document which contains 137 atomic requirements for a RTMS. The requirements were gathered through an extensive search in the literature of RTMS [14] [15]. 3.1 Requirements for the case study The elaborated requirements document depicts requirements for a Control System for a Road Traffic Intersection where the requirements are related to the time control at the intersection, flow control of vehicles, configuration and control of adaptive controllers, and receiving, storing and processing various data from each road approaches which interconnect the intersection, and also, controlling the green time of the signal. The configuration of the document is described as follows: Fourteen general purpose requirements as shown in Table 1. Sixty one functional requirements. Given the space of this article, only nonfunctional requirements modeled in this study were represented (Table 2). Sixty two non-functional requirements. Some of the Non-functional requirements used in the case study can be seen in Table 3. The requirements in each one of the different levels were presented in natural language. However, the focus of this work is the use of graphical models for improved representation of system requirements of the RTMS. The SysML constructions for modeling requirements are explained in detail in the following section. 3.2 Modeling the Case Study It can be seen from Figure 7 that requirements TM5, TM6, TM8, TM9 and TM12 are related to the requirement TM1 through the derive relationship using << derivereqt >> and the hierarchical relationship. The derive relationship is justified by the fact that the high-level requirements mentioned above are all

7 ID TM1 TM2 TM3 TM4 TM5 TM6 TM7 TM8 TM9 Requirement Name VII The system must control the standard of vehicular traffic at the intersection. The system must allow synchronization of semaphores. The system must collect all kinds of information of the road approaches in order to properly evaluate these data. The system must allow management of traffic history. The system must possess the adaptive control of schedules to the intersection in response traffic flow. The system must actuate in response to intersection traffic flow. The system must have the emergency preemption mode, i.e., preferential movement of emergency vehicles. The system must allow the control of the intersection in response to manual commands. The system must allow control of intersection in response to replacement of remote commands. TM10 The system must control incident management. TM11 The system of the intersection should be able to interact with the software control panel. TM12 The system must allow the automatic operation of semaphores. TM13 The system must use TCP/IP SNMP interface for inter-communication system. TM14 The system could generate statistical data to assist decision making. Table 1. High Level Requirements for a Road Traffic Management System ID Requirement Name TMFR5.1 The system must capture information of the approaches (detect volume) TMFR5.2 The system must store information sent from the vehicle detection loop TMFR5.3 The system must process traffic information TMFR5.4 The system must trigger new state in sufficient time to the reprogramming of intersection controllers TMFR5.5 The system must maintain statistics of counting vehicles Table 2. Functional Requirements for a Road Traffic Management System derived from the requirement that controls the traffic pattern of vehicles at the intersection. The hierarchical relationship (represented by a circle with a cross inside) represents one stronger relationship between a more general requirement and the more specific requirements. Figure 8 demonstrates the use of the new created relationship (the << aggregate >> relationship and its stereotype are shown in Figure 5). The relationship << aggregate >> shows when two or more requirements at the same level are linked to a more general requirement. In Figure 8 the associations between a requirement at the same level (in the same branch of the tree of modeling) with more than one requirement was suppressed due to readability. The application of the metamodel to the case study is described in Figure 9. It clearly demonstrates through the new stereotype << linkage >> which

8 VIII ID Requirement Name TMNFR5.1 The information of approaches (detection volume) must be captured with a maximum of 100ms. TMNFR5.2 The storage of traffic information, sent by loop detection vehicle, must be done with maximum of 1000ms. TMNFR5.3 The traffic information must be processed with a minimum of 150ms and a maximum of 200ms. TMNFR5.4 The system must trigger new state in sufficient time to program the controllers with a maximum of 100ms. TMNFR5.5 The new state of the actuators should be modified in synchronization with the other controllers on the network. TMNFR5.6 The controllers must receive their state safely. TMNFR5.7 The detection volume must be performed with maximum performance and reliability. Table 3. Non-Functional Requirements for a Road Traffic Management System Fig. 7. High Level Requirements and their relationships in SysML requirement at any level of abstraction (at a high level as TM5, or TMRF5.3) is interlinked with another one at Figure 10 where the hierarchy is clearly expressed among requirements. Figure 6 shows the relationship << linkage >>. Thus, the tree that demonstrates traceability of a requirement can be drawn from the << linkage >> relationship. Any requirement that has in its two ends the << linkage >> relationship indicates a point of connection between a more abstract requirement with another less abstract one. The requirements where

9 IX Fig. 8. High Level Requirements and their relationships with << aggregate >> parallel strategies should be applied are expressed by the << synchronized >> relationship. The linkage relationship, differently from the original SysML relationship of trace, provides well-defined semantics, as it allows toclearly observe the hierarchy levels or trace of a set of requirements. The tracing is demonstrated by hyperlinks of a basic requirement, whether functional or non-functional, with others in higher or lower levels. It is also possible to observe the classification and organization of such requirements. The obvious advantage of these new relationships and stereotypes is that complexity of the software design can be treated from the beginning of development by classification (in which the functional requirements, for example, are easily identified and can be manipulated directly) through the detailing of the various attributes of requirements relevant to the design of a real-time system. 4 Discussion The extension of the SysML Requirements diagram to modeling critical requirements of RTS, the approach proposed in this article, is convenient to accomplish the many characteristics relevant to a document of software requirements (as suggested in [13]). The completeness was demonstrated as all the general requirements, functional and non-functional ones may be related concisely to be further analyzed.

10 X Fig. 9. Application of the metamodel Fig. 10. Traceability between requirements of different levels The conflict between any requirements that are at the same level of the hierarchy or between high-level requirements with their less abstract requirements can be clearly visualized through the new relationships and the proposed modeling. The use of the new stereotype << aggregate >> also lists requirements on the

11 XI same level, and with that, conflicts in the same set of requirements are easily discovered. The ranked by importance, proposed as an attribute, is useful to define the priority attribute between requirements. This can be useful in order to clarify which requirements must be prioritized in phases of validation, testing or development. As each requirement is described separately the complexity of these changes is minimized, since a change in any requirement can be made completely and consistently maintaining structure and style of requirements. Expressing each requirement separately is highly desirable. This characteristic is addressed in this article by modeling requirements using a well-defined SysML Requirements diagram, and by organizing the relationship between requirements. 5 Conclusion The SysML is an interesting and reasonably modeling language for designing requirements of RTS. However, the current state of the language is not complete enough to satisfy many of the needs of representation, description and manipulation of requirements for RTS. The language provides the representation of a limited number of concepts related to these systems as, for instance, elements allowing the representation of time to build computing models with interpretations of time. The proposal in this article is to create extensions to the SysML Requirements diagram and adding new relationships which can express the classification of requirements for modeling RTS at different levels of abstraction. The extensions to the basic metamodel of SysML aims for better identification of software requirements at different abstraction levels, enabling the mapping of requirements relationships among themselves. In addition, the relationships between requirements are shown together in order to make it easier to trace these requirements in the many different levels of abstraction and thus facilitating the verification and the testing of a set of requirements in any phase of the life cycle of RTS. The proposed metamodel makes it possible to trace requirements, thus enabling the identification of their origin, detailing why and when they were included in the requirements document. This allows better care for many types of conditions required for the development of RTS and also improves the support of evaluation of the impact of requested changes. As a result, an improvement in the quality of software development is expected, as well as an improvement of the development process as a whole. References 1. Minor, O., Armarego, J.: Requirements Engineering: a Close Look at Industry Needs and Model Curricula. Australian Journal of Information Systems 13(1) (2005) Parviainen, P., Tihinen, M., van Solingen, R.: Requirements Engineering: Dealing with the Complexity of Sociotechnical Systems Development. Idea Group Inc (2005)

12 XII 3. Brooks, F.P.: No Silver Bullet: Essence and Accidents of Software Engineering. Computer 20(4) (1987) Martin, G.: UML for Embedded Systems Specification and Design: Motivation and Overview. In: Design, Automation and Test in Europe Conference and Exhibition. (2002) Cote, I., Heisel, M.: A UML Profile and Tool Support for Evolutionary Requirements Engineering. In: 15th Software Maintenance and Reengineering. (2011) Soares, M.S., Julia, S., Vrancken, J.: Real-time Scheduling of Batch Systems using Petri Nets and Linear Logic. Journal of Systems and Software 81(11) (2008) Silvestre, E.A., Soares, M.S.: Multiple View Architecture Model for Distributed Real-Time Systems Using MARTE. In: 20th International Conference on Information Systems Development. (2011) OMG: UML Profile for Schedulability, Performance, and Time, Version 1.1. Technical report, OMG (2005) 9. OMG: UML Profile for MARTE: Modeling and Analysis of Real-time Embedded Systems Version, 1.1. Technical report, OMG (2011) 10. OMG, S.: Systems Modeling Language (SysML) Specification - version 1.1. (2010) 11. Soares, M.S., Vrancken, J.: Requirements Specification and Modeling through SysML. In: International Conference on Systems, Man and Cybernetics. (2007) Soares, M.S., Vrancken, J.: Model-Driven User Requirements Specification Using SysML. Journal Of Software 3 (2008) IEEE: IEEE Recommended Practice for Software Requirements Specifications. (1998) 14. Laplante, P.A.: Real-Time Systems Design and Analysis. 3th edn. John Wiley & Sons, Piscataway, NJ, USA (2004) 15. Klein, L.A.: Traffic Detector Handbook. 3 edn. Prentice Hall, USA (Department of Transportation - Federal Highway Administration)