| nikdo |
| Newbie |
|
| Canada |
|
|
| None Specified |
|
| Friday, July 27, 2007 |
| Tuesday, September 18, 2007 5:33:53 PM |
4
[0.02% of all post / 0.00 posts per day] |
|
Thank you for the reply.
Assigning a type to the port made the interface realization usable. It would help then if the tooltip would indicate the port needs a type in order to use the interface realization when the interface realization is selected from the toolbar. This is what happens for other artifacts, such as parts.
The modeling of dependencies on composite diagram would be useful, indeed. Looking forward to it.
Keep up the good job. uModel is starting to shape up as a great tool to use. Now if only you'd implement my feature of being able to use .NET namespace aliases in diagrams, most of my problems would be fixed (that one is a serious setback for me)
|
In composite diagrams, it appears one is supposed to be able to model input and output from ports to interfaces. In Component diagram one can do this. Dependency association to illustrate input, usage dependency to illustrate output.
However in composite structure diagram, I cannot model an interface as an input to a port, because the 'dependency' association is not allowed to be used.
Am I missing something here?
|
So Altova released the new version of uModel. It added some nice features. However half the website doesn't mention the new release, the release notes are still not up and the worst: the plugin for VS.NET is only available for the Enterprise edition and not for the professional one.
Am I the only one to feel a bit cheated here? I mean all other components of the professional suite have plugins for VS.NET for the professional suite, but not uModel. Furthermore, the professional series includes uModel, so why exclude the plugin? On top of that the altova website mentions the integration of uModel into VS.NET as a big feature (which it is!) but they don't mention anywhere that this integration is available exclusively to enterprise license holders.
Any explanation? Thanks
|
Hello,
We often use aliases to namespaces in our C# code.
Example: Code:using DL = Acme.DataLayer;
We then use the alias to declare member variables, such as: Code:DL.SQL.Command cmd = new DL.SQL.Command();
When reverse-engineering a .NET C# project, this results in having all these alias becoming "Unknown Externals" and of course the links, such as associations and dependencies are not mapped to the appropriate objects.
Any idea how to resolve this? using aliases in C# is very convenient and I don't see us dropping this practice. However it then involves us retyping the datatypes in the class diagrams, and, of course if we were to re-merge the model into the code, we'd loose the declarations with the aliases.
Thank you kindly for your response
|
|
