oowiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Object-oriented programming was supposed to unify the perspectives of the programmer and the end user in computer code: a boon both to usability and program comprehension. While objects capture structure well, they fail to capture system behavior. DCI is a programming paradigm through which the end user mental model is more fully reflected in readable code. The vision of DCI is to become a unifying foundation for programming in both introductory and advanced programming education, and to bridge the gap between programmer and everyday user through concepts that everyone can understand.

To quote from the article [[http://fulloo.info/Documents/CommSenseCurrentDraft.pdf|Working with objects—in computer and mind]], the primary goals of DCI are as follows:

MENTAL MODELS. To reflect the way different users conceptualize the objects of their world so that a program feels like an extension of its user's mind.

REASONING. To help software developers reason about system state and behavior in addition to the state and behavior of isolated objects.

READABILITY. To improve the readability of object-oriented code by giving system behavior first-class status.

REUSE. To be able to reuse old solutions for new purposes.

REVISION. To cleanly separate code for rapidly changing system behavior (what the system //does//) from code for slowly changing domain knowledge (what the system //is//), instead of combining both in one class hierarchy.

Alan Kay introduced the notion of object orientation in the early seventies. He regarded an object as a virtual computer and an object system as many computers hooked together by a very fast network. Fundamentally, a computer offers three simple services: it can store data, process data, and communicate data.

DCI achieves these goals by considering three fundamental aspects:

**Data**\\
The “storing” function of a system is realized by the //Data// model, which is comprised of objects representing the structure and relationships of a domain.

**Context**\\
The Data model gives rise to objects that will collaborate to implement use case scenarios and other system operations. Object interaction takes place within a //Context// where the objects are identified by the //Roles// they play. Objects are temporarily extended with //Role Methods// while they are playing a Role. The Context orchestrates which objects play which Roles.

**Interaction**\\
At runtime, the environment will trigger the Context to start the //Interactions// between the role-playing objects. These Role Players will send messages to each other in order to fulfill the system operation. Runtime parameters might vary the topology of interactions within a Context, e.g. if a use case has various scenarios. The interactions form a structure that closely reflects our human mental model of the behavior of our domain.

In traditional class-based programming, “storing” and “processing” code is placed together in the same class, and the code for “communicating” (communication between objects) is often scattered across many different classes. DCI is more truly “object-oriented”: objects still contain both data and behavior at runtime, but we avoid the often incorrect assumption that system behavior shares the same structure as the data model. This is accomplished by clearly delineating the storing, processing, and communicating capabilities in the code, allowing the programmer to orchestrate how these elements will combine to form //objects at runtime// and their interactions with each other.

Encoding behavior as a first class citizen in the Context firmly consolidates our ability to reason about what the code will do at runtime without having to study a plethora of classes or prototypes of role-playing objects. This has an array of advantages:

DCI allows:
  * Programmers and other stakeholders to more easily synchronize their mental model of the domain
  * New programmers to more easily understand what a program is supposed to accomplish
  * Current programmers on a DCI project to more easily maintain and debug the code base
  * Managers and end users to more easily review domain behavior in Contexts together with programmers

In many ways, DCI builds on the same concepts that underly MVC (both were invented by Trygve Reenskaug). In MVC, the Model is intended to make the computer feel like an extension of the user's mind, made accessible by supporting Views and Controllers. In other words, MVC transforms the Model data into a physical form that can readily be assimilated by the user’s brain. DCI is about creating a program that faithfully represents the human mental model. The two meet when MVC is used to bridge the gap between the human mind and the model implied by the DCI-based computer system.

History and common sense argue that users can reap the full value of software only when they understand how the system works, the ideal being that stakeholders can understand critical parts of the program and that some can even write code themselves. DCI makes this goal practical and acheivable today. Store, process, and communicate: so simple that everybody can understand it, so universal that it can form the nucleus of computing in business and school.

For more information, see these introductory articles:\\
http://fulloo.info/Documents/CommSenseCurrentDraft.pdf\\
http://www.artima.com/articles/dci_vision.html
oowiki

User Tools

Site Tools

Page Tools
