home babyUML

BabyUML:
A laboratory for exploring
a New Discipline of Programming
(previously the IS21C project)

The goal of the BabyUML project is to increase my confidence in my programs. The keywords are simplicity and leverage. Simplicity helps me to think clearly and a reader to understand and audit my code (my peers are very good at catching my blunders). Leverage lets me say more with less. The end result shall be a new interactive development with appropriate languages and tools for supporting high level abstractions.

The essence of object orientation is that objects interact to produce some desired result. Yet current programming languages are focused on individual objects as they are specified by their classes; there are no explicit language constructs for describing communities of interacting objects. In BabyUML, I will zoom back from the individual objects and let my code specify the community as a whole with abstractions taken from OOram role modeling and the UML concepts of collaboration and interaction.

The conceptual foundation for BabyUML is now established. It is called the DCI paradigm: Data-Collaboration-Interaction. (Formerly DCA). A presentation was at the JAOO conference in Aarhus in September 2007. This is a .ZIP-file. JAOO-trygve.ppt is the talk itself.

Things your motherdidn't tell you about architecture and GUIs

An earlier version was at the ROOTS conference in Bergen in april 2007.

An article on the use of roles in programming is a submission to the Roles’07 workshop that was co-located with ECOOP 07:

Roles and Classes in Object Oriented Programming

An interim report on the BabyUML project was published by Nova Scientific Publishers as a chapter in Klein (ed): "Computer Software Engineering Research";2003; Chapter 2 - Programming with Roles and Classes: The BabyUML Approach; pp. 45-88; ISBN: 1-60021-774-5. The submitted chapter can be found at

Programming with Roles and Classes; the BabyUML Approach

I am riding a dear hobbyhorse in this short commentary in the same book:

The Case for Readable Code.

Some other publications:

MVC and DCA: Two complimentary system architectures.
(Model-View-Controller and Data-Collaboration-Algorithm)
A Java program presented at JavaZone 2006 that explores two powerful BabyUML object structures:
      JavaZone talk on Sept. 13, 2006: 09-JavaZone/talk.ppt
      Demo program discussion (Final Version) 09-JavaZone/mvc-dca.pdf
      Java experimental program: 09-JavaZone/BabyProject-3.zip
      Demo: Activity network demonstration applet.

An invited "expert voice" article for the Springer Journal on Software System Modelling:
The BabyUML Discipline of Programming
where A Program = Data + Communication + Algori thms

Final slides for ECMDA 2005 keynote (.ppt)

The BabyUML vision:
Empowering People with BabyUML: A sixth Generation Programming Language. Opening talk, ECOOP 2004, Oslo (.pdf)

Other:

Reverse Engineering of the Squeak/Tweak Islands construct and why it is not suitable as a foundation for BabyUML components (.pdf)

Latest walk-trough of demo code (.ppt)

Latest demo code report (.pdf)

Latest Squeak image. (Work in chaotic progress, not recommended for anything) (Squeak, .zip)

BabySRE: Squeak Reverse Engineering: Three tools making the Squeak objects visible and tangible (.pdf)

A good tool is an artifact that augments its user's might. A good tool is also a pleasure to use. Christopher Alexander discusses the concept of a quality without a name in relation to architecture. It could equally well be applied to information systems. Looking back on my almost half century in the business, I realize that the thrust has been on making tools for ordinary people. Particularly if we remember the oft forgotten fact that programmers are also ordinary people needing good tools.

A lifetime with computers culminates in my current project. I call it BabyUML. Deep down, it's all about giving information systems the quality without a name. I have always believed that people should be foremost in our minds when we design systems. The BabyUML goal is to make programs readable so that we can master them.

1973 marked the end of an era and the beginning of a new in my career as a computer programmer. The first era culminated with me writing the last program of a series that gave me a comfortable feeling. The new era came about because we moved from stable, closed systems to continuously changing, open systems. New problems, new challenges. I have still not mastered them; I still cannot build a significant program that is “so simple that there are obviously no deficiencies”.

There is a widespread belief that current software complexity is an unavoidable consequence of the complexity of the requirements and that we have to tolerate deficient software. I claim that this is merely a myth, and that our problems can be solved with adequate programming concepts, languages and tools that leverage the communication aspects of our systems.

BabyUML is probably an unreasonably ambitious project, but it is great fun. It builds on Smalltalk, Dynabook, UML, and most of the work I have been doing for the past 45 years. Its goal is to surmount a number of problems we often find in current mainstream applications:

• Problems with programming languages. "UML is what the programming language designers omitted to include in their language." BNF is inadequate as a metalanguage and must be replaced by something much more powerful, perhaps a variant of MOF. I propose an executable and sophisticated program model that people can access in different ways depending on their interests, skills and tasks. This model will support different languages and even different execution models. It is an object model with objects representing user information, application programs, program models, metamodels, and meta-metamodels. We start with a merge of Smalltalk and UML.
• Problems with continuity. Currently, the life cycle of a typical application is "write source - compile - install - (load - run - stop)...- uninstall. This is hopelessly inadequate. A different, and more promising model is the idea of a universe of objects that exist over spce and time and where objects appear and dissappear as required. The universe includes all information of interest, even the programs. The information space is continuous in both time and space. The BabyUML objects over time and can be interchanged/accessed across space. (The current BabyUML image is a Smalltalk image that is a starting point started its execution around 1972!).
• Problems with understanding. Many mainstream applications are unfathomable. I suggest that systems must be designed to support an explicit user mental model to give users the mastery of their tools. I further propose that the top level models should be object models. The users' modeling language should be a part of the developer's programming language.
• Problems with ownership. I believe systems should be decentralized and split into components and that these components should be owned and controlled by the relevant departments in the enterprise line organization. A distributed object model can support distributed ownership, but the problem belongs mainly on the human/organization level.

It is hard to do sums with roman numerals. It is equally hard to build communicating systems with current tools. BabyUML is a laboratory for experimenting with new programming disciplines and languages. The laboratory is used to explore the specification of hierarchical structures of collaborating components and to explore how to make the component essence explicit and visible, hiding the details within the component members. The goal is to disprove the complexity myth and to help me feel comfortable with my future programs. The means is to harness three generations of programming technology into a coherent whole:

• Communication between component member objects is coded as collaborations and interactions.
• Member objects and their relationships are defined in a three schema architecture:

1. A conceptual schema defines all legal member structures.
2. The implementation constitutes the implementation schema.
3. The component collaborations constitute the external schemas. The collaboration roles are mapped to the conceptual schema through queries.

• Finally, object behavior is coded as methods.

I attack the challenges of this project from three angles:

• Top down - by writing and talking about it
• Bottom up - by implementation experiments using Smalltalk
• Sideways in - by working with UML and Smalltalk

I have two goals:

• A feasibility demonstration through a convincing implementation experiment.
• A technical report that may ultimately result in a book

This is too much work for one person, and I hope that other people will identify interesting inssues and dig into them..

Here is some relevant material:

Last updated 2005-11-11