Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - kepNCI

Pages: 1 ... 3 4 [5] 6 7 ... 9
61
Bugs and Issues / Re: Stereotype bug? using same name stereotypes
« on: December 13, 2012, 05:05:02 am »
More Info: (leading me to believe it is a database issue)
I have a project on a SQL Server. I transfer the project to an EAP database on local PC.  

In both database projects, I create an instance on a diagram from dragging an element from the project browser that has a stereotype of "Switch" as defined in my MDG.

In both cases the instances inherits the tagged values of the classifier, however...
in the SQL project the instance does NOT pick up the stereotype name (Switch), or the icons defined in the MDG stereotype profile.
in the EAP project the instance does have the correct stereotype name and icons.

62
Bugs and Issues / Re: Stereotype bug? using same name stereotypes
« on: December 06, 2012, 05:16:32 am »
This apparently is a bug.  The 10.RC1 release partially fixes it in that the creation of the instance from the project browser is creating both the Router and Server instance with the correct stereotype name and icons.

Where the issue still is not working is when one tries to change the stereotype of the element via its properties. Now when I select "Server" which should be my MDG's stereotype, it appears to be picking the stereotype name and display defaults/icons of the Web Modeling profile's "server" stereotype.

63
Bugs and Issues / Re: Stereotype bug? using same name stereotypes
« on: December 06, 2012, 03:35:25 am »
Likely important point I forgot to mention in the detail above:
The tagged values created from the stereotype's attributes always reflect my MDG attributes (fro initial element and any instances), so apparantly EA is not getting confused at that point.

64
Bugs and Issues / Stereotype bug? using same name stereotypes
« on: December 06, 2012, 03:07:26 am »
Can I define a stereotype with the same name as an EA defined stereotype?  For example, EA has a node stereotype for "router".  In my MDG I have a node stereotype called "Router".  I think EA is getting them confused (see detail below).

If the answer is that there can only be one stereotype of the same name, case insensitive, then can I somehow selectively disable the EA stereotypes causing the confliction?  
(Note that some MDGs delivered with EA also duplicate stereotype names and thus may have the same issues. For example, server and unit).

DETAIL OF PROBLEM:  
  (using EA 935)

MDG PROFILE SETUP:
I have a node metaclass and extended from it, several network device stereotypes defined, including:

Name: Server
   StereoType: stereotype
   Attributes include:
        _metatype  string  Server
        _image   string  <Image type="EAShapeScript 1.0" xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="bin.base64">UEsDBB...
        icon   string   C:\...\Icons\Server_16.png
   Default Appearance has background color of blue.
Name Router
   StereoType: stereotype
   Attributes include:
        _metatype  string  Router
        _image   string  <Image type="EAShapeScript 1.0" xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="bin.base64">UEsDBBQA...
        icon   string   C:\...\Icons\Router_16.png
   Default Appearance has background color of green.

Both are referenced in a toolbox profile in identical format and appear in the toolbox with their associated icon.

All seems well within the MDG.

PROJECT USING THE MDG:
As you can see the definition of the stereotypes are nearly identical, yet EA is treating them differently when creating elements in a project.

When I drag the Server element from MDG toolbox onto a diagram, EA draws the rectangle with the correct blue fill color, displays the server icon and the displayed name includes the "<<Server>>" stereotype. The element in the project browser has the correct icon. Likewise when I drag the Router from toolbox onto a diagram, EA draws the rectangle with the correct green fill color, displays the server icon and the displayed name includes the "<<Router>>" stereotype.  Both look as expected.

I now create an instance of a Server by dragging the Server element created above from the project browser onto a diagram and selecting to create an instance. Likewise I create a Router instance. This is where EA treats them different.

For the Server, EA draws the rectancle with the correct fill color, icon, but does not display the stereotype name above the name. In the project browser the stereotype is "<<server>>", not "<<Server>>". (note the small case on "server" as if it is picking up the EA defined stereotype.

For the Router, EA draws the rectancle with the correct fill color, but does NOT display the icon,  but does display the stereotype name above the name, but its value is "<<router>>, not "<<Router>>". In the project browser the stereotype is also "<<router>>".

I am guessing that when EA looksup the stereotype for an element, some logic is getting confused between its own defined stereotype "<<router>>" and my MDG defined stereotype "<<Router>>" when they have the same name (with exception of the case).

This speculation is further supported when one tries to change the stereoype of an element in the project browser (for either the inital element or an instance). Although I see my MDG defined stereotypes in the dropdown selection (as determined by the Title case used),  if I select my "Router" strereotype, it always deploys the EA "router" stereotype name and no icon. Even if I use the ... lookup and uncheck "router" and then select the "Router" under my MDG, EA deploys the "router" stereotype.

Karl

65
Bugs and Issues / Re: Edit a glossary item
« on: December 07, 2012, 04:50:22 am »
Doug:
I am not able to create your scenario, that is, I do not know what you are right clicking to get a selection to modify your glossary.

You should be able to change a glossary defintiion by:
- Go to Project/Documentation/Glossary...
- Find your term (note that the items are sorted by Type, Term. It might be easier to find your term, if you click on the Term heading to sort by Term instead of Type.)
- When you make an update in the Description, it will enable the Save button. Once you make the update, just click Save.

If you are updating the name of the Term, then clicking Save will actually create a new glossary item. You then will have to delete the old (misspelled term).

Another perculiarity is that if you are just changing the case of an existing Term (e.g.  "AAA" to "Aaa"), you will get a duplicate key error. The workaround I use would be to  Change "AAA" to "Aaa.", which creates a new item, delete the old "AAA" term and then change the new term from "Aaa." to "Aaa".

Hope this addresses or at least helps your issue.
Karl

NOTE: Within the EA glossary, you are not allowed to enter the same Term value duplicate times. Thus if you have multiple definitions/descriptions for the same term, you must enter them all under the same Term item.  

66
Bugs and Issues / Re: Stereotype background default color and instan
« on: October 13, 2012, 12:58:04 am »
KP:
Currently in my MDG profile, the stereotype extends to a Node metaclass.  Are you saying that I need to add an Object metaclass (or maybe an ObjectNode metaclass) and extend the stereotype to that also?
Karl

67
Bugs and Issues / Re: Stereotype background default color and instan
« on: October 13, 2012, 12:44:14 am »
How do I extend object as well as class?  
Setting either of these options seem to have an effect:
- Objects/Extend Complexity
- Diagram/Behavior/Instance has Classifier style
and I do not see any special attribute that I can apply to the stereotype.



"Diagram/Behavior/Instance has Classifier style" raises another question...if I have Instance has Classifier style set, I would also exect that if I change the instance classfier, that the instance would reflect the background color of its classifier's default, but the instance appears to remain the same color as it was.

68
Bugs and Issues / Stereotype background default color and instances
« on: October 12, 2012, 03:52:55 am »
Believe this is a bug.

When converting a node to an instance, the instance should pick up the attributes of the node, including color.

I have a node stereotype defined in a profile for "Router" where I have set its default appearance for its background color to blue. When I create a Router on a diagram from the Router element in my toolbox the background is correctly filled with the default blue background. When I change the element to be an instance, the instance's background reverts back to the EA default tan color. It should still be blue.  

This works in other areas such as dragging the Router stereotype from the project browser. If you select creating an instance or link, the resulting background color is the correct default of blue.

Agree?    

69
Bugs and Issues / Alternate Images and Microsoft Cursor Error
« on: October 03, 2012, 12:23:41 am »
Occassionally on my deployment diagrams when using an aternate image with visible attributes (tags and notes) I receive the following error when I attempt to save the diagram:

Microsoft Cursor Error [-2147467259]
Data provider or other service returned an E_FAIL status

Appears to be associated with the placement of the visible attributes of the ogject using the alternate image. If I move the attributes (not the image) to another location in the diagram the error sometimes goes away. I have yet to determine a consistent condition(s) that always causes the error.

Any ideas?  It is happening more that I would like and takes a good bit of playing around with the daigram to get a good save.

Karl

70
Bugs and Issues / Re: physical (visual) arrangement of ports on node
« on: June 22, 2012, 12:12:49 am »
Just discovered a big clue.  Not only does moving a port on a node effect the position of ports on the node, it effects the position of ports on other nodes. The commonality was that the nodes were in the same boundary.  

Removing the boundary has greatly improved the capabilty to accurately position the ports on each node. I am hoping that once I position the ports on each node I can re-create the boundary.  Apparently it is in the logic that assoicates the element within a boundary.

71
Bugs and Issues / Re: physical (visual) arrangement of ports on node
« on: June 21, 2012, 11:31:19 pm »
In this example I was not even using MDG technology. Both the node and the ports were created from EA's component diagram and associated toolbox.

72
Bugs and Issues / physical (visual) arrangement of ports on node
« on: June 21, 2012, 04:54:55 am »
I have a network node with 13 sets of 12 ports.  On a diagram I try to evenly space a node within each group and then separate each group by even more space. The purose of the diagram is not only to document the network config, but also to use a printed view for management, thus I am trying to make the diagram visually attractive as well as functional.

Why does moving one port for better visual placement effect the position of other ports. Almost appears that EA is trying to control some grouping of some of the ports, but the grouping does not make any sense. It is making it impossible to make a nice looking dagram.

73
Bugs and Issues / Re: UML Profile Alternate Image Issue
« on: April 05, 2012, 04:04:20 am »
That is all you did you fix it?  
In my profile I used emf and jpg files. The emf images were imported from SPARX image reference xml. Neither are being displayed in the new project.

74
Uml Process / Re: Tracing network device locations
« on: February 24, 2015, 04:11:26 am »
Thanks for the comments.
Do not know why I did not find the package content option. Seems obvious now and just what I wanted.
The primary purpose of the project is a massive system architecture so UML and EA seems perfect.  Location of network devices is a small function of the total design and thus I would not believe would warrant a separate GIS tool.
Am I breaking any UML rule/guideline when connecting a device node to a package element via a nesting connection?    

75
Uml Process / Re: Tracing network device locations
« on: February 22, 2015, 04:04:13 am »
Additional comment:
One think I do not like about using package elements on a diagram is that it lists all of the elements found in the associated diagram.  Apparently there is bit an appearance option to not display the list, at least I could not find it. For example the package element for the building that has a main server room becomes huge because it lists each server and composite parts.

Pages: 1 ... 3 4 [5] 6 7 ... 9