UML + some UI

[Peter Korsten]

2009/4/10 Mikael Hansson <forums at deadmengods.com>

> To what extent do you use UML in your coding? (none, planning,
> documenting, codegeneration...)
>


The least amount I can get away with for documentation purposes, which is
usually activity diagrams, entity relationship diagrams, and whatever else
is needed to properly document a system for other people (and no, the code
does *not* speak for itself, especially my code). If I really can't help it,
it would include use case diagrams.

The people on this list who claim it's useless or that they don't use it or
that it attracts the wrong kind of people or that it will bring the
Antichrist in our mids have never done a proper course of designing with
UML, starting with stakeholder interviews and ending with a full design,
from which tools can generate skeleton code for you.

It *is* indeed very powerful, especially if you're not very good or not very
experienced at programming. In my case, I can just see the design in my
mind, draw a few boxes and arrows on paper, and know what interfaces and
classes to write. This is not what they teach you to do, but I'm not your
average kind of guy when it comes to programming.

This is not to say that I'm incredibly good (just quite good and quite a bit
too lazy), or that I wouldn't make mistakes (make them all of the time, and
I keep rewriting my classes and interfaces as the development progresses),
but it works for me, and my colleagues seem to think that I'm God's gift to
their programming department - when it comes to writing code, that is, let's
not go into all the rest. :)

>
> Any hints of what to think of when making a program with an
> easy-replacable user interface. I'm supposed to make a Library DB
> application with the option to add and remove different items, search
> for them with different keys, borrow and return by itemid.
>
> I'm supposed to do two interfaces, one textbased and one with Qt and the
> underlying code should be the same for both. The plan is to make an
> abstract LibInterface, which the other inherits from.
>
> How would you set up the connection between the app and the UI?
>

Ah, that's simple. You have your set of data, and you have operations that
you can perform on that data. These operations can be expressed as a couple
of methods, and those methods you can put in an interface. In C++ speak,
these would probably be pure virtual methods, or something like that.

In my view, the prescribed design is kinda stupid, because it appears that
they want to share code between the various interfaces, which sorta defeats
the whole scope of having different interfaces in the first place.

I was going to write something about events and listeners, but really,
inheriting both interfaces from some sort of base just won't work. It's
really trying to force a procedural way of thinking into an object-oriented
design. The interfaces trigger events, the events cause methods in the
interface that I mentioned before to be called.

If you really must stick to the design with an abstraction for both text and
GUI, you could consider abstracting the event model, but it would not be a
design that I would look kindly upon. Could you clarify this with your
teacher(s)?

- Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.music-bar.org/pipermail/music-bar/attachments/20090415/197dd77a/attachment-0001.html>