OSLC Integration Wishlist

[TomasJkn]

Hello dear forum members,

Here at No Magic we are planning to have some integration with the OSLC capable tools (the IBM's Jazz platform tools, other vendor's tools).
If it happens, OSLC integration will be stepwise, spanning several MagicDraw+ecosystem releases.

Now "supporting OSLC" is not a simple yes/no proposition - there is a truckload of various tool interaction scenarios where OSLC might be used.

Because of this we are seeking community input - to better grasp which usage scenarios are most important to our users.

Does your company already use OSLC-capable tools or plans to use such tools in the near future?

If yes, what types of OSLC resources are you using (requirements? change and configuration management? see http://open-services.net/workgroups/ for the list of OSLC domains) and would like to integrate with MagicDraw ecosystem?

What workflows or features would you like to be implemented?

Please give us a note by posting into this forum - either replying to this topic or starting a new topic in this OSLC forum.

Sincerely,

[jlhoward@mantech]

Yes, Legacy Doors and Jazz. And custom OSLC. Considering OSLC4J in Java Plugins/Jython scripts.

[dworella@usc.edu]

I work for a defense company and we would like to see OSLC integration to the Jazz environment (including classic DOORS). We have a scenario where are teams use various tools for different levels of architecture and would love to see OSLC links between them as a way to create impact analysis through our teams. Would also like to see some collaboration tools from No Magic to complement the Cameo suite as it moves to the cloud for project planning and execution as well as reporting and easy access to model content using OSLC/RDF.

[robert.marino@ngc.com]

IBM DOORS 9.x, IBM Jazz (DNG, RTC, RQM, etc), and Siemens TeamCenter would be highly desireable

[j.flender@wzl.rwth-aachen.de]

Polarion ALM (Requirements Engineering) would be absolutely great!

[sraley@itc-llc.com]

Is OSLC available in 18.5sp2 ?

[TomasJkn]

Hello all,

I am pleased to anounce that OSLC support is comming with v19.0 (sorry folks, not in 18.5sp2). See News announcement https://docs.nomagic.com/display/MD190/19.0+LTR+Beta+Version+News#id-19.0LTRBetaVersionNews-oslc

On OSLC provider front:
Teamwork Cloud server will be providing OSLC data for other tools - OSLC consumers - to use. OSLC Architecture Management vocabulary will be used.
To have not just the data but also previews - user-oriented information presentation - you will need TWC + Cameo Collaborator combination (note - previews are planned in 19.0GA,
they are not there yet in 19.0beta)

n.b.: this is only applicable for the new TWC server, which uses database repository, not the old Teamwork server, which has filesystem repository!

On OSLC consumer front: MagicDraw client shall be able to work with OSLC data providers. You will need Cameo DataHub plugin for that.
It shall be possible to connect to OSLC providers, select and/or create the OSLC resources in them, preview OSLC resources insice MD, create (hyper)links to external OSLC resources.

n.b.: even though Doos Next Generation is an OSLC provider, do not use the generic OSLC connector to connect to it - use a dedicated DNG connector of DataHub.

Please note that OSLC implementations of various OSLC providers are rather fickle (especially in the authentication aspect), so there may be some small quirks and/or impediments
to correct connecting to the OSLC provider (with unclear attribution - whether problem lies on the OSLC consumer side or on the OSLC provider side).
If you have any problems connecting to some specific OSLC provider X, please report them and we will try to investigate where the problem lies and provide some guidance.

For people asking about Polarion: here is a demo video, illustrating the generic OSLC connector: https://www.youtube.com/watch?v=oyD1ugPf_Yo

For Siemens TeamCenter integration - there is a separate integration. As far as I know, it is not OSLC based, but uses a dedicated APIs.
See https://docs.nomagic.com/display/MD190/19.0+LTR+Beta+Version+News#id-19.0LTRBetaVersionNews-siemens

Sincerely,

[sraley@itc-llc.com]

You comment about the " new Teamwork" that uses a database vs the old that is filesystem based. What version went to database because we are about to run 18.5 and it states it requires Cassandra. And I see 19 upgrades Cassandra to 3.11. Is this sufficient to use OSLC ? Thanks

[TomasJkn]

Hi,

You comment about the " new Teamwork" that uses a database vs the old that is filesystem based. What version went to database because we are about to run 18.5 and it states it requires Cassandra

If your server requires Cassandra, then it is the "new" one - Teamwork Cloud. And it will be providing OSLC data once you upgrade to 19.0 (but also see my note about previews and Cameo Collaborator).

In the 18.x series, we do support two server flavors in parallel - Teamwork Cloud (available, if I am not mistaken, from v18.2 upwards) and the old Teamwork (which we had for a long time - since v5 maybe? the answer is lost in the depths of history ). This situation with two servers will continue for some time (current plans are to support the old server for ~3 more years). But in the long perspective, only the new Teamwork Cloud flavor will remain.

I hope this clarifies the situation.

[eli.d.wilson@raytheon.com]

We use IBM's Jazz Server and No Magic tools. Would love to see the integration improved via OSLC. Specifically, here are the capabilities that are on my wishlist...

- Magic Draw connecting to RTC to track modeling tasks to schedule and team member.
- Magic Draw connecting to RQM to show how test events and test plans break down into smaller pieces. Currently, we use RQM for test plans with Rhapsody showing the test flow (Activity diagram), and test setup (Internal Block Diagram). The linking is decent, but I would prefer to use Magic Draw, as the views it has are much more consumable.
- Ability to see representations (remote resources, etc.) of RTC and RQM elements in Magic Draw. This would allow us to tabulate, show coverage and gaps, as well as show impact from Magic Draw elements through the RTC and RQM elements.

Currently, if I want to show the impact of a behavior or design in Magic Draw to something like schedule (RTC) or test verification (RQM), I would have to show that meta-chain going through DOORS, but in several cases, that linking makes the context of that meta-chain too narrow.

Another big wish list item (outside of OSLC) that would drive the replacement of Rhaposdy with Magic Draw is the InterOp. When we used that tool a year or so ago, roughly 80% of the information translated from Magic Draw to Rhapsody, and several of the classes and stereotypes required manual clean-up. If Magic Draw can interoperate well with Rhapsody - it makes it easier to replace, without compromising reuse of models built in each tool. If Magic Draw can also link into RTC and RQM as well as DOORS/DNG - then there's hardly an argument to keep Rhapsody.