We use the proposed approach to revisit the high-level architectural design of data provision service in two real-world open software platforms. Both platforms are embedded operating systems. The first platform is an operating system controlling the electronic units of a vehicle and the second one is an operating system for smartphone devices.
To apply the proposed approach on each design case, two preparatory steps have been taken: (1) The documents containing information about the design of each platform have been collected from the literature. (2) The information required for applying the proposed approach has been extracted from the collected documents. The extracted information is of two types: (a) the important design requirements for each case; i.e. the requirements that openness introduces and other general concerns that should be considered in opening up each platform; and (b) the priority of each design requirement. Where the required information was absent or not explicitly mentioned, we have augmented the information based on our own understanding from the case. Augmented information is distinguished from the extracted information using “*”.
To use the catalogues, two preparatory steps need to be performed. (1) The domain requirements are matched with the requirements items available in the catalogues. If the wording of a requirement is different, the most similar requirement item in the catalogues is selected. If no similar item is found, the correct placement of the requirement is found and the related catalogue is augmented with new the content. Adding new content may also need modifying the structure of the catalogue. (2) The evaluation of design mechanisms in the correlation catalogues may also be revised in each context.
To re-design the data provision service in each case, the seven steps described in the beginning of Sect. 2 are performed. To refine the requirements in each design context, the related refinement paths in the catalogue presented in Fig. 4 are used. Refinement is done up to the level that there is evaluation data for the refined requirement and the three alternative designs in the correlation catalogue. The fulfillment of the requirements is then evaluated using the goal-oriented forward evaluation procedure. The evaluation results identify the degree of requirements fulfillment in each design alternative. Requirements fulfillment is described in five degrees: Satificed (Sat), Partially Satisficed (PSat), Conflict (Conf), Partially Denied (PDen), and Denied (Den). The evaluation results are used to compare alternative designs and identify the potential trade-offs that should be made between identified requirements by choosing each option. Based on the comparison results, the most appropriate design for the data provision service is selected. The selected option is then compared to the original design.
An Open Embedded Automotive Software Platform.
The information related to this platform is extracted from . In , the process of designing the platform is explained in detail. The document explains the requirements of the platform, their priorities, the decisions that were made to design the platform, and the rationale for those decisions. However, no modeling and analysis has been done in the design process. All the information required for our analysis was available in the document.
The platform is an operating system sitting on top of the electronic hardware of a vehicle to control the vehicle electronic units. The platform has to deal with safety critical functionalities and data. Thus it should be highly dependable. The platform has been opened to different types of third-party applications, such as applications developed by certified developers and applications developed by undirected developers. Third-party applications sit on top of the platform and add functionality to it. Examples of these additional functionalities include: automatic control of the speed of the vehicle or displaying the speed of the vehicle in the display. To perform such operations, third-party applications may need read or write access to data (such as speed and lateral acceleration data), controlled by the platform or other third-party applications.
The important design requirements of the platform and their priorities are described in Table 2. The related paths in the catalogue of Fig. 4 that help specify and refine the requirements as well as their fulfillment in each alternative design are shown in Fig. 5.
Table 3 summarizes the fulfillment of key requirements in each design alternative. As shown, “centralized data provision” outperforms the other two alternatives in fulfilling all the requirements except performance. In contrast, the other two alternatives partially satisfice performance. However, “semi-centralized data provision” violates two openness requirements of “composability” and “deployability”, and “decentralized data provision” underperforms in the fulfillment of all the other requirements.
Although “centralized data provision” fulfills four of the five important design requirements and achieves the highest rank among the three alternatives, it has negative impact on the performance of the platform. Centralized control over all data interactions creates a bottleneck in the platform. In case of several simultaneous data read and write requests, this design creates a queue of requests that should be checked by the platform and increases the waiting time of data operations. However, the automotive platform is in charge of safety-critical and real-time operations. Considering this, performance is not a negligible requirement.
In comparison, “semi-centralized data provision”, though violating two openness requirements of “composability” and “deployability”, alleviates the load of platform by delegating the control of some data interactions to the related third-party applications. Since critical third-party applications are developed by certified developers, the platform can easily decide to control which data operations, delegating the control of less critical data interactions to the related third-party applications. Considering this, semi-centralized control does not negatively impact the integrity and security of the platform data. Accordingly, we assess the final impact of “semi-centralized data provision” on “Security [Platform]” as positive. Thus, it would be reasonable to sacrifice some degrees of “composability” and “deployablity” to achieve higher degrees of performance for real-time operations of the automotive platform.
In , “centralized data provision” alternative has been adopted to open up the automotive platform data to all types of third-party applications. The problem of performance (real-time data access) is alleviated via attaching different priorities to different types of third-party applications waiting in the data request queue. However, according to our analysis, for the third-party applications with less safety-critical operations “semi-centralized data provision” is also appropriate. Thus, using both options of centralized and semi-centralized data provision to open platform data to different types of third-party applications improves performance, while minimizing negative impacts on the openness requirements of composability and deployability.
This difference might have several reasons: (1) Performance has been sacrificed to gain higher degrees of composability and deployability, and probably security. (2) It is also possible that the track of performance requirements has been lost in designing data provision service. This is plausible due to the large number of decisions made during the design and the lack of support for requirements tracking. (3) Alternatively, due to some domain characteristics not mentioned explicitly in the design document, such as the hardware infrastructure, performance is not significantly impacted by the bottleneck of centralized data provision.
An Open Embedded Mobile Operating System Platform.
Different pieces of information related to the design of the mobile platform have been collected from [2, 15, 17]. Some requirements and priorities have been added based on our understanding from the context, which are distinguished by “*”.
The platform is an operating system sitting on top of the hardware device of a smartphone to control its functionalities. The platform hosts native and non-native applications. Third-party applications add a wide range of functionalities that could be of potential interest to various mobile users. Development of mobile applications is highly knowledge-intensive. Thus, mobile application development is usually open to a wide range of third-party developers. Third-party applications may need read or write access to platform data or the data generated by other third-party applications.
The requirements of the mobile platform and their priorities are described in Table 4. The related specification and refinement paths from the catalogue of Fig. 4 and the fulfillment degree of the requirements in each design alternative are shown in Fig. 6.
Table 5 summarizes the fulfillment of the identified requirements in each design alternative. As shown, “centralized data provision” underperforms in fulfilling all the high-priority requirements, namely “accessibility”, “adoptability”, “partner ecosystem gravity”, “innovative features”, and “performance”. Interestingly, this alternative outperforms in fulfilling medium-priority requirements, such as “composability”, “deployability” and “ownership”. In contrast, the other two design alternatives equally satisfice high-priority design requirements. However, “semi-centralized data provision” performs better in fulfilling “privacy [data]” requirement.
Although “semi-centralized data provision” satisfices all the high-priority requirements and achieves the highest score from among the three design alternatives, its implementation has negative impact on two openness requirements of “composability” and “deployability”. It also violates “data ownership” requirement. Nevertheless, composability and deployability are two important technical quality attributes for an open platform. Decoupling third-party applications from each other and reducing their dependencies plays an important role in the maintainability and controllability of the platform. Specifically when the size of a platform and its complementary applications and services grow, which is usually the case for an open mobile platform. Moreover, the ownership of platform data is not a negligible requirement for a platform owner.
However, “accessibility” and the impact it has on the “adoptability” and ‘innovative features” is strategically critical to the success of a mobile platform in the market, specifically in a fierce competition with other platforms. Thus, it would be reasonable to sacrifice some degrees of the system-level openness requirements to gain more support from innovative and complementary applications (the business-level openness requirements), specifically in a knowledge-intensive domain as mobile applications.
The result of our analysis indicates that “semi-centralized data provision” is the best option from among the three alternatives to open up mobile platform data to third-party applications. This result is consistent with real-world implementation of open mobile platforms such as Android . In Android, third-party applications declare the data they require from the platform and other third-party applications at install time. The access is permitted by the end user (i.e. end user is the mediator).