Abstract

Introduction Web applications are commonly assembled from a number of existing components that are combined together to support a custom business process. These are components such as Drupal and SugarCRM, which provide commonly used functionality for content management and user-profile management. The code that connects the components is known as “glue code”.

Highlights

  • The core idea of the approach is that developers can implement customer requirements by configuring platform components, instead of writing large amounts of “glue code” to wire the components together

  • Web applications are commonly assembled from a number of existing components that are combined together to support a custom business process

  • If a company plans to create a series of web applications in the same application domain, it should consider building a configurable platform first

Read more

Summary

Introduction

Web applications are commonly assembled from a number of existing components that are combined together to support a custom business process. The second problem can really be considered a subproblem of the first one: a configurable platform would be of little use if developers had to have detailed knowledge of specific components This primary audience of this article are companies like our hypothetical company Tickets R Us who need to create more maintainable applications and achieve a higher degree of reuse. These users are less likely to be familiar with expressing this information in the format required by a particular barcode component Creating these common interfaces closes the “gap” that exists between how business owners express their requirements and the way developers think about writing glue code. The benefits of this approach are: 1. It raises the level of abstraction: Software platform configurations are defined in the language of the business owner ( known as the domain level), not at the implementation level

It makes reuse more systematic and efficient
Modelling domain requirements
Identifying commonalities and variabilities in the requirements model
Modelling application requirements
Binding variabilities to components
Findings
Conclusion
Full Text
Paper version not known

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.