elementary-dev-community team mailing list archive

[Craig <weberc2@xxxxxxxxx>]

On Thu, Sep 27, 2012 at 5:03 AM, Sergey "Shnatsel" Davidoff <
sergey@xxxxxxxxxxxxxxxx> wrote:
>
>  Model centric programs boasts high reusability, efficiency, portability,
>> and simplicity (which translates into reduced maintenance, testability,
>> changeability and easier understandability) all for the minor cost of
>> prolonging the code producing phase in favor of a longer design phase.
>>
> In short, parties interested in pushing UML claim that it's a cure-all.
>

To be clear, I'm not talking about UML specifically. I'm talking about
model-centric development. UML is just the most noted means of representing
model based design. It's just a higher level of abstraction.

> It's implemented all over, and most developers are probably trying to
>> implement it subconsciously.
>>
> Many companies use UML tools to make/edit a system model and those tools
>> will generate code from the model abstraction in much the same way that a
>> compiler efficiently converts a high level language into assembly language.
>>
> "Many companies do this" is not an argument. Many (or rather, most)
> companies make UIs utterly inconsistent with the rest of the system to make
> them "better"; most companies write proprietary software, many companies
> use CVS for revision control, etc. We're not taking up any of this.
>

It wasn't intended to be an argument. Daniel asked who is using it. I'm
noting that it's not an entirely new idea. People have been making model
based designs for years. Only now is its potential being realized. As the
value of quality software has become increasingly quantifiable, employers
have been demanding employees who are familiar with model based design,
which is why schools are rapidly adopting UML into their CS curriculum.
Furthermore, are you implying that model-based design somehow lends itself
to a particular quality of UI design or version system?

>
> The analogy with compilers or other higher-level wrappers is not true.
> With high-level wrappers like Vala all you need to know is how to work with
> the wrapper, and the machine does the rest. With UML you have to know both
> UML and the programming language and work with both in one project. Is it
> worth to raise the entry barrier by requiring to learn/know not only GTK
> and Vala but UML too?
>

It is true. UML can be compiled down into machine code without manual code
manipulation. However, as I don't know of any OSS UML compilers and, except
for the crazy expensive industry compilers, the technology really isn't
there to compile it down efficiently anyway. However, the analogy works.
It's widely considered "good programming practice" to program in high level
terms. It's considered beneficial to abstract away the unnecessary details
to enable the programmer to focus on the task at hand. If you espouse
object-oriented programming or programming in a language other than
Assembly or machine code, model-based development is logical. With
object-oriented programming in particular, the subconscious objective is
typically some sort of a model based abstraction anyway--I'm simply
proposing using formal, conceptual tools to help you reach that objective
quickly and accurately. I'll write what this looks like more specifically
when I have the time.


>
> The other problem with UML is that it's a kind of documentation describing
> the code. And we all know how much developers hate updating documentation.
> The diagrams will quickly become outdated and misleading, unless developers
> spend time on updating them, all the time.
>

It certainly can be a way of documenting the code. However, if you do your
work in a sort of rough-draft UML (edit your objects, states, and
algorithms via UML diagrams), you can quickly convert it to clean, accurate
code, and have the documentation to boot. I get the impression you think
I'm espousing a strict adherence to UML. I'm not. I'm talking about
employing it to the extent that it makes sense to suit elementary's goals.
Again, I'm working on a blog post that I hope will describe my vision more
fully. Until then, try not to jump to any crazy conclusions. Consider it as
a tool--try to understand what about it is useful and if any part of this
tool could benefit you.

But you're right--it will require some change and I don't expect everyone
to welcome it with open arms. I'm just asking you to wait until you've
actually heard my proposal before you get up in arms.


>
> And, most importantly, I doubt we would benefit from model-centric
> approach at all. Most elementary apps are simple and concise, and
> communicate over simple and obvious interfaces. We don't build any
> complicated systems or engage in system programming (yet). So for most of
> our apps using UML will be an unnecessary burden.
>
>
If Elementary apps are so simple that they never have bugs and never take
more than a week to program, then you're absolutely right--don't use a
model-centric approach. Anyway, as I mentioned earlier, Elementary Apps
already _are_ developed using a model-centric approach; however, you're
saying they are so simple that you can manage the model mentally without
putting it on paper.



> Considering the above arguments, the only way I see the possibility of UML
> adoption is creation of tools for visualizing existing code as UML and
> converting edits done in UML back to code; i.e. making UML diagrams:
>
>    1. strictly bound to the code
>    2. generated without wasting a lot of developer time
>    3. completely optional for usage
>
> This way it won't raise the entry barrier and won't burden applications
> that don't benefit from using it.
>

I've considered all of this and I believe I have a plan that will _lower_
the entry barrier for new developers and allow the Elementary higher-ups to
focus on high level concerns.

>  However, that is rather cutting edge and I don't think any good OSS tools
>> exist to automate the code generation process yet, so I'm espousing the
>> manual approach from which these code-generation tools are derived.
>>
> BOUML can generate C++ and Java code from UML and decode existing code
> into UML diagrams. Perhaps Vala support can be added to it.
>

I've only used BOUML for a brief time while I was in France. I don't
believe I used its code-generation feature; however, I doubt it will
produce code that is particularly pleasant to deal with. While I won't go
so far as to say it isn't an option, I personally wouldn't consider a
code-generation tool unless it creates extremely simple, efficient, and
comprehensible code.

In summary, I'm encouraging you to familiarize yourself with model based
software design (MBSD) while I prepare my proposal on how Elementary could
leverage it to its advantage. I'm asking everyone involved to keep an open
mind and evaluate it on its merits rather than shooting it down because
it's different.


>
>
> --
> Sergey "Shnatsel" Davidoff
> OS architect @ elementary
>