[Uml-devel] Wish for redesign

[P. Fleury]

Andrew Sutton wrote:

>On Thursday 24 October 2002 16:26, Sebastian Stein wrote:
>  
>
>it seems to me that most of the people using uml (or even considering to use 
>uml) are software engineers or architects or what have you, and most work of 
>this variety (sorry to say) revolves around M$ world. given that most people 
>doing serious design work are writing for windows, why build a product for it 
>on linux?
>  
>
If you work for desktop software, M$ is probably the choice. If it is on 
embedded software, which is growing, then the win32 platform is not the 
de facto choice, and linux is still a good candidate if the hardware is 
more than a single-chip 8 bit computer. And not every piece of software 
is of the size of COM+...

>then, if you think about the typical linux developer (kde, gnome, etc.), they 
>don't really paint the greatest picture of "user-ship". alot of people 
>working on this stuff focus on the little picture or have this hack first, 
>redesign later. too many people working on open source take too much pride in 
>the term "hacker". personally, i think its one of the more disappointing 
>aspects (side effects?) of the open source movement. i mean really, how many 
>linux projects have well documented designs - much less diagrams of those 
>designs. i'm not knocking open source here (if you're wondering), and i'm not 
>trying to play some elitist role - its just kind of disappointing to me.
>  
>
Good documentation, easy to find information is what makes the 
entry-level to an open-source easier. I think Umbrello is on a good path 
here.

>given these arguments, we're trying to build a product for a group of people 
>who - in many cases - abhor the idea of even slightly more rigorous process 
>(since design is a phase of almost all development processes). actually, alot 
>open source developers (hackers) people are really repulsed by the idea of 
>writing down, god forbid, requirements, much less following that by a real 
>design.
>  
>
I do not think so, however, the requirements may be gathered on a 
web-page or in a mail-list archive. Lack of easy to exchange 
documentation is of course not helping, and Word files are still a pain 
to read on linux. Javadoc, Doxygen and these tools have been designed so 
that the effort of documenting code is the least possible. And see, more 
and more open-source is documented that way. For design docs, it maight 
well be the case too. Hence, following standards (XMI, MOF, etc, all of 
which is not too clear to me :-) will make this exchange of information 
the more easier.

>so we're building this software engineering tool (which is what UML modellers 
>are - CASE (Computer Aided Software Engineering) tools) for a platform that 
>is being developed by people who, for the most part, seem to reject a greater 
>part of the disciplines of software engineering - particularly those dealing 
>with process. i don't blame them, it can be tedious.
>  
>
Design and documentation are, to me, mostly about communication: between 
people and machine-human. Between people means there should be an easy 
way to exchange the documentation (again the de facto MSWord example), 
so XMI is a good move, linking into documentation (KOffice?) would be 
another such step. Between machine and human, this is the 
importing/exporting from/to source. First is to analyze, second is to 
help turn a design into source.
To get a first grasp at Umbrello (at the time uml), the most useful 
things I had seen was the classbrowser of KDevelop. If I can get the 
same kind of idea from an unknown piece of software, that will hook me 
up to such a tool.

>to paint the picture darker, assuming we do attain even the smallest amount of 
>usership from the open source development community, the learning curve for 
>UML is kind of high. i'm seeing that in my advanced software engineering 
>class. people who've never done it before are flailing, people who have stay 
>afloat. that means, we'd be responsible for educating our users as well - 
>assuming we know what we're doing (which, lets face, isn't always the case ;)
>  
>
Well, educating a community takes some time. But look at the designs od 
KDE, Qt, STL, and others. If you want to write open source, you will 
face these sooner or later. And you will have to use them. So you learn, 
and then you know about a few patterns already. Applying these to your 
own piece of software should be the logical step. Many projects talk 
about redesigned/refactoring. And I think you can learn UML quite 
gradually. Learn class diagrams, then object diagrams, then sequence, 
then state, etc. And, well, school can only last for so long, then at 
some point, you need cash :-)

>3. How can we get open source developers to use it
>
Push to have it in the "standard" KDE distro. So people have it, even if 
they do not know it ... And push to make it a default  tool in KDevelop.

>4. How can we reduce the learning curve of UML?
>  
>
Have a few easy tutorials, either in the Umbrello doc or on the 
web-page, or both. I think the UML notation is fairly easy to grasp, the 
modeling and design patterns is a whole other story...

>5. How can we reduce the "process association" affiliated with designing 
>software as opposed to writing software. that is, can we fool hackers into 
>adopting even the most trivial of processes for writing open source software?
>
>6. How can we make the application more available (easier to use) for hackers? 
>Would this affect its full range of capabilities for professional software 
>engineers?
>  
>
I think if it helps getting a grasp of the complexity of the software, 
then it will be adopted. When having 15 C++ files, it's ok for lacking 
and/or sloppy documentation. When it's kdelibs, you better get it in 
some parsable format (Doxygen). Then you can auto-extract it, and you 
have it grouped in several ways illustrating the relations between 
things. It's more human-readable.
That's an argument for importing of source, but also for a common core 
for UML, which enables one to write "modules" for things like verifying, 
refactoring, code-generation, smart diff for XMI models, etc. These are 
a big help, as they remove tedious and mechanical work. As did doxygen, 
autoconf, automake, makedepend, etc.

>7. I can't think of any more and friends is on. mull it over.
>
>  
>
Me neither, it's Friday,  so have a nice weekend!
--Pascal