Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic Rhapsody (steve huntington)
Decrease font size
Increase font size
Topic Title: Creating OMDs via API
Topic Summary:
Created On: 23-Nov-2006 12:22
Status: Read Only
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 23-Nov-2006 12:22
User is offline View Users Profile Print this message


Tobias Gern

Posts: 1
Joined: 23-Nov-2006

Hello!

Creating an OMD by script is very simple with the command

Set OMD = pkg.addObjectModelDiagram("NewOMD").

But how can I add classes, objects and relations to the new OMD via API?

Best Regards,
Tobias Gern
Report this to a Moderator Report this to a Moderator
 27-Nov-2006 08:35
User is offline View Users Profile Print this message


Charlie Lane

Posts: 86
Joined: 16-Sep-2005

Hi Tobias,
I have used quite a few of the API features (some undocumented!) for setting up OMDs and Structure Diagrams (I was doing an import of Teamwork models to Rhapsody). So some pointers:

a) I found it useful to set up quite a few properties for the OMDs at package level, e.g. p_Pkg.setPropertyValue "ObjectModelGe.Flow.line_style", "straight_arrows"

b) You can add a class to the diagram (assuming the class already exists in the model) like this: Set m_DFDContainer = m_DFD.AddNewNodeForElement(a_ProcessClass, a_X, a_Y, a_Width, a_Height)

c) You can add new lines (I was adding flow lines, but same should apply to relations etc) like this: m_DFD.AddNewEdgeForElement(a_FlowElem, a_SourceGraphNode, a_FirstX, a_FirstY, a_DestGraphNode, a_LastX, a_LastY)

d) If you want a multi-segment line, set the polygon property after creating the edge, like this: p_RPGraphEdge.setGraphicalProperty "Polygon", a_Polygon
where a_Polygon is a string containing the number of points (including the start and end) and then the x and y of each point.

e) State charts etc are done similarly: Set m_StateChart = a_CSCClass.addStatechart then add graphical nodes and edges for the states and transitions.

f) For text notes I used comments in Rhapsody, but the thing I haven't been able to work out yet is how to set the size to fit the contents.

g) I found that positioning of ports on the circumference of blocks (or classes) was difficult -- setting the position in the graphical properties did some very strange things to the placement of the port on the diagram.

h) I submitted a number of questions to i-Logix which hopefully will lead to improvements in the API, e.g. the ability to set other shapes of block, connectors for flows (like connectors on state charts), setting the location of a flow name (or transition trigger/action) on the diagram, suppress the name of a port.

Hope this helps -- let me know if there are any particular points you need more on. I found that experimentation was quite fruitful!
Regards, Charlie
Report this to a Moderator Report this to a Moderator
 14-Aug-2008 07:32
User is offline View Users Profile Print this message


Akilah Jones

Posts: 23
Joined: 14-Dec-2005

Could you please elaborate how you imported a Teamwork Model into Rhapsody?

We are toying with the idea, but not sure if it was possible or not....

Any assistance would be greatly appreciated.


Thanks

Akilah S. Jones
Report this to a Moderator Report this to a Moderator
 15-Aug-2008 08:32
User is offline View Users Profile Print this message


Charlie Lane

Posts: 86
Joined: 16-Sep-2005

Hi Akilah,

Yes, it is possible, with some limitations. What we wanted to do was to provide the means to transfer a Teamwork design into Rhapsody and continue its maintenance and development there -- both the Teamwork tool and the servers we have it running on are becoming obsolete, so this was in part to protect our IP. It also has the advantage that it enables piecemeal refactoring of the design into UML, supporting both the legacy ex-Teamwork SASD design and the new UML design in the same tool. Once in Rhapsody, the design can be linked to requirements in DOORS, Word etc using the Rhapsody Gateway tool (thus providing automatic traceability that was previously done external to Teamwork). The attached file shows a comparison of a DFD in Teamwork and Rhapsody.

What it does:
a) Bring context diagrams, DFDs, into Rhapsody as stereotyped OMDs (so they appear as DFDs): process bubbles are round-rectangles (internally they are blocks and hold PSpecs as the description), flows stereotyped to distinguish between data and control flows, stores and terms as rectangles, text notes as comments.
b) Bring state charts into Rhapsody as state charts (of CSCs).
c) Bring data dictionary into Rhapsody as flow item definitions, including analysis of what flow items include others (for composite flows).
d) Bring Structure Charts into Rhapsody (as activity diagrams).
e) Bring ASGs into Rhapsody (similar to structure charts)
f) Check flow balance (surprisingly good -- it found some inbalances that Teamwork checks missed).
g) Add some useful things like hyperlinks between processes in different levels.
h) Link processes to functions in the code (use the Rhapsody built-in reverse engineering of code, then create dependencies between code and design to help them keep in step, unlike the Teamwork models which we found easily get out of step with code).

What it doesn't do (but in principle could be augmented to do):
i) Code generation from the imported data.
j) Import of matrix elements (e.g. PAT/SEM/DT), ERDs, Picture Notes.
k) Automatically add flows to keep levels balanced.
l) Link structure charts to code.

It's worth highlighting that the whole point of this was to be able to continue SASD-style development in Rhapsody, which isn't really an SASD tool, by representing the SASD artifacts as well as possible. There are other initiatives both in our company and elsewhere that are looking at a more radical approach that aims to produce a proper translation from SASD to UML -- this approach doesn't attempt to represent DFDs etc but instead translates them into the equivalent UML artifacts. The downside is that significantly more engineering input is required in the process and you probably need engineers that are skilled in both SASD and UML.

Does all that help?
Please let me know if you'd like more information or if you want me to run a sample for you.
Regards, Charlie.

DFDcomparison.JPG
DFDcomparison.JPG  (33 KB)

Report this to a Moderator Report this to a Moderator
 23-Aug-2008 09:11
User is offline View Users Profile Print this message


Akilah Jones

Posts: 23
Joined: 14-Dec-2005

Thanks and yes, that does help...

As you stated, SASD-to-UML translation would be the preferred method for us as well.

...But preserving SASD in UML "format" would work for the meantime.


I will attempt a small test and if I get stuck, I will definitely check back with you!

Thanks Again!

Akilah S. Jones
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic Rhapsody forum.
There are currently 1 users logged in.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.