The BabyUML project started with the need for a new programming paradigm and the assuption that this paradigm could be based on UML. This assumption did not prove fruitful, and there was no UML left when the project reached its goal in 2008. The new DCI programming paradigm had been developed and was illustrated with several examples together with an experimental BabyIDE interactive programming environment. This marked the fulfillment of the BabyUML goal and the beginning of the maturation of the DCI paradigm. The early results are very promising and a growing community centered around its mailing list at email@example.com is taking DCI forward.
I am in my 81st year. My great great grandfather planted an apple tree when he was 93. He was very particular about the kind of apples he wanted. His family pointed out that it would be 10 years before his chosen tree would give its first fruit. My great great grandfather could not see the relevance of this argument. So I follow a family tradition when I happily continue working with DCI together with the DCI community. I will post any results as they appear. Just in case.
I want increased confidence in my programs. I want my own and other people's programs to be more readable. I want a new discipline of programming that augments my thought processes. I create and explore a possible discipline in my BabyUML project. I select, simplify and twist UML and other constructs to demonstrate how they help bridge the gap between me as a programmer and the objects running in my computer The key is to let my code explicitly specify three important aspects of my programs: What are the objects, how are they linked, and how do they collaborate to realize their goals. The goal was to close the chasm between the compile time classes and the runtime objects.
The BabyUML project is completed. The expected legacy from UML did not materialize. The new results have their roots in OOram and Traits; there is almost no trace of UML. It is time to move on to a new project. It is called the BabyIDE project.
I created the Model-View-Controller pattern as an obvious solution to the general problem of giving users control over their information as seen from multiple perspectives. MVC has created a surprising amount of interest. Some texts even use perverted variants for the opposite purpose of making the computer control the user. I have collected some relevant papers including my original technical note from Xerox PARC.
Roles are about objects and how they interact to achieve some purpose. For thirty years I have tried to get them into the into the main stream, but haven't succeeded. I believe the reason is that our programming languages are class oriented rather than object oriented. So why model in terms of objects when you cannot code them? And why model at all when you cannot keep model and code synchronized?
My current project, BabyUML, binds all together into a composite code using different languages to code different aspects of the systems: algorithms coded as classes + declaration of semantic model + coding of object interaction as role models/collaborations.
See almost any of the documents in this site or read my book about role models. It is now out of print, but you can download a draft version here 1996/book/book11d.pdf
The goal of most of my work throughout my career has been to create systems that optimally combine human insights, experience and imagination with the computer's speed, accuracy and capability for managing large sets of data. The perspective has been to view the enterprise as a sociotechnical system and to firmly anchor the computers with their data and programs in the line organization rather than in some staff function such as an EDP department. The logical consequence is an IS architecture of distributed communicating components.
The UML definition document specifies a set of well-formed object structures. Each of these structures is a valid UML model. I wanted to see at least a few of these objects and implemented a rudimentary UML Virtual Machine. Somewhat to my surprise, the objects were very similar to Java, Smalltalk, and XML objects describing the same phenomenon.
I created some package and class inheritance diagrams for my own use. I keep a large print on my office wall. It is covered with a plastic sheet so that I can use it as a whiteboard. I find it very useful and well worth the effort to create it.
This web site has existed for many years and evolved whimsically, like many a long lived application program. It was now time to reorganize and I have chosen the only principle I know that works: Sort by year. The files are presented in a table with title, keywords and a short abstract. Enjoy.