Content deleted Content added
m Added link to official website. |
RandFreeman (talk | contribs) Importing Wikidata short description: "Architectural pattern in computer software development" |
||
| (20 intermediate revisions by 4 users not shown) | |||
Line 1:
{{Short description|Architectural pattern in computer software development}}
'''Data, context, and interaction''' ('''DCI''') is a paradigm used in computer software to program systems of communicating [[Object (computer science)|objects]]. Its goals are:
* To improve the readability of [[Object-oriented programming|object-oriented]] code by giving system behavior first-class status;
Line 9 ⟶ 8:
==Description==
===Data===
The data remains "what the system ''is''."<ref name="Artima">{{cite web |author1=Trygve Reenskaug |author2=James O. Coplien |title=The DCI Architecture: A New Vision of Object-Oriented Programming |url=https://fulloo.info/Documents/ArtimaDCI.html}}</ref> The ''data'' part of the DCI architecture is its (relatively) static data model with relations. The data design is usually coded up as conventional classes that represent the basic ___domain structure of the system. These classes are barely smart data,<ref name="Artima" /><ref>{{cite web |author1=James O. Coplien |title=A Glimpse of Trygve: From Class-oriented Programming to Real OO |url=https://www.youtube.com/watch?v=lQQ_CahFVzw#t=1304 |publisher=ACCU Conference 2016}}</ref> and they explicitly lack the functionality that is peculiar to support of any particular [[use case]]. These classes commonly encapsulate the physical storage of the data. These data implement an information structure that comes from the mental model of end users, ___domain experts, programmers, and other ''people'' in the system. They may correspond closely to the model objects of MVC.<ref name="Artima" />
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. So, for example, while a bank account may offer a primitive for increasing the balance, it would have no method called <code>deposit</code>. Such operations belong instead in the interaction part of DCI.<ref name="Artima" />
Data objects are instances of 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.<ref name="DCI Paradigm">{{cite web |author1=James O. Coplien |author2=Trygve Reenskaug |title=The DCI Paradigm: Taking Object Orientation Into the Architecture World |url=https://fulloo.info/Documents/CoplienReenskaugASA2012.pdf}}</ref>
===Context===
The context is the class (or its instance) whose code includes the [[Role-oriented programming|Role]]s for a given algorithm, scenario, or use case, as well as the code to map these Roles into objects at run time and to enact the use case. Each Role is bound to exactly one object during any given use case enactment; however, a single object may simultaneously play several Roles.<ref name="Execution model">{{cite web |last1=Reenskaug |first1=Trygve |title=A DCI Execution Model |url=https://fulloo.info/Documents/DCIExecutionModel-2.1.pdf |page=9}}</ref> A context is instantiated at the beginning of the enactment of an algorithm, scenario, or use case. In summary, a context comprises use cases and [[algorithm]]s in which data objects are used through specific Roles.<ref name="Artima" />
Each context represents one or more use cases.<ref name="Artima" /> 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 assign them to play the Roles which carry out the use case through their responsibilities. A Role may comprise methods, and each method is some small part of the logic of an algorithm implementing a use case. Role methods run in the context of an object that is selected by the context to play that Role for the current use case enactment. The Role-to-object bindings that take place in a context can be contrasted with the polymorphism of vernacular object-oriented programming.<ref name="Glossary">{{cite web |author1=Trygve Reenskaug |others=With assistance from Object-composition group |title=The DCI Glossary |url=https://folk.universitetetioslo.no/trygver/2011/DCI-Glossary.pdf}}</ref> The overall business functionality is the sum of complex, dynamic networks of methods decentralized in multiple contexts and their Roles.
Each context is a scope that includes identifiers that correspond to its Roles.<ref name="Artima" /> Any Role executing within that context can refer to the other Roles in that context through these identifiers.<ref name="Artima" /> These identifiers have come to be called ''
An example of a context could be a wire transfer between two accounts, where data models (the banking accounts) are used through Roles named SourceAccount and DestinationAccount.
===Interaction===
The interaction is "what the system ''does''."<ref name="Artima" /> The interaction is implemented as Roles which are played by objects at run time. These objects combine the state and methods of a data (___domain) object with methods (but no state, as Roles are stateless<ref>{{cite web |last1=Coplien |first1=James |title=Why must roles be stateless? |url=https://fulloo.info/doku.php?id=why_must_roles_be_stateless |website=DCI FAQ}}</ref>) from one or more Roles.<ref name="Artima" /> In good DCI style, a Role addresses another object only in terms of its (methodless) Role. There is a special Role called <code>self</code> which binds to the object playing the current Role. Code within a Role method may invoke a method on <code>self</code> and thereby invoke a method of the data part of the current object. One curious aspect of DCI is that these bindings are guaranteed to be in place only at run time (using a variety of approaches and conventions; [[C++ template]]s can be used to guarantee that the bindings will succeed<ref>{{cite web |title=DCI Examples for C++ |url=https://fulloo.info/Examples/C++Examples/ |website=fulloo.info}}</ref>). This means that interactions, the Role methods, are ''generic''. In fact, some DCI implementations use generics or templates for Roles.
A Role is a stateless programming construct that corresponds to the end user's mental model of some entity in the system.<ref name="DCI Paradigm" /> A Role represents a collection of responsibilities. Whereas vernacular object-oriented programming speaks of objects or classes as a multiplicity 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 on the language. The injection can be fully dynamic at run-time in languages like [[Ruby (programming language)|Ruby]] and [[Python (programming language)|Python]]; it is more static in languages like [[Smalltalk]]-[[Squeak]], [[Scala (programming language)|Scala]] and [[C++]]. The Qi4j programming environment offers a way to express Role method injection into Java objects.<ref name="Qi4j">[http://www.qi4j.org/ Qi4j framework]</ref> Java 8 [http://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html default method] on interfaces can be used to implement Roles in a typesafe way.
In the above money transfer use case, for example, the Role methods in the SourceAccount and DestinationAccount enact the actual transfer.
==Distinguishing traits of DCI==
DCI limits all permissible networks of communicating objects to networks that share common topologies, one for each use case.<ref name="Working with objects">{{cite web |author1=Trygve Reenskaug |author2=James O. Coplien |title=Working with objects - in computer and mind |url=https://fulloo.info/Documents/CommSenseCurrentDraft.pdf}}</ref><ref name="DCI Paradigm" /> Such networks are explicit in the interactions between DCI Roles, whereas in classical object orientation they are emergent. A Role is a node in such a topology; it is a partial classification of the behaviors of all objects that can occupy this node. The topology is a description of the run-time structure of a system.<ref name="Common sense">{{cite web |last1=Reenskaug |first1=Trygve |title=The Common Sense of Object Oriented Programming |url=https://fulloo.info/Documents/200904commonsense.pdf}}</ref>▼
▲DCI limits all permissible networks of communicating objects to networks that share common topologies, one for each use case. Such networks are explicit in the interactions between DCI Roles, whereas in classical object orientation they are emergent. A Role is a node in such a topology; it is a partial classification of the behaviors of all objects that can occupy this node. The topology is a description of the run-time structure of a system.
An object-oriented program is a complex and dynamic network of objects, in the same sense that relationships between real-world objects are complex and dynamic. Consider a waiter at a restaurant. The waiter himself is a complex object that can be viewed in many ways: as my Waiter (e.g., who describes tonight's menu and takes my order), as an Employee of the restaurant (with a certain salary and working hours), and as a Person in the restaurant (which has an occupancy limitation of 150 people). If a Waiter class was written to capture the real-world essence of Waiters (which is what object orientation is really all about), it would have to be very complex to support all of these perspectives.
In DCI these different views are factored into Roles. At run time, the Role is the identity of the object.<ref name="Glossary" /> During the enactment of a [[use case]] (like ''Serve the Wine'') the Role ''Waiter'' unambiguously identifies a single object at any given time.<ref name="Execution model" /> You might argue there may be several Waiters at the table. However, they are likely to differ in their responsibilities within a [[use case]], such as are found in Role names HeadWaiter and Busboy. Even if their responsibilities are identical, they would still be described as Waiter-1 and Waiter-2, or as individual (named) elements of a Waiter vector, if someone intended to write software for them. So a Role like HeadWaiter becomes the identifier, the handle, by which objects refer to each other in a [[use case]].
DCI recognizes the Waiter as an object rather than, say, a composition of an Employee part, a Waiter part and a Person part. The object has its own identity independent of the [[use case]]; this is the Data facet of DCI. Roles are aliased names for their objects but are never separate objects themselves; that would cause [[schizophrenia (object-oriented programming)|self schizophrenia]]. In this sense, every Waiter is a ''homo sapiens''. This is the Waiter's rudimentary what-the-system-is part. The object has many possible identities depending on the [[use case]] it is involved in; this surfaces in the Role identities that form part of the Interaction facet of DCI. These are the (usually more interesting) what-the-system-does part. However, in DCI, there is only a single ''object'' that carries both these perspectives at run time. These perspectives may be grouped differently at coding time. The code is dominated by the [[use case]] structure, which cuts across the objects, and which also is part of the Interaction facet of DCI.
DCI allows an object to take on one or more Roles during a [[use case]] enactment. In other words, an object is re-bound to Role identifiers on each [[use case]] enactment.<ref name="Execution model" /> These Roles infer an interface, referred to as the ''Role type.'' Each object is "re-cast" (in the theatrical sense) anew on every [[use case]]. Though a Role is bound only to a single object, an object may play several Roles. For example, a HeadWaiter may be involved in a [[use case]] to count all the occupants of the restaurant during a fire inspection, and will play the Person Role as well as the HeadWaiter Role. The single object supports the behaviors of both Roles necessary to carry out the [[use case]].
In summary, DCI architectures tend to be characterized by the following properties:<ref name="Artima" /><ref name="Common sense" />
* The Data model reflects the ___domain structure rather than partitions of its behavior;
* Objects dynamically take on Roles during [[use case]] enactments;
Line 55 ⟶ 52:
==Execution model==
DCI can be thought of as an [[event-driven programming]] paradigm, where some event (as a human gesture in a [[model-view-controller]] (MVC) architecture) ''triggers'' a [[use case]].<ref name="DCI Paradigm" /> The [[use case]] can be short-lived or long-lived. The events are called ''triggers'', and they are handled in the ''environment'' in which DCI is embedded. This environment may be the controller of a conventional MVC architecture or any other system-level code.▼
▲DCI can be thought of as an [[event-driven programming]] paradigm, where some event (as a human gesture in a [[model-view-controller]] (MVC) architecture) ''triggers'' a [[use case]]. The [[use case]] can be short-lived or long-lived. The events are called ''triggers'', and they are handled in the ''environment'' in which DCI is embedded. This environment may be the controller of a conventional MVC architecture or any other system-level code.
The trigger causes the environment to instantiate a ''context object''. The type of object is chosen according to the kind of [[use case]] that will ensue, based on information about the trigger or the system state or both. For example, a cash machine might have separate Context classes for money transfer, withdrawal, deposit, balance inquiry, and so forth. Once the environment instantiates the Context object, it invokes its ''trigger method'' to start the use case enactment.<ref name="Execution model" />
As described above, each Context provides a design scope for the Roles that participate in the [[use case]] enactment. It is the job of the Context to assign objects to play these Roles.<ref name="Glossary" />
# The Context first finds the objects that are to take part in this [[use case]] enactment. These objects may be anywhere in the environment, or in a database, or created on the fly; DCI does not restrict these objects. Within a Context there is at most one instance playing any given Role at any given time.
# Second, the Context assigns a single object to play each of its Roles (though a single object often plays multiple Roles in a single Context). In strongly dynamic languages (Ruby, Python) the Context [[dependency injection|''injects'']] the Role methods into the object. In most dynamic languages, any extant object can be asked to play any Role at any time (though some object-Role combinations may of course make no sense; nonsense combinations of objects and Roles would lead to <code>MESSAGE NOT UNDERSTOOD</code> at run time if the Role method were invoked.) In more statically typed languages (Scala, C++) there has to have been some prior arrangement for the object to support the Role methods. For example, Scala creates an anonymous class that combines the rudimentary logic of a ___domain class with the [[use case]] logic of the [[Trait (computer science)|trait]] used to implement a Role; Roles are effectively assigned to ___domain objects when they are instantiated.
Line 67 ⟶ 63:
==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]].<ref name="DCI Paradigm" />
Implementation techniques differ across programming languages. What is common to many approaches is that Roles are represented by such constructs as generics, templates, classes, or [[Traits (computer science)|traits]]. Code for the basic ___domain logic is implemented separately, following conventional object-oriented practice and most commonly using classes. Each Role's code is injected into the ___domain object that will play it during the [[use case]] enactment. To implement [[Role-oriented programming|Roles]], [[method injection]] is usually needed. [[Traits (computer science)|Traits]] are one common programming language technique to support [[method injection]]. Some languages, such as [[Scala (programming language)|Scala]], have native support for [[Traits (computer science)|traits]], while other languages (e.g., [[Ruby (programming language)|Ruby]] and [[Python (programming language)|Python]]) allow run time injection of methods. In [[Java (programming language)|Java]], pre-compiler tricks based on annotations are needed to support DCI. [[Haxe]] uses its compile-time macro feature to transform the DCI semantics to target language code.
Several example implementations exist on the [https://fulloo.info/Downloads/ fulloo.info site] maintained by the creators of DCI.
==History==
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]].
DCI arose largely as an outgrowth of Trygve Reenskaug's work on role-based modeling.<ref>Trygve Reenskaug. Working with Objects: The OOram Software Engineering Method. Prentice-Hall, 1995.</ref> Trygve had long recognized that Roles played a central part in the way programmers think about objects, and that the class-based progression of programming language technology took away much of the motivation to think about the objects in a program. That in turn made it difficult to reason about the program at run time. Further, the fact that object-oriented programming languages offered only classes to express program logic left the programmer at the mercy of the structural layout of the data to delineate behavior, which is unnatural compared with a delineating behavior on Role boundaries. This in turn made program behavior more difficult to reason about than in, say, a procedural program in [[Fortran]].{{citation needed|date=February 2016}}
Trygve felt it was important to create program structures about which one can reason, and started socializing these ideas as early as 2000. By 2006 he had a working design model, and his discovery in 2008 of Schärli's work on [[Traits (computer science)|Traits]] provided the keystone that would provide natural programming language expression of these ideas. He prototyped the ideas in the Baby programming environment, written in Squeak.
Different approaches taken for the evolution of object-oriented programming, both on a language and [[programming pattern|pattern]] level, agree to various degrees with DCI:
* [[Mixin]]s are a way of encapsulating code for specific what-the-system-does functionality in closed form; however, there is no consistent mechanism to link multiple mixins into a unit at the level of a [[use case]]. They can be employed to implement to the concept of Role in DCI, although not in a strict sense.{{citation needed|date=February 2016}}
* [[Multiple dispatch]] was an early attempt to more fully separate an algorithm from the objects that were involved in its execution, which can be complemented with DCI's separation of common recurring algorithms from the code fragments that could individually be localized to individual objects. DCI conceptually leads to broader re-use of a single algorithm in closed form across many sets of objects of widely heterogeneous types. DCI's Context object acts like an explicit, intelligence dispatcher that is analogous to the dispatching mechanisms of languages with multiple dispatch.{{citation needed|date=February 2016}}
* True object-oriented programming languages like [[Self (programming language)|Self]] attempt to break down the dichotomy between the domains of classful programming and objectful execution, which helps programmers focus on run-time objects. DCI restores the code-level knowledge about the relationships between them in Contexts and in the static relationships between Role methods.
* [[Dependency injection]] is a longstanding approach to change the functionality of an object at run time by allowing it to "outsource" some of its execution to an external object that can be re-bound at will. Most implementations{{which|date=October 2014}} of dependency injection lead to the [[Schizophrenia (object-oriented programming)|self schizophrenia]] problem,<ref>{{
* Multi-paradigm design<ref>James Coplien, Multi-paradigm design for C++. Addison-Wesley, 1998.</ref> attempts to separate behavior and structure by according the behavior to a procedural design and the structural component to objects, allowing free access between them, in accord with the design principles of C++. The DCI approach can improve on expressing the relationship between the procedural and structural parts of design and general cohesiveness.<ref name="Empirical Study on Code Comprehension">{{
The challenges of object-oriented programming can also be met by addressing its issues on the paradigm level.
* [[Aspect-oriented programming]] (AOP) is perhaps the closest historic relative to DCI. Most use of Aspects is closely tied to the programmer perspective and require strong tool support to provide good understanding of the software's
* [[Role-oriented programming]] brings together ideas from [[Aspect-oriented programming]], conceptual modeling <ref>Friedrich Steimann, On the representation of roles in object-oriented and conceptual modelling, 2000, http://www.fernuni-hagen.de/ps/veroeffentlichungen/zeitschrift_46129.shtml {{Webarchive|url=https://web.archive.org/web/20161007005544/http://www.fernuni-hagen.de/ps/veroeffentlichungen/zeitschrift_46129.shtml |date=2016-10-07 }}</ref> and more. Early attempts (1991) defined roles in an independent fashion,<ref>Joel Richardson and Peter Schwarz, Aspects: extending objects to support multiple, independent roles, 1991, http://www.informatik.uni-trier.de/~ley/db/conf/sigmod/RichardsonS91.html {{Webarchive|url=https://web.archive.org/web/20071017185308/http://www.informatik.uni-trier.de/~ley/db/conf/sigmod/RichardsonS91.html |date=2007-10-17 }}</ref> but more recent approaches (2002 and onward) converge in emphasizing that roles depend on context (also "teams" <ref>Stephan Herrmann, Object Teams: Improving Modularity for Crosscutting Collaborations, http://www.objectteams.org/publications/index.html#NODe02, 2002</ref> or "institutions" <ref>Guido Baldoni et al., Roles as a coordination construct: introducing powerJava, 2005, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.77.6337</ref>). In role-oriented programming, roles are defined with respect to some intrinsic (or base) entity, which corresponds to the data-role dichotomy in DCI. The concept of context is essentially the same in both approaches. Both approaches emphasize the interaction among a group of roles.
:Several differences can be identified. Role-oriented programming is focused on adding support for roles to object-oriented ''programming languages'' where emphasis is on increasing the expressiveness of a programming language and enabling more designs. In comparison, DCI has stronger focus on the ''method'' of how mental models should be captured, defining this method in part as restrictions on what should be regarded a legal design corresponding to DCI. For example: Authors of DCI tend to discourage some use of inheritance (e.g. "within DCI you do not inherit roles" <ref>J. Coplien, posted in Object-Composition Google group, https://groups.google.com/forum/?hl=en#!topic/object-composition/haza-J2Doz8 21.10.2010</ref>) whereas role-oriented programming embraces (and even enhances) inheritance as a central concept of object-orientated programming, supporting free combination with other concepts. DCI emphasises that [[Schizophrenia (object-oriented programming)|self schizophrenia]] should be avoided, whereas role-oriented programming claimed to manage split objects in such a way that schizophrenia was no longer a problem <ref>Stephan Herrmann, Demystifying Object Schizophrenia, 2010, http://www.objectteams.org/publications/index.html#MASPEGHI10</ref> but a facilitator for more flexible designs. A later paper by the DCI authors claims that self-schizophrenia remains a problem in role-oriented programming using a counter-example based on a modified implementation of [[Dijkstra's algorithm]].<ref>James O. Coplien, and Trygve Mikkjel Heyerdahl Reenskaug, The data, context and interaction paradigm. In Gary T. Leavens (Ed.): Conference on Systems, Programming, and Applications: Software for Humanity, SPLASH '12, Tucson, AZ, USA, October 21–25, 2012. ACM 2012, {{ISBN|978-1-4503-1563-0}}, pp. 227 - 228, http://dl.acm.org/citation.cfm?id=2384782&dl=ACM&coll=DL.</ref> As such, DCI sacrifices the advantages of inheritance for the complete avoidance of its shortcomings, while Role Oriented Programming takes a mitigation approach, awarding importance to the balancing of the dangers with its popular advantages.
==Research==
A study in 2017 by Héctor Valdecantos et. al. showed that "The correctness analysis shows that programmers in the DCI group performed better than programmers in the OOjava group. This is aligned with the theories behind DCI and it should encourage further and systematic investigations
concerning the possibilities of this paradigm."<ref name="Empirical Study on Code Comprehension" />
According to researchers Bluemke and Stepień at Institute of Computer Science, Warsaw University of Technology, "DCI based systems are very flexible much more than the traditional ones, this is due to the fact that static (Data) and dynamic (Context, Interaction) parts of the system are separated and separation of concerns is very powerful strategy to master the complexity."<ref name="Experiences with DCI Pattern">{{cite book |last1=Bluemke |first1=Ilona |last2=Stepień |first2=Anna |title=Experiences with DCI Pattern |website=Software Engineering in Intelligent Systems |series=Advances in Intelligent Systems and Computing |pages=87–96 |doi=10.1007/978-3-319-18473-9_9 |date=2015 |volume=349 |isbn=978-3-319-18472-2 |url=https://www.researchgate.net/publication/279199208}}</ref>
==References==
Line 99 ⟶ 101:
==External links==
*[
*[https://
*[https://groups.google.com/group/object-composition/ object-composition Google group with several early implementations of DCI by individuals]
*[https://blog.jayway.com/2010/03/30/contexts-are-the-new-objects/ Contexts are the new objects] by [[Rickard Öberg]]
| |||