As an ArgoUML contributor I'm going to blog my activities here, so that they may draw interest by other developers or help other developers when doing tasks similar to what I've done. AND(!) the grand vision that makes an Argonaut what he is, TO THRIVE IN THE BIG DANGEROUS WORLD, TAKING THE Argo TO A GOOD SHORE ;-))

Saturday, March 20, 2010

The Functional Object System idea

Functional languages and functional programming techniques are getting into the mainstream of software development these days. Clojure is an example of a recently created language (a Lisp dialect) that although not purely functional, applies the techniques and principles of functional programming very seriously and IMHO with success. Now, how do we combine this in a seamless way with object oriented programming? OOP has been up-to-now very dependent on the objects having mutable states in a destructive way. This isn't compatible with the functional data types which although having state, this is immutable, being the objects' data shared and construction only – and therefore reusable.

My idea is that we need a new object paradigm, which enables easy definition of immutable objects which have the same nature as the functional data types. I've seen this to some degree in a specific SISCOG library defined as an extension to CLOS and that enables an object state tree – much more advanced than the typical command pattern stack based undo/redo functionality you commonly see. It could be implemented in Java with aspect oriented programming (i.e., with AspectJ). Alas, this library suffers from its objective not being specifically of providing a Functional Object System (FOS) and by using the mutable Common Lisp standard types – once you get hold to one of its fields, you can wreck the state indirectly. It also relies on the common with wrapper macros to change from state to state, instead of assuming that all state changes shall be construction only and therefore dropping the use of wrapper macros.

So, what specific concepts must a FOS take to heart in order to work?

  • Differentiate between query operations and construction operations.
  • Construction operations always return new objects that shall have one or more of their fields with different values than the objects they clone.
  • There shall be ways to change the state of the application, pointing some reference to a new root node tree, but, these shall follow concurrency (and maybe distribution) aware protocols, such as the ones defines in Clojure. These aren't necessarily part of the FOS, but, the FOS must play well with these.
  • The FOS shall provide means for its objects to take advantage of non-FOS objects. E.g., a FOS for Clojure must provide a potentially largely inclusive way for impure mutable Java defined objects to be used with it, even if that means to take advantage of introspection on these objects' operations and expensive quasi-duplication of them without the benefit of reuse.

So, now that I had one more crazy idea thrown into the web, lets check prior art...

OCaml has objects and contains a basis operation called functional update. This provides the basis for maintaining that an object is data plus behavior, but, making it side effect free. The convenience it provides is very interesting, it is almost more terse than actually mutating the objects! Even so, you have the possibility to use an imperative style, but, it isn't the default and you must declare the methods that actually change with mutable.

In Clojure it is all about concurrency, so, you would have to guard against concurrent access to objects that are being mutated. So, there might be additional semantics involved, which weren't obvious in the small part of OCaml that I read.

Gentoo and automated tests

With Gentoo Linux you already have the sources for all the software you install. It would be nice if you could also execute the automated tests that the software packages have. If the practice of having also deployment tests in software packages was common enough, you could in the end check if the whole stuff was working as expected by the authors of the software and provide very valuable diagnostic information to open source software projects.

Deployment automated tests

A nice thing I read in an agile book was of being able to execute the automated tests after deploying the software as a means of diagnosing if the installation was alright. I think that such a practice should be common place as a means of diagnosing if a certain deployment is correct.

UML representation in Clojure

UML representation in Clojure. I.e., create a Clojure domain language for representing UML models and diagrams, which should be serializable to XMI and graphically displayable in several formats, like for instance in ArgoUML format and in SVG. Another idea for ELS 2010...

Distributing Clojure

Make a framework for distributed computing with Clojure. Another idea for ELS 2010...

Exploring the clouds

Parallel system to explore the infrastructure of cloud providers. With Amazon use its web services to deploy clients and listen to the result. With Google AppEngine ping hosted applications. Use Google Web search to search for hosted applications – site:.appeng.com. Do this with Clojure. How about Microsoft's cloud? ClojureCLR?!?

Common Lisp design patterns

Actually catalog of common Common Lisp idioms. Some idioms are generalizable for all major Lisp dialects. Another nice idea for ELS 2010.

reduce map
with-x
defx or def-x
dox or do-x
<conditional-operator>-let or b<conditional-operator> [b is for binding]
...

Provide examples from SISCOG code base?

Each pattern should have an associated implementation strategy for being defined with macros.

Reverse engineering of XML specifications

Make a module to handle reverse engineering of XML specifications. One obvious use would be to model XMI's representation of UML in UML. A specific usage interesting for SISCOG's domain would be to reveng RailML specs.

Make this with NSN BicNet Tnml and bring Tnml into UML world as I was proposing internally some years ago.

Change the ArgoUML plugins technology to be based on OSGi

ArgoUML has modules (the ArgoUML's terminology for its plugins), as an extension mechanism of the application. The more common use case are the programming language modules, but, you can also have core modules, like for instance the sequence diagram module or the UML property panels module. The problem with the ArgoUML modules as I see it now is that ArgoUML is reinventing the wheel and that this wheel has it share of limitations.

  • One of the biggest limitations is the problem of not being able to specify a dependency of one module of another.
  • Another problem is that it is a bit of work to define a module which only purpose is to integrate a third party library into ArgoUML.
  • The final thing I dislike is that for one reason or another, currently the installation of ArgoUML includes all standard modules in the classpath by generating a hard-coded list of the jars (see META-INF/MANIFEST.MF in argouml.jar in a installation of ArgoUML).

My idea is that we should base our modules or plugins in OSGi. I think that this isn't very hard to achieve because the current scheme doesn't differ very much from what plain OSGi requires. In part this was performed by necessity of the Argoeclipse project – definition of the Eclipse build system based on the MANIFEST.MF files. But, the other part is simply due to the usage of good object oriented design with the Java language, which is related to the interface involved in the definition of the base module (see ) and of specific interfaces for functionality oriented modules, like for instance .

Updating ArgoUML tests to JUnit 4.x

We should update ArgoUML tests to JUnit 4.x, is order to take advantage of some of the new features of it. Since ArgoUML now must have compatibility with JSE 5, this should be no problem.

Updating ArgoUML libraries

There are several libraries in ArgoUML that need to be updated: easymock, JUnit, etc.

Organizing ArgoUML's automated tests

ArgoUML has all the automated tests mixed in a single directory tree for each of the sub-projects of which it is composed. I think that as a project we should differentiate the levels of testing according to the nature of those tests: unit, module, integration, acceptance [non-existing as of now] and deployment. This would enable the TDD cycle, by having unit tests execution in seconds instead of minutes. It would also be very educative for the testing practices in ArgoUML.

UML profile for Lisp

Creating a UML profile for Lisp should be very interesting. It would be an excellent exercise for a lightning talk in the ELS 2010. It would be an excellent opportunity to test in depth the ArgoUML profile support. It would be a learning opportunity for me into the depths of the extensibility aspects of UML.

My idea is that it should have some common patterns amongst the several dialects and that those patterns should in principle be modeled in a reusable way in a common profile, maybe a PIM.

Then, each Lisp has a specific namespace system, macro system and library. This must be derived with a PIM to PSM transformation and then developed on its own.

A REPL for each would also be required.

A connector to connect to live Lisps to enable reverse engineering is also interesting. This is something that could take advantage of some sharing of a common base project, but, would naturally diverge for each Lisp dialect.

A multiple languages REPL in ArgoUML

Sub-project of ArgoUML that provides a base REPL infrastructure to enable and easy development of multiple language REPLs for ArgoUML. I would make one for each of the dynamic languages modules that exist. Even for the C++ module or other non-dynamic languages modules a special purpose and convenient REPL could be interesting if it contained the interesting imports for interaction with the model. Modeling at the REPL with Common Lisp (ABCL), Clojure or Jython, what a dream!

I'm trying to embed ABCL in ArgoUML, opening a REPL in Emacs, but, because my SLIME setup for ABCL is broken, I'm having difficulties. The idea is to try to develop interactively a ETL from a UML1.4 model into a UML2.2 model to make it easy to update the profiles from UML1.4 XMI into UML2.2 XMI.

One possible solution would be not to use Emacs and SLIME. For instance, I could reuse Netbeans REPL. Since Netbeans already has Jython and JRuby support, I could try to port those easily into ArgoUML.

Auto coordinated traffic

System or platform that signals drivers' intent from cars to cars, so that the cars could be smart enough to warn the drivers about what other persons intend to do or even take appropriate measures to avoid accidents.

TODO: elaborate on this.

TODO: develop the idea of developing computational models/simulations where the platform modules could be tested and developed. Do it in Clojure, visualization in Google Maps with site in Google AppEngine. Do this in the programacao handbook.

Tuesday, March 09, 2010

ArgoUML 0.30 is out

ArgoUML 0.30 is out.

Happy modeling :-)

Reader Shared items

Followers