Miscellaneous files from 1970 and onwards

Title Keywords Comment

Rickard Öberg: DCI in practice
Øredev 2009

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

  In this session we explore how the DCI concepts can be applied in practice using the Qi4j Java framework and Composite Oriented Programming model. You will learn how COP concepts map to DCI, and how DCI can be implemented. We will look at a practical example, and how DCI helps making the code easier to read and also enables a number of powerful features.

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

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

Video at


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.


The Common Sense of Object Oriented Programming
  The second release of the DCI paradigm and BabyIDE. This report includes Squeak example code with comments. (74 pp.)
The DCI Architecture: A New Vision of Object-Oriented Programming (with James Coplien)
Recommended introduction to DCI

  An article starting a new blog: (14pp)
Comments on the essential mechanisms for DCI implementations
  Report. (5pp). For the systems programmer.

The DCI Paradigm Implemented in Squeak
  Report. (11pp). For the systems programmer.

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



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.
Things your mother didn't  tell you about architecture and GUIs
JAOO conference, Aarhus, September 2007.
ZIP-file: http://heim.ifi.uio.no/~trygver/2007/jaoo07.zip
---JAOO-trygve.ppt is the talk itself;
---The BabyProject directory is the Java demo program. .

  There are two roads through design. Both clarify user environment and needs. Use Cases capture examples of required operations, the imperative aspects of the requirements. Data Modelling captures the user's mental model; the declarative aspects. New operations can be added as new requirements are discovered; the Data Model acts as a constraint on what will be easy to do, what will be hard to do, and what will be almost impossible. This talk looks at software design through the eyes of Model-View-Controller. One implication of this perspective is that Data Model and architecture are as important to usability as are GUI design and Use Cases. The approaches complement each other well and are captured in the MVC architecture. This architecture is augmented with the DCAC paradigm that provides additional leverage by elaborating the inner details of the Model.

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.


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.

BabyUML An interim report on the BabyUML 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. 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.

Two System Architectures: MVC and DCA.
Talk directory. Bergen, 2006-04-26
Model-View-Controller and Data-Communication-Algorithm are two complimentary architectures for object systems.
The BabyUML Discipline of Programming
(where A Program = Data + Communication + Algori thms)
BabyUML BabyUML overview article in SoSyM "expert voice" 7 March 2006
 The Islands Implementation
Reverse Engineering with an evaluation of its suitability as a BabyUML Foundation

report 2005-09-20 (.PDF)
BabyUML BabySRE This article reports a reverse engineering study if the Islands implementation. It focuses on the object structure of a simple island in its environment and the process of creating a new island with two member objects. The result was a surprise to me and might be of interest to serious users and implementors of Islands and Tweak packages.
Towards A New Discipline of Programming
Talk at ROOTS, Bergen, 2005-04-27
BabyUML General overview
Workshop at ROOTS, Bergen, 2005-04-29
(.PPT) (.PDF)
BabyUML Presenting the code of the demo programs.
BabySRE: Squeak Reverse Engineering.
User manual with example.
BabyUML BabySRE is a package containing three tools making the Squeak objects visible and tangible. This is a technical note with a demo example. The package is also published on SqueakMap.
Empowering People with BabyUML:
A sixth Generation Programming Language.

Opening talk, ECOOP 2004, Oslo
Handout (.PDF)
Combine the algorithms of the 3rd generation languages with the information modelling of the 4th. Unify the technology of UML/MOF with that of Smalltalk and get:
> Systems that the users can understand , control and own.
> A world where the atoms are objects and the molecules are encapsulated constructs of interlinked objects
> A world where clearly delineated groups of objects are seperately owned and controlled.
> A world where the description of system design, code and run time objects all coexist and are part of the same program.
> A world where the execution lasts forever while different pieces are added and removed dynamically.
InformationSystems for the 21st Century

rOOts, Bergen, April 2004
Squeak slides/demo
is21c System development methodologies and architectures face several severe challenges. The premier goal of the IS21c project is to give users understanding, mastery and control of their information systems. The key to a solution is a user's mental model of his or her information and applications. The model must be explicit and tangible. Our focus is on the professional user in a business setting. We propose to let the models be tangible object models which the user can investigate, operate and otherwise manipulate.

(You can run the demo on a Windows system. Download the .zip-file, unzip, and execute IS21C-Squeak\Squeak.exe)
Object Orientation and Information Systems for the 21st Century
Understand – Explore – Master – Control
(Objektorientering og Informasjonssystemer for det 21. århundre) NIK Confenernce, Oslo 2003.
.PPT (in English)
is21c, vm

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.

Model Driven Development with the Emerging UML 2.0
rOOts 2003 Conference, Bergen. .PPT
components, mda Illustrating MDA/MDD with an example: Building a garden shed. Illustrating the UML 2.0 concepts of roles, classes, components and transformations.
Applications and Technologies for Maritime and Offshore Industries. Technological Significance of Early Norwegian Applications
History of Nordic Computing Conference, Trondheim, 2003.
DOI: 10.1007/0-387-24168-X_34
people Autokon, a CAD/CAM system for ships, was one of the first and most important early Norwegian applications. I describe the background for the Autokon project and its results. I specifically follow three technology threads that I have called Data-centred architectures, Mathematical modelling, and Personal information systems, where the last one includes distribution and component based architectures. I start with a brief history of computing.
Unified Modeling Language:
Static Superstructure

Composite Class & Package Diagram. April 2003. .PDF

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 Model-View-Controller (MVC ).
Its Past and Present

JavaZONE, Oslo, 2003.
JAOO, Århus, 2003

Abstract .HTML
Handout with draft pattern language .PDF
mvc, uml MVC was conceived in 1978 as the design solution to a particular problem. The top level goal was to support the user's mental model of the relevant information space and to enable the user to inspect and edit this information. The first part of the talk describes the original problem and discusses the chosen solution. The second part elaborates the original ideas and extends the scope to include current day challenges to the original goal. It is all summarized in a condensed MVC pattern language.
UML for beskrivelse av distribuerte informasjonssystemer
(Mogul Technology celebrates that it is 5 years since the introduction of UML with seminars in Oslo, Trondheim and Kongsberg, 2002)
uml, architecture, components Distribusjon betyr her langt mer enn å knytte sammen datamaskiner i et nett. Det innbefatter også distribusjon av ansvar og myndighet sammen med støtte for samvirke mellom virksomheter og personer. I dette foredraget tar vi frem behov som ennå er udekket og ser på om UML 2.0 kan hjelpe oss å takle disse behovene.
A Rudimentary UML Virtual Machine as a Smalltalk Extension
Working paper, Feb. 2002 .PDF
uml, vm, is21c

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 Rudimentary UML Virtual Machine.
Draft version of above, Jan 2002. .PPT
is21c, uml, vm

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.

Data, Metadata, Metametadata, and a UML Virtual Machine
(Talk, JavaBIN. Aug. 2002) .PPT
is21c, uml, vm OMG is promoting metadata in different forms. MDA, CWM, MOF and various dialects of UML are integrated through the use of metadata. This informal talk describes some of what I have discovered through my work with a UML Virtual Machine. (Also presented informally to OMG)
Architectural Design of Distributed Business Systems
(TOOLS Europe 2001 tutorial handout) .PDF .PPT
components, architecture, people This tutorial focuses on issues that are critical for the success of distributed systems development: Who are the users (actors)? What are their goals (use cases)? What are their processes? What are the system components? What are their responsibilities? How do they collaborate?
Perspectives on the Unified Modeling Language semantics
Invited talk to the 10th SDL Forum, Copenhagen, 2001
.PDF (Handout) .PPT (Presentation)
uml, components, roles The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system’s blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components.
The UML Collaboration,
a Standard for Role Modeling.

(OMG Technical Committee invited talk June 2000) PowerPoint
Modeling Systems in UML 2.0
A Proposal for a Clarified Collaboration

A proposal to UML 2.0 proposers and the UML Revision Task Force. June 2001. .PDF
uml, roles, people

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)

Modeling System Behavior.
The What, the Why and the How of the UML Collaboration

May 2000.
Draft article .PDF
Example Java Applet .HTML
Example code .ZIP
UML, roles, people

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 What, Why and How of the UML Collaboration.
(ROOTS 2000 tutorial) .ZIP
(TOOLS 2000 tutorial) PowerPoint
uml, roles The UML Collaboration is a powerful tool for modeling system behavior. We use it for many purposes ranging from enterprise modeling and designing distributed systems architectures right down to shaping the details of object oriented programs. We will focus on the practical application of the Collaboration and illustrate how it helps us create simple solutions to complex problems through separation of concern.
The UML Collaboration, a standard for role modeling.
Everybody Must Understand IT and Managers Must Master IT
(ROOTS 2000 keynote) .ZIP
roles, people  
Unleashing the Power of Distributed Enterprise Information Systems.
(TOOLS 1999 tutorial) PowerPoint
components, people, systems

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."

UML Collaboration semantics.
(A 1999 green(?) paper and a presentation. )
.PDF , .HTML , PowerPoint
uml, roles

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.

Designing the Enterprise A hierarchy of Goals and Means.
(OOPSLA 1999 Position Paper to the System Envisioning workshop) .PDF , .HTML
roles, people I explore the relationship between enterprise needs and solutions at the upper levels and the possible information systems and solutions at the lower levels. What I find is a goal-means hierarchy, where the specification of the computerized system can be considered as a fairly low level design decision.
Komponentbasert utvikling.
Den sanne objektorientering.

(GEILOO 99) PowerPoint ,
components Essensen i objektorientering er at objekter samvirker ved å sende meldinger til hverandre. Hovedstrømmen av objektteknologien har lenge fortrengt dette enkle bilde til fordel for en fokusering på programmeringsspråk, klasser og arv. Med den "nye" komponentteknologien slipper vi nå endelig løs objektenes sanne styrke: enkle løsninger på store problemer. Komponenter er gjenbrukbare objekter som er laget for å kunne settes sammen som Legoklosser. JavaBeans er for eksempel byggestener for brukergrensesnitt, mens Enterprise Java Beans er byggestener for bakgrunnstjenester. Begge er standarder som fokuserer på objektenes semantikk og grensesnitt; implementasjonen er usynlig og trenger ikke være i Java.
Visjoner og arkitektur for virksomhetens Informasjonsnettverk.
(Komponenttorget ‘99) PowerPoint
people, components, systems Organisasjon, oppgaver, informasjonssystem. De tre elementene må utgjøre et hele i informasjonsintensiv virksomhet.  Foredraget vil diskutere hvordan vi kan utvikle distribuerte informasjonssystemer med utgangspunkt i en virksomhetsmodell. Modellen forteller oss hvilke roller mennesker spiller i organisasjonen, deres informasjonsbehov, oppgaver og mål. Dette spesifiserer hvilke verktøy som behøves på den enkelte arbeidsplass, og hvilken informasjon som må lagres sentralt fordi den skal deles av mange og er av verdi for bedriften som helhet.
Distribuerte Systemer.
Viktigere enn vi tror, vanskeligere enn det høres.

(Komponenttorget ‘99)

people, models

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.

Collections in Java 2 (1.2) Compared to Smalltalk and Java 1.1.
(Oslo Java Society 4 Feb 1999.) PowerPoint , .HTML
programming This PowerPoint presentation discusses the new Collection classes of Java 1.2 (a.k.a. Java 2), comparing them to the corresponding Smalltalk classes. Java has now inherited much of the elegance and power of Smalltalk Collections. But it has also sacrificed the safety of hard typing; exceptions can be raised for illegal type casting anf for 'method not implemented'.
Unleashing the Power of Distributed Objects.
(Keynote, EDOC 1999)
PowerPoint and .DOC
Summary and references .DOC
people, systems, components Distribution of objects and components is more than a new technology; it is a new paradigm for thinking about, designing and implementing information tools and services in the enterprise. Closed systems are replaced by a vast world of co-operating objects. We only own and control a very small part of this world, the rest is owned and controlled by others. The talk will explore the new paradigm and the deep changes needed in enterprise organization, system architectures and personal competence if we are to reap its benefits and meet its challenges.
Lasse Bjerde, Arne-Jørgen Berre, Jon Oldevik: "
Describing a system from multiple viewpoints – using ISO/RM-ODP with OOram role modelling and UML
Workshop position paper, OOPSLA '98 .DOC
systems, mda This paper describes a methodology based on the ISO Reference Model for Open Distributed Processing (ISO RM ODP)[1-4] and the UML 1.1[5] notation. This methodology has been developed in the context of several projects concerned with methodology development: DISGIS [6], MAGMA [7] and OBOE [8]. ODP provides the overall framework and a foundation for describing distributed systems. UML provides a flexible notation for describing them. The methodology will be described in relation with experiences and specialisations within different application areas like geographical information systems, production-surveillance systems, finance and administrative systems.
Working With Objects. Analysis and Design of Corporate Information Systems.
(Handout. WOOD 1998) .PDF
Architecture, uml, roles, components

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
The Four Faces Of UML
(Presentation, May 1998) .PDF
uml, roles The Collaboration of UML version 1.1 represents a significant improvement/extension compared to the previous versions. This is particularly true for the definition of UML semantics; the UML notation does not yet reflect the full power of the language. This  presentation explores the different abstractions supported by UML 1.1. The main message is that one should choose modeling abstraction to suit ones needs, and that there is more to objects than what we can express with classes.
Egil P. Andersen:
Conceptual Modeling of Objects.
A Role Modeling Approach

Dr Scient thesis 4, November 1997, Department of Informatics, University of Oslo.
University of Oslo mirror .PDF .PS.GZ

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.

Working with objects:
Designing Distributed Systems for Reuse

OOPSLA 97 tutorial
handout .html, slides .pdf
roles Practical object systems are often very complex. We show you how to use the OOram methods to divide and conquer by separating out different areas of concern by identifying use cases and system activities. Each area of concern is described by a role model that shows the static and dynamic properties of a pattern of interacting objects. We also show how you can synthesize composite models by specifying how objects are to play several roles from different role models. This provides a key to systematic reuse through the inheritance of whole patterns of interacting objects. We finally show how the basic technology permits you to create large systems in small projects by a policy of systematic reuse of proven models and programs (frameworks).
Why Programmers Don't Use Methods
And What We Can Do About It.
(A column in ObjectEXPERT January 1997)
uml, people At a meeting in the OMG in Tampa, Florida, Ivar Jacobson stated that only 5% of the world's programmers use some method for analysis and design. The remaining 95% just write code. As a methodologist, my knee jerk reaction is one of horror. Can it really be that bad? In all mature engineering disciplines, formal design plays an essential part of their procedures. Isn't it time that software engineering grew up and made formal analysis and design a natural part of the software production process? In this column I examine this question and suggest that the answer is not as obvious as we like to believe.
Role Modeling Enters the Main Stream
(A column in ObjectEXPERT January 1997)
roles, uml  Conventional wisdom has been that the Object Modeling Technique (OMT) covers all needs for object oriented analysis and design. A new wisdom is now emerging: OMT needs to be augmented with an entirely different abstraction to cover the needs of distributed systems and system reuse.

The OOram Meta-Model.
A proposal in response to OMG OA&D RFP-1

8 January 1997 (103pp)

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)

  Taskon's contribution to the definition of UML 1.1 The immidiate result of this contribution was the UML Collaboration that buildt on part of OOram Role Modeling
Working With Objects
OOram Framework Design Principles

(OOPSLA workshop 1996) .PDF
roles, frameworks,

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.

Working with objects in the user interfaces
(A column in ObjectEXPERT, July 1996)
people, roles My first exposure to personal information systems was in 1970 when I heard Douglas Engelbart talk about computer augmentation; the idea that computers could provide an extension of the human intellect. A ship designer needs much more then a CAD system; he works with scheduling and building contracts, he interacts with shipowner and classification society, he deals with materials management and production technicalities. Inspired by Douglas Engelbart, I saw the dichotomy between personal information tools tailored to the tasks performed by the individual; and the business services dedicated to supporting functions such as accounting, scheduling, materials management, and design.
OOram/SRE Static Reverse Engineering.
(Draft User Manual 1996)
progr, roles

(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

people, is21c, mvc, roles

"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."

Working with objects. A three-model architecture for the analysis of information systems. Report 1995 .PDF is21c, roles The presentation discusses the merging of object oriented technology with the well established data base technology in a third generation client server architecture. The architecture is based on three kinds of models: information models, organization model, and tool model.
Industrial Creation of Intelligent Network Services
The following suite of reports contains a complete description of a simple example system for the creation and invocation of point-to-point telephone communication:
Set of project reports 1993.
Overview .HTML
roles, frameworks, architecture IN-Lab2 is a software laboratory was set up in 1993 for small-scale experiments with the design and construction of Intelligent Networks. The theme of this suite of reports is to study a simple, but complete value chain for this industry, and to to illustrate appropriate technologies for each of the levels of this value chain by means of a simple worked example. The example illustrates that object orientation in general and the OOram methodology in particular is exceptionally well suited as a base technology for this industry. The controlled reuse of proven components is a key to the effective production of an extensive and evolving offering of services.

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

O-O Design - Interaction-Oriented Design - Role Modeling - Object Composition This paper describes the outline of an object-oriented design technique denoted role modeling, emphasizing the ability to compose parts of a design. The purpose of role modeling is to achieve separation of concerns, allowing the designer to consider different aspects, or the same aspect at different levels of detail, more or less independent of other aspects of the overall design.
A role model represents the concept of a structure of communicating objects; each object being represented by a role to be ‘played’ in the context of this role model. Each role model is considered a design of a separate aspect of some overall design. Composition of designs is achieved by synthesizing roles in several role models, constructing more aggregated and specialized roles and role models.
Trygve Reenskaug et.al.: ORASS: seamless support for the creation and maintenance of object-oriented systems. JOOP 5(6): 27-41. October 1992 roles The group's report on the ORASS/OORAM project.
 User-Oriented Descriptions of Smalltalk Systems.
Byte Magazine, August 1981
is21c  From the Byte special issue on Smalltalk. More than twenty years of experience has shown us that a bad system design can never be hidden from the user, even by a masterfully devised user interface. 
an Example from a planningsystem.

Xerox PARC technical note May 1979.
is21c, mvc, roles The original MVC report. The yards of the Aker Group in Norway have been using network techniques and ad hoc methods for planning and control for many years. The systems used have not been satisfactory, and a new modelling tool was devised for the yards. The basic building block of this tool is considerably more powerful than the activity of the traditional networks. It is called a Component, and carries both its own data and the algorithms needed to manipulate them. Each Component represents an identifiable portion of the real world in the yard. The planning process consists of the Components sending information to each other (messages), and acting upon information received.
Xerox PARC technical note December 1979
is21c, mvc, roles Defines the MVC terms
A note on DynaBook requirements
Xerox PARC Technical note March 1979.
A scan of the first 13 pages out of this 32 page note.
people, systems All DynaBook users must have a good understanding of the functioning of their personal system in order to utilize it properly. Most users would like to go further: To build their own variations on top of whatever they have purchased. The claim of this note is to experiment with some structuring techniques and user-oricnted descriptions of Dynabook systems.

A scan of 13 out of this 32 page note. Introduces the notions of roles and nested components.
by Erik Holbæk-Hanssen, Petter Håndlykken, Kristen Nygaard
Extract from report,
Norwegian Computing Center, Feb. 1977

systems, is21c Erik Holbæk-Hanssen, Petter Håndlykken and Kristen Nygaard give this imortant definition: "A system is a part of the world which we choose to reqard as a whole, separated from the rest of the world during some period of consideration, a whole which we choose to consider as containing a collection of components, each characterized by a selected set of associated data items and patterns, and by actions which may involve itself and other components. "
Paper, IFIP Congress, Toronto, Canada, 1977
First published in the 1977 IFIP Proceedings.
Scanned by the author July 2003.

is21c, roles, uml, mvc The yards of the Aker Group in Norway have been using network techniques and ad hoc methods for planning and control for many years. The systems used have not been satisfactory, and a new moelling tool was devised for the yards. The basic building block of this tool is considerably more powerful than the activity of the traditional networks. It is called a Component, and carries both its own data and the algorithms needed to manipulate them. Each Component represents an identifiable portion of the real world in the yard. The planning process consists of the Components sending information to each other (messages), and acting upon information received. An experimental system for the planning and control of the Design Sector of A/S Bergens Mekaniske Verksteder has been developed.
Paper, ICCAS conference, Tokyo, 1973.
Scanned by the author July 2003
is21c, components, architecture, mvc, The organisation of a yard may be strongly influenced by the information system it takes into use. The converse should also be true: Systems development should be subordinated the desired evolution of the organisation. The principle of Communicating Data Processes is introduced as a tool for building information systems that are easily moulded for fitting an existing organisation and for adaption to its continuous development. A description of the principle is given, as well as an outline of a new system designed for testing it out in practical shipbuilding.
Proposal for an R&D program. June 1970.
.PDF (In Norwegian)
people, components, architecture Proposing a program for information systems development in the Aker Group based on the decentralized development of communicating components.