Wikipedia

Data, context and interaction

This is an old revision of this page, as edited by Jcoplien (talk | contribs) at 14:05, 14 June 2010 (→References). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

DCI

Data, Context and Interaction (DCI) is a paradigm used in computer programming. Its goals are:

  • To improve the readability of object-oriented code by giving system behavior first-class status;
  • To cleanly separate code for rapidly changing system behavior from that for slowly changing ___domain knowledge, instead of combining both in one class interface;
  • To support an object style of thinking that is close to peoples' mental models, rather than the class style of thinking that overshadowed object thinking early in the history of object-oriented programming languages.

The pattern separates the ___domain model (Data) from Use cases (Context) and Roles that objects play (Interaction). DCI is complementary to Model–view–controller (MVC). MVC as a pattern language is still used to separate the data and its processing from presentation.

DCI was invented by Trygve Reenskaug, also the inventor of MVC. The current formulation of DCI is mostly the work of Reenskaug and James O. Coplien.

Description

Data
Static data model with relations.
Barely smart data, that commonly abstracts the physical storage of the data. These data reflect the end user cognitive model of the computation. They correspond closely to the Model objects of MVC.
An example of a Data object could be a bank account. Its interface would have basic operations for increasing and decreasing the balance and for inquiring about the current balance. The interface would likely not offer operations that involve transactions, or which in any way involve other objects or any user interaction. Those operations belong instead in the Interaction part of DCI.
Data objects are the sort that relate to the classes that might come from ___domain-driven design, and such classes might use subtyping relationships to organize ___domain data. Though it reduces to classes in the end, DCI reflects a computational model dominated by object thinking rather than class thinking. Therefore, when thinking "Data" in DCI, it means thinking more about the instances at run time than about the classes from which they were instantiated.
Context
Use cases and algorithms in which data models are used through specific roles.
A Context is an object that is a collection of code that includes the roles for a given algorithm, scenario, or use case; and the code to map these roles into objects at run time. A Context is often implemented as a class that is instantiated as a Context object at the beginning of the enactment of an algorithm, scenario, or use case.
The scope of a Context is at the level of a whole algorithm, scenario, or use case, and each Context represents one or more use cases. A Context object is instantiated for each enactment of a use case for which it is responsible. Its main job is to identify the objects that will participate in the use case and to associate them with the roles whose responsibilities characterize the use case. Each role comprises methods, and each method is some small part of the logic of an algorithm implementing a use case. The role-to-object bindings that take place in a Context can be contrasted with the polymorphism of vernacular object-oriented programming. The overall business functionality is the sum of complex networks of methods decentralized in multiple roles. For a given use case enactment, each of these roles runs in the context of an object selected for it by the Context.
Each Context is a scope that includes identifiers that correspond to roles. Any role executing within that Context can refer to the other roles in that Context through these identifiers. These identifiers have come to be called methodless roles.
An example of a context could be a wire transfer between two accounts, where data models (the banking accounts) are used through source account and destination account roles.
Interaction
The Interaction is implemented as roles which can be assigned to data models.
A role is a programming construct that corresponds to the end user's mental model of some entity in the system. A role is a collection of responsibilities. Whereas vernacular object-oriented programming speaks of objects or classes as the locus of responsibilities, DCI ascribes them to roles. An object participating in a use case has responsibilities: those that it takes on as a result of playing a particular role. Most modern programming languages have a way to express roles, and to express the injection of role methods into objects, and implementation techniques vary depending the language. The injection can be fully dynamic at run-time in languages like Ruby and Python; it is more static in languages like Scala and C++. The Qi4j programming environment offers a way to express role method injection into objects in Java.
An example of a role could be a bank account being the source account.
”What the system does”

Execution Model

Implementing DCI

DCI depends on a design process that separates use cases from the data model. The data model is often based on an informal ___domain analysis. The roles that characterize the end-user's model of system functionality come from the use cases. One approach to overall DCI design is Lean Architecture[1] described in a book of the same name [2].

Implementation techniques differ across programming languages. What is common to most approaches is that the code for system behavior is implemented in constructs that represent roles, which are variously represented as generics, templates, classes, or traits. Code for the basic ___domain logic is implemented separately, usually in line with conventional object oriented practice and most commonly using classes. Role code is injected into those ___domain objects that will play the role during a use case enactment. For roles, method injection is usually needed. Traits[3] are one common programming language technique to support method injection. Some languages, such as Scala, have native support for traits, while other languages (e.g., Ruby and Python) allow run time injection of methods. In Java, pre-compiler tricks based on annotations are needed to support DCI.

Several example implementations exists: Smalltalk/Squeak, C++[4], C#[5], Ruby[6], JavaScript[7], Python, Qi4J (Java)[8] , Scala and PHP[9].

History

Multi-paradigm, role modelling.

References

  1. ^ Lean Software Architecture web page, http://www.leansoftwarearchitecture.com
  2. ^ James Coplien and Gertrud Bjørnvig, Lean Architecture for Agile Software Development. Wiley: 2010.
  3. ^ Nathaniel Schärli et al. Traits: Composable units of behavior. http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf
  4. ^ C++ source code on Object-Composition Google group, http://object-composition.googlegroups.com/web/20090118C__DCI.tar?gda=YZxxZkQAAADrRvU1tICZInrYQGkdqcjVB9LJpDFQtNZStXvSrZaE044UiKBbjmHuWOApdsY8dkxV6u9SiETdg0Q2ffAyHU-dzc4BZkLnSFWX59nr5BxGqA 17.10.2009
  5. ^ C# source code on Object-Composition Google group,http://object-composition.googlegroups.com/web/20090504_C%23_DCI.zip?gda=KuAYkEcAAADrRvU1tICZInrYQGkdqcjVB9LJpDFQtNZStXvSrZaE07Ryyh4ndddBwXohD2r2F8gbzHe87USdioT9uNiA7PHaeV4duv6pDMGhhhZdjQlNAw 17.10.2009
  6. ^ Ruby source code on Object-Composition Google group,http://groups.google.com/group/object-composition/browse_thread/thread/561f638b43f1b960# 17.10.2009
  7. ^ JavaScript source code on Object-Composition Google group,http://groups.google.com/group/object-composition/browse_thread/thread/8ec4cf18e127cc3e# 17.10.2009
  8. ^ Qi4j source code on Object-Composition Google group,http://groups.google.com/group/object-composition/browse_thread/thread/fe317e615b9008fe# 17.10.2009
  9. ^ PHP source code on Google,,http://code.google.com/p/php-coredci
 

This software-engineering-related article is a stub. You can help Wikipedia by expanding it.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Data,_context_and_interaction&oldid=367971122"