Archives

  • 2018-07
  • 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
  • Building applications by selecting and integrating component

    2020-03-24

    Building applications by selecting and integrating components is known in software engineering as COTS-based development. Nowadays, this approach is recognized as a crucial success factor for the software industry (Ahuja, 2014). The advantages of using COTS components include minimizing the overall development and maintenance costs of software. The use of COTS products is also associated with reducing risks of software development and shortening time-to-market for software application being developed. As evidence, Vale et al. (2016) in their systematic literature review about twenty eight years of component-based software engineering found that COTS is the most addressed application domain among 10 identified domains. Indeed, 25% of research studies were dedicated to COTS-based development. This is justified according to the authors by the fact that “reusing components from third-party providers is one key technology used to develop systems quickly and cost-efficiently”. Despite the given benefits of COTS-based development, there are still several challenges, risks and uncertainties related to this approach. Some reasons of these risks and uncertainties are due to the wrong selection of relevant COTS components (Arora and Singh, 2014). As a Fmoc-Leu-OPfp sale of fact, existing COTS candidates that likely meet the needs are first searched. The identified list is usually screened using some basic criteria in addition to functionality in order to keep only the most promising ones. Retained alternatives are afterward fully evaluated to select the best candidate. However, if the COTS component that best meets the needs, requiring the minimum of effort and cost to be reused, is not identified or not retained, another one could be selected. This leads to an additional cost and effort and increases the risk of project failure due to the non compliance with project costs and deadlines constraints. Therefore, the success of COTS-based development greatly depends on the results of the identification step. As COTS components are mainly marketed on the Web through catalog editors and vendors sites, and as their number is continuously increasing, the use of tools during the identification step is unavoidable. Search engines are topping the list. However, if they are not domain specific by taking into account semantics, they may return a great number of results without including many relevant ones, nor ranking them at top of the list. Recommender systems are a new type of emerging tools proposed to support developers in their tasks. A recommender system for software engineering is defined by Roubillard et al. as “a software application that provides information items estimated to be valuable for a software engineering task in a given context” (Robillard, Walker, Zimmermann, 2010, Robillard, Maalej, Walker, Zimmermann, 2014). They are distinguished from classical search tools by being able to estimate items relevance according to a context while being intended to a specific task (Robillard et al., 2014). The authors point out that estimation is not necessarily prediction. Several different information items can be recommended to support the software engineer in his/her task according to his/her needs. These items types include source code within a project, reusable source code, code examples, operations and people (Robillard et al., 2014). We witness several works on target cell field, among which we cite: CodeBroker (Ye and Fischer, 2002), Erose (Zimmermann et al., 2005), Strathcona (Holmes et al., 2005), XSnippet (Sahavechaphan and Claypool, 2006), Suade (Warr and Robillard, 2007), Code Conjurer (Hummel et al., 2008), Selene (Takuya and Masuhara, 2011), Quick Fix Scout (Muşlu et al., 2012) and a code reviewer recommender system (Hannebauer et al., 2016). Gasparic and Janes (2016) find in their recent research that the majority of recommender systems in software engineering recommend source code. Files, either digital documents or binary ones representing deployed source code are also the concern of some recommender systems. In turn, Web services, seen as software components where implementation details are hidden behind the interfaces (Yu et al., 2007), are the focus of some recommender systems. Indeed, we cite some existing papers about recommendation in the field of Web service discovery (Ma, Sheng, Liao, Zhang, Ngu, 2012, Xu, Martin, Powley, Zulkernine, 2007, Chan, Gaaloul, Tata, 2012), Web service selection (Manikrao, Prabhakar, 2005, Zheng, Ma, Lyu, King, 2009, Zheng, Ma, Lyu, King, 2011), and Web service composition (Chen, 2012, Garg, Mishra, 2008, Maaradji, Hacid, Daigremont, Crespi, 2010). The reader may refer to Kasmi et al. (2016) for the mashup context.