Archives

  • 2018-07
  • 2018-10
  • 2018-11
  • 2019-04
  • 2019-05
  • 2019-06
  • 2019-07
  • 2019-08
  • 2019-09
  • 2019-10
  • 2019-11
  • 2019-12
  • 2020-01
  • 2020-02
  • 2020-03
  • 2020-04
  • 2020-05
  • 2020-06
  • 2020-07
  • 2020-08
  • 2020-09
  • 2020-10
  • 2020-11
  • 2020-12
  • 2021-01
  • 2021-02
  • 2021-03
  • 2021-04
  • 2021-05
  • 2021-06
  • 2021-07
  • 2021-08
  • 2021-09
  • 2021-10
  • 2021-11
  • 2021-12
  • 2022-01
  • 2022-02
  • 2022-03
  • 2022-04
  • 2022-05
  • 2022-06
  • 2022-07
  • 2022-08
  • 2022-09
  • 2022-10
  • 2022-11
  • 2022-12
  • 2023-01
  • 2023-02
  • 2023-03
  • 2023-04
  • 2023-05
  • 2023-06
  • 2023-07
  • 2023-08
  • 2023-09
  • 2023-10
  • 2023-11
  • 2023-12
  • 2024-01
  • 2024-02
  • 2024-03
  • 2024-04

    • The UI compo http www apexbt com

    2020-06-29

    The UI components used in our proposal are called COTSgets, from COTS (Commercial Off-The-Shelf) [28] and gadgets (understood as any software that can work alone or as a piece of the architecture). A COTS component is any coarse-grained component developed by third parties available for building more complex systems. An example of a GUI application developed by us under a Project of Excellence funded by the Junta de Andalucía [Andalusian Government] [18] may be seen at http://acg.ual.es/enia/COTSbasedArchitectureExample. This real application will show the reader what a COTSget-based architecture looks like. It can be tried out, and hopefully, the role of this kind of component will be easier to understand. The second pillar is Model-Driven Engineering. This engineering discipline is focused on constructing models on different levels of abstraction, facilitating software specification, and providing several mechanisms for automating the development of the final product using of model transformation techniques. Some systems developed with these techniques attempt to provide software with adaptive capabilities for dynamic reconfiguration of the models at run-time, so they may act differently as the adapt to the circumstances of their execution, such as changes in the user interaction, available resources, or execution platforms [37], [16]. In the particular domain of component-based software systems, MDE techniques can facilitate architecture design and development, for example, in defining their structure, component behavior and relationships, interaction, or their functional and non-functional properties [12]. Furthermore, bacteriological of architectural models at run-time makes it possible to generate different software systems based on the same abstract definition, for example, to cope with different user preferences, component status or target platforms [3]. Fig. 1 shows how our component-based architectures can be represented on three levels of abstraction (in the infrastructure proposed): Run-time adaptation of the architectures is based on processes executed on the abstract and concrete architecture levels [10], [27]. On the abstract level, model-to-model transformation processes [14] are executed to adapt the abstract architectural models to changes in context [9]. On the concrete level, the concrete architectural models are realized by a trading process [28], [8], which calculates the configurations of concrete components that best meet the abstract definitions. This provides the possibility of generating different software architectures based on the same abstract definition, for example so it can be executed on different platforms. The content of this paper focuses only on showing the technological infrastructure used on the concrete level and the final architecture. Adaptation on the abstract level (PIM perspective), the trading process for the concrete architectures (PSM), synchronization of abstract models and final architectures, or how the changes in the models affect the executing architecture are outside the scope of this paper. The third pillar is Cloud Computing. The strengths of cloud computing for users and organizations have been widely described in the literature, e.g., [33] or [44]. The benefits identified include the use of Software-as-a-Service (SaaS) and specifically Models-as-a-Service (MaaS) as on-demand high-level abstract software. The combined use of MaaS and MDE in turn has many benefits [6] to highlight such aspects as their availability, run-time sharing, improved scalability and distribution, etc. In our proposal, instead of proposing general use of this concept, our work focuses on the management of software architectures based on our COTSget components. Therefore, inspired by the use of these components in models as services and as a mechanism for access to these models through web services deployed in the cloud, we have created a cloud service called COTSgets-as-a-Service. To provide this service, a cloud infrastructure organized in three layers has been created (Fig. 1): the client layer (C), the platform-dependent server layer (B) and the platform-independent server layer (A).