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 a 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 provides a detailed comparison of 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; an 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.
The following figure shows the five alternatives we consider and compare in the paper. At this stage, the proposal is still at the theoretical level so theres 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).
To know more about our proposal you can read the full paper or take a look at the following presentation
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Non-functional requirements are technological choices and can be addressed the same way all other technological choices are made: transformation PIM->PSM (for instance, code generation templates).
For instance, where do you address the requirement “the implementation should be made in Java 6”?
For things that are not one-size-fits-all (for instance, “progress should be reported for long running operations), the same idea still applies, but you can annotate the PIM (directly or not) with markings that will drive the decision in the transformation (for instance, if an operation is marked as “longRunning”, enable progress reporting, or if an operation is marked as “privileged(level: admin)”), require proper authorization level).
Or am I missing something? Sorry, I looked over the presentation, did not RTFA.
Rafael
http://alphasimple.com
Rafael,
We agree on this. The problem is that right now, MDD tools do not offer this kind of transformations. Tools only implement, for instance, one UML to RDB or UML to Java transformation. You don´t have several ones (depending on whether you want a Java code focused on performance or one easier to maintain)
I would not expect the MDD tool to provide that out of the box. From my experience with code generation, the tooling only provided a general purpose transformation engine (for instance, model-to-text) and it is up to the team to (re)factor the application, which would would have MxT hand-coded artifacts, into M modeled classes and T templates (for code, DB schema, etc). I wouldn’t need special help WITH addressing NFR given that I control the models AND the templates, so I can sprinkle the model WITH SOME NFR-related markings, AND code the templates TO do the RIGHT thing based ON them.
Going off ON a tangent, we probably think OF different things AS the MDD tool. I see the ecosystem eventually (we don’t have one yet) dividing into modeling tools, code generation engines and target platform/architecture generation cartridges, with companies picking best-of-breed offerings for each of those pieces.
But I guess the main difference in perspectives here is that you are doing research on future trends and I am talking about an experience from almost 10 years ago. You are looking for better things, I can’t help being held back by the status quo.
Cheers,
Rafael
Hello,
Just TO complement the answer, I would LIKE TO mention that FOR us IS also very important TO consider other higher LEVEL decisions OF the architecture (e.g. deployment decisions).
David.
… it´s always good that people remind us that apart from “futuristic” solutions we also need to worry about “realistic” ones at least from time to time. In fact, we try to combine both, but it´s usually very difficult to achieve.
Hi Jordi,
It’s good TO see that MORE attention IS given TO non-functional requirements IN the context OF MDD.
> we would really appreciate ANY INPUT you can give us ON this.
Maybe you can use SOME OF the ideas (very high-LEVEL) IN my post about the place OF Architecture IN Model-Driven Engineering. It ONLY talks about how architecture principles influence an MDD approach.
I’m also wondering… do you actually want to deal with non-functional requirements in the MDD process? Or do you select an MDD tool based on it’s non-functional characteristics AND never think about it again? That’s probably not feasible because the models will in most cases influence the non-functional characteristics. Or can we abstract that?
Just some raw thoughts…
Johan, you put a very interesting question: “do you actually want to deal with non-functional requirements in the MDD process?”
I´d say yes. In theory, I´d like to gather the NFRs of a given project, input them in the MDD tool together with the functional ones and get a running system (either by generation or interpretation) that satisfies those NFRs.
A different question is that it’s what practitioners also want OR they just don’t care. As a follow-up to the paper we are doing some empirical research on this. Hopefully, I’ll be able TO publish SOME info ON that soon enough.
The NFO covered here are traditional one. With progress in technology and understanding of software capabilities and engineering new breed of NFO has emerged. I have tried listing some of the contemporary NFO at my blog (http://architecture-soa-bpm-eai.blogspot.com/2010/10/contemporary-non-function-requirements.html)