Miscellaneous files from 1970 and onwards

Rickard Öberg: DCI in practice
Øredev 2009
2009-11-06

Video at http://oredev.org/videos/dci-in-practice

Jim Coplien: The DCI Architecture: Supporting the Agile Agenda in your Software Architecture
Øredev 2009
2009-11-06

Video at http://oredev.org/videos/the-dci-architecture

The vision of object-oriented programming was to capture the end user mental model in the code. Until recently, programming languages weren't able to do that. With DCI, we can now use most professional programming languages to achieve the object vision—which is curiously similar to the goals of Agile software development. We now can capture both domain structure and structures from user experience analysts. Learn how in this seminar—and learn more in Rickard Öberg's associated presentation!

DCI: Re-thinking the foundations of object orientation
and of programming
Øredev 2009
2009-11-06

Video at
http://oredev.org/videos/dci--re-thinking-the-foundations-of-oo

Sometime in the last 40 years, object-oriented programming got lost. Instead of producing code that can be understood by reading, it produces code that can be explored only by tests. In this talk, the inventor of the DCI (Data, Collaborations, and Interactions) architecture will describe its motivations and origins: how it can produce source code that maps directly from end user mental models, making it easier to understand and evolve.

Common Sense of Object Oriented Programming
A technical report explaining the basic concepts in some detail.
2008-09-11

A report on the first release of BabyIDE (41pp)

• read section 1 if you want to find out what it is all about
• read section 2 if you want to find how we use the DCI paradigm to describe the object interaction process visualized in the BabyShapes4 animation (shown in the above movie.).
• read section 3 if you want to see how BabyIDE lets you work with a program such as BabyShapes4 in different perspectives.
• read section 4 if you want to know more about the DCI paradigm.
• read the rest of the report if the previous sections made you want to see it all.
• read appendix 1 to learn the terminology used in this project.

The Case for Readable Code.
Klein: Computer Software Engineering Research;Expert Commentary; pp. 3-8. Nova Science Publishers, New ork, 2007; ISBN-13: 978-1-60021-774-6.
http://heim.ifi.uio.no/~trygver/2007/readability.pdf

Readable code is the key to correct and maintainable programs. Pure class oriented programming does not scale and tends to lead to code that is hard to read. Extensive subclassing is an effective obfuscator and should often be replaced with delegation. A strategy of divide and conquer can be achieved with suitably structured components. This opens a path to readable, object oriented programs. Pair programming and, even better, peer review are work processes that help getting it right the first time.

Programming with Roles and Classes: the BabyUML Approach.
Klein: Computer Software Engineering Research;ch. 2; pp. 45-88. Nova Science Publishers, New York, 2007; ISBN-13: 978-1-60021-774-6.
http://folk.uio.no/trygver/2007/babyUML.pdf

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. Leverage lets me say more with less. The end result shall be a new interactive development environment 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 classes and let my code specify the roles that objects play in collaborations and interactions.

My first presentation of the IS21c project. Features a demo of the meta-layers with an object, its class, and its metaclass. All as objects simultanesously on the screen. Change a method in the class, and the object immediately changes behavior.

I needed to see the proposal's class herarchy. This is not obvious from the text, since the class definitions are spread out over a multitude of packages and diagrams. The use of PackageMerge did not help any. So I have drawn a class diagram for the structure part of the June 2003 version of UML superstructure.  The diagram also shows the package diagram. The diagram helps me get an overview of the core semantics and I post it because it might help others. I would be surprised if there weren't any errors. In any case, the FTF is currently busy polishing the classes and packages.

The UML metamodel defines the abstract syntax of well formed model. A UML model is a structure of interrelated objects that conform to this syntax. I am experimenting with a UML Virtual Machine where anything and everything of interest exists as objects in this VM. Things in the application domain exist as objects. Classes and metaclasses exist as objects. Metametaclasses exist as objects. An Instance object is created by sending the message new to a class object. A class object is created by sending the message new to a metaclass object, etc. up the instantiation chain. I discuss three, disjoint structures in this UML-VM:
• Collaboration structure. How objects are interconnected and how they interoperate.
• Subclass/superclass structure. How classes inherit features from other classes.
• Instantiation structure. Every object is an instance of a class. Every class object is an instance of a metaclass, etc.

A Smalltalk world is a structure of interrelated objects that reside in a Smalltalk Virtual Machine (VM). Anything and everything of interest exists as objects in this VM. Every object is an instance of a class. So is every class and metaclass object.

The analogy to UML is striking. A UML model is a structure of interrelated objects. I have found I cannot see through the details of a UML Virtual Machine (UMLVM) without actually writing one. It seems to me that this will be well worth while because it will illuminate the principles underlying UML.

I propose that UML 2.0 semantics and notation is clearly separated into two, clearly distinguished, model perspectives: The Class Perspective (CP) and the Role Perspective (RP)

Business information systems are becoming far too important to be left to the computer experts. Top management, marketing experts and the user community in general must be actively involved in shaping their future information systems. This means that they must not only know how to operate their current systems; they must also understand how the systems are structured.

It is never easy to make the complex appear simple without lying. What is needed is a common language that lets the computer professional present the nature of an information system in terms that are meaningful and interesting to the user. And the presentation must be complete and true on the chosen level.

The communication-centered architectures represent a new paradigm that subsumes the older storage-centered and computation-centered architectures. The main advantages of the new architectures are unlimited size and complexity, distributed ownership and control, and a higher level of reuse through components. Architectural themes covered include "The connected society, a new system paradigm"; "Separation of concern with role models, responsibilities and interfaces"; "Powerful reuse with components"; and "The component developer - a new layer in the value chain."

A Collaboration describes how a number of objects work together for a common purpose. A CassifierRole is the named specific position of an object participating in a Collaboration. If there can be more than one object corresponding to a given ClassifierRole, one of these instances is selected to represent them all. The other instances are constrained to behave in a way corresponding to the selected representative.

Dataindustrien har lenge ønsket og lovet å gjøre riktig informasjon tilgjengelig der den behøves, når den behøves, og på en hensiktsmessig form. Vi vil her fokusere på problemer der beslutningstakere og andre brukere utfører oppgaver som best kan støttes av spesialiserte dataverktøy. Disse verktøy utgjør grensesnittet mellom brukerne og de bakenforliggende informasjonstjenester. Vi tilbys et morass av teknologier og produkter som skal hjelpe oss å lage slike systemer.

We see all enterprise information as a huge system of loosely coupled components. Separation of concern will be essential for mastering its complexity. We apply three perspectives on the enterprise:

• People use information in their business processes
• Information services manage this information
• People perform tasks using information tools

This is a deeply technical foundation for object oriented modeling. It makes a contribution to the problem of handling complexity due to the size of the modeling task. The subject is highly relevant. Modeling of large compex systems is central to development of computer systems and is not easy.

The role modeling techniques presented are novel contributions and very interesting. The treatment of overlapping states and analysis of legal statespaces is original, and the proposal for fair and unfair action is novel, amongst many other things. The author presents the ideas in a convincing manner and gives a number of good examples of the usefulness of role modeling. The chapter on composition of role models and virtual roles for manipulating conceptual models is also very convincing. (The original idea of role modeling is due to Trygve Reenskaug and Else Nordhagen, but the current dissertation extends the ideas and gives them a theoretical foundation that was missing from the earlier, largely intuitive work.)

The parts on modeling behavior presents a number of ideas for modeling the dynamic behavior of objects and extends work by David Harel and others. In addition to handle the 'state explosion' problem, problems regarding 'composition of separately developed descriptions' and 'separation of concerns' are handled. A number of interesting techniques for analyzing behavior descriptions are presented including deadlock and livelock.

The OOram Meta-Model.
A proposal in response to OMG OA&D RFP-1
8 January 1997 (103pp)
.PDF

Published as OMG document
ad/97-01-15: Joint Submission on OA&D RFP1 by Taskon A/S, Reich Technologies and Humans and Technology [Trygve Reenskaug, Taskon A/S] (Contact: Mr. Juergen Boldt)

Highlights the application of frameworks to the creation of a software production facility for Intelligent Networks. We define a framework as an encapsulated solution to a recurring problem. The solution consists of role models designed for reuse through synthesis, accompanied by an ensemble of classes designed for subclassing.

(NOTE: This development did not make it into the OOram Professional product)
In the OOram methodology, we distinguish between forward and reverse engineering. In forward engineering, we start with a problem and describe its solution in a series of successively more elaborate models. In reverse engineering, we start with an implementation and develop one or more System Design models that highlight important aspects of the implementation.

Working with objects.
The OOram Software Engineering Method.
Manning/Prentice Hall 1996. ISBN 0-13-452930-8.
Out of print, but is still available from some bookshops including Amazon as of January 2010.

You can alternatively cownload the last draft before publication. It has not had the benfit of the copy editor's corrections and improvements, but its substance correspond closely to the printed book. .PDF

"The first method that deals realistically with reuse, and one of the few that comes close to describing what I do when I design." (Ralph Johnson, University of Illinois)

Ian Graham voted this book "One of the Three Best Books" of 1996/97. (JOOP September 97):
"This book brings the OOram method before the public, along with its most significant contribution to object-oriented software engineering: role modeling. It also provides plenty of sensible advice for developers adopting object technology, based on the author's evident experience and understanding of the the technical intricacies and human aspects of software development. However, it is a deeply technical book and will put off readers who are not already familiar with an object-oriented programming language."... "As a technical contribution it should become one of the classic texts within the field. The role modeling ideas will undoubtedly influence other object-oriented software engineering methods and I think we will see them quickly adopted in the now emerging third generation methods."

Egil P. Andersen and Trygve Reenskaug: System design by composing structures of interacting objects.
ECOOP '92
DOI: 10.1007/BFb0053034