The Model Driven Software Network
Raise your level of abstraction
SysML requirements diagrams for MDA software modeling
Hi!,
in order to describe a software system in an MDA approach, I would like ask your opinion about SysUML. Do you think is formally correct use requirements diagrams in a only software system?. The point is describe your system requirements using and standard model and write an MDA transformation for automatic documentation in html, docbook or others.
Javier Nieto
in order to describe a software system in an MDA approach, I would like ask your opinion about SysUML. Do you think is formally correct use requirements diagrams in a only software system?. The point is describe your system requirements using and standard model and write an MDA transformation for automatic documentation in html, docbook or others.
Javier Nieto
Views: 75
Replies to This Discussion
-
Permalink Reply by Rafael Chaves on -
Javier,
I think it is a valid approach to use transformations for what you want. I just don't see this as relevant in the context of MDD/MDA.
Model-driven development is all about automating as much as possible the construction of an application by starting from highly abstract models describing a *solution*. Requirements are really about the *problem* statement, and as such don't really belong to the scope of model-driven development.
Just my R$ 0,02.
-
Permalink Reply by Rui Curado on -
"Requirements are really about the *problem* statement, and as such don't really belong to the scope of model-driven development."
Why not? A "requirement" is a concept that can certainly be modeled.
-
Permalink Reply by Rafael Chaves on
-
Peter, it is true that for very trivial things one can establish a 1:1 correspondence between problem statement and solution specification. But for anything more interesting, the gap is just too wide to be bridged via automatic transformations.
-
Permalink Reply by Rafael Chaves on
-
It sure can be modeled, Rui (and so can many other things), but that still does not make it really useful in the context of building a solution using MDD.
You cannot get from requirements to solution via automated transformations. That is where we are always going to need people (unless you limit the requirement/solution spaces so much there is little to no gap - like in DSM).
-
Permalink Reply by Rui Curado on
-
"You cannot get from requirements to solution via automated transformations."
Yes, I agree. Modeling requirements requires human intervention for its transformation. However, If we could just have requirements in the model, and a way to link them to their corresponding implementation, we would have already a good benefit.
-
Permalink Reply by Rafael Chaves on
-
Yes, traceability is a good thing. My point was that requirements is something outside of the domain of model-driven development (even if we use models for that).
-
Permalink Reply by Pedro J. Molina on -
Hi:
If you plan just to generate documentation for your requirements it's ok.
Probably a textual representation with or without list or hierarquical grouping will be more than enough to accomplish the given task. Natural language can be quite well represented in an unparsed string.
But, on the other hand, if you are going to gather requirements in the way that Peter comments, things start to be more interesting:
- Probably you will need to define templates for families of requirement types you are accepting. For example: the max char validation Peter cited. Once gathered, lets call it a SizeValidationRequirement you will have to define how this will be managed in the doc, code generated, db, etc.
- That is certainly doable for frequent requirement types.
However following this second path, is quite difficult to cope with any general unanticipated requirement such as:
- the response time for this system should be lower than 5 ms.
- the UI should conform to AAA accessibility.
- Credit debt should appear in red.
- ...
In general, modeling requirements is nice. They are the very first artifacts that should drive the full developing.
On the other hand, how you model the requirements can drive you to:
- just documentation,
- a restricted set of family requirements (and still relevant in your constrained domain)
- or a endless types of requirements to be modeled if the domain is to broad.
Transforming natural language into formal requirements with precise semantics is not so easy. No code generator for that, not yet! So, that why we need analysts. }:)
Regards,
-
Permalink Reply by Jordi Cabot on -
Exactly. I call this the pareto principle for MDD (http://modeling-languages.com/blog/content/pareto-principle-applied-mdd): "20% of the modeling effort suffices to generate 80% of the application code " i.e. with a small effort on the modeling of the static aspects of the domain you can generate around 80 of all the required functionality (all basic CRUD operations account for that 80% in several studies we did, check the previous URL if you want to get the full information)
-
Permalink Reply by Lee Riemenschneider on -
This "pareto principle for MDD" doesn't look to be valid for Executable UML. The majority of the modeling effort in Executable UML is spent modeling the class diagram for the domain. If the class diagram is correct, then the dynamic aspects are much easier to model. It's not 80/20, but at least 50% to 60% of the effort is in class modeling.
-
Permalink Reply by Dan George on -
Lee, I have been uncomfortable with the Executable UML action language concept. It seemed like a big loophole in the process where we just get back to a low level of abstraction after all. I worry about falling back into "nice picture, now show me the code" and the code being an action language like any 3GL. Based on your comment I might make a guideline. If the action language effort exceeds 50% then the class model is probably lacking. Perhaps complex action logic results from awkward class model.
This reasoning leads to better justification for an action language being something other than an existing 3GL. Existing 3GLs might lack constraints on expression necessary to trigger the above guideline. If it is easy to express complex actions then the ratio tilts toward complex dynamic model. If the action language is constrained, makes complex actions hard to express, then it would be easier to determine the class model is lacking. I like this justification (perhaps contrived) for a new action language better than the usual portability-based justification. Portability is only compelling if it is needed and it isn't always needed. Minimized system complexity is always beneficial if it can be achieved economically.
Sorry if I'm overstating the obvious but for some reason I've not thought of it exactly this way before.
-
Permalink Reply by Lee Riemenschneider on
-
Dan, It's good to hear this point of view. The mind tends to get aligned to the familiar, so you start to wonder how someone else gets to a conclusion. It never occurred to me that anyone would consider the action language to be at a 3GL level of abstraction. (Although I always considered it a possible pitfall to using a 3GL for action language.)
Portability of using an existing 3GL as an action language is restricted to platforms that use that 3GL. The action languages in use by the Executable UML tools (e.g., BridgePoint, iUML, PathMATE) give you much more portability across platforms. The problem is that they aren't exactly the same (although they are very similar), so it's harder to move among the Executable UML tools. If XMI ever gets action semantics, then export/import will become much easier (if supported by the tool vendor).
An awkward class model leads to complex state models as well as procedural models(action language). Any time either one starts getting complex, I go revisit my class model. Leon Starr hammers on this point in his class modeling book.
-
Permalink Reply by Javier Nieto Esteban on -
Hi,
After reading the thread I'm writing my requirement model using de SysML Requirement diagram. I have a transformation M2T (to html) for the documentation. I'm using Acceleo for it.
One of the advantages of MDA is solve the maintenance documentation problem (Mda Explained. The Model Driven Architecture: Practice and Promise). That is important because documentation is part of the final release of your system. So, I think is a good practice use a model for the requirements in order to generate a synchronized documentation. It has other advantage: you can automate the traceability of your requirements along the development. For example, use cases refine the functional requirements. If you write this in your model, you can trace all the functional requirements along your project and ensure all your functional requirements are satisfied. This is especially important in large projects.
And about the non functional requirements, is a good think have all in the same model. With a little effort your model is the complete documentation … only you need a good transformation and that's all. :).
SysML seems to be a good alternative for requirements diagrams. But I have created a profile to complete it. It has two stereotypes: functional and not functional. Not functional requirements have a property (type) with this values: Security, Performance, etc.
Thanks All!
© 2012 Created by Mark Dalgarno.
Powered by
