The design co-ordination framework : key elements for effective product development

This paper proposes a Design Co-ordination Framework (DCF) i.e. a concept for an ideal DC system with the abilities to support co-ordination of various complex aspects of product development. A set of frames, modelling key elements of co-ordination, which reflect the states of design, plans, organisation, allocations, tasks etc. during the design process, has been identified. Each frame is explained and the co-ordination, i.e. the management of the links between these frames, is presented, based upon characteristic DC situations in industry. It is concluded that while the DCF provides a basis for our research efforts into enhancing the product development process there is still considerable work and development required before it can adequately reflect and support Design Co-ordination

Distances to six Cepheids in the LMC cluster NGC1866 from the near-IR surface-brightness method

We derive individual distances to six Cepheids in the young populous star cluster NGC1866 in the Large Magellanic Cloud employing the near-IR surface brightness technique. With six stars available at the exact same distance we can directly measure the intrinsic uncertainty of the method. We find a standard deviation of 0.11 mag, two to three times larger than the error estimates and more in line with the estimates from Bayesian statistical analysis by Barnes et al. (2005). Using all six distance estimates we determine an unweighted mean cluster distance of 18.30+-0.05. The observations indicate that NGC1866 is close to be at the same distance as the main body of the LMC. If we use the stronger dependence of the p-factor on the period as suggested by Gieren et al. (2005) we find a distance of 18.50+-0.05 (internal error) and the PL relations for Galactic and MC Cepheids are in very good agreement.Comment: Presented at the conference "Stellar Pulsation and Evolution" in Monte Porzio Catone, June 2005. To appear in Mem. Soc. Ast. It. 76/

Off-lattice Monte Carlo Simulation of Supramolecular Polymer Architectures

We introduce an efficient, scalable Monte Carlo algorithm to simulate cross-linked architectures of freely-jointed and discrete worm-like chains. Bond movement is based on the discrete tractrix construction, which effects conformational changes that exactly preserve fixed-length constraints of all bonds. The algorithm reproduces known end-to-end distance distributions for simple, analytically tractable systems of cross-linked stiff and freely jointed polymers flawlessly, and is used to determine the effective persistence length of short bundles of semi-flexible worm-like chains, cross-linked to each other. It reveals a possible regulatory mechanism in bundled networks: the effective persistence of bundles is controlled by the linker density.Comment: 4 pages, 4 figure

The Rascal Language Workbench

Rascal is a programming language for source code analysis and transformation. This means that typically the input of a Rascal program is a program in some programming language, and the output is often yet another program. So Rascal is a meta programming language. Source code is thus primary object of manipulation in Rascal. Many of the use cases that Rascal is designed to address, follow the Extract-Analyze- SYnthesize, or EASY paradigm (shown in Figure 1.1). Meta programs often start by extracting information (facts) from the input program. This is the extraction phase. An example could be the call-graph of a program. Then, this extracted information is often subject to analysis: derived facts are computed, the information is enriched. For the call graph, a simple analysis is determining the root or leaf routines in the a source program by analysing the extracted call-graph. Another analysis could be concerned by identifying routines that are never called (dead code). Finally, the meta program will synthesize some kind of result. This can be transformed source code (e.g., removal of dead code from the input program), a report (e.g., statistics on the number of root and leaf routines), or a visualization (e.g., a graphical depiction of the call-graph). Of course, these phases are not strictly sequential: there may be feedback loops. Some analysis leads to new extraction, synthesis of a result may lead to new analyses and so on. Rascal has elaborated features to support each of the phases of the EASY paradigm fully integrated in the language. Naturally, the implementation of domain specific languages (DSLs), or more generally, modeldriven engineering (MDE) fits the EASY paradigm very well. When implementing a DSL compiler or interpreter the input is, of course, DSL source code. Extraction could, for instance, include the derivation of an AST from the concrete syntax tree. Another extracted model could be a graph-like structure representing the input in a more abstract way, or a performance model. Such abstractions are input to analyses such as constraint checking or type checking, verification, quality-of-service analysis etc. Finally, synthesis covers tasks such as graphical visualization, code generation, and optimization. To conclude, in the context of Rascal, we see DSL implementation as an instance of source code analysis and transformation

Composing configurable Java components

This paper presents techniques to reason about the composition of configurable components and to automatically derive consistent compositions. The reasoning is achieved by describing components in a formal component description language, that allows the description of component variability, dependencies and configuration actions. It also enables the automatic, configuration-driven, derivation of product instances. To illustrate the approach we instantiate the abstract component model for Java components (packages

Backtracking Incremental Continuous Integration

Failing integration builds are show stoppers. Development activity is stalled because developers have to wait with integrating new changes until the problem is fixed and a successful build has been run. We show how backtracking can be used to mitigate the impact of build failures in the context of component-based software development. This way, even in the face of failure, development may continue and a working version is always available