I will try to give more insight into PA by using a more formal approach. In the section below I will use the definitions “success state” and “system” a lot. I will define these first:

Success state: P_1 and P_2 and … P_N

P_x (1 <= x <= N) is a predicate, for example: P_1 == (All timesheets employees are submitted), P_2 == (All submitted timesheets are correct).

System: S

S => P_i and P_i+1 and … P_i+m and Q_j and Q_j+1 and … Q_j+n

where P_i and P_i+1 and … P_i+m is a subset of our success state P_1 and P_2 and … P_N

Q_j and Q_j+1 and … Q_j+n are additional predicates, not in our success state.

Instead of system you can also read solution. A system can be an already existing system or something that can be built. To illustrate the difference between traditional strategies and the PA strategy, we will do a step by step construction towards an at first unknown success state T_success. We will start from an empty state T_empty.

Traditional strategy 1:
Step 1) Design new component C_1.
Step 2) Check new state T_1 with customer: is this state the success state? Yes: done, No: proceed.
Step 3) Design new component C_2, connect C_2 to C_1.
Step 4) Check new state T_2 with customer: is this state the success state? Yes: done, No: proceed.
Step 5) Design new component C_3, connect C_3 to C_2 and C_1.
Step 6) Check new state T_3 with customer: is this state the success state? Yes: done, No: proceed.
…

The first strategy starts building new components, one at a time. After each component is finished we check if success state is reached. This is not unlike many hobby projects where you start from scratch and build a component at a time. Once you are happy with result you have reached T_success.

Traditional strategy 2:
Step 1) Apply systems S_q, S_q+1, … , S_q+k (short: S_q’) to T_empty.
Step 2) Check new state T_k’ with customer: is this state the success state? Yes: done, No: proceed.
Step 3) Design new component C_1, add this component to S_q’.
Step 4) Check new state T_k1′ with customer: is this state the success state? Yes: done, No: proceed.
Step 5) Design new component C_2, add this component to S_q+1′.
Step 6) Check new state T_k2′ with customer: is this state the success state? Yes: done, No: proceed.
…

The second strategy starts from a combination of, most likely existing, systems. We then add components one at a time. After each component we check if we have reached the success state. This is a way of building systems which is used often when adding functionality to legacy systems.

Traditional strategy 3:
Step A.1) Apply a permutation of systems S_q, S_q+1, … , S_q+k (short: S_q’) to T_empty.
Step A.2) Check new state T_k’ with customer: is this state a good enough approximation of the success state? Yes: proceed to B.1), No: proceed.
Step A.3) Apply a different permutation of systems S_q, S_q+1, … , S_q+k (short: S_q1′) to T_empty.
Step A.4) Check new state T_k1′ with customer: is this state a good enough approximation of the success state? Yes: proceed to B.1), No: proceed.
Step A.5) Apply a different permutation of systems S_q, S_q+1, … , S_q+k (short: S_q2′) to T_empty.
…
Step B.1) Design new component C_1, add this component to previously found near success system permutation S_q”.
Step B.2) Check new state T_k1” with customer: is this state the success state? Yes: done, No: proceed.
Step B.3) Design new component C_2, add this component to previously found near success system permutation S_q”.
Step B.4) Check new state T_k1” with customer: is this state the success state? Yes: done, No: proceed.
…

The third, somewhat less traditional, starts by finding a good combination of systems. This combination should give a good approximation of the final state the customer wants to achieve. Only then you start adding new components.

Classic PA strategy:
Step A.1) Create a definition of T_success, called T_success’.
Step A.2) Check T_success’ with customer: is this state the success state? Yes: proceed to B.1), No: proceed.
Step A.3) Change the definition of T_success’ resulting in a new definition called T_success1′.
Step A.4) Check T_success1′ with customer: is this state the success state? Yes: proceed to B.1), No: proceed.
…
Step B.1) Directly derive definitions of components C_1, … C_u from best definition T_success”.
Note that C_1, …, C_u => P_1 and P_2 and … P_N must hold.
Step B.2) Match components C_1, … C_u with systems S_q, S_q+1, … , S_q+k.
Step B.3) Choose best matching(s). For these matchings T_success” must be a subset of resulting state T_matching.

PA first creates a state definition as close as possible to the success state. It then reviews and alters this state iteratively. Only when the definition is satisfactory the next phase starts. In this phase component definitions are derived from the success state definition. These component definitions are then matched with systems and the best matchings are chosen. Simplicity is important in PA: we always strive for a correct succes state with minimal size.

Note that the first two traditional strategies have no real focus on the final success state. This means that during development the chosen success state might actually be (a lot) different than the real success state. The biggest difference between the third strategy and the PA strategy is that in PA we disregard existing systems (read: solutions) until a really good success state definition has been found. Also, we extract as much information as we can from the success state definition. We then use this information to define components. Each component definition should represent a part of the success state. These component definitions should be mutually exclusive (i.e. no overlap) and all component definitions together should imply the success state. Next we match the component definitions with all known systems and come up with the best matchings. Classic PA is almost done here. We now compare the best matchings and present them, with cost figures, to the customer.

As mentioned earlier an important aspect of PA is the separation of the success state from any solution. This is important because of the reduced effort needed: anyone involved in the process can just think about the success state and can forget about (existing) systems. Depending on the number of systems this can be a serious advantage.

When there are only few solutions and the customer really doesn’t know what he or she wants, starting from an existing solution and building from that is the way to go. However, when there is one clear success state and many possible (existing) solutions PA will shine.

• [1]: http://www.procesacceleratie.nl/

For my assignment I used metrics to evaluate the modularity, encapsulation and complexity of different implementations of the same concurrency functionalities.The modularity, encapsulation and complexity gave an indication of their maintainability.

The fact that more and more tools for software metrics are released and used is a good thing, because evaluating source-code and refactoring the ‘bad’ code can be of great importance for a good evolution of a software product (to keep it maintainable).
But it should not be used as a ‘development method’, lately I see other developers write their code in a way to get optimal results on one or two of these metrics. This is what I would like to call metric driven development and should be avoided. Why ?
Well because software metrics are indicators no more no less, a program for which metrics show good complexity metrics indicates the code is easy to understand, but does not guarantee it !

Software with good metric values can still be ‘bad’. For example, brainlessly refactoring for good metrics might hurt the shared abstraction levels of the methods or their cohesiveness. Which are also important source-code characteristics according to McConnell, and therefore making it doubtful that the refactoring was of any help to the project.

A second reason would be that optimizing code for some metrics will likely hurt the other metrics. For example when minimizing the number of lines of code in a method, one might extract new methods, resulting in a larger amount of methods per object and probably larger amount of lines per class.

So my personal advice would be to use software metrics only in the way they where meant to be: to evaluate a piece of software and to realize that it’s just a tool to indicate software quality not a guarantee.

During our projects we noticed that working in a central repository really isn’t a problem, but when looking at the automated build some problems arise. First you’ll need a tool to provide the automation. We currently use CruiseControl to provide the loop.

But how to build the results from the sources? JDeveloper provides us with a deployment profile with which we can create JAR, WAR and EAR files very easily, but on our development machine. However JDeveloper is the only program that understands those .deploy files. On the build server we don’t want any manual intervention. We first started to create Ant files to build the project by hand. This is a tedious and repetitive task that really is bug prone. You’ll also have to supply those ADF libraries someplace that is accessible (and known) by the build process (JDeveloper hides those libraries pretty well). Next we tried a solution that uses JDeveloper itself. It is an Ant task created by Gerard Davidson and is available via OTN (here at the extension exchange). It starts JDeveloper headless and can execute any JDeveloper command. We found found it a little troublesome and tricky to work with. Especially when an update is available JDeveloper will wait around for your mouse-click and so break your automated cycle.

Then an idea came to mind: what if we parsed the project files ourselves and built our Ant build file around that? Most problems creating Ant files manually where caused by libraries (user defined and those from extensions) and source paths. All that information is stored inside your project file (and the extensions within JDeveloper). As practically all JDeveloper configuration files are currently written in XML, those can be parsed without problem.

The current solution is one i did not want to withhold from all you guys (and gals ofcourse). We created an Ant Task that takes your (ViewController) project file and parses it (and it’s dependent projects, for example the Model project) and exposes the relevant paths and settings as filesets, paths and properties that Ant can use to compile, copy and jar to create your deliverable(s).

We almost always have workspaces that contain two projects: a ADF BC Model project and an ADF Faces ViewController project. The Ant Task is currently tailored to that situation (However probably other projects can work with it, however i haven’t tested it). The Task does however need a complete JDeveloper installation on the server. It won’t run it, but it is used to parse the JDeveloper extensions to find out with internal libraries are used (for example all those ADF BC libraries). You can now use a pretty generic Ant script that just uses those lists and properties to build your deliverables (JAR/WAR/EAR).

The Task itself has the following JavaDoc which hopefully makes it more clear:


Task to parse a jDeveloper project file.
 
Takes the supplied jpr (Jdeveloper project file) parses it and creates the following lists:
 - (Path structure) Sourcepaths (prefix + '.sources')
 - (Path structure) Classpath (prefix + '.classpath')
 - (Fileset structor) Resources (non java-files) on the classpath (prefix + '.resources')
 - (Fileset structure) Deployed libraries (subset of classpath) (prefix + '.deployed')
 - (Fileset structure) Web content directory (prefix + '.webcontent')
 - (Property) J2EE web application name (prefix + '.j2ee.name')
 - (Property) J2EE web application context (prefix + '.j2ee.context')
 
With this information you can use ant to create a simple WAR/EAR deployment.
To copy the resources from the classpath(s) you need to use the supplied filename
mapper (based multiple classpaths can be used and you'll not want those relative
directories in the classpath)
 
A known problem is that fileset cannot span multiple drives on windows. If your
deployed libraries are located on multiple drives you will get an exception through
the ProjectParser.


We are currently using it to automatically build our projects on a Build server. Unfortunately i cannot give you the sources as my boss would go through the roof. However i think this Task will be usefull to a lot of people so hopefully you won’t mind.

You can download the package here.

Just unzip and read the included .HTML file. The package contains the HTML (overview from the JavaDoc), the JAR file and the JAR-ed JavaDoc. The HTML (or JavaDoc) also supplies a complete Ant build file that we currently use in our project to create the WAR and EAR files.

If anything is unclear (or, i hope not, not working) just leave me a comment or give me a howler on e-mail.