Abstract

For software products, the specifications, the requirements even the variables, the code or the software modules are subject to be labelled with key-terms, or described using attributes or specific values. The purpose of these notations is linked to the semantic of the object labelled, and is used as an indexing form for that specific category. A separation of concerns meta model is proposed here to provide the support of using a unitary type of notation in labelling various kind of resources used in the process of developing software, from requirements and specifications all the way to variables, code or software modules. The use of a standard, unitary notation can have multiple benefits, covering areas like code reusability, reverse engineering, assigning technologies for development, aspect-oriented software development (AOSD), requirements engineering (engineering web applications, grouping requirements by categories, such as: technology, importance, actor, volatility, functionality).

Highlights

  • The separation of concerns in software engineering can provide multiple benefits such as reduced complexity, improved reusability, and simpler evolution

  • Change impact analysis and reuse of code are supported by concerns.Basically, software systems should benefit in many ways when using separation of concerns during product cycle

  • Looking to a software product as an outsider, one might consider that describing the concerns produces a substantially large amount of metadata that adds bureaucracy during the development process of the software product

Read more

Summary

INTRODUCTION

The separation of concerns in software engineering can provide multiple benefits such as reduced complexity, improved reusability, and simpler evolution. Defining concern spaces and relating concerns to the source code during development stage has the power to add semantic to the components of an application. The semantic value can be added to different entity spaces such as: the application model, the data, the relations, the views, and the design; to the requirements, and . The purpose of this paper is to express the need of a unitary framework for modelling Concern Spaces and the relations with different types of entities, to define primitives needed to represent such relations, and to propose patterns that can be followed in various scenarios during the use of the approach. The paper will end with further work and conclusions sections

RELATED WORK
MODELING CONCERN SPACES
CASE STUDY
FUTURE WORK
CONCLUSION
Full Text
Published version (Free)

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