The rapid growth of software-based functionalities has made automotive Electronic Control Units (ECUs) significantly complex. Factors affecting the software complexity of components embedded in an ECU depend not only on their interface and interaction properties, but also on the structural constraints characterized by a component’s functional semantics and timing constraints described by AUTomotive Open System ARchitecture (AUTOSAR) languages. Traditional constraint complexity measures are not adequate for the components in embedded software systems as they do not yet sufficiently provide a measure of the complexity due to timing constraints which are important for quantifying the dynamic behavior of components at run-time. This paper presents a method for measuring the constraint complexity of components in automotive embedded software systems at the specification level. It first enables system designers to define non-deterministic constraints on the event chains associated with components using the AUTOSAR-based Modeling and Analysis of Real-Time and Embedded systems (MARTE)-UML and Timing Augmented Description Language (TADL). Then, system analysts use Unified Modeling Language (UML)-compliant Object Constraint Language (OCL) and its Real-time extension (RT-OCL) to specify the structural and timing constraints on events and event chains and estimate the constraint complexity of components using a measure we have developed. A preliminary version of the method was presented in M. Garg and R. Lai, Measuring the constraint complexity of automotive embedded software systems, in Proc. Int. Conf. Data and Software Engineering, 2014, pp. 1–6. To demonstrate the usefulness of our method, we have applied it to an automotive Anti-lock Brake System (ABS).

Software requirements are often not set in concrete at the start of a software development project; and requirements changes become necessary and sometimes inevitable due to changes in customer requirements and changes in business rules and operating environments; hence, requirements development, which includes requirements changes, is a part of a software process. Previous work has shown that failing to manage software requirements changes well is a main contributor to project failure. Given the importance of the subject, there's a plethora of research work that discuss the management of requirements change in various directions, ways and means. An examination of these works suggests that there's a room for improvement. In this paper, we present a systematic review of research in Requirements Change Management (RCM) as reported in the literature. We use a systematic review method to answer four key research questions related to requirements change management. The questions are: (1) What are the causes of requirements changes? (2) What processes are used for requirements change management? (3) What techniques are used for requirements change management? and (4) How do organizations make decisions regarding requirements changes? These questions are aimed at studying the various directions in the field of requirements change management and at providing suggestions for future research work. The four questions were answered; and the strengths and weaknesses of existing techniques for RCM were identified. This paper has provided information about the current state-of-the-art techniques and practices for RCM and the research gaps in existing work. Benefits, risks and difficulties associated with RCM are also made available to software practitioners who will be in a position of making better decisions on activities related to RCM. Better decisions will lead to better planning which will increase the chance of project success.

Abstract To perform requirements elicitation and analysis, effective communication and collaboration between stakeholders are necessary. Global Software Development (GSD), where software teams are located in different parts of the world, has become increasingly popular. However, geographical distance, cultural diversity, differences in time zones, and language barriers create difficulties for GSD stakeholders in engaging in effective communication. Taking into consideration the factors involved in GSD, previous research showed that the ways by which requirements are gathered and analyzed for collocated software development cannot be used effectively for GSD. Thus, in this paper, we present a method of requirements elicitation and analysis for GSD. The method consists of 4 stages: (1) data collection; (2) educating stakeholders about GSD issues; (3) post‐education assessment; and (4) requirements elicitation and analysis. Past researchers used student groups in a university environment to play the roles of stakeholders in experiments in GSD studies. Likewise, we preliminarily validate our method by applying it to a case study of an online shopping system, where the roles of client, requirements engineer, project analyst, and designers were played by a group of students.

Requirements analysis and component selection is widely recognized as an interrelated process that plays a central role in overall component-based system (CBS) development. Fundamental to the success of CBS is a requirement analysis model in which both stakeholders and candidate components balance the conflicting interests between what is needed and what is available. The effectiveness of CBS relies heavily on a system analyst's expertise to select suitable components. Owing to the lack of a language that could describe component alternatives with respect to stakeholder requirements, there is a need to develop one to describe CBS requirement analysis. In this paper, we present an extension to unified modelling language (UML) named RE-UML with a formal semantics utilizing Prolog programming language to support CBS requirements analysis. It helps balance the conflicts between what is required for a CBS-to-be and what features are supported by candidate components. RE-UML extends the UML sequence diagrams with a satisfaction interaction frame and mapping operators to model matching criteria between stakeholder demands and candidate component features. Further, associations between requirements and candidate components are introduced to model risk assessment and conflict resolutions during CBS requirements analysis. To demonstrate the usefulness of RE-UML, its application to the Seven-Eleven Japan software system is also presented.

Performance analysis derived from a formal specification of a multimedia protocol provides important information on the performance characteristics of a multimedia system before implementation; this information includes time-dependent functional behaviours, and statistical traffic characteristics. We have developed an extended Estelle, called Time-Estelle, suitable for specifying time-dependent performance characteristic of a multimedia system, and a method based on GSPN (Generalized Stochastic Petri Net) for analysing the performance of a protocol specified in Time-Estelle. This paper describes an application of this method to analyse the performance of an industrial multimedia protocol, the Resource ReSerVation Protocol (RSVP) specified in Time-Estelle; it also presents the performance analysis results which are expressed in terms of blocking probability, packet dropping probability, channel utilisation and packet delay, with variations in time intervals.

Abstract A component‐based system (CBS) is integration centric with a focus on assembling individual components to build a software system. In CBS, component source code information is usually unavailable. Each component also introduces added properties such as constraints associated with its use, interactions with other components and customizability properties. Recent research suggests that most faults are found in only a few system components. A complexity measure at a specification phase can identify these components. However, traditional complexity metrics are not adequate for a CBS as they focus mainly on either lines of code (LOC) or information based on object and class properties. There is therefore a need to develop a new technique for measuring the complexity of a CBS specification (CBSS). This paper describes a structural complexity measure for a CBSS written in Unified Modelling Language (UML) from a system analyst's point of view. A CBSS consists of individual component descriptions characterized by its syntactic, semantic and interaction properties. We identify three factors, interface, constraints and interaction, as primary contributors to the complexity of a CBSS. We also present an application of our technique to a university course registration system. Copyright © 2006 John Wiley & Sons, Ltd.

It is difficult to measure the maintainability of a software system early in the development life cycle from its requirement descriptions written in a natural language because informal specifications cannot be analyzed. With the uses of formal description techniques (FDTs) in the communication protocol area since the mid-1980s, avenues have been opened up for a system to be analyzed early in the specification phase. Quantitative measures on its maintainability can then be extracted from such a formal specification, so that we can develop easily maintainable communication software systems and further reduce the increasingly high cost of software maintenance. To date, there is hardly any work done on measuring the maintainability of a system early in its specification phase. This paper presents a method for measuring the maintainability of a communication by using maintainability metrics derived from its formal specification written in Estelle. The methodology for building the Estelle maintainability metrics hierarchy is presented. We have also developed an automated tool, called PSAMS, to automate the calculation of the maintainability indices. We also found that there is a significant correlation between the specification metrics proposed and the widely adopted implementation metrics, thus demonstrating that our proposed metrics are a reliable means of measuring the maintainability of a communication protocol early in the specification phase.

Good project management is key when developing a software system successfully. To manage a project well, it is important to have the optimal resource allocation which is affected by the size of an implementation. Early software size estimation is essential for good project management. Existing software size models estimate the size of an implementation usually in terms of the number of lines of code. The main drawback of these models is that there is a wide margin of uncertainty as the actual size depends on the type of application and the software development method adopted. To address this drawback, we focus our work on communication protocol, and propose that the size of a formal specification needs to be estimated from an informal specification. This paper presents a two-stage size model for estimating the sizes of a formal communication protocol specification and its implementation, with the model validated using a test data set. The main benefit of this work is that it can give an indication of the likely sizes of both a formal specification and its implementation early at the development stage, giving developers a technique for managing communication software project better.

Abstract An obstacle to the uses of software metrics and size models, which we have developed for measuring the complexity and maintainability of a communication protocol specified in Estelle and for estimating the size of its specification and implementation, is the time‐consuming effort in collecting the metrics. To address this problem, a software system called PSAMS (protocol specification assessment and measurement system) for automatically calculating the metrics and sizes of specification and implementation has been developed. This paper describes the design of PSAMS, which provides five functionalities for a communication protocol Estelle specification: exploring its specification, measuring its complexity, assessing its maintainability, estimating its specification size and estimating its implementation size. To demonstrate the usefulness of PSAMS, we have applied it to measure the complexity and maintainability of 10 communication protocol Estelle specifications; the measurement results and decision support information provided by each functionality are presented in this paper. With PSAMS, communication protocol designers and developers are able to assess the complexity of a communication protocol early in the specification stage and have information which helps them manage a communication software project better. Copyright © 2002 John Wiley & Sons, Ltd.

Fuzzy logic controllers (FLCs) are gaining in popularity across a broad array of disciplines because they allow a more human approach to control. Recently, the design of the fuzzy sets and the rule base has been automated by the use of genetic algorithms (GAs) which are powerful search techniques. Though the use of GAs can produce near optimal FLCs, it raises problems such as messy overlapping of fuzzy sets and rules not in agreement with common sense. This paper describes an enhanced genetic algorithm which constrains the optimization of FLCs to produce well-formed fuzzy sets and rules which can be better understood by human beings. To achieve the above, we devised several new genetic operators and used a parallel GA with three populations for optimizing FLCs with 3x3, 5x5, and 7x7 rule bases, and we also used a novel method for creating migrants between the three populations of the parallel GA to increase the chances of optimization. In this paper, we also present the results of applying our GA to designing FLCs for controlling three different plants and compare the performance of these FLC's with their unconstrained counterparts.

With the application of formal description techniques (FDTs) in the communication protocol area since the mid 1980s, avenues have been opened up to allow a system to be analyzed early in the specification phase. Quantitative measures on its maintainability can then be extracted from such a formal specification, so that we can develop easily maintainable communication software systems and further reduce the increasingly high cost of software maintenance. This paper describes some maintainability metrics for a communication protocol specified in Estelle.

Communication software systems have become very large and complex. Recognizing the complexity of such software systems is a key element in their development activities. Software metrics are useful quantitative indicators for assessing and predicting software quality attributes, like complexity. However, most of existing metrics are extracted from source programs at the implementation phase of the software life cycle. They cannot provide early feedback during the specification phase; and subsequently it is difficult and expensive to make changes to the system, if so indicated by the metrics. It is therefore important to be able to measure system complexity at the specification phase. However, most software specifications are written in natural languages from which metrics information is very hard to extract. In this paper, we describe how complexity information can be derived from a formal communication protocol specification written in Estelle so that it is possible to predict the complexity of its implementation and subsequently its development can be better managed. © 1998 John Wiley & Sons, Ltd.

Multimedia synchronization scenario modelling can be classified into four categories: axes-based model; synchronization point control; event-based model; and interval-based model.1 Existing formal languages do not support the specifications and verifications of all these four categories of synchronization scenarios. Estelle,2 an internationally standardised Formal Description Technique (FDT), unfortunately does not have enough expressive power to specify the time-dependent behaviours of a multimedia system. To address this limitation, we have developed an extended Estelle, called Time-Estelle3 to express multimedia QoS parameters, to identify various types of media objects, to describe temporal and spatial relationships, and to specify a range of synchronization scenarios. This paper discusses how Time-Estelle can be used for specifying the four categories of synchronization scenarios, and describes how these scenarios can be verified for correctness, thus enabling any potential temporal inconsistencies to be identified. © 1998 John Wiley & Sons, Ltd.

Existing software size models estimate the size of an implementation of a software system usually in terms of the number of lines of code. The main drawback of these models is that there is a wide margin of uncertainty, as the actual size depends on the type of application and the software development method adopted. To address this drawback, the authors focus their work on the formal communication protocol development, and present a size model for estimating the size of an Estelle specification of a communication protocol from its informal specification.

At present, ASN.1, and encoding and decoding rules, are not supported by Estelle. Estelle only specifies dynamic behaviours of protocols; and protocol data units of application layer protocol are specified in ASN.1. Hence, two standardized languages are required to specify an application protocol. In addition, Estelle and ASN.1 tools have been developed independently and do not support each other. As a result of these difficulties, the implementation of an application protocol is time consuming. To address this difficulty, we have proposed an approach which unified ASN.1 and Estelle specifications, and showed that the automatic implementation of an application protocol can be readily achieved by providing a software environment which supports this unified specification. This paper describes the detail of this software environment called EASE, and the results of using it to develop an implementation of the ISO FTAM protocol.

With the rapid growth in the applications of computer networks, protocol implementations have become essential. Such implementations require error-free and unambiguous protocol design and specification. One solution to this problem is to formally specify a protocol using formal languages to eliminate ambiguity and form the base's for verification, validation, implementation and testing. Estelle and ASN.1 are two formal languages standardised by ISO, Estelle being used for specifying distributed and concurrent information processing systems, and ASN.1 being used mainly for specifying application Protocol Data Units (PDUs). This paper presents a rapid protocol prototyping development system, which facilitates the automatic implementation and verification of the unification of Estelle and ASN.1 specifications.

Abstract Communication protocols used in the field have always suffered from failures. Some of these faults are the result of design errors; others are the result of implementation errors. These errors dramatically increase maintenance cost and decrease software reliability. The best time to maintain software is during its design stage. A formal approach to developing a protocol is deemed necessary to improve the quality of communication software and to reduce maintenance costs. Protocol verification plays a major role in achieving these objectives; a protocol is first specified formally and then this formal specification is analysed using a computer‐aided tool. PROTEAN is a software tool that verifies a protocol specified formally in Numerical Petri Nets. This paper describes the experience and practice of using PROTEAN to verify a complex protocol and then presents an evaluation of PROTEAN and its associated techniques in the light of protocol software development. The ISO FTAM protocol is used as a case study.

The techniques for verifying protocols specified in Estelle have so far focused on translating the specifications into another form, such as finite state machines or Petri nets, for which tools of verification have already been implemented. All the Estelle verification tools impose some restrictions on the specifications to be verified: the techniques use a subset of Estelle or restrict the complexity of the specifications that can be verified; or the specifications need to be specified in a variant of Estelle, rather than standardized Estelle. In particular, the dynamic behaviors of Estelle are not handled. This paper describes the verification of Estelle specifications by translating them into those of numerical Petri nets, which can then be verified by a proven automated verification tool, PROTEAN.>