Hudson, a continuous build tool

Software configuration management(SCM) is the corner stone of every good software development. SCM is a generic term which includes Source managements (CVS, SVN, Mercurial, ...), issue management (Mantis, Bugzilla, Jira, ...), CMS for the documentation management (Joomla, Drupal, ...), version management through the use of methods (scrum, xp, ...), and finally build management, ie the ability to generate automatically production ready software from the source. It is especially needed when development is test-driven, or continuous-build-driven.
To perform this goal we have many possibilities :

• hand-written scripts in whatever language
• use of ANT, GANT, Maven, ...
• use of continuous build dedicated tools like Continuum, Luntbuild, CruiseControl ; these tools generally use the previous possibilities to perform the builds.
  

A quite new project has emerged this year : Hudson.

As the introduction says : "Hudson monitors executions of repeated jobs, such as building a software project or jobs run by cron. Among those things, current Hudson focuses on the following two jobs:

1. Building/testing software projects continuously, just like CruiseControl or DamageControl. In a nutshell, Hudson provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.
2. Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those that are run on a remote machine. For example, with cron, all you receive is regular e-mails that capture the output, and it is up to you to look at them diligently and notice when it broke. Hudson keeps those outputs and makes it easy for you to notice when something is wrong."

See the demo videos.
For french readers, a good tutorial is available here.
It also exists an eclipse plugin for Hudson.

The use of mockup for specifying graphical applications

Specifying an application is the corner stone of software development success ; well performed, the end-product has a chance to be compliant with the customer needs, if not, the success is unpredictable.
We've seen in a previous post that the specification phase consists in defining the problem domain, and especially a knowledge model in interaction with the system under study. So we have to focus on formalizing the definitions, the domain rules and the functionnalities the customer need.
Many technics may be used to perform theses tasks, and especially use case diagrams, sequence diagrams, user stories, and so on...
Once we begin to have a good understanding of the problem, we have to ensure that this understanding is in conformance with the customer one. This has to be done before starting any development of course.
The use of a mockup is then highly recommended, especially when designing a graphical application, but obviously not only.
There are many ways to do this :

• word documents or diagrams on paper : it is the old way. It is very uneffective, especially when there are many stakeholders in the decision process
• diagramming tools like visio, smartdraw, ... : it is better than nothing, but we have to face to a static way of presenting the mockup... The dynamic aspect is bypassed... and yet, ergonomics is also a matter of dynamics
• graphics tools like photoshop, paintshoppro, .. : the result is smarter than with the former tools, but the result is the same. We may also introduce confusion while mixing application design, and presentation design, which are two different things in my opinion. We also need some specialists to perform this task.
  
• development tools like dreamweaver, eclipse, visual studio : in that case we can have dynamics and then have relevant advices from the customers. The counterpart is a development time which is not compliant with the iterative and quick process of specification. By experience, it is a very consuming task. The use of GWT or similar frameworks may nevertheless be taken into account to reduce the drawback. But the collaborative aspect of the specification is absent.
  
• wikis like google sites or editme : it is an alternative way of performing the mockup ; it is quite easy to use, it is a collaborative (a major point, we may for instance leave comments on each page), quick to develop. But up to know, we still lack of ready to use components/wireframes to simplify the development. Another alternative is to use powerpoint to do this, but it is less collaborative.
• specialized tools like Axure ones : the goal of this kind of tools is to help the specifier to quickyl develop mockup by combining the advantages of all the former solutions described here. Of course it is not gratis, but I think this approach is the right one.

As said previously, I thing we have to dissociate the functional mockup to the graphical design.
The use of wireframes can be very helpful to do this (another link).

Thoughtfulness about specification phase

In the post series about definitions, I would like to focus today on the specification phase, and in particular on viewing this phase according to different perspectives we used to use. It is not revolutionary while we root them out "old methods" like SART or HOOD.
First of all I would like to consider the V life cycle, which is traditionnaly used as reference for every life cycles, under the concepts of Problem and Solutions domains.
We actually can break down the V life cycle into two main parts, i.e.

1. Problem domain : it is the modelization from an external point of view of the real system under development, and also the requirements wrt the system to be developped. We find in this area three main types of activities, ie establishing system needs document by the customer, describing by IT guys the software specification from this document, describing then running validation tests, and qualification tests
   
2. Solution domain : it is the internal view of the system under development which regroups the following formal phases : analysis, design, coding, verification testing(unit and integration testing)

In this post, we focus specifically on the specification phase which is part of the Problem domain area.
The goal of the sofware specification is to provide the development team with a set of elements needed to realize in the best conditions a system which is as close as possible from the customer needs.
There are many means to reach this goal. We can envisage :

• simulation
• modelisation
• mockups and prototypes
• free textual expression of the needs
• formal specifications with methods like the B Method
• ...

All these methods can be used simultaneously of course, everything being a matter of means and/or time.
It is important to notice that the specification model pursues three goals, ie :

• a cognitive aiming, ie understanding the environment of the system under development. We then speak about establishing the Knowledge model
• a prescriptive aiming, ie undertanding interactions between the environment and the real system under development. We then speak about Requirement model also known as Interaction model
  
• an operational aiming, ie designing an effective system in order to fulfill customer needs as close as possible; it is known as Operational model.
  

Knowledge and Requirement models are part of the Problem domain and the Operational model mainly constitutes the Solution domain.
Knowledge and Requirement models establishment is the goal of the specification phase.

We'll see in later blog messages a deeper definition of thoses models.

The AMMA project

We have spoken formerly about the IMP project, Methods, Models, and so on... I would like today to speak about the AMMA project which is actually the umbrella project for different projects around model management.
In order to perform Model Oriented Development(MOD), or also called Model Driven Development(MDD), we need advanced tools to perform modelization, model to model transformations, model merging, etc...
It is the goal of the AMMA(Atlanmod Model Management Architecture) project developped by the INRIA AtlanMod team directed by Jean Bezivin, i.e. to propose a global platform to ensure all these tasks. It is obviouly still research projects, but some of them like the ATL project have reached a quite mature point to be used in production.
What are the main projects of the AMMA platform? We can find the following ones :

• AM3(Atlanmod MegaModel Management): the goal is to help developpers to manage megamodels (models composed of models as elements), i.e. create, store, view, access, and modify these ones. In a domain where many models are handled, the need of such platform is obvious to reduce complexity and render their use possible
  
• AMW(Atlanmod Model Weaver):when we have many models, we may want to combine them or merge them. It is done by the model weaver.
  
• ATL(Atlanmod Transformation Language): this project enables the developper to transform an instance of a model into another one of another model, eg a powerpoint document into an excel sheet. ATL define also a Virtual Machine to perform the tranformations efficiently. ATL is furthermore well tooled by ADT(ATL Development toolkit) an eclipse plugin used to write transformation with the ATL language, and even debug them.
  
• KM3(Kernel Meta Meta Model): it is an implementation-independent language to write metamodels, and thus to define abstract syntaxes of Domain Specific Languages
• TCS(Textual Concrete Syntax): it is an Eclipse/GMT component that enables the specification of textual concrete syntaxes for Domain-Specific Languages (DSLs) by attaching syntactic information to metamodels. With TCS, it is possible to parse (text-to-model) and pretty-print (model-to-text) DSL sentences. Moreover, TCS provides an Eclipse editor, which features: syntax highlighting, an outline, hyperlinks, and hovers for every DSL which syntax is represented in TCS.
• MoDisco(Model Discovery): the goal of the project is to provide a support for model-driven reverse engineering, i.e. principles, methodologies and tooling.
• ACG(ATL VM Code Generator): it is a domain specific language designed to express the compilation of a model transformation into ASM code executable by the ATL Virtual Machine (ATL VM).

We can see that all the bricks are present in order to reach Model Driven Engineering heaven. The challenge now is to :

• provide a well packaged set of all these tools to be usable in a simple manner
• reduce the learning curve to be adopted by developpers
• evangelize a lot these technos
• give evidence that there is a quite big capital gain to switch to such a technology

Nevertheless, I find promising and well thought all these projects, and I hope you'll browse them deeply after reading this post.

OpenUp, an agile method

Agility has been trendy since some years, but it is not just fashionable ; it is a right way to ensure that software development will produce a high quality software in time and matching the customer needs.
It exists well-known agile methods like XP, Scrum, DSDM, and so on... We won't discuss today about them, but in particular of the OpenUp method which has been developped since 2 years under the umbrella of the Eclipse Consortium, right next to the EclipseWay method, the agile method directly derived from the Eclipse development scheme.
OpenUp states for Open Unified Process, and is based upon an iterative and incremental approach.
In my point of view, this method could match quite well the Change function assertion, which stipulates that the success can be formalized by the following function :

Change Function = F(Perceived Crisis/Perceived Pain of Adoption)

For the Perceived crisis aspect, we all actually know projects which don't end, are abandonned, or don't achieve goals the customer wanted to reach. Industrialization of the sofware process is quite far behind today industrialization in automotive, aerospace or even games domains. Agility is a pragmatic way to industrialize at low cost and in effective manner software engineering.
For the Perceived Pain of Adoption aspect, I find that OpenUp is a good mix between more traditionnal concepts/vocabulary and agiles ones. For someone who understood the agility paradigm and is used to use traditionnal methododologies like for instance RUP, transition will be softer.

OpenUp rests upon three angular stones :

• requirement management through the use of use cases and scenarii
• hazard/risk management
• an approach clearly centered on architecture very early in the life cycle

OpenUp can be used for small projects, but it is best suitable for larger size projects IMO.
OpenUp follows the Agile manifest too, i.e. centered on :

• the team : "people and interactions rather than process and tools"
  
• the application : "Functionnal sofware rather than complete documentation"
• the collaboration : "Collaboration with the customer rather than contract negocaition"
• accepting changes : "React to changes rather than follows a predefined planning"

Moreover, OpenUp proposes the following project life cycle in 4 phases:

• Starting the project (Inception) :the goal is to get agreement of the actors of the project on what we have to do and how
• Elaboration : the goal is to discriminate the technical risks from the non technical ones
• Construction : the goal is to develop at the best cost a full product which can be deployed in an operational manner
• Transition : the goal is to ensure that the software is ready to be delivered to the end-user customers

OpenUp overal process

Inside each phase you have an iteration phase lifecycle, and inside this iteration phase micro-increments (typically daily).
It is not the topic of this post to describe in details the OpenUp method, so I enjoin you to visit the OpenUp web site here for further information.

Team Concert on the Jazz Technology Platform

Rational Team Concert 1.0 was just out on jazz.net one month ago. It is the first collaborative development tool based uppon the Jazz technology platform initiated by IBM to improve collaborative agile development. An edition named Express-C is available for free.

The platform is a mix of tools as Eclipse plugins and web 2.0 pages, and offers all the basic features - as described by IBM- to:

• Support seamless integration of tasks across the software lifecycle.
• Facilitate team collaboration and coordination throughout the software lifecycle.
• Provide an extensible platform.
• Help teams build software more effectively.
• Support globally distributed development teams.
• Provide solutions scalable from small teams up through large enterprises.
• Maintain audit trails and automate bookkeeping so that teams are accountable.
• Support UI integrations (IDE, web browser, etc.) that fit the needs of customers.
• Foster a broad ecosystem of tool providers, including independent software vendors (ISVs).
• Make software development more enjoyable.

The Jazz Platform's principal role is to provide tool writers with mechanisms to use, and rules to follow, that lead to seamlessly-integrated lifecycle tools. These mechanisms are exposed via well-defined APIs. The Jazz Platform also provides useful building blocks and frameworks that facilitate developing new tools.

A diagram is often the best means to quickly understand an architecture :

Jazz is itself developped in an agile way by using the EclipseWay development scheme (which is expressed itself by the ECPF tool). It is called Open Commercial Software Development.

I tested Jazz as early adopter one year ago, and I thought then it was a very promising platform built uppon a solid conceptual model and prooved tools. I've not yet tested the first occurence of Team Concert, but I'll do it quite soon. My opinion is that the platform aims relative big projects with many developpers working together in a collaborative way, i.e. under a customizable agile approach. The result is a relative consequent tool which needs to be administered and planned in the company organization as we have to administer SCM tools in big organizations. It is obviously not a drawback, but you have to take this data into account.

Distributed Revision Control

Software engineering can't be well processed without also a good SCM (Sofware Configuration System) policy. A corner stone of SCM is Revision Control which aims to trace along the development phase (and later) every artefact of the application under development.
We of course know all of us Revision Control systems like CVS and its autoproclamated successor Subversion. We know Clearcase, Sourcesafe, and so on... We know the differences between "pessimistic" and "optimisitic" approaches in revisions systems.... We also know the concept of task oriented systems which enables the developper to revision a set of changes for a specific task.
Since several years we also have to confront "centralized" and "distributed" Revision Systems, a new battle between "ancients" and "moderns".
I let you discover three tools of this new revision control paradigm

• Mercurial : the most advanced system in my sense, and already used by several big companies or projects
• GIT : initiated by Linus Tornval, a mix between a revision Control system and a new kind of files system itself
• Monotone : interesting, but newer, less used and tooled fup to now
  

I let you also read this introduction of Mercurial I find interesting, and which gives a very good overview of the ins and outs of the paradigm and the tool.