Messages

1

Suggestions and Requests / Re: Packages, Namespaces & groupings

« on: December 18, 2007, 07:26:21 am »

Hi Paolo -

Does this solution help the synchronization issues mentioned above?  It seems to me that they are two different issues.

Paul Ourada
Principal Software Engineer
Covidien (formely Tyco Healthcare)
Energy-based Devices (formerly Valleylab)

2

Suggestions and Requests / Re: Packages, Namespaces & groupings

« on: May 02, 2007, 11:35:43 am »

Hi Paolo -

I have a similar issue, and have asked Sparx to implement something like what you've just described.  

Here's my issue.  We have actually organized our project exactly the way you've described: namespaces with organizational containers under them (suppose more than one person wants to work in the same namespace, but on different aspects of it?).  In order to get this to codegen properly, I have hijacked the Namespace* templates to generate just the namespaces we want (actually, just two namespaces - one is a framework and the other is the application).

Here's an example.  Suppose that I have a class, Foo in namespace Name and class Bar in namespace Space, and Bar derives from Foo.  Both classes are in one or more "organizational folders.  When you codegen Bar without namespaces turned on, you get the following:

Code: [Select]


namespace Space {
class Bar : public Foo
{
}

} //namespace Space


The generated namespace declaration is the result of the template modification.  The using statement is missing (because of some fancy footwork in File Impl codegen template) so this may not compile (depending on how smart or how diligent your compiler is) because Foo is not in the same namespace as Bar.  So, you think, "Aha!  I'll just qualify Foo, and that's nicer C++ code as well!" and you then have something like this:

Code: [Select]


namespace Space {
class Bar : public Name::Foo
{
}
} //namespace Space


However, now when you synchronize the class Bar in the model, the specialization relationship disappears, and the class box is now decorated with Name::Foo to indicate that the base class is missing from the diagram.

So, I asked Sparx to somehow conditionally make the package a namespace.  I thought that a package tag something like isNamespace with a default of "true" would do the trick.  Other UML modeling tools have such a facility -- or they used to.  It's been a few years since I used that other tool.

I haven't heard anything from Sparx since then.  So, if anyone has heard anything more about this, please drop me a line.

Thanks,
Paul

3

General Board / Re: Organisation of diagrams and elements?

« on: July 09, 2010, 12:00:18 am »

Still flogging this horse, Paolo? Good! Keep it up!  

I'm a little late to this particular party, but I have been complaining about this type of issue for many years. Sparx's competitors allow many options for organizing projects, including allowing package specifications which are not part of the namespace structure. For some reason Sparx has decided to more closely toe the UML party line.

In my work, we have just two namespaces: One for a framework, and one for the application which uses the framework (OK mulitple applications, but only one app namespace per project). But there are many domain packages and each have multiple component packages. And under the component packages we like to split out test code into a separate test package. If we were to put all these domains and packages into the namespace specification under the root, things would get ugly but fast. Using statements help, but can be confusing. (C++ is the language of choice for us.)

So, for us it's enough separation to have Framework::MyClass and App::MyClassDerivative types of structures. And we have about 2200 classes in the framework alone. Without some sort of organizing feature such as a "folder" or other non-package, or a tag that specifies a package not be in the namespace, how can you get multiple developers to work on the same model? You have to lock things somehow. We can't have 2500 classes all under one package.

I have tried modifying the code generator, and I can get it to spit out code which ignores all the sub-packages in the namespace specification. However, when I try to sync the same code, the diagram editor thinks that I am syncing a different class, causing IsA or sub-classing type of relationships disappear from the diagram. This is directly due to the fact that the namespace specification of the synchronized class or element is not what EA expects from the package structure in the EA project.

It's bad enough trying to get colleagues to adopt good design practices, but when I can't get the tool to do something simple as not include a package in the namespace, and then they try to sync and the diagrams don't follow suit, they just give up and our process goes to hell.

The point is that it is one thing to attempt to adhere to a standard. It's quite another to hamstring your users with it.

GAH!  

I really like EA in most respects, but we're having to seriously consider moving to a more expensive product @ IBM.

Paul Ourada

4

General Board / Re: Namespace issue

« on: May 02, 2007, 10:58:08 am »

I have a similar issue in C++ codegen.  The %fileHeader% macro always adds the using statements.  I put the following code at the beginning of the C++ File Impl codegen template:

Code: [Select]


$COMMENT="Remove the using statement from the headers"
$headers=%fileHeaders%
$usingIdx = %FIND($headers, "using")%
%if $usingIdx != "0" and $usingIdx != "-1"%
$headers=%LEFT($headers, $usingIdx)%
%endIf%


And then commented out the ImportSectionImpl under the "WARNING" section.

Code: [Select]


$COMMENT="WARNING: DO NOT MODIFY THIS TEMPLATE BELOW THIS POINT"
$COMMENT="Do not use ImportSectionImpl as it causes a using statment to be generated"
$COMMENT="%ImportSectionImpl%"
$headers


Hope this helps!

Paul

5

Bugs and Issues / Re: Sorry to beat a dying horse: Local Paths Issue

« on: December 08, 2009, 12:07:04 pm »

Hi Paolo -

Thanks for the quick response.  While I basically understand what it is that you are telling me, and I do have the general idea that the *.eap files are MS databases, I am an embedded systems developer, and not a database guy.  So, I don't exactly know what tool to use to manually examine the database.  We do have some copies of Visual Studio, is there a database spelunker in there I can use?

Also, this brings up another question.  We use Synergy as a version control tool for the XML files.  The EAP file is basically empty, but for a few package stubs.  The idea was that we wouldn't have to keep a fully populated, and fairly enormous EAP file in the version control system.  We'd just use the XML files to keep the state of the individual packages and use Get All Latest to lock and/or import them.  

So, is this surgery you speak of something that is going to have to be repeated every time someone starts out w/a fresh copy of the EAP file?  Or should we consider abandoning the idea of having an essentially empty copy of the EAP file and start keeping the fully updated version in Synergy as well?

Thanks,

Paul

6

Bugs and Issues / Sorry to beat a dying horse: Local Paths Issue

« on: December 08, 2009, 09:18:53 am »

I *have* done a search on this issue, and I think I have a different problem than what has been discussed in the last couple of years.  So, please bear with me.

Yes, we do have a database which has a half dozen or so different paths to generated code.  Yes, I do know how to hunt them down and fix them with a local path.  But this is where the problem comes up, that I haven't seen any solutions to in previous posts.  

After I apply the local path, I don't see the local path macro show up in the Generate Code dialog box.  The XML file shows the %MyPath% macro in the code generation path, but when I look in the Code Generation dialog box it shows it as if it were expanded: "C:\Some\Path\To\This\Darn\File.h".  It should look like: "%MyPath%\To\This\Darn\File.h"

If I am to have any hope of getting the rest of my users to use Local Paths, I've got to fix this.

Any Ideas?

Thanks,

Paul Ourada
Principal Software Engineer
Covidien, Energy-Based Devices

7

Automation Interface, Add-Ins and Tools / Re: MDG Link for DOORS - still supported?

« on: October 12, 2011, 02:55:26 am »

Thanks Adrian -

I had searched for the DOORs key word, found just the one response from Sparx, and didn't expand it before I responded. After I posted, I saw your original post. Me<--Duh.

Paul Ourada
Covidien, Surgical Solutions

8

Automation Interface, Add-Ins and Tools / Re: MDG Link for DOORS - still supported?

« on: October 12, 2011, 02:49:18 am »

Hi Adrian and Sparx -

I'm also having issues w/the DOORs plugin. I'm using DOORs v9.3, but I can't get EA (9.1.908) to connect to DOORS to import requirements. It says it connects, but when I try to import, it gives an error.

My support ticket is #11091152, and I've enquired after I entered the ticket, but have had no resolution.

Paul E Ourada
Covidien, Surgical Solutions

9

Automation Interface, Add-Ins and Tools / Re: C++ and Addins...

« on: December 16, 2005, 03:34:09 pm »

Thank you Eric, my colleague from three cubes over.  I am planning on putting together a zip of a VS project called Cpp_AddinFramework, which I will put on the EA Users Group website.

Paul

10

Automation Interface, Add-Ins and Tools / C++ and Addins...

« on: December 15, 2005, 07:26:54 am »

Ok, so this noob has done his homework and has seen that there is no support for writing C++ Addins.  

However, I don't really know C# nor VB nor Delphi, and neither do I particularly care to have to pick them up.  

So, at this point, the only impediment that I can find to writing pure C++ (not .Net) Addins is the lack of a header file that I can include to define an EA object, and thus create methods such as EA_Connect(EA.Repository Repository), etc.  Can anyone give me any ideas about how I should go about defining an EA object such that I can write a C++ Addin?

I'd be more than happy to post an example of how to write C++ Addins, if I could just get over this one small hurdle.  Or perhaps, therein lies the rub.

Much obliged,

Paul