Since I am going again through my UML course, I am reading again and thinking again about use cases, layers, UML, classes, objects and GUIs stuff.
My main objective is to find a way that I can show in simple examples how to model a small problem using UML and then go and implement this design into a program respecting a clear separation of concerns and keeping a reasonable object oriented model. The problem is always the GUI.
I have been looking at some XUL frameworks, but they are not object oriented at all.
However, I have found two interesting frameworks to check:
Both of them construct a GUI from a domain model.
Obtaining a design with separation of concerns puts the GUI code "close to" the GUI code and the model code "close to" the model code. Patterns such as MVC do that. However, those patterns (even PAC) end up with a lot of data flowing through the objects, contrarily to what would be expected in a nice OO design (I mostly do agree with most of Holub opinions as expressed in his Javaworld articles). A nice OO design will ask for putting code "close to" the data it needs to execute.
I think that the main problem as of today is with current programming languages and the idea of "close to". Current programming languages rely for their design in the concept of file. It should be possible to express a program or system as a set of files. If two things appear in the same file, it means they are somehow "mixed" or "close to" each other. Think of the ".h"-".c" stuff in C, or the "1 class"-"1 file" java stuff.
Usually, in any reasonable programming language, the environment for a piece of code is determined by the set of "files-packages-modules" that are "included-imported".
This is a kind of 1-dimensional dependency relationship that allows us to structure our code into a "package dependecy tree". However, there is no possibility that the same class is present into several packages. There is no possibility (in the sense of the programming language making it simple) for a package to export several different APIs for its usage by different kinds of users. There is no direct structuring of the packages (in Java, classes import classes, but no dependency between packages can be expressed).
I think that, in order to organize code in a way that I will be proud to show my students I will need a programming tool (not language, the concept of language is too tied to the expression of programs as a set of words instead of as a set of diagrams for example) which allows me to express these ideas. A tool that allows me to describe the system architecture and the go on and fill in the details. I have to think of a way of structuring the following fundamental concepts into a software system:
- Layers
- Classes
- Packages (or modules)
- Interfaces
- Objects
so that every piece of code is located and has dependencies exactly on what it needs.
I think that the only reasonable result is that code resides in a database where it can be accessed from several perspectives and is edited by a tool instead of residing in a set of files and being edited by a (however advanced) file editor.