====== Welcome to the C3 Website ======

The aim of Concept-Centric Coding (C3) is to provide programmer support to cope with software evolution in an agile context. The core tool supporting the Concept-Centric Coding approach is [[cobro|CoBro]], which stands for the 'Concept to Code Browser'.  

A {{downloads:c3-cobro_poster.pdf|poster}} in which we briefly illustrate the main points of this research track is available for download.  Currently we investigate the use of C3 for functional software variability.  A brief overview and a number of code examples can be found in a recent {{downloads:2007_12_13_benevol_variability_c3.pdf|presentation}} given at [[http://www.info.fundp.ac.be/benevol|Benevol 2007]].

This work originates from the [[phd|PhD dissertation]] by [[http://ssel.vub.ac.be/ssel/about:members:dirkderidder|Dirk Deridder]] (2006).  Note that the CoBro toolsuite has evolved a lot since that time.  This includes among others a full rebuild of the CoBro meta level interface and the surrounding tools.  So please refer to the [[cobro|CoBro pages]] on this site for an up-to-date discussion of the toolsuite.

==== Overview ====

When a programmer needs to keep up with swift changes to a software system, it is crucial to remove  hindrances as much as possible and to provide intrinsic support for devising a malleable implementation.  In the image below we illustrate the targeted context.

{{  c3_context.jpeg?400  |Context}}  

Therefore C3 first of all targets the problem of the //implicitness of domain knowledge// in an application's source code.  This is problematic since a major amount of effort is put in code comprehension during the evolution of a system.  Hence [[cobro|CoBro]] provides a way to make the domain knowledge (e.g. a definition of a novice and expert user category) about the application explicit in a conceptbase.  

Next to this it is also important to keep the //connection of this knowledge to the code// available to the developer.  Therefore the conceptbase acts as a //domain meta layer// for the application in which implementation entities (e.g. a ''MediaLibary'' class) can be connected to domain entities (e.g. a ''NoviceUser'' concept). The connection between both sides is done transparently through either an intensional or an extensional concept definition.  

In order to ensure that developers keep the domain knowledge and the connection to the code up to date, both should //contribute actively in providing the application functionality//.  Broadly speaking an interplay is set up by attributing domain concepts with code (and vice versa) which are called from within the implementation.  This  is especially important in an agile context where one has to deliver an application in an extremely limited timespan.  Hence the  developer will also focus on the domain knowledge and its connection since it yields a short term benefit (as opposed to a long term promise to help future evolution efforts).  

Lastly, to reduce the overhead for developers who use the C3 approach, it is important to make the manipulation and the active use of the domain meta layer as //transparent// as possible.

The different problems tackled by C3 and the corresponding solution pillars are illustrated in the image below.

{{  c3_pillars.jpeg?400  |Pillars  }}  


[[cobro|CoBro]] is implemented in //symbiotic integration// with Smalltalk and the [[http://www.cincomsmalltalk.com|VisualWorks]] development environment.  This implies that the domain meta layer can be manipulated by using the same syntax and interaction mechanisms as Smalltalk.  Moreover, the close integration with the development environment results in a highly interactive and natural way which is beneficial for incremental development in an agile context.  Part of the power of [[cobro|CoBro]] is realised by its (partial) metacircular implementation.  Consequently, [[cobro|CoBro]] can  be adapted by changes to the domain meta layer at runtime, leading to a highly extensible and flexible toolbase.  We will now briefly sketch the essential properties of Smalltalk used for implementing the [[cobro|CoBro]] environment.


**Introspection**  [[cobro|CoBro]] needs to represent code level entities at the domain meta layer, in order to connect them to domain level entities (and vice versa).  This is achieved automatically by executing an intensional concept definition which assembles the necessary information by introspecting the Smalltalk environment. 

**Intercession** Implementing [[cobro|CoBro]] in symbiosis with Smalltalk requires intercession.  This allows us to adapt the default //binding lookup// and //method lookup// mechanisms of Smalltalk. In doing so, a developer can manipulate the domain knowledge (stored in an RDBMS) using the same syntax and interaction mechanisms provided for standard Smalltalk.  Intercession is also required to adapt [[cobro|CoBro]] behavior at runtime by changing entities in the domain meta layer.

**Dynamic typing** As mentioned above, a developer can manipulate [[cobro|CoBro]] entities as if they were plain Smalltalk objects.  This is not only implemented by using the introspective and intercessive capabilities of Smalltalk.  It is also facilitated by the fact that Smalltalk is dynamically typed.  An important extra is that existing developer tools can be used out-of-the-box to manipulate [[cobro|CoBro]] entities.  Moreover, dynamic typing made it possible to accomplish the runtime adaptation of [[cobro|CoBro]] (and applications written in it) by modifying elements at the domain meta layer.  

**Open implementation** The symbiotic //integration// of [[cobro|CoBro]] with Smalltalk requires an open implementation of both the language and the development environment.  The close integration of the [[cobro|CoBro]] tools with the programming environment is needed for a non-obstrusive synergy between the concept level and the code level.