Messages

1

General Board / Re: Requisite Pro intergration/import

« on: March 27, 2008, 09:33:37 am »

David
if I were to give you anything, it would be source code, and obviously you would then have to change it for your particular application and compile it etc.
Sounds like that isn't going to help you though.

2

General Board / Re: Requisite Pro intergration/import

« on: March 26, 2008, 09:38:50 am »

David

are you able to do c# development with a view to creating EA add-ins?

3

General Board / Re: Requisite Pro intergration/import

« on: March 25, 2008, 09:54:33 am »

David
Its unlikely that I would be able to give you code but I will ask "the management" and see what they say.

I just modelled both the requirement hierarchy (as seen in the ReqPro browser) and any explicit "trace-to" relationships attached to the requirements, with EA connectors (dependency relationships).  This is time consuming to construct but once you have done it, you can do silly things like (for example) create an EA diagram with all the requirements on it, and see how they relate to one another or, for each design component, create a diagram with your classes on it and paste-as-link the relevent requirement objects and create dependency links between the requirements to your classes, etc. From those links we can document our requirement-to-design traceability.

Modelling hierarchy and inter-relationships is a fairly complex thing to do. When importing the ReqPro content, I build in memory a representation of it as a kind of graph-like structure. Each node in the graph represents either a ReqPro package or requirement, and each node can have as many links to other nodes as needed. From this I can create a facsimile of the ReqPro database in EA. The code to do this is highly recursive in places and my mind is often bent trying to understand it, even though I wrote it  

Because the requirements in EA are marked with tagged values of the GUIDs of their counterparts in ReqPro, when a new import occurs, the add-in updates existing requirement objects in EA, so your traceability links remain intact. New requirements are obviosly created as needed, and requirements that have been deleted in the ReqPro database lead to warnings to the EA user to delete their counterparts manually in EA, once the design impacts have been assessed. Each import creates a fully detailed change report displayed in the output tab (and persisted in the model). This report can help the designer figure out what design elements have been affected by the requirement changes, assuming that before the latest import, they established requirement-to-design traceability, either diagrammatically, or using the relationship matrix editor in EA.
 

4

General Board / Re: Requisite Pro intergration/import

« on: November 02, 2007, 03:45:03 pm »

Hi Bokkie,
I have used some of the ideas I found in your eareqpro add-in to make an add-in for the organisation I work for. Unfortunately, I dont think I will be allowed to share it, at least not the source code (I will keep badgering the management on this issue). I can share ideas with anyone interested in this area though. The add-in I made facilitates both import AND export of requirements between ReqPro and EA.

5

General Board / Re: Enterprie Architect and RequisitePro

« on: February 20, 2008, 01:12:20 pm »

David,

I'm not sure what you are asking so  I will just ramble a bit.

I have the Rational Suite v7 on my desktop PC. RequisitePro is part of that suite of tools and with RequisitePro installed, you automatically get the extensibility interface. It comes as a COM object that you can see and use (reference) when developing a .NET assembly in c# or visual basic (or other language).  I know the extensibility interface existed prior to v7 of the Rational Suite, because I used to use an earlier version of the suite, and it was that which I began developing against. During the add-in's development I upgraded to v7 of the suite and I did not notice any changes to ReqPro's object model or interface.

Does that help? If not, you will probably have to enquire at IBM Rationals web site (a bit of a nightmare to navigate unfortunately).

6

General Board / Re: Enterprie Architect and RequisitePro

« on: February 15, 2008, 03:39:47 pm »

Emiliano,

what you are asking is possible, to an extent. I have done it using a c# add-in to EA that I wrote that uses the ReqPro automation interface to read the ReqPro database content. However, there are problems. For example, attributes of requirements (eg. Difficulty, Priority, Status, etc) are so customizable in ReqPro that when you copy them into EA, there may not be a good mapping to a value in EA's attribute values. Ofcourse, you can try and align EAs attribute values to ReqPro's as you go, since EA is fairly customisable too. Then there may be issues like, in ReqPro, a given attribute is multi-select, but in EA, it is only single-select. I tried to keep things simple in my add-in. I just copied structure and element names and notes, and a few simple attributes into EA.

I cannot share this add-in with you because it belongs to the company I work for, but feel free to ask me any questions about this approach should you decide to tackle the problem in a similar way.

7

General Board / EA doesnt always respect version control status

« on: October 21, 2007, 10:37:28 pm »

Hi, I've done an experiment with EA v7 build 815, that shows up some dodgy behaviour w.r.t. version controlled package content. The upshot of the experiment seems to suggest that EA does not respect the version controlled status of things.

I have two version controlled packages. They both reside in seperate package hierarchies such that each has a different package ancestral path up to the root. Both version controlled packages are checked in. One package contains requirement elements. Lets call this, the source package. The other (destination) package contains classes.

I open up the Relationship Matrix and select the source as the version controlled source package, and the destination as the version controlled destination package. As long as I keep both source and destination packages checked-in, the Relationship Matrix prevents me from adding a new relationship, either from the source to the destination, or vice-versa. The option to add a relationship only becomes available when I check-out one or both of the packages. So far so good.

Now, if instead, I select the destination package as the parent package containing the version controlled package, things change. Now I can create Target->Source relationships in the matrix. Furthermore, when I view the properties of the target elements, you can see the relationships in the requirements tab. If I tried to add those myself manually in the properties dialog when the package was checked-in, EA would prevent me. It greys out the OK button so the only way out of the properties dialog is to CANCEL. But in this experiment, EA did change the properties of the element, behind the scenes, and seems to have ignored the fact that the element belongs to a version controlled package.

Does anyone know if this is a feature or does it sound like a bug?

8

General Board / wierd code generation dialog behaviour

« on: August 21, 2007, 10:18:32 pm »

Hi, I am using EA version 7.0.815, build 815.

I have noticed that when working on a class diagram, if I select a class and bring up the code generation dialog using F11 (or a RMB menu selection), and then on that dialog select the Advanced button, you get the "Object Options" dialog. For some classes, the "Always synchronize..." radio button is selected, and for other classes, the "Replace (overwrite)..." radio button is selected. I cannot seem to modify these settings - clicking on the non-selected radio button does not turn it on. The attempt to do so is ignored by the EA GUI.

This is very irritating because now I want to code generate just one class at a time as I change them, and since I am only generating skeletal code at the moment, I do not need (or want) the synchronize option, but rather the overwrite option. However, some of my classes seem stuck in "synchronize" mode.

How can I overcome this?
Has anyone else discovered this "feature"?

9

General Board / Re: c++ code generation - include file statements

« on: July 30, 2007, 06:18:56 pm »

Thanks for the reply simonm.

Dont take this the wrong way - I am just curious,....why doesn't EA work correctly (subject to opinion ofcoarse) in this regard straight out of the box? Is this intentional? Was what I was trying to do in my experiment so strange or unusual that sparxsystems felt they need not support it as standard behaviour? Or do all purchasers of EA have to accept that they must embark on a process of tailoring/customization of the tool to achieve the outcomes they want?

10

General Board / c++ code generation - include file statements

« on: July 30, 2007, 03:04:01 pm »

Hi,

I am using the 30-day trial version of EA, and I set up an experiment with 2 c++ header files, class1.h and class2.h if you like. In class1, I added an operation that takes a reference parameter of type class2. I added an include statement in class1.h to include class2.h (this is just one way of keeping the compiler happy, a forward declaration of class2 in the class1.h file may also have been ok).

I then imported the source directory into a class model within my EA test project. Sure enough, it created the two classes, but the class diagram did not show any relationship between the two classes. Furthermore, when I generated new source from the model, the generated class1.h file failed to include the class2.h file.

I have tried everything obvious to establish that relationship diagrammaticaly in order to get the generated source code correct, but have failed. Nothing works.

The only thing I did find that worked, was to manually type in the include statement into the "Generate Code" dialog box that comes up when you select class1 on the class diagram and hit F11 (or select it from the context sensitive menu after a right mouse button click).

Surely, EA should know that class1 has a dependency upon class2? It is there in the parameters of an operation in class1. How can EA miss it? Why do I have to manually ensure that the generated source for class1 is correct? This problem has got quite a few other people in my office scratching their heads.

Any help would be appreciated. Thanks in advance.

11

Automation Interface, Add-Ins and Tools / Re: EA_OnOutputItemClicked and how to use it

« on: February 10, 2009, 10:03:18 am »

Ah yes - the classic "another level of indirection will solve all problems" trick.  

12

Automation Interface, Add-Ins and Tools / Re: EA_OnOutputItemClicked and how to use it

« on: February 09, 2009, 03:21:09 pm »

Cant use GUIDs, the paramater must be an interger.

13

Automation Interface, Add-Ins and Tools / EA_OnOutputItemClicked and how to use it

« on: February 06, 2009, 04:53:55 pm »

I want to be able to write messages to my output tab and place IDs there that can be package, element, or diagram IDs and have the EA_OnOutputItemClicked handler function automatically highlight the correct one in the project browser. Unfortunately, the code I wrote for this is not guaranteed to work. Am I right in thinking that IDs are not unique across the 3 types, that is (for example), a given element ID might also have the same value as an unrelated package ID?

Most of the time I am putting element IDs into the output tab so my EA_OnOutputItemClicked handler function tries to interpret them as that type and if it fails then it tries packages, and if that fails it tries diagrams. But this is not bullet proof.

The only way around this as far as I can see is to encode in the text string itself the type of the ID. Has anyone else had this problem and what did you do about it?

14

Automation Interface, Add-Ins and Tools / Re: Interop.EA.dll and object model changes

« on: February 09, 2009, 05:29:06 pm »

I sort of expected it to also.

I know the automation interface had some additions made in between v7.0 and v7.1 (correct me if I am wrong anyone).

However, on comparing the interop DLLs I find that they are identical in size (amazing coincidence or not as the case may be) and report the same version number (2.10.238.1) but they do not compare binary like for like.

I suspect the older of the two was built using a a version 6 toolset (visual studio 6) and the newer by a version 8 toolset (eg. visual studio 2005). But why are the version numbers and size the same? (well, I'm more interested in why the version number is the same).
 :-?

15

Automation Interface, Add-Ins and Tools / Interop.EA.dll and object model changes

« on: February 09, 2009, 03:29:14 pm »

Does anyone know if the Interop.EA.dll file changes when Sparx Systems add new methods to classes exposed in their automation interface?