Dealing with Non-Functional Requirements in Model-Driven Development

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

In a joint work with David Ameller and Xavier Franch (presented at the RE’10 conference) we have investigated the support for non-functional requirements (NFRs) in model-driven development (MDD).

The impact of non-functional requirements (NFRs) over software systems has been widely documented; especially regarding the choice of the right software architecture for the system (two different sets of NFRs may need two different system implementations even if the functional requirements are the same). Consequently, cost-effective software production methods shall provide means to integrate this type of requirements into the development process. Unfortunately this is not the case in MDD processes that mainly focus on the functional aspects of the system. Therefore, the software implementation generated as part of the MDD processes must be manually adapted by programmers to comply with the NFRs of the stakeholders. Needless to say this is not an ideal scenario.

In our work, we outline a general framework that integrates NFRs into the core of the MDD process and provide a detailed comparison among all the MDD approaches considered. We discuss two possible variants: an automatic (based on a predefined set of M2M transformations where, to put it simply, each transformation is designed to generate a PSM model that satisfies a given NFR/s; a MT knowledge repository is used to link transformations and NFRs) and an iterative one in which the designer itself chooses the most appropriate transformations for the given NFR scenario.

At this stage, the proposal is still at the theoretical level so there’s plenty of (research) challenges that we need to solve to put this in practice (e.g. how to obtain the architectural knowledge from human experts and use it in automatic NFR-aware MDD processes). Therefore, we would really appreciate any input you can give us on this.

To know more about our proposal you can read the full paper or take a look at the following presentation

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
Comments
  1. rafael
  2. jordi
  3. rafael
  4. David Ameller
  5. jordi
  6. Anonymous
  7. jordi
  8. Anonymous

Reply

Your email address will not be published. Required fields are marked *