Abstract: With the rise in initiatives such as software ecosystems and Internet of Things (IoT), developing robust web Application Programming Interfaces (web APIs) has become an increasingly important practice. One main concern in developing web APIs is that they expose back-end systems and data toward clients. This exposure threatens critical non-functional requirements, such as the security of back-end systems, the performance of provided services, and the privacy of communications with clients. Although dealing with non-functional requirements during software design has been long studied, there is still little guide on addressing these requirements in web APIs. In this paper, we present WEBAPIK, a body of structured knowledge on addressing non-functional requirements in the design of web APIs. WEBAPIK is comprised of 27 distinct non-functional requirements, 37 distinct design techniques to address some of the identified requirements, and the trade-offs of 22 design techniques, presented in two forms of natural language and knowledge graphs. The design knowledge compiled in WEBAPIK is systematically extracted and aggregated from 80 heterogeneous online literature resources, including 7 books, 15 weblogs and tutorial, 5 vendor white papers, 6 design standards, and 47 research papers. These resources are systematically retrieved from two search engines of Google and Google Scholar and five research databases of Web of Science, IEEE Xplore, ACM Digital Library, SpringerLink, and ScienceDirect in two periods of March to August 2018 and August 2022. WEBAPIK gathers and structures expert and scholarly discussions to provide insight about addressing non-functional requirements in the design of web APIs. The structure brought to the design knowledge makes it amenable towards extension and creates the potential for employing it in the database of knowledge-based systems that aid software developers in design decision-making.

Abstract: With the rise in initiatives such as software ecosystems and Internet of Things (IoT), developing web Application Programming Interfaces (web APIs) has become an increasingly common practice. One main concern in developing web APIs is that they expose back-end systems and data towards clients. This exposure threatens critical non-functional requirements, such as the security of back-end systems, the performance of provided services, and the privacy of communications with clients. Although dealing with non-functional requirements during software design has been long studied, there is still no framework to specifically assist software developers in addressing these re-quirements in web APIs. In this paper, we introduce Rational API Designer (RAPID), an open-source assistant that advises on designing non-functional requirements in the architecture of web APIs. We have equipped RAPID with a broad range of expert knowledge about API design, systematically collected and extracted from the literature. The API design knowledge has been encoded as a set of 156 rules using the Non-Functional Requirements (NFR) multi-valued logic, a formal framework commonly used to describe non-functional and functional requirements of soft-ware systems. RAPID uses the encoded knowledge in a stepwise inference procedure to arrive from a given re-quirement, to a set of design alternatives, to a final recommendation for a given API design specification. Seven well-experienced software engineers have blindly evaluated the accuracy of RAPID’s consultations over seven dif-ferent cases of web API design and on providing design guidelines for thirty design questions. The results of the evaluation show that RAPID’s recommendations meet acceptable standards of the majority of the evaluators 73.3% of the time. Moreover, analysis of the evaluators’ comments suggests that more than one-third of the unac-ceptable ratings (33.8%) given to RAPID’s answers are due to valid but incomplete design guidelines. We thus ex-pect that the accuracy of the consultations will increase as RAPID’s knowledge of API design is extended and re-fined.

Abstract: With the rise in software ecosystem initiatives, developing Application Programming Interfaces (APIs) has become an increasingly common practice. One main concern in developing APIs is that they expose back-end systems and data towards clients. This exposure threatens critical non-functional requirements, such as security of the back-end systems, performance of the provided services, and privacy of the communications with clients. Although dealing with non-functional requirements during software design has been long studied, there is still no framework to specifically assist software developers with addressing these requirements in APIs. In this thesis, we introduce Rational API Designer (RAPID), an assistant that provides consultation about designing non-functional requirements in the architecture of APIs. We have equipped RAPID with a broad range of expert knowledge about API design, systematically collected and extracted from the literature. The API design knowledge has been encoded as a set of 156 catalogues using the Non-Functional Requirements (NFR) language, a multi-valued logic commonly used for describing non-functional and functional requirements of software systems. RAPID uses the API design catalogues in a step-wise refinement and selection procedure to arrive from a given requirement, to a set of design alternatives, to a final suggestion for a given API design specification. Seven well-experienced developers have blindly evaluated accuracy of RAPID’s consultations over seven different cases of API design and on providing design guidelines for thirty design questions. The results of evaluation show that RAPID’s recommendations meet acceptable standards of the majority of the evaluators 73.3% of the time. Moreover, analysis of evaluators’ comments suggests that more than one-third of the unacceptable ratings (34%) given to RAPID’s answers are due to valid but incomplete design guidelines. We thus expect that the accuracy of the consultations will increase as RAPID’s knowledge of API design is extended and refined. Software developers can use RAPID to receive design suggestions generated through reusing the knowledge of experts, or to add their own knowledge of API design to RAPID for future use of their peers.

Abstract: Adopting appropriate openness design strategies, which fulfill open-innovation objectives while maintaining quality requirements, calls for deliberate analysis of openness requirements from early on in opening up software platforms. We propose to treat openness as a distinct class of non-functional requirements, and to refine and analyze it in parallel with other design concerns using a goal-oriented approach. We extend the Non-Functional Requirements (NFR) analysis method with a new set of catalogues for specifying and refining openness requirements in software platforms. We apply our approach to revisit the design of data provision service in two real-world open software platforms and discuss the results.

Abstract: Opening up software platforms to third-party applications often involves difficult trade-offs between openness requirements and critical design concerns such as security, performance, privacy, and proprietary ownership. Deliberate assessment of these trade-offs is crucial to the ultimate quality and viability of an open software platform. We propose to treat openness as a distinct class of non-functional requirements, and to model and analyze openness requirements and related trade-offs using a goal-oriented approach. The proposed approach allows to refine and analyze openness requirements in parallel with other competing concerns in designing software platforms. The refined requirements are used as criteria for selecting appropriate design options. We demonstrate our approach using an example of designing an open embedded software platform for the automotive domain reported in the literature. The proposed approach allows to balance the fulfillment of interacting requirements in opening up platforms to third-party products, and to determine “good-enough” and “open-enough” platform design strategies.

Abstract: It has become an increasingly common practice that software companies collaborate with external developers to develop a software platform for a shared market, constituting software ecosystems. One main concern in adopting the practice of software ecosystem is how to attract external developers to a platform, and how to establish sustainable collaborative relationships with them. We discuss that explicating and in-depth analysis of developers’ objectives and decision criteria can facilitate the design of sustainable collaborations in software ecosystems. Scenarios from Apple iOS and Google Android ecosystems are used for illustration.

Abstract: It has become an increasingly common practice for software companies to collaborate with external developers in order to develop software platforms for a shared market, constituting software ecosystems. Creating and sustaining a software ecosystem is a challenging problem that involves numerous technical, organizational, and business concerns. To support the systematic design of software ecosystems, modeling is a crucial tool. In this paper, we (a) identify a set of descriptive and analytical requirements raised in the design of software ecosystems; (b) review several modeling techniques used for describing and examining software ecosystems; and (c) assess the support of the reviewed techniques towards addressing the identified requirements. The results provide insight into the gaps between the issues raised in the design of software ecosystems, and the coverage of the studied techniques, suggesting an agenda for future research.

Abstract: As a software organization matures and expands, it often evolves through different styles of organization, for example, beginning with creative chaos as a start-up, then introducing disciplined processes to raise quality, and later regaining agility through light-weight practices. Recently, many firms join collaborative networks to develop software products and platforms for a shared market, constituting “Software Ecosystems”. At each stage of evolution, the software organization aims to overcome critical challenges faced in its earlier stages, while balancing business, organizational, social, and technical forces of change. To illustrate how the evolutionary trajectory of a software development firm is shaped by various interacting forces, we draw upon a longitudinal case study taken from the literature. We use the i* strategic actors modeling framework to help analyze the forces that trigger the transition from one organizational configuration to another.