Feeds:
Posts
Comments

Bluprint Icon

Bluprint


I just wanted to update you on some of the exciting things that have been happening since my last post. Previously I mentioned that I am incubating an open source software project. That project is called Bluprint. Bluprint is an MDA tool designed to support Agile MDA. Key-points are:

  1. It is built using itself – although to the end user this isn’t too relevant, it does mean it has been put through its paces and can accommodate non-trivial software projects. The current Bluprint software model and code contains over a hundred classes.
  2. It makes very few uses of UML stereotypes. I was aiming to use none, but I had to concede and adopted one, called <<nogen>>. This is used to prevent the generation of code from some parts of the model and is useful when you are modelling third-party APIs.
  3. It supports full lifecycle software development, you can generate code from models, amend the generated code, amend the model and re-generate. All user modifications to the code are preserved because the tool supports intelligent model/code merging. There is no need to use sub-classing for user written extensions or annotations to mark and protect sections of the code.
  4. Bluprint interprets UML models to create Java code currently (but other target languages will be possible in the future). It supports:
    • Classes
    • Interfaces
    • Enumerations
    • Inheritance, both extends and implements
    • Associations
    • Generation of member variables and corresponding accessors.
      • unary members
      • non-unary members, from associations with cardinality greater than one
      • qualified associations
    • Generation of constructors
    • Generation of stub-methods, including throws clauses

Family Tree Example

Let me show you Bluprint in action, to give you a taste of some of Bluprint’s capabilities. It will demonstrate some of Bluprint’s code generation and model/code merging features showing Agile MDA in action.

Imagine we are going to create a program for the creation and management of family trees. In the following example we’ll be able to create people and define their descendants.

  • The Initial Model
    We start by modelling a simple class for representing people in our family tree called Person, which initially looks like this.
    Person class step 1

    Person class step 1


    Bluprint has been developed, initially and tested, with MagicDraw 16.0. The model is created in MagciDraw and exported as an EMF UML 2 (v1.x) XMI file for use by Bluprint. Bluprint is designed to work with any tool that can export UML models in this format.

    After running Bluprint for the first time, the following code is generated. Notice the generation of member variables, accessors and stub methods for main(), print() and the constructor.

    package org.family;
    
    /**
     * Class Person has been generated from a UML model by @author Bluprint.
     * Date: Tue Mar 24 15:18:23 GMT 2009
     */
     
    import java.util.Date;
    import java.lang.String;
    
    
    public class Person {
    
    	private String name;	
    
    	private Date dob;	
    
    
    	public Person(String name) {	
    		// TODO - Auto-generated
    	}
    
    	public static void main(String[] args) {
    		// TODO - Auto-generated
    	}
    
    	public void print() {
    		// TODO - Auto-generated
    	}
    
    	public String getName() {
    		return name;
    	}
    
    	public void setName(String value) {
    		this.name = value;
    	}
    
    	public Date getDob() {
    		return dob;
    	}
    
    	public void setDob(Date value) {
    		this.dob = value;
    	}
    }


  • Edit the Code
    We fill in the details of the stub methods, as follows. For the constructor we just set the name of the Person.

    	public Person(String name) {	
    		this.setName( name );
    	}


    For now the print() method is very simple

    	public void print() {
    		System.out.println( getName() );
    	}


    And in main() we create a single Person object and ask it to print itself

    	public static void main(String[] args) {
    		Person fred = new Person( "Fred" );
    		
    		fred.print();
    	}


    At the moment the model and the code only support the definition of a single stand-alone person. Executing the program we get the following output.

    Fred

  • Amend the Model and Code Merge
    Now we have the basics working, we want to be able to define the descendants of a Person. We amend the model to add a one to many associations from Person to Person. One end represents the parent and the other the descendants. We could have made it many to many, but I wanted to show that Bluprint can handle associations of different cardinalities.
    Person class step 2

    Person class step 2


    We also add a new private method for printing. Note, we don’t need to add this to the model, we could have added it straight to the code, but it is easy to do it here while we are thinking about it.

    We export the model again and run Bluprint against the new model and our original code. Bluprint interprets both and generates the following result for the Person class.

    package org.family;
    
    /**
     * Class Person has been generated from a UML model by @author Bluprint.
     * Date: Tue Mar 24 15:44:16 GMT 2009
     */
     
    import org.family.Person;
    import java.util.Date;
    import java.lang.String;
    import java.util.Vector;
    
    
    public class Person {
    
    	private String name;	
    
    	private Date dob;	
    
    	private Person parent;	
    
    
    	private Vector descendants = new Vector();
    	
    
    	public Person(String name) {	
    		this.setName( name );
    	}
    
    	public static void main(String[] args) {
    		Person fred = new Person( "Fred" );
    		
    		fred.print();
    	}
    
    	public void print() {
    		System.out.println( getName() );
    	}
    
    	private void print(Person person, int depth) {
    		// TODO - Auto-generated
    	}
    
    	public String getName() {
    		return name;
    	}
    
    	public void setName(String value) {
    		this.name = value;
    	}
    
    	public Date getDob() {
    		return dob;
    	}
    
    	public void setDob(Date value) {
    		this.dob = value;
    	}
    
    	public Person getParent() {
    		return parent;
    	}
    
    	public void setParent(Person value) {
    		this.parent = value;
    	}
    
    	public void addDescendant(Person aDescendant) {
    		this.descendants.add( aDescendant );
    	}
    
    	public void removeDescendant(Person aDescendant) {
    		this.descendants.remove( aDescendant );
    	}
    
    	public Person getDescendantAt(int index) {
    		return this.descendants.get( index );
    	}
    
    	public int getDescendantsSize() {
    		return this.descendants.size();
    	}
    }


    Notice the original code changes have been preserved. Bluprint has helpfully added member variables for the parent and the descendants. Some helper methods have been created to allow descendants to be added and removed. In addition members of the descendants collection can also be accessed.

    (The sharp eyed amongst you will notice the Bluprint understands plural names for collections and has created singular forms when adding and removing individual members. So although the Person has many descendants, you add, remove and get individual descendants.)

    A stub method has also been created for the private print() method, which will be used for indenting the name of a person based upon their depth in a descendant tree.

  • Edit the code again
    We add a printIndented() function

    	private void printIndented( String string, int tabs ) {
    		for( int i = 0; i < tabs; i++ ) {
    			System.out.print(  "\t" );
    		}
    		System.out.println( string );
    	}


    We don’t need to add every method to the model since Bluprint is designed to be pragmatic. You can decide what to include in your model and what to leave out as detailed implementation. Bluprint provides reporting so you can identify what has been coded and not included in the model.

    Next we amend our print() methods to look like this

    	public void print() {
    		print( this, 0 );
    	}
    
    	private void print(Person person, int depth) {
    		printIndented( person.getName(), depth );
    
    		for( int i = 0; i < person.getDescendantsSize(); i++ ) {
    			print( person.getDescendantAt( i ), depth + 1 );
    		}
    	}


    Finally we set up some test data in the our main() function

    	public static void main(String[] args) {
    		Person fred = new Person( "Fred" );
    		Person mary = new Person( "Mary ");
    		Person bill = new Person( "Bill" );
    		Person benn = new Person( "Benn" );
    		Person jill = new Person( "Jill" );
    		
    		fred.addDescendant( mary );
    		fred.addDescendant( bill );
    		mary.addDescendant( benn );
    		mary.addDescendant( jill );
    		
    		fred.print();
    	}


    When we run the program we get the following output

    Fred
    	Mary 
    		Benn
    		Jill
    	Bill


    Summary
    The above is a very simple example, but it does demonstrate some of the powerful features of Bluprint including code generation and intelligent model/code merging. Bluprint removes the burden of creating and maintaining a lot of boilerplate code. The engineer can focus on the value add parts of their task which is the coding of the business logic. The power of Bluprint comes into its own for much larger, real world, models containing many classes, interfaces, associations and inheritance.

    Advertisements
  • Things have been a little quiet lately in blog-world as I have been incubating an open source model driven project – watch this space. This has been motivated after taking a look at AndroMDA. Although AndroMDA is excellent I have a number of quibbles. Some of these aren’t unique just to AndroMDA.

    1. Lack of ‘eating your own dog food’. If an MDA tool is worth its salt, surely it must be capable of being used to generate itself from a model. None of the tools that I have seen contain a UML model that describes the software that can be used to generate itself. Obviously there needs to be a bootstrapping process, but once the kernel of the tool is written it can be used to further refine and develop the tool.

      It would be a pretty good acid test, since it would prove that the tool is sophisticated and pragmatic enough to develop a moderately complex application. It addition it would be put through its paces as the model for the application would go through multiple edit, generate and test cycles. (Oh did I mention Agile-MDA? MDA doesn’t preclude being used within an agile development project. I’ll expand upon Agile-MDA in a future blog entry if there is interest.).

    2. AndroMDA makes use of stereotypes to help drive the code generation process. For example the classes within a model being used to represent entities, those classes that are to be made persistent, are flagged with the «entity» stereotype. This helps direct the code generator to create the appropriate persistent code. To this end, the model must include the AndroMDA profile containing the valid AndroMDA stereotypes.

      Although the use of stereotypes provides expressiveness, it does mean that there is a deviation between the classes represented in the model and classes that get generated as code. The MDA purists would argue that this level of abstraction and transformation is acceptable.

      I personally prefer adopted a WYSIWIG (what you see is what you get) approach, where the model is a pretty faithful representation of the classes that will be generated. For example it is possible to model the frameworks and APIs that will be exploited by the implementation model. I argue that by modelling the frameworks and APIs you get a better insight into the structure of that which is being extended and used. In this way you can see clearly the relationship between the classes in your model and those of the frameworks that you’ll exploit.

    3. I’m not a fan of using inheritance to separate generated code and developer written code. We all realise that to be pragmatic, that developers will need to write code in addition to that which is generated. UML (+OCL) isn’t practical for detailed program description.
      Tools like AndroMDA allow developer written code to be contained in an ‘implementation’ class that inherits from a generated class. The generated class can be changed and regenerated, without loosing the developer written code in the inherited implementations class.

      Simple Inheritance
      However this creates an artificial separation between the generated and user written code. If I wish to sub-class the generated class, I can, but I will loose the extensions in the developer written implementation class. There are techniques for getting around this, but this is an extra burden which most developers cannot be bothered with.

      The answer I feel is not to use sub-classing, but to allow developer written code and generated code to be contained within the same class. The tool should be able to merge user written code with generated code so that no developer written code is lost. This is also in line with my previous point, that the model represents more closely what is being generated.

    4. Support of OO concepts. Most tools like AndorMDA can generate simple attributes and accessors (getters/setters). For example if I have a Customer class and an attribute called ‘id’ of type long, this will be faithfully generated. However when we start to use more complex modelling constructs such as a 1 to many association between classes or qualified associations these tools do not provide much assistance.

      Customer and Product
      For instance if the afore mentioned Customer class is associated with a Product class via a 1 to many association as shown, most tools will for create something like the following when generating code for Java,

      public Vector products = new Vector();

      Sometimes it may be declared private and a pair of accessors to the products variable will be provided. However in both cases, the implementation generated does not enforce encapsulation, something as all good OO practitioners we know is a good thing and would want.

      What would be better, would be for the collection to be encapsulated and for the following kind of interface with corresponding implementation to be generated,

      public void addProduct( Product aProduct );
      public void removeProduct( Product aProduct );
      public Iterator getProductsIterator();

      And perhaps optionally,

      public int getProductsSize();
      public Product getProductAt( int index );

      Notice that we don’t break encapsulation. We can add and remove Products to the Customer, and we also provide mechanisms for iterating over the Products associated with the Customer.

      In an ideal world we would also like qualified UML associations to also be supported. These are very useful for representing key, value pairs between classes.

      With this, a lot of boilerplate code can be generated removing the burden from the developer and enabling then to concentrate on creating the unique business logic.

    AndroMDA is an open source model driven architecture project, which is both surprisingly sophisticated and mature.  It allows, for instance, complete J2EE applications to be created from UML models.  The user-interface, business logic and persistence tiers can all be generated.  It supports both BPM4Struts and JSF UI frameworks, Spring, EJBs and Hibernate.  It even has the ability to generate .NET code.  Given its sophistication, I am surprised it isn’t more extensively used.

    In summary AndroMDA is a transformation engine, taking as input a UML model in XMI format containing the UML 1.4 metamodel, and a set of pluggable cartridges.  Each cartridge uniquely transformations the model into output code.  There are separate cartridges for example for jBPM, Hibernate, Spring and EJBs.

    Version 3.3 of AndroMDA provides full Maven integration, so the configuration and operation of the tool is very much simplified.  The Maven automation allows new AndroMDA projects to be created, for these to be developed and subsequently deploy.

    Virtually any UML tool can be used.  I have been using AndroMDA quite happily with MagicDraw 16.0 CE.  The AndroMDA site includes a UML tool support matrix, however this seems a little out of date.

    Installing AndroMDA
    The installation of AndroMDA in a Windows environment can be found at the AndroMDA site.  I have successfully installed and operated AndroMDA on my Mac under Mac OS X 10.5 (Leopard).  It works surprisingly well.  Below are outlined the installation steps for AndroMDA 3.3 on a Mac which mirror those for Windows.

    To set up the AndroMDA development environment you will need to install:

    • Maven
    • AndroMDA itself
    • A UML Tool such as MagicDraw
    • An IDE such as Eclipse

    For the run-time environment you’ll need:

    • A J2EE Application Service such as JBoss
    • A database, MySQL on the Mac works excellently

    Maven Installation

    1. Download Maven from here, http://maven.apache.org/download.html.  I installed and been using version 2.0.9.
    2. Unzip the contents and place it in a folder such as /Users/peterlong/usr/Java.
    3. Create a, or edit your existing, .bash_profile in your home directory (~) so that it includes the following

    4. export M2_HOME=/Users/peterlong/usr/Java/apache-maven-2.0.9
      export M2=$M2_HOME/bin
      export M2_REPO=/Users/.m2/repository
      export MAVEN_OPTS=’-XX:MaxPermSize=128m -Xmx512m’
      export JAVA_HOME=/Library/Java/Home/
      export JBOSS_HOME=/Applications/jboss-4.2.3.GA
      export PATH=$PATH:$M2

    Seeing Hidden Files within the Mac Finder

    By default on a Mac the Finder does not show hidden files and directories that are prefixed with a dot/period (‘.’).  Within a Terminal window use the following so that hidden files can be seen.

    defaults write com.apple.finder AppleShowAllFiles TRUE
    killall Finder

    To disable the display of these hidden files perform the following.

    defaults write com.apple.finder AppleShowAllFiles FALSE
    killall Finder

    Testing the Maven Installation

    1. Open a Terminal window.
    2. Create a temporary project directory, say ~/usr/java/test
    3. cd to the directory and test execution of the maven command with
      mvn –version
      Something similar to the following should have been produced.
      Maven version: 2.0.9
      Java version: 1.5.0_16
      OS name: “mac os x” version: “10.5.6” arch: “i386” Family: “unix”
    4. If this is successful, test the creation of a temporary project, by issuing the following
      mvn archetype:create -DgroupId=testapp -DartifactId=testapp
      After a minute or so you should see
      [INFO] ———————————————————–
      [INFO] Using following parameters for creating OldArchetype: maven-archetype-quickstart:RELEASE
      [INFO] ———————————————————–
      [INFO] Parameter: groupId, Value: testapp
      [INFO] Parameter: packageName, Value: testapp
      [INFO] Parameter: basedir, Value: /Users/peterlong/usr/java/test
      [INFO] Parameter: package, Value: testapp
      [INFO] Parameter: version, Value: 1.0-SNAPSHOT
      [INFO] Parameter: artifactId, Value: testapp
      [INFO] ********************* End of debug info from resources from generated POM ***********************
      [INFO] OldArchetype created in dir: /Users/peterlong/usr/java/test/testapp
      [INFO] ———————————————————–
      [INFO] BUILD SUCCESSFUL
      [INFO] ———————————————————–
      [INFO] Total time: 1 minute 6 seconds
      [INFO] Finished at: Wed Jan 28 16:47:17 GMT 2009
      [INFO] Final Memory: 7M/14M
      [INFO] ———————————————————–
    5. Check that you got BUILD SUCCESSFUL and that a testapp directory was set up containing the corresponding project files.
    6. Delete the test directory when you are finished as you have successfully set up the Maven environment.

    Install the AndroMDA application plugin

    1. Download the AndroMDA Maven plug-in from here.
    2. Unzip the contents and place the org folder into the Maven repository, in my case /Users/peterlong/usr/Java/repo.
      Now we need to build our plugin.
    3. Create temporary directory for building andromda, say ~/Java/andromda
    4. Create the following pom.xml file in this newly created directory

      <project>
      
      <modelVersion>4.0.0</modelVersion>
      <groupId>samples.test</groupId>
      <artifactId>test</artifactId>
      <version>1.0</version>
      <packaging>jar</packaging>
      <name>test</name>
      
      <dependencies>
      <dependency>
      <groupId>org.andromda.profiles.uml14</groupId>
      <artifactId>andromda-profile</artifactId>
      <type>xml.zip</type>
      <version>3.3</version>
      </dependency>
      <dependency>
      <groupId>org.andromda.profiles.uml2</groupId>
      <artifactId>andromda-profile</artifactId>
      <type>xml.zip</type>
      <version>3.3</version>
      </dependency>
      </dependencies>
      
      <build>
      <defaultGoal>compile</defaultGoal>
      <plugins>
      <plugin>
      <groupId>org.andromda.maven.plugins</groupId>
      <artifactId>andromdapp-maven-plugin</artifactId>
      <version>3.3</version>
      </plugin>
      </plugins>
      </build>
      
      <repositories>
      <repository>
      <id>andromda</id>
      <name>AndroMDA Repository</name>
      <url>http://team.andromda.org/maven2</url>
      </repository>
      </repositories>
      
      <pluginRepositories>
      <pluginRepository>
      <id>andromda</id>
      <name>AndroMDA Repository</name>
      <url>http://team.andromda.org/maven2</url>
      </pluginRepository>
      </pluginRepositories>
      
      </project>
    5. Run Maven, by just issuing the mvn command in that directory.
      You should get BUILD SUCCESSFUL as before,
      [INFO] [compiler:compile]
      [INFO] No sources to compile
      [INFO] ————————————————————–
      [INFO] BUILD SUCCESSFUL
      [INFO] ————————————————————–
      [INFO] Total time: 26 seconds
      [INFO] Finished at: Wed Jan 28 17:23:23 GMT 2009
      [INFO] Final Memory: 4M/8M
      [INFO] ————————————————————–
    6. Delete the temporary directory when you have finished.

    Install a UML tool
    I have installed MagicDraw on my Mac, it works surprisingly well (it is a Java app after all).  I am using MagicDraw 16.0 community edition.

    Note that the projects generated by AndroMDA have a dependency on a number of AndroMDA profiles.  MagicDraw expects to find these in the Maven Repository.  For some reason although the directory structure was there, the required xml.zip files were missing.  I manually copied these from the AndroMDA installation profiles directory to the .m2 repository.

    I had to copy the following files:
    andromda-profile-datatype-3.3.xml.zip
    andromda-profile-meta-3.3.xml.zip
    andromda-profile-persistence-3.3.xml.zip
    andromda-profile-presentation-3.3.xml.zip
    andromda-profile-process-3.3.xml.zip
    andromda-profile-service-3.3.xml.zip
    andromda-profile-webservice-3.3.xml.zip
    andromda-profile-xml-3.3.xml.zip
    andromda-profile-messaging-3.3.xml.zip

    Installing Eclipse
    Download and install Eclipse for Mac OS X from http://www.eclipse.org/downloads/.
    Installing JBoss on Mac
    This is really straight forward.

    1. Download JBoss from http://www.jboss.org/jbossas/downloads/.  I have successfully deployed and used 4.2.3 GA.
    2. Unzip the file and move the contents to your chosen installation directory.  I put mine in /Applications.
    3. Edit .bash_profile so that JBOSS_HOME is defined, for example include the following:
      export JBOSS_HOME=/Applications/jboss-4.2.3.GA

    Installing MySQL

    1. Download the latest community edition of MySQL from http://www.mysql.com/.  At the time of writing this is 5.1.31.  Download the version for Mac OS X 10.5 i86.   I elected to use the package installer version rather than tar.
    2. Once downloaded, open the disk image.  The readme file tells you what to do.  Basically double click on the mysql-5.1.31-osx10.5-x86.pkg.  This is an option for installing the auto-start by clicking on the MySQLStartupItem.pkg.  We’ll skip this for now.
    3. Once installed, you can start MySQL using the following (if auto start hasn’t been used).
      cd /usr/local/mysql
      sudo ./bin/mysqld_safe
      (ENTER YOUR PASSWORD, IF NECESSARY)
      (PRESS CONTROL-Z)
      bg
      (PRESS CONTROL-D OR ENTER “EXIT” TO EXIT THE SHELL)
    4. Modify your ~/.bash_profile with the following
      export MYSQL=/usr/local/mysql/bin
      export PATH=$PATH:$MYSQL
    5. This will enable the mysql and mysqladmin commands to be used directly without having to specify the full path.
    6. Download the MySQL GUI Tools from http://dev.mysql.com/downloads/gui-tools/5.0.html.  Again I elected to choose the Mac OS X version.
    7. Open the Disk Image and drag the MySQL Tools folder into Applications.
    8. Download the MySQL Connector/J from http://www.mysql.com/products/connector/j/.  I chose the latest 5.1.7.zip.
    9. Unzip the file and copy the mysql-connector-java-5.1.7-bin.jar file to your JBoss Server installation into server/default/lib.  In my case I am using JBoss 4.2.3.  In the process I changed the file name so that it didn’t contain ‘-bin’.

    Testing your AndroMDA environment
    The AndroMDA site includes a comprehensive tutorial for the creation of a complete J2EE application which includes a Web UI and MySQL backend database, called TimeTracker.  Follow the steps outlined in the TimeTracker tutorial to verify your installation.  Note that you won’t need to installation the MySQL driver if you have followed the steps above.

    In this and subsequent posts I will expand of upon the themes of putting the engineering back into software development.  Along the way I’ll introduce you to some practical tools and techniques.

    I passionately believe that Model Driven Development (MDD) and Model Driven Architecture (MDA) represent one viable approach.  This belief is born from practical experience and success in delivering software using such techniques.  Kalido’s Business Information Modeler, a .NET application was built using MDD.

    There is a wealth of material already written on MDA especially by the Object Management Group (OMG).  However it is written in a pretty dry, formal way that is often impenetrable to the casual reader.  In summary MDA is all about driving the generation of software from models, models that are pictures, models that represent the blueprint for the software.  That’s it, the ability to produce software using a higher level abstraction other than just the code.

    MDA and MDD have many benefits including:

    • It enables rapid prototyping.  I can sketch a model and produce working software quickly.
    • It enables iterative development.  I can tweak my model and regenerate my application frequently.
    • It breaks the disconnection between design and implementation.  No longer will I have design diagrams that are out of date once the code is written.  I can see a picture, the blueprint, of the software that is actually executing.
    • It increases productivity and quality.  Changes to the model will cause amendments to be made to the code systematically, without error prone manual intervention.

    The models in MDA can come in any form, however the use of UML, a modelling notation, is a good popular approach.  UML models can be drawn by hand or more practically using a tool.  I can highly recommend MagicDraw as a UML tool, which I have successfully used for a number of years.  You can download the community edition for free and it even works on my Mac.

    Now creating pictures of software can be a pretty fruitless activity.  In the past developers had to translate these diagrams manually into code.  This was a labour intensive activity and often only preformed once as it was so laborious.  It was next to impossible to ensure that subsequent changes to models could be reliably reflected in the software.  The majority of engineers soon abandoned the use of UML and went to straight coding.

    There are many tools that can be used for translating models into code.  In the next post I will examine one of these in more detail, the open source software AndroMDA.

    A few years ago I started the Angry Architect blog.  Since then I have calmed down a little and having been unable to recovery my account password, I have decided to start afresh.

    In this blog we’ll explore my personal journey through the world of software.  I feel as an industry we are heading off in the wrong direction.  We are no better at creating software than we were when I started twenty years ago.  We as an industry fail to learn and improve.  Software is hard to create, it is often delivered late and when it does arrive it fails to meet expectations.  Even one of the most successfully software companies in the world, with all its vast resources, is unable to produce software on time and to budget.  (Microsoft delays Vista ).

    In these credit crunch times I hope that the industry is forced to change.  The answer I feel isn’t off-shoring software development, as that just moves the problem somewhere else and only delays the day when companies will have to address the underlying software economic issues.  It isn’t following the latest fad such as agile development, appealing as this seems, as this isn’t providing the step change needed in producing software.

    Software is incredibly labour intensive.  We are still in the Middle Ages as a discipline.   We rely on all too primitive tools and the herculean efforts of individual coders.  We think that by building better IDEs with IntelliSense, auto-completion and refactoring editors that this is the answer.  Unfortunately I think that this is not the case as we are still scratching away at code.  Painful as it seems, we need to break away from this paradigm and raise ourselves up to a higher level of abstraction.

    We attempt to call software development an engineering discipline however I see very little engineering being done in software today.  If we compare ourselves to architecture, electronics and product engineering, we see the habitual use of blueprints, circuit diagrams and design schematics.  These are used to explore solutions, reason about and predict the characteristics of implementations before they are built.  Building engineers are able to test the load-baring characteristic of a bridge before it is built for instance.  By comparison we are unable to do this for software.

    Unfortunately I don’t personally have the answer, I wish I did.  However I would like in this blog to touch upon some themes, technologies and approaches that I think point the way in which we should be heading if we are to put software engineering back into software development.