International Design Conference:

The goal of the DESIGN conference is to bring together researchers who have worked on or thought about engineering and industrial design from a variety of perspectives, disciplines, and fields: engineering, aesthetics, ergonomics, psychology, sociology, and other disciplines. Therefore, we encourage contributions describing the role and importance of collaborative design in the overall product cycle and interdependencies between the design activity and other product development processes.

Conference is in part organized by The Design Society, which has DTU Professor Mogens Myrup Andreasen among its initiators.International Engineering Management Conference (IEMC):

IEMC 2005 invites papers for presentation at the conference. Suggested topics include but are not limited to:

* Rebuilding from Devastation
* Environmental Management
* Supply Chain Management
* Quality Management/Business Excellence/Six-Sigma
* Knowledge Management
* Engineering Management
* Technology/Innovation Management
* Managing "Mega-Projects

Conference is in part organized by the IEEE Engineering Management Society (EMS)

If you enjoyed this post, make sure you subscribe to my RSS feed!

Resultater fra Eventyrløb:

2006:

2005:

2004:

2003:

If you enjoyed this post, make sure you subscribe to my RSS feed!

As noted in an earlier post, I am currently reading "Notes on the Synthesis of Form" by Christopher Alexander.In chapters 2 and 3, Alexander explains how the aligment between form and context in a design ensemble can be expressed as a system of binary variables. Each variable of the system represents a potential misfit of the ensemble and the value of the variable indicates if the misfit is occurring. Alexander illustrates a such system by referencing an example from the book "Design for a Brain", by W. Ross Ashby - one of the founding fathers of cybernetics. The example is about a system of lightbulbs. Each lightbulb can be either on or off; if a lightbulb is on, it can go off in a second. The lightbulbs are connected, such that the state of any lightbulb depends on the states of the connected lighbulbs: If a lightbulb is off and it is connected to at least one lightbulb that is on, there is a chance that the lightbulb will also go on in a second.

Alexander then analyses how different configurations of the connections between lighbulbs causes the system to react to change in different ways. From the example, Alexander conclude that the internal decomposition of a system is reflected by the way, in which the system reacts to change.

Alexander's description made me think of the object-oriented design principle concerning decomposition: "Low Coupling & High Cohesion". I knew that Alexander had something to do with this, that much seems to be established. But I started to think about ways to determine, if coupling and cohesion are appropriately designed in a software system? I mean, clearly it is something you strive for as a designer, but do you succeed? Of course, this is something you can get a feel for - as a developer. An unstable code base, difficult maintenance, ridding bugs in one part of the system makes bugs appear in other parts etc., are all indicators of bad decomposition. But what if it would be possible to actually measure coupling and cohesion? My idea was to analyze the information in a Concurrent Version System - CVS - repository for a given software system. If one were to correlate update information with information about packages and references across package boundaries, it should be possible to get some measure of the decomposition of the system. E.g. for at system with *bad* decomposition, you would expect that an update to any one component (fixing a bug, introducing a new feature etc.) would "ripple" to components in other parts of the system, and thus result in a swarm of updates across the system.

I decided to do a little checking, to see if something like this has already been developed. I first came across The System and Communication Group, GSyC, at the Universidad Rey Juan Carlos in Spain. GCyC do conduct research based on analysis of CVS repositories. Their approach, however, is based on the application of social network analysis [1] and therefore seems to be primarily concerned with the relationship between developers and code structure - not the structure of the code by itself.

I then found my way to professor, Dr. Harald Gall and his research group at the Department of Informatics at the University of Zurich in Switzerland. Dr. Gall and his group appears to have developed some analysis tools that are capable of perfoming exactly the kind of measurements, that I was thinking of: through the combination of three different analyses, their approach lays bare the logical couplings of the system [2]. If you compare figures 1 and 2 from [2] with the illustrations of force interdependencies in "Notes on…" (pp. 43), the resemblance is striking. By searching for work that cite [2], I was also able to locate the LOOSE research group at Polytechnical University of Timisoara, Romania. The LOOSE group appears to conduct research of a similiar kind [3].

[1] L. Lopez-Fernandez, G. Robles and J. M. Gonzalez-Barahona. Applying Social Network Analysis to the Information in CVS Repositories. In Proceedings of the Mining Software Repositories Workshop. 26th International Conference on Software Engineering, Edinburgh, Scotland, 2004.

[2] H. Gall, M. Jazayeri and J. Krajewski. CVS Release History Data for Detecting Logical Couplings. In Proceedings of the International Workshop on Principles of Software Evolution (IWPSE), Helsinki, Finland, IEEE CS Press, pp. 13-23, September 2003.

[3] T. Girba, S. Ducasse, R. Marinescu and D. Ratiu, Identifying Entities That Change Together. In Proceedings of 9th IEEE Workshop on Empirical Studies of Software Maintenance (WESS 2004), Chicago, USA, 2004.

If you enjoyed this post, make sure you subscribe to my RSS feed!

I have had a busy weekend, updating and improving this site.
First, I got the details down on implementing a search function for this blog, using the Apache Lucene search engine. As noted earlier, I have been wanting to get this done for some time and you can now see the result in the menu on the left. The way in which Lucene is used on these pages is illustrated by the class diagram shown below.

Next, I have deployed ROME - Rss and atOM utilitiEs - to generate a RSS 2.0 syndicated web feed from recent blog entries. ROME required a small work-around, since there is a problem with the encoding of the generated XML (in ROME v. 0.5).
ROME uses the

as the super type for all feeds. The encoding to be used can be set using the

method. Unfortunately, any set encoding is not used by the ROME parser, so usage of this method is to no avail. Luckily, ROME can output the generated feed to a JDOM

object (

) upon which an encoding can be set, and the

object can then be outputted to XML, using JDOM's

. This is actually what ROME does behind the scenes, save for the encoding bit.
The hack goes something along these lines:

/* Generate feed using ROME API prior to this */
SyndFeedOutput output = new SyndFeedOutput();
Document doc = output.outputJDom(feed);
String encoding = feed.getEncoding();
Format format = Format.getPrettyFormat();
format.setEncoding(encoding);
XMLOutputter outputter = new XMLOutputter(format);
outputter.output(doc, writer);

Finally, I decided to subscribe to the services offered by statcounter.com:

Got a website? Get a StatCounter! A free yet reliable invisible web tracker, highly configurable hit counter and real-time detailed web stats. Insert a simple piece of our code on your web page and you will be able to analyse and monitor all the visitors to your website in real-time!

It took me approx. five minutes to register, set up a project for this application and copy-paste the necessary bits of code into my pages. So far, it has been most informative.

If you enjoyed this post, make sure you subscribe to my RSS feed!

I am currently reading "Notes on the Synthesis of Form" by Christopher Alexander - a most remarkable book. Since first learning about design patterns and software architecture, I have been vaguely aware of Alexander's influence on the field of software engineering. I have never, however, tried to read any of his books - save a few, brief stints into "The Timeless Way of Building".
In comparison, "Notes on…" is a much more accessible book.

As has been noted by many others before me, this book is a wealth of information about design processes and the structures of designed artifacts. I will not attempt to list Alexander's many significant observations here, but I will try to give a brief overview of the fundamental idea of the book…
The book is divided into two parts - in the first part, Alexander:

• Argues for the necessity of rational design approaches.
• Explains how a design problem can be viewed as a cybernetic system of interdependant variables of potential misfits.
• Analyses why current (1964) design approaches cannot achieve good fitness for a such system.

Detailed description of the first part of the book:

Design used to be carried out within a tradition, which would guide the decisions of the designer, but

…what once took many generations of gradual development is now attempted by a single individual. (pp. 5)

Add to this the fact, that we live in a modern world and have great ambitions:

At the same time that the problems increase in quantity, complexity, and difficulty, they also change faster than before. New materials are developed all the time, social patterns alter quickly, the culture itself is changing faster than it has ever changed before. (pp. 4)

Despite this lack of innocence in the modern world, many designers insist on innoncence - design must be a purely intuitive process. This is not good, we need rational approaches, since

A logical picture is easier to critize than a vague picture since the assumptions it is based on are brought out into the open. (pp. 8)

Alexander then proceedes to outline a such, rational approach,

…based on the idea that every design problem begins with an effort to achieve fitness between two entities: the form in question and its context. In other words, when we speak of design, the real object of discussion is not the form alone, but the ensemble comprising the form and its context. Good fit is a desired property of the ensemble which relates to some particular division of the ensemble into form and context. (pp. 15-16)

The fitness relation between form and context can be expressed as a system of binary varaibles, where each variable describe a potential misfit. The system is decomposed through interdependencies between variables. The nature of the decomposition can be established by examining the system's response to change:

As form-making proceeds, so the system of variables changes state. One misfit is eradicated, another misfit occurs, and these changes in turn set off reations within the system that affect the states of other variables. (pp. 38)

Alexander distinguishes between design processes in unselfconscious and selfconscious cultures.

I shall call a culture unselfconscious if its form-making is learned informally, through imitation and correction. And I shall call a culture selfconscious if its form-making is taught academically, according to explicit rules. (pp. 36)

Designprocesses of unselfconscious cultures are suited to achieve fitness for a system of potential misfit, because

…the directness of the response to misfit ensures that each failure is corrected as soon as it occurs, and thereby restricts the change to one subsystem at a time. And on the other hand the force of tradition, by resisting needless change, holds steady all the variables not in the relevant subsystem, and prevents those minor disturbances outside the subsystem from taking hold. (pp. 52)

While the design processes of selfconscious cultures are unable to achieve fitness for the proposed systems of potential misfits, due to modernity plus the selfconscious design approach's attempt to grasp large and complex design problems by conceptualizing requirements based on function [functional decomposition?]:

…the viscosity which brought the unselfconscious process to rest when there were no failures left, is thinned by the high temperature of selfconsciousness. (pp. 56)

The form-maker's assertion of his individuality… (pp. 57)

In the selfconscious situation, …, the designer is faced with all the variables simultaneously. …he tries to break the problem down, and so invents concepts to help himself decide which subsets of requirements to deal with independently…These concepts will not help the designer in finding a well-adapted solution unless they happen to correspond to the system's subsystems. (pp. 65)

If you enjoyed this post, make sure you subscribe to my RSS feed!