elementary-dev-community team mailing list archive

["Sergey \"Shnatsel\" Davidoff" <sergey@xxxxxxxxxxxxxxxx>]

>
> Again, apologies for lack of information. It's a design process, I
> suppose. It pertains primarily to developers.
>
Clarification for designers: this is "software design" aka "code
microarchitecture".

>  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.

> 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.

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?

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.

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.

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.

> 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.

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary