1

I have an existing suite of SOA-connected applications (mixture of JavaEE, PHP and .Net) for which I need to provide an overall deployment model or architectural diagram.

I have found an example of a UML diagram for J2EE Application Deployment which is attractive because it's at just about the right level of detail (apps, containers, some component manifestation) for my current diagramming requirements.

I may even aggregate those at a higher level using something like the same author's Application Clustering Example.

I'm confident that I can jump right in at the component level or even at the artifact level and build my diagram(s) from there.

However, I also design specific Java components and would like to begin providing overall class diagrams to the development team when this current "architectural" exercise is complete. I expect this involves reverse engineering the Java code and starting from there.

My question is: what is my best strategy for meeting my current deployment and future component modeling needs?

Can I expect to back-fill the current artifacts I create now (eg. WAR or JAR file) with reverse-engineered components later?

Should I reverse engineer now, create the artifacts from the "bottom up", ignore most of the components, then update the reverse-engineered code later when it's time for component modelling? I would still require only logical (i.e. not backed by code) components for the .Net and PHP pieces since they're not my domain.

Should I make & keep my deployment artifacts separate (either via different EA projects or disconnected models in the same project) from my components, requiring a "manual" update to deployment diagrams / artifacts if/when code changes?

I'm just getting started with Sparx EA (after migrating from RSA) and would appreciate the perspective of anyone with more EA experience than myself... as well as feedback on any anti-pattern red flags raised by my descriptions above.

Jacob Zwiers
  • 1,092
  • 1
  • 13
  • 33
  • 1
    Just some notes: **1)** I suggest that you click through the path `menu Help → Open Example Model → UML Modeling → UML Modeling : UML 2.0 Diagrams → Deployment → Server Configurations → Web Server`, **2)** consider using the structure created by `Model Wizard` when you check both component and deployment models, **3)** deployment diagrams won't change when your code (class diagrams) changes. It is different level of detail – xmojmr Oct 21 '14 at 17:06
  • 1
    Understood on the first two. Will try. For (3)... in Java, code compiles into `.class` files which are packaged into JAR and/or WAR files which are deployment artifacts. So, to keep deployment model from changing, are you suggesting an "gap" between the JAR/WAR and the classes which it contains? If so, does that mean the deployment diagram goes as detailed as the Component level and those components are never modeled as having their origin in specific classes? – Jacob Zwiers Oct 21 '14 at 17:48
  • 1
    Good point, actually I don't know how huge "gap" would be just fine in your case. I thought about it like: deployment diagrams are for admins to know which files get copied/installed where. It is not changing frequently during the application life. Package diagrams may change across major version changes. On the other hand the number of classes and their dependencies changes frequently, e.g. during refactoring. What is the position of component diagrams which stand in the middle is an open question → http://www.agilemodeling.com/style ← may have some useful guideliness – xmojmr Oct 21 '14 at 18:56
  • Yes, target audiences are different. I guess it's the age-old problem of traceability #sigh. FWIW, using the `Model Wizard` and selecting Class, Component and Deployment as you suggested makes no connections between the three Models. – Jacob Zwiers Oct 21 '14 at 19:32
  • The wizard gave you a "folder" structure for storing your "files" thus giving you the artifact separation (your question). You can now use Drag-Drop & Link to reference (re-use) artifacts from one model in another. e.g. you can define a class in one model and Drag-Drop & Link it into diagram in completely different model, while hiding the attribute details. That's all what my note was about. You can find some other "best practices" on http://www.sparxsystems.com/resources/demos/ and http://www.sparxsystems.com/resources/webinar/webinar-series.html (perhaps it'll answer "just getting started") – xmojmr Oct 21 '14 at 20:31

1 Answers1

1

There is no good/general answer to your question. You should use MDA with CIM/PIM/PSM views where you put the components in the PSM and the class model in the PIM. Now, to keep all that in synch the only true way is to do it manually - the hard way. Though EA offers a model transformation I can not really recommend that. It pretends to link/synch PIM and PSM (in this case) automagically. But it's just a bad facade. First it works only one way (PIM to PSM) and second you soon loose the contact between both model views as you don't really see the traces. Instead install the <<trace>> connectors manually and annotate them as needed.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • Coming back to this after icing the activity for a while. Appreciate the suggestion and warning about the transformational features in EA. I've abandoned any hope of linking the classes with the components (so no real need for the PIM). I'm sticking with a PSM model for conceptual / deployment description and leaving details and traceability back to code for those who need to to spelunk their way through. – Jacob Zwiers May 21 '15 at 17:09
  • You might want to have a look into my BA-book where I describe that whole procedure. You can read it online. http://liquit.biz/brain/books.html – qwerty_so May 21 '15 at 18:38