Evolve – a powerful, UML-based alternative to dependency injection

Evolve is a UML-based tool for creating, wiring up and executing components. It currently supports Java.

It is now in public beta, and we invite you to try it out.

http://intrinsarc.com/evolve/what-is-evolve

Have a look at the screenshots at:

http://intrinsarc.com/evolve/screenshots

“evolve is a more powerful and principled alternative to dependency injection”

This is a bold claim. We are going to be contentious at this point and just go ahead and list Evolve’s advantages. We will then follow up on a serious of blog posts that substantiate our claims. For those who require proof now, please download the software and work through the examples in the user manual.

a better way to connect objects

Evolve is based on a powerful component model with full connectors. This lets you wire up any structures you want, in a similar way to how an electronics designer wires chips up into a circuit board. No more messing around with “prototype” and “singleton” tags to construct complex components. No more problems making two instances refer to each other.

The use of connectors gives far more power than standard DI approaches. This is not conjecture – Evolve’s component model comes from years of deep academic research, and we will provide simple examples showing the difference in future posts.

explicit architecture

No more hiding architectures inside XML files or smattering them through your codebase as annotations. The full architecture of your application is visible as UML diagrams, and the code and architecture are always kept completely synchronized.

evolution support is built-in

Evolve is based on cutting-edge research into highly extensible systems. It offers a powerful way to graphically evolve a system. Many variants of an application can be held in one Evolve model, and any system you make in Evolve has the remarkable property that it can always be extended without destroying the original!

This support for evolution provides a more principled alternative to aspects, without many of their disadvantages.

easy handling of complexity

Evolve has been designed to handle large systems with ease. It can literally scale to thousands of components. Fine-grained or coarse-grained, Evolve handles them all. No more getting lost as your DI configuration grows too large.

The above just covers a fraction of Evolve and its extensive facilities. Stay tuned as we work to release the other parts!

2 comments (leave a reply)

  1. ted stockwell (October 4, 2010)

    This is a very interesting tool.
    I have done a lot of development using the Eclipse Extension Point/Extension mechanism and am very excited by the idea of a hierarchical model that automatically provided extension points.

    I will be reading the manual and the thesis over the next few days.

    Quick question… would Evolve be good for ‘dynamic’ extensions? That is, adding ‘plugins’ to a deployed system that extend the system? Like the Eclipse IDE…

    Anyways,
    I wish you success…

    -ted stockwell

  2. Andrew (October 4, 2010)

    >This is a very interesting tool.

    Thanks Ted.

    >I have done a lot of development using the Eclipse Extension Point/Extension mechanism
    >and am very excited by the idea of a hierarchical model that automatically
    >provided extension points.

    You’ve got it exactly! That’s how Evolve, and the underlying Backbone component model works. The idea is that it completely aligns creation and extension. Every element of each component (port, part, connector, attribute etc) forms another possible extension point. These are identified under the covers by UUID, rather than name, so it is very robust.

    As you have noticed, this is a powerful alternative to plugin architectures – with Evolve you don’t explicitly create extension points, but instead you simply design and create components, thereby automatically providing extension points. This is actually the focus of the research work that led to Evolve – the creation of systems that are always extensible. It’s a big advantage over existing approaches, and it is not unusual to see an Evolve model with 10 or more extensions of the same system in that one model.

    >I will be reading the manual and the thesis over the next few days.
    >Quick question… would Evolve be good for ‘dynamic’ extensions? That is, adding
    >’plugins’ to a deployed system that extend the system? Like the Eclipse IDE…

    It’s certainly something we are looking at for our roadmap. The systems in academia that Evolve is based on actually pioneered the area of dynamic additions back in ’85 or so (!), and we plan to add this to the toolset at some point. See page 104 of the user manual. The structural changes are the easy bit — it’s the detection of when it is safe to transfer the data over (known as “quiescence”) which is tougher.

    In my phd thesis (rather than the user manual) I compare and contrast Evolve to the Eclipse plugin system. I’d be very interested in your views on this. The thesis can be accessed at http://www.intrinsarc.com/backbone/research from page 141 to 152.

    >Anyways,
    >I wish you success…
    >-ted stockwell

    Many thanks Ted!



leave a reply

name
(* required)
email address
( * required - will not be published)
web site
comment
(* required)

*