Book a Demo

Author Topic: UML component diagrams: Forward engineering how-to  (Read 13165 times)

mi.ku

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
UML component diagrams: Forward engineering how-to
« on: January 15, 2013, 12:00:31 am »
Hello,

using EA 9, I cannot forward-engineer a UML component to Java source code so that the components are mapped to anything (at the current state, the classes are not defined - only the components). Intefaces are forward engineered, components are not.

Is forward engineering of components somehow possible, e.g. by specifying the mapping manually? I would expect to be able to work with abstract Java classes, or possibly packages.

Once I understand forward engineering, I would like to reverse engineer UML component diagrams from Java source code. Is this possible with EA?

Many thanks,

Michael


Makulik

  • EA User
  • **
  • Posts: 400
  • Karma: +0/-0
    • View Profile
Re: UML component diagrams: Forward engineering ho
« Reply #1 on: January 15, 2013, 12:19:04 am »
Usually forward and reverse engineering code is based on classes, not components. The component structure is just used to show the various public interfaces of your application and how these should interwork.
The class model is used to refine the components by giving them an internal implementation.

It's currently neither possible to forward engineer, nor to reverse engineer code at the level of component structures.

You might try to develop a transformation from component models to class models, but I doubt its useful or worth it doing so.

HTH
Günther

gericson

  • EA Novice
  • *
  • Posts: 7
  • Karma: +0/-1
  • I love YaBB 1G - SP1!
    • View Profile
Re: UML component diagrams: Forward engineering ho
« Reply #2 on: January 15, 2013, 01:26:16 am »
At DMTF, we've begun to use Component Structure Diagrams to represent a specific interface definition as a collaboration of instances, together with requirements and constraints. The instances are defined by classes of a base model.  The connections between these instances are defined by the associations and association classes of the base model.  Each part of the collaboration represents a specific use of a set of instances.  Collaborations are glued together using collaboration use and role bindings.  The role bindings declare that the part in the current collaboration is a subset of the part in the referenced collaboration.

We have defined a process, like merge, to roll-up these relationships into an implementation model for that interface.

The biggest problem we have with using this technique is that none of the UML tools we are familiar with provide sufficient (much less complete) support for Collaborations and Composite Structure Diagrams as defined by UML v2