UML + some UI

[M-.-n]

Hey Mikke,

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

I like UML as a good way to think about it. It stays the best scrach pad for
code in my books. It doesn't make code run on garantee anything but it is an
excellent way to see the responsabilities you are expecting from each part
of you will code. At the same time you get pretty close to having a rough
documentation/reference later when you come back to the project so it's all
bonus. I don't think I even use UML properly in terms of notation, I've sort
of aquired my own way of describing things using those tools.. There are a
few free modelling tool like argos for example. Why not giving it a spin ?

http://argouml.tigris.org/

>Check out the model-view-controller pattern. Essentially, it's about 
>separation of data vs. display vs. modification code. Each of these
> fields get their own set of classes.

Definetly a good start. To that I like to add one more layer that is
influenced by J2EE's business object. Here's my classic structure - hasn't
really failed me so far:

1- Lowest level: the model. 

These classes only implement the data part ; what you play with and what you
store. To ensure to keep your program open, you don't implement *any* logic
in those class. They just 'hold' the data, save it, & restore it. To a
certain extend, that level can also _check_ for consistency in debug but not
inforce it

2- The wiring level: business objects

These class will implement higher level (and sometimes redundant) routines
that will alter the model class and inforce thier consistency. All
modification of the model should go through here.

3- The application level: implements the methods that will correspond to
user actions. Ideally, these should be chosen wisedly to provide
functionalities that can be called either because the user has done
something from the GUI, or it's been invoqued through a command line, a
server, anything. This is where the functionalities of the application take
form.

4- The user interface: The ui should mostly be restricted to presenting the
data in a coherent fashion, provide "entries" (menu, buttons, dialog) for
calls to the application level and manage all of the GUI specific task
(enable/disable elements,etc..)

Structuring the code in that fashion will also help you keeping your code
clean. If you use the easiest separation level (one root folder for each
level) you will KNOW something is wrong with your modeling as soon as you
need to include level 4 code in the level 3 layer. When that happens, think
again.

I would also recommend looking at the observable/observer mechanism which is
invaluable to help notification from a lower level to a higher one while
keeping the code independant.

The most important is to try to figure out how much the program will need to
evolve. If it is a one shot, it's not really a big deal (unless, you get all
pouncy like me about all the code you write, just 'in case'). But if it is
something that you will need to support over years, good thinking is really
a time saver in the long run

Hope that wasn't too long & boring,
Marc.


-----Original Message-----
From: music-bar-bounces at lists.music-bar.org
[mailto:music-bar-bounces at lists.music-bar.org] On Behalf Of Mikael Hansson
Sent: vendredi 10 avril 2009 17:58
To: Music-bar
Subject: UML + some UI

Happy easter everybody!

Just a small inquiry to our coders:


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?


/Micke
_______________________________________________
music-bar mailing list
music-bar at lists.music-bar.org
http://lists.music-bar.org/cgi-bin/mailman/listinfo/music-bar