Who never asked for more time to focus on things that matters, like, for instance, gigantic
barbecues ?
And then you fulminate against this tool which should help you and which is not,it's just another burden placed on you to provide this documentation nobody will ever maintain or even read. Is that what modeling is about ?
Life as a software user is often harsh, especially as you have, most of the time, no control at all on the software you use. As a developer it's even more difficult as you have an idea on what's going on behind the scene, and not having control is something you just can't handle now that so much open-source products are providing you this power.
If you had control on your tools, if you could adapt it or even easily define it, then you could focus on useful things. Modeling can bring it back to you, not modeling like in UML Modelers, modeling like formalizing your domain model as a way to capture your though or your coding tasks.
A Model doesn't have to be high level, a model doesn't have to provide as much information as your source code, a model is just here to help you answer questions about what you're doing.
If you can't say, for a given model what kind of questions it's helping you to answer, then your model is just not relevant, it's not a model, let's call that boxes with edges.
And now let's take a small example, you wants to define a software using components which are providing services, then you wants to assign these "logical" components to Eclipse plugins, here is a model definition you can come up with :
From an instance of a model you can answer the
questions : how is split my application ? what services are provided and required by who ? And how these components are
linked to the Eclipse plugins I'm coding ?
From now you can either capture an instance and start working thanks from EMF Dynamic support , or specify a tooling to ease this capture. If a diagram is a good representation for your problem, pick it, if it's not, pick a tabular, tree or even textual representation.
The following demo describe a tooling specification (click on the image! ) at the top, the specification, at the bottom, the tooling which is dynamically adapting itself to the specification.
Modeling itself is useful to organize your though, validate your design or even can help to pick the best trade-off for a given architecture. In a old post I was showing how a modeling tooling having support for viewpoints is powerful in this regard. The next demo is showing you how the developer or analyst, can then leverage the tooling definition (click again !) :
Now you described everything and you're quite happy with the result, why not using this information to help you produce code ? As soon as the modeling environment is linked to the development tasks with code generators, the model is not going to be deprecated, it will be used by the team to get the tedious work done.
Moreover when the environment provides you navigation from your code to the model, then to the code, and support for customizing anything in the generated code, then the tool is no more a burden, but a relief. (yet another demo !)
It's been 3 years now since I arrived in Obeo, and every tool we developed since then has been designed following this motto : "Having more control, not getting in the way and providing value to the developer."
So far I'm quite happy with the results :)
ps : thanks to Jérôme who did the démo
And then you fulminate against this tool which should help you and which is not,it's just another burden placed on you to provide this documentation nobody will ever maintain or even read. Is that what modeling is about ?
Life as a software user is often harsh, especially as you have, most of the time, no control at all on the software you use. As a developer it's even more difficult as you have an idea on what's going on behind the scene, and not having control is something you just can't handle now that so much open-source products are providing you this power.
If you had control on your tools, if you could adapt it or even easily define it, then you could focus on useful things. Modeling can bring it back to you, not modeling like in UML Modelers, modeling like formalizing your domain model as a way to capture your though or your coding tasks.
A Model doesn't have to be high level, a model doesn't have to provide as much information as your source code, a model is just here to help you answer questions about what you're doing.
If you can't say, for a given model what kind of questions it's helping you to answer, then your model is just not relevant, it's not a model, let's call that boxes with edges.
And now let's take a small example, you wants to define a software using components which are providing services, then you wants to assign these "logical" components to Eclipse plugins, here is a model definition you can come up with :
From an instance of a model you can answer the
questions : how is split my application ? what services are provided and required by who ? And how these components are
linked to the Eclipse plugins I'm coding ?From now you can either capture an instance and start working thanks from EMF Dynamic support , or specify a tooling to ease this capture. If a diagram is a good representation for your problem, pick it, if it's not, pick a tabular, tree or even textual representation.
The following demo describe a tooling specification (click on the image! ) at the top, the specification, at the bottom, the tooling which is dynamically adapting itself to the specification.
Modeling itself is useful to organize your though, validate your design or even can help to pick the best trade-off for a given architecture. In a old post I was showing how a modeling tooling having support for viewpoints is powerful in this regard. The next demo is showing you how the developer or analyst, can then leverage the tooling definition (click again !) :
Now you described everything and you're quite happy with the result, why not using this information to help you produce code ? As soon as the modeling environment is linked to the development tasks with code generators, the model is not going to be deprecated, it will be used by the team to get the tedious work done.
Moreover when the environment provides you navigation from your code to the model, then to the code, and support for customizing anything in the generated code, then the tool is no more a burden, but a relief. (yet another demo !)
It's been 3 years now since I arrived in Obeo, and every tool we developed since then has been designed following this motto : "Having more control, not getting in the way and providing value to the developer."
So far I'm quite happy with the results :)
ps : thanks to Jérôme who did the démo