Contact
The Colored Integrated Development Environment (CIDE, formerly also ColoredIDE) is a software product line tool for software product line development (esp. analyzing and decomposing legacy code). It follows the paradigm of virtual separation of concerns, i.e., developers do not physically extract the feature code, but just annotate code fragments inside the original code and use tool support for views and navigation. For annotation, background colors are used, so that code fragments belonging to a feature are shown with a background color; hence the name.
CIDE is a research project. The current prototype is available for download on this site. It is used in various branches of software engineering research for feature-oriented development, e.g., granularity of feature extensions, safe composition, feature scoping, extractive SPL adoption model, language-independent feature-decomposition, feature interaction analysis, feature location/feature mining, feature modularity, and many more.
As of June 2009, the pure-Java version of CIDE has been discontinued, since all features have been migrated to the new version.
Here is a list of features supported in the current version| Feature |
Current
Version (CIDE 1.4) |
|---|---|
| Feature Models |
Simple List, Guidsl Model, or pure::variants connector |
| Assigning Features
to Text
Fragments based on underlying AST |
available for
several languages |
| ASTView to see the
structure of
the document |
available |
| Coloring whole
files and
directories |
available |
| Advanced Editor
with Syntax
Highlighting, Content Asssistant, etc |
available for Java |
| Feature Projection
(hide
irrelevant features in code and file navigator) |
Java editor only |
| Ensures syntactic
correctness of
all variants (all configurations can be parsed) |
available |
| Type-checking of
whole SPL (all
configurations can be compiled) |
limited support for
Java and Bali |
| Interaction
Statistics |
available |
| Export to AHEAD,
FeatureHouse, CPP, Munge, and AspectJ Import from FeatureHouse |
prototype |
Feature-oriented software development (FOSD) is a paradigm for the construction, customization, and synthesis of large-scale software systems. In this survey, we give an overview and a personal perspective on the roots of FOSD, connections to other software development paradigms, and recent developments in this field. Our aim is to point to connections between different lines of research and to identify open issues.
Physical separation with class refinements and method refinements à la AHEAD and virtual separation using annotations à la #ifdef or CIDE are two competing groups of implementation approaches for software product lines with complementary advantages. Although both groups have been mainly discussed in isolation, we strive for an integration to leverage the respective advantages. In this paper, we provide the basis for such an integration by providing a model that supports both, physical and virtual separation, and by describing refactorings in both directions. We prove the refactorings complete, such that every virtually separated product line can be automatically transformed into a physically separated one (replacing annotations by refinements) and vice versa. To demonstrate the feasibility of our approach, we have implemented the refactorings in our tool CIDE and conducted four case studies.
A software product-line is a family of related programs that are distinguished in terms of features. A feature implements a stakeholders' requirement. Different program variants specified by distinct feature selections are produced from a common code base. The optional feature problem describes a common mismatch between variability intended in the domain and dependencies in the implementation. When this occurs, some variants that are valid in the domain cannot be produced due to implementation issues. There are many different solutions to the optional feature problem, but they all suffer from drawbacks such as reduced variability, increased development effort, reduced efficiency, or reduced source code quality. In this paper, we examine the impact of the optional feature problem in two case studies in the domain of embedded database systems, and we survey different state-of-the-art solutions and their trade-offs. Our intension is to raise awareness of the problem, to guide developers in selecting an appropriate solution for their product-line project, and to identify opportunities for future research.
The separation of concerns is a fundamental principle in software engineering. Crosscutting concerns are concerns that do not align with hierarchical and block decomposition supported by mainstream programming languages. In the past, crosscutting concerns have been studied mainly in the context of object orientation. Feature orientation is a novel programming paradigm that supports the (de)composition of crosscutting concerns in a system with a hierarchical block structure. By means of two case studies we explore the problem of crosscutting concerns in functional programming and propose two solutions based on feature orientation.
A software product line (SPL) is a family of related program variants in a well-defined domain, generated from a set of features. A fundamental difference from classical application development is that engineers develop not a single program but a whole family with hundreds to millions of variants. This makes it infeasible to separately check every distinct variant for errors. Still engineers want guarantees on the entire SPL. A further challenge is that an SPL may contain artifacts in different languages (code, documentation, models, etc.) that should be checked. In this paper, we present CIDE, an SPL development tool that guarantees syntactic correctness for all variants of an SPL. We show how CIDE's underlying mechanism abstracts from textual representation and we generalize it to arbitrary languages. Furthermore, we automate the generation of safe plug-ins for additional languages from annotated grammars. To demonstrate the language-independent capabilities, we applied CIDE to a series of case studies with artifacts written in Java, C++, C, Haskell, ANTLR, HTML, and XML.
Database schemas are used to describe the logical design of a database. Diverse groups of users have different perspectives on the schema which leads to different local schemas. Research has focused on view integration to generate a global, consistent schema out of different local schemas or views. However, this approach seems to be too constrained when the generated global view should be variable and only a certain subset is needed. Variable schemas are needed in software product lines in which products are tailored to the needs of stakeholders. We claim that traditional modeling techniques are not sufficient for expressing a variable database schema. We show that software product line methodologies, when applied to the database schemas, overcome existing limitations and allow the generation of tailor-made database schemas.
Es gibt eine Vielzahl sehr unterschiedlicher Techniken, Sprachen und Werkzeuge zur Entwicklung von Softwareproduktlinien. Trotzdem liegen gemeinsame Mechanismen zu Grunde, die eine Klassifikation in Kompositions- und Annotationsansatz erlauben. Während der Kompositionsansatz in der Forschung große Beachtung findet, kommt im industriellen Umfeld hauptsächlich der Annotationsansatz zur Anwendung. Wir analysieren und vergleichen beide Ansätze anhand von drei repräsentativen Vertretern und identifizieren anhand von sechs Kriterien individuelle Stärken und Schwächen. Wir stellen fest, dass die jeweiligen Stärken und Schwächen komplementär sind. Aus diesem Grund schlagen wir die Integration des Kompositions- und Annotationsansatzes vor, um so die Vorteile beider zu vereinen, dem Entwickler eine breiteres Spektrum an Implementierungsmechanismen zu Verfügung zu stellen und die Einführung von Produktlinientechnologie in bestehende Softwareprojekte zu erleichtern.
The separation of concerns is a fundamental principle in software engineering. Crosscutting concerns are concerns that do not align with hierarchical and block decomposition supported by mainstream programming languages. In the past, crosscutting concerns have been studied mainly in the context of object orientation. Feature orientation is a novel programming paradigm that supports the implementation of crosscutting concerns in a system with a hierarchical block structure. We explore the problem of crosscutting concerns in functional programming and propose two solutions based on feature orientation. Two case studies support our claims.
Software product lines can be implemented with many different approaches. However, there are common underlying mechanisms which allow a classification into compositional and annotative approaches. While research focuses mainly on composition approaches like aspect- or feature-oriented programming because those support feature traceability and modularity, in practice annotative approaches like preprocessors are common as they are easier to adopt. In this paper, we compare both groups of approaches and find complementary strengths. We propose an integration of compositional and annotative approaches to combine advantages, increase flexibility for the developer, and ease adoption.
Implementing software product lines is a challenging task. Depending on the implementation technique the code that realizes a feature is often scattered across multiple code units. This way it becomes difficult to trace features in source code which hinders maintenance and evolution. While previous effort on visualization technologies in software product lines has focused mainly on the feature model, we suggest tool support for feature traceability in the code base. With our tool CIDE, we propose an approach based on filters and views on source code in order to visualize and trace features in source code.
Feature modules are the building blocks of programs in software product lines (SPLs). A foundational assumption of feature-based program synthesis is that features are composed in a predefined order. Recent work on virtual separation of concerns reveals a new model of feature interactions that shows that feature modules can be quantized as compositions of smaller modules called derivatives. We present this model and examine some of its unintuitive consequences, namely, that (1) a given program can be reconstructed by composing features in any order, and (2) the contents of a feature module (as expressed as a composition of derivatives) is determined automatically by a feature order. We show that different orders allow one to `adjust' the contents of a feature module to isolate and study the impact of interactions that a feature has with other features. Using derivatives, we show the utility of generalizing safe composition (SC), a basic analysis of SPLs that verifies program type-safety, to prove that every legal composition of derivatives (and thus any composition order of features) produces a typesafe program, which is a much stronger SC property.
A software product line (SPL) is an efficient means to generate a family of program variants for a domain from a single code base. However, because of the potentially high number of possible program variants, it is difficult to test all variants and ensure properties like type-safety for the entire SPL. While first steps to type-check an entire SPL have been taken, they are informal and incomplete. In this paper, we extend the Featherweight Java (FJ) calculus with feature annotations to be used for SPLs. By extending FJs type system, we guarantee that - given a well-typed SPL - all possible program variants are welltyped as well. We show how results from this formalization reflect and help implementing our own language-independent SPL tool CIDE.
Software product lines (SPL) usually consist of code and non-code artifacts written in different languages. Often they are created by decomposing legacy applications into features. To handle different artifacts uniformly (code, documentation, models, etc.), current SPL technologies either use an approach that is so general that it works on character or token level, but can easily introduce subtle errors; or they provide specialized tools for a low number of languages. Syntax errors that only occur in certain variants are difficult to detect, as the exploding number of variants makes a manual testing unfeasible. In this paper, we present CIDE, an generic SPL tool that can ensure syntactic correctness for all variants. We show CIDE’s underlying mechanism that abstracts from textual representation and generalize it from Java to arbitrary languages. Furthermore, we automate the generation of safe plug-ins for additional languages from annotated grammars. To demonstrate CIDE’s capabilities, we applied it to a series of case studies with artifacts from different languages, including Java, C#, C, Haskell, ANTLR, and XML.
Building software product lines (SPLs) with features is a challenging task. Many SPL implementations support features with coarse granularity - e.g., the ability to add and wrap entire methods. However, fine-grained extensions, like adding a statement in the middle of a method, either require intricate workarounds or obfuscate the base code with annotations. Though many SPLs can and have been implemented with the coarse granularity of existing approaches, fine-grained extensions are essential when extracting features from legacy applications. Furthermore, also some existing SPLs could benefit from fine-grained extensions to reduce code replication or improve readability. In this paper, we analyze the effects of feature granularity in SPLs and present a tool, called Colored IDE (CIDE), that allows features to implement coarse-grained and fine-grained extensions in a concise way. In two case studies, we show how CIDE simplifies SPL development compared to traditional approaches.
Creating a software product line from a legacy application is a difficult task. We propose a tool that helps automating tedious tasks of refactoring legacy applications into features and frees the developer from the burden of performing laborious routine implementations.
Taking an extractive approach to decompose a legacy application into features is difficult and laborious with current approaches and tools. We present a prototype of a tooldriven approach that largely hides the complexity of the task.
CIDE is an Eclipse Plug-in. To install you need Eclipse 3.5 (Galileo) running with Java 1.6. (Other versions may work but have not been tested). Install the plugin only in an Eclipse version you don't use productively, since CIDE is in development status and may affect all projects in the workspace.
Use the Update Site http://wwwiti.cs.uni-magdeburg.de/iti_db/research/cide/update/ to install CIDE (see site for instructions).
On installation you may select from the following options
(In case you want to use an older CIDE version (Java only, works in Eclipse 3.3) you can also use this plugin: coloride_1.2.0.jar April 10th, 2008)
Switch to the CIDE perspective.
If CIDE is correctly installed you see a CIDE submenu in the context menu of every project (use the "project explorer", not "package explorer" in Eclipse). In this submenu you find options to specify features, generate variants/products for specific feature selections, or type-check the SPL.
Now you can open every file with a special CIDE editor. In this editor you can highlight a piece of code and select a feature from the context menu. You should see a colored background on this code segment shortly after. If the "Colored Java Editor" (Advanced Java Support) or "Colored Source Editor" (for all other languages) is not show in the "Open With" selection, select it using the "Other..." dialog. Tip: In Eclipse preferences (General - Editors - File Association) you can assign certain file types to always open with the CIDE editor.
In some cases marking color in the code is not sufficiently accurate. In these cases the ASTView (Menu: Window - Open View - ASTView) can assist, as it shows the underlying structure of CIDE and helps understanding how CIDE works. You can select individual AST nodes and color them with the context menu. We recommend to always develop with the ASTView visible.
The features themselves can be edited in the project's context menu. By default only a simple list of features is used (fixed to 50 features). Alternatively an expressive guidsl feature model can be plugged in, or pure::variants can be used. For each feature, a color can be specified. If visibility is not checked the feature is hidden in many options or dialogs.
Only Advanced Java Support and Bali: In the background the whole SPL is type-checked. Typing errors that may occur in some variants are reported (e.g., it checks that a method invocation can find the target method declaration in all variants; thus it is illegal to color only the method declaration but not the invocation in an SPL in CIDE) . The type-checker runs automatically in the background, however in case of problems it can be forced to recheck the entire project using the "Force Type-Checking" operation from the project's context menu. The errors found with these type-checks are signaled like Java errors in the "Problems" view and underlined directly in the source code. Often also "Quick fixes" are provided (context menu).
To create a variant/product for a certain feature configuration select
"Generate Variant" from
the project's context menu. You have to select the features to include
in this configuration and a target project. CIDE
will now
copy the source code to the target project and remove all colored code
that is not included in the variant. The
creation of variants can also be automated using an ANT task from within
Eclipse. Use
the task cide.confGen
as shown
below, with featureSelection containing a comma-separated list of
features that the variant should contain (no whitespace!). Make sure
you run the ANT script from within Eclipse with the same JRE as Eclipse.
<cide.confGen inputProject="coloredProject" outputProject="output" featureSelection="FeatureA,FeatureB,FeatureC" />
Finally
statistics
can be collected
about interactions and even
derivatives (cf. Jia
et
al., Feature oriented refactoring of legacy applications, Proc. ICSE,
2006), again from the project's context menu, or by opening
the
interaction view and selecting "refresh". The result is shown in the
Interactions View. By clicking on the child-entries it is possible to
jump the source code where this interaction occurs. The same view
can also be used for navigation within a single feature.
The derivative notation used is the following: A* contains the changes of A to the base code. B*A* contains the changes of B to the changes made by A to the base code. Therefore B*A* and A*B* are not equal. In cases where the order is not fixed, e.g., if a node is directly colored with two colors, this is shown with parenthesis in the derivative's name. For example, (A*B)* could be stored in either A*B* or B*A*, and D*(C*B*A)*X* could be stored in D*C*B*A*X* or D*A*B*C*X* or similar..
| Language
Extension |
File
extension |
Plugin,
Grammar |
Comments |
|---|---|---|---|
| Featherweight Java |
.fj |
[grammar] |
|
| Java |
.java |
[grammar] | |
| C |
.c, .h |
[grammar] | exact parser, does not understand preprocessor statements |
| C (approx) |
.c, .h |
[grammar] | pseudo-parser, does
not
recognize full structure and not all preprocessor statements; use only one C extension at a time |
| C# |
.cs |
[grammar] | |
| ECMAScript
(JavaScript) |
.js |
[grammar] | |
| Haskell |
.hs |
[grammar] | pseudo-parser, skips over expressions |
| Bali |
.b |
[grammar] | |
| ANTLR |
.g |
[grammar] | simple productions
only, no options or semantic extensions. |
| JavaCC |
.cc |
[grammar] | |
| gCIDE |
.gcide |
[grammar] | bootstrapped
grammar for gCIDE
itself |
| Properties |
.properties |
[grammar] | for line-based
property files |
| HTML and XML |
.html; .xml |
[xml grammar] [html grammar] | XML parser does not parse doctype declarations yet |
| XHTML |
.xhtml |
[.jar] [gen. grammar] | version 1.0 strict, does not understand doctype declaration yet; generated from dtd |
| XML-People |
.xml |
[grammar] | simple
proof-of-concept parser
for the following DTD: [people.dtd];
do not use together with XML extension |
| Name |
Original
Implementation |
Colored
Implementation |
|---|---|---|
| Minimal Stack
Example |
- | [zip,
3kb] |
| Graph Product Line |
[zip,
55kb] [pdf] |
[zip,
34kb] |
| Berkeley DB |
[link,
Oracle] [link,
AspectJ Decomposition] |
[zip, 802kb] |
| Name |
Comments |
Colored
Implementation |
|---|---|---|
| GPL |
Java + HTML Documentation [original paper] | [zip] |
| Berkeley DB |
documentation only,
for Java
code see above, [original
implementation] |
[zip, 2.3mb] |
| AHEAD Tool Suite |
buildfiles and
documentation
(java code stripped because of size) [Original
Implementation] [Previous
Decomposition] |
[zip, 8.9mb] |
| SQL Grammar |
subset of an ANTLR
grammar for
SQL with 4 features |
[zip], [pdf] |
| Haskell Arithmetic
SPL |
Arithmetic
expression evaluator, 16
features, for Haskell & guidsl Plugin |
[zip] |
| Haskell Graph Library | Haskell code, 18 features, for Haskell & guidsl Plugin | [zip] |
CIDE was developed at the University of
Magdeburg, Germany
and the University of Texas at Austin by Christian Kästner.
For
information about the
project, please contact the development team via kaestner
(at)
iti.cs.uni-magdeburg.de. The source code can be requested
via
email for research purposes.
For bug reports and feature requests you can also create a
ticket in
CIDE's
bug tracker.
CIDE Project Members: