Modelling Spring Deployment

[mattinger]

I'm currently doing an application design. This design uses the standard DAO and Service patterns to provide access to the application's domain model. There are Dao interfaces, and the implementation classes extend HibernateDaoSupport. There are also service interfaces which provide roughly the same methods as the Dao, but at a higher level. The Service implementation classes have a Dao instance as a member variable, and provide a setter for injection, and delegate the appropriate calls to the Dao instance.


This is all well and good, and a standard design technique. However, other injected objects, such as as the SessionFactory, Quartz Scheduler, etc... are shared amongst several services.

I want to model the deployment of the application (which is where spring fits in) using UML. In this way, we can show where the objects are coming from, which implemenation classes are really used when there is only a static relationship with an interface.

I have begun by creating deployment diagrams, using the "artifact" stereotype to represent the configuration files themselves, and created associations between the main application context, and each configuration file.

Then, i have a deployment diagram for each configuration file which documents what beans are provided. When there is an injection, i create an association from the bean instance to the injected dependency.



Has anyone else attempted this? Have you taken the same approach?

[mschuerig]

Have you had a look at BeanDoc?

http://springframework.sourceforge.net/beandoc/

I have written a Maven plugin for BeanDoc (as much alpha and subject to change without notice as BeanDoc itself)

http://www.schuerig.de/michael/java/...gin/index.html

Michael

[mattinger]

BeanDoc is nice if you already have your deployment files setup, you can document them. However, in the design phase, this doesn't really help you model the inject dependencies, supplied beans, etc....

I've actually decided that a component diagram makes more sense, since it typically is allowed to contain both artifacts (i'm debating between an artificact and component here) and object instances, whereas a deployment diagram typically does not contain object instances.

I'm also leaing toward components for the spring bean files. The main reason is that my UML software (enterprise architect) represents artifacts with an included stereotype of <<artifact>>. Using a component allows me to stereotype spring bean files as <<spring-context>> and <<spring-beans>>. That would allow someone to write a generator which could take an XMI document and generate the appropriate files.

Thoughts?

[davison]

Has anyone else attempted this? Have you taken the same approach?

I think this is a really promising idea and had a look at similar myself. One problem I found was that the XMI generated by various UML tools[*] seemed awfully inconsistent. At least one (Omondo) made constant references to values held in the central repository and others didn't expose relationships between any attributes or types in the same way.

Do you know much about XMI? I don't - perhaps there's some way of generating a consistent dialect from multiple tools.

If such a thing could be made tool-agnostic, I think this would be really powerful. The transforms could be managed with a simple extension to BeanDoc giving a nice end to end approach.
[*]

• Omondo UML eclipse plugin
  Poseidon UML
  Umbrello (KDE/Linux)

Regards,