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 [2] 3 4 ... 9
16
General Board / Object status colors displayed in diagrams
« on: May 23, 2015, 02:59:54 am »
Besides the value of the Status field in the object and the color associated with the status value in settings, how is EA determining the status color on the object in the diagram?  

I have a Package with many sub packages, diagrams and requirement object. When created they all defaulted to the status of "Proposed" which displays as a yellow border/shadow.

I tried to be quick and updated the t_object.status field to "Mandatory" for all elements in the package and subpackages. Expected to see the border displayed a orange, but it is still yellow. When I look at the properties of the object, status = Mandatory.

Apparently there is somewhere else in the database that is used to set the element's displayed color.  I looked at t_diagramobjects.ObjectStyle, but I do not think that is it.  

Any ideas?


17
General Board / V12: Where is connection qualifier text?
« on: February 26, 2015, 04:14:50 am »
In network deployment diagrams created before v12, I had servers and switches defined and displayed as nodes. Where appropriate I used a CommunicationPath between two nodes with the text of the qualifier for the source and target to denote the speed, such as "10 Mbps".
In v12, while the qualifier text does display on the diagram, I cannot find the text in the CommunicationPath properties dialog. Would have expected to see it under Role(s)/Detail/Qualifier for SOURCE or TARGET.

Appears in v12 one can now add multiple qualifiers to connection's source/target, thus, I assume t_connector.SourceQualifier and t_connector.DestQualifier may not be used in v12 except as legacy and that the qualifiers are now stored somewhere else. I guess I can accept this going forward and I see that if I add a new qualifier with the same or different text as the previous one, the display updates appropriately, HOWEVER, for some reason, EA will sometimes change the value of Role(s)/Advanced/Owner to True, causing a dot end point to be drawn on the connection. Not sure why it does it.

18
General Board / Re: Stereotype based on the Table metaclass
« on: October 21, 2014, 08:03:14 am »
Thanks q

Maybe I am not understanding your response.  In my case the issue is not so much as there are two stereotypes associated with the new object, but that the new stereotype that I created is not picking up the attributes of the table stereotype.
If I use the ellipse button and turn off the "table" stereotype, leaving just my "vTable" stereotype, I loose the capability to define table columns (reverts back to typical node attributes).  What I was hoping via the MDG generation was an object with a stereotype of vTable, a default name starting with vTable and maintaining the column definitions like a table stereotype.

Karl

19
General Board / Re: Stereotype based on the Table metaclass
« on: October 21, 2014, 06:59:34 am »
Jays (or anyone else):

Did you ever figure anything out about this.

I am trying to do the same thing or something similar. I wanted to create a stereotype of a table so that I can use it to display views with defined columns rather than (or addition to) using EA's view stereotype that only displays the definition text. The overall intent was to be able to associate an application's screen control to the source view.column than in turn can be traced back to the underlying database/schema table.column.

So I used the metatype of "table" and a stereotype called "vTable" whose only attributes were:
   _metatype: string = vTable
   icon: string= c:\.....\image.png
and then added it to an existing section of my custom toolbox with the attribute of:
   MDGName::vTable(UML..Table)

I expected that when I drag the vTable object from my toolbox onto my schema diagram, I would see an object with a stereotype of vTable which has a default name of vTable1 with the defined default color/text.

Instead I get:
- correct default color
- correct stereotype name on displayed diagram box, i.e.:
<< vTable >>"
- Correct association to allow defining table column attributes rather than node attributes.
- incorrect default name. I get "Table1" instead of "vTable1"
- incorrect stereotype when displaying properties. get "Table" instead of "vTable"

NOTE: If I change the property's stereotype from Table to vTable, it changes the attributes to normal node attributes rather than Table column definition.  

Karl  


20
General Board / Re: Element shadows for class status
« on: July 02, 2014, 12:56:16 am »
Thanks Simon.

I'm getting old, so I had to question my eyes :<)

Should I enter a feature request on the border width and transparency or should I expect it in an update release?

21
General Board / Re: Element shadows for class status
« on: July 01, 2014, 06:16:26 am »
I think it changed in v11.  I use it extensively in my network device diagrams.  I even added a few additional status and assigned a color, for example, if one of our scanning tools can discover it on the device on the network, I set the status to "Discovered" which has its own color.  

The shadow outline was working fairly well in v10, but now I can barely see it and forget it if the color is light (such as yellow).

22
General Board / Element shadows for class status
« on: July 01, 2014, 04:19:21 am »
I swear the shadow around elements in versions before v11 was lager and thus more visible to determine the color per status. (maybe it my eyes).
Whatever the reason, can the shadow outline be larger?
Would be nice if there was an option to set the width and location of the shadow, e.g., I would prefer to have it larger and be on the top and right side.  
I think it is a great feature, but as it appears now, IMHO, it useless.


23
General Board / Re: Glossary Import?
« on: September 20, 2012, 06:40:24 am »
I created a huge glossary within an EA project that consists of over 5000 terms and acronyms from over 70 sources. It was not simple and somewhat time consuimg (over a week) to get the data in a format that was easily imported.

I ended up using MS Access to directly update the t_glossary table after performoing a lot of data cleaning of the various sources. Basically, using PDF, Word, Excel and/or Access, I created tables in Access of the various sources in the same 3 fields that are in t_glossary table (Term, Meaning, Type). Besides some issues in the data cleaning, the largest issue regarding EA is the the Term field must be unique, thus you cannot have more than one definition (Meaning) for a term. So in Access before importing to EA, part of the cleaning effort was to concatenate multiple definitions within the same Meaning field. I also creates a standard where each definition eas followed by the name of the source and a blank line. I set the value of Type for each term to a value that suggested the purpose or type of the source glossary. Once I was happy with the tables in Access, I appended them to the t_glossart table in the eap file.

To handle acronyms/abbeeviations of terms, I did two things. I listed any abbreviations/acronyms in the definition.  I also created a separate entry for each abbreviation/acronym where Term=value of acrynym, Meaning=full name of acroynym and Type='ACR".  

Works out fairly nice.  Becomes a simgle source that can be imported into other projects.

24
General Board / Re: Associating GUI controls with data model colum
« on: April 06, 2013, 12:39:25 am »
Yes, using the Link Feature.name works in the RTF report.  THANKS. Not sure why I did not try that.  

On the other hand, there is an advantage of naming the connection similar to how table associations are named (see previous post reply).  The Relationship grid in the template appears to be sorted by the connection name (displayed under "Columns"). By naming my linked element connections, I get a better grouping of the elements in the report.

25
General Board / Re: Associating GUI controls with data model colum
« on: April 05, 2013, 12:54:14 am »
Thanks Geert

No, I have not tried eaDocx.

I did come up with an easy workaround, at least for reporting in the data model report. Taking a clue from EA's table association connections, I use the connection's property name field. When EA imports a schema from ODBC, it places the associating column names as the name of the connection. The data model template displays the connection name field under the Relationship grid's first column (named "Column"), for example "(FKeyID = PKeyID)". For my linked attribute connection, I enter the linked column (attribute) name as the name of the connection, for example: "(attriburename)".  Without changing the data model template, I now see both the table column (attribute) and the GUI Control's element name.
Also, in my version of the data model template, in addition to the element name of the source and target, I display the parent package name. That way, by naming the package the same name as the application screen name, I now have reference to the screen and control in the report.  

I think this well work well for the report.  

Karl

26
General Board / Associating GUI controls with data model columns
« on: April 04, 2013, 06:41:02 am »
Would like to relate an application screen field with its underlying database column(s) and then create a create a report that, given a database column, displays all application's screen/fields that are associated.  I am thinking this cannot be done, but wanted to see if anyone has any solutions. This is what I tried...

- I have the screen defined using interface models/GUI Elements.
- I have the database defined by creating a data model via "Import DB schema via ODBC..." function.
- It is the association of the GUI control with the table/column that I am having trouble.

I tried using the "Link to Element Feature"...
On my user interface diagram, I dragged a link to the database table and then created an association (realization) between the GUI Control and the database table. I then used the "Link to Element Feature" to associate the link to the actual table column (attribute). This is great for a visual representation on the diagram, but as the EA documentation clearly states, the actual association is still between the GUI control and the table (not the column). Thus the data model RTF template now includes all of the GUI associations under the "Relationships" grid for the table. This would be OK, in fact, desired, if the report could display the "linked" column (attribute) in addition to the table, but I do not see a way to do this. Assuming I cannot use the data model template to display the GUI to Table column association, I  would like to filter out the GUI control association so that the Relationships grid only shows schema table associations. I cannot see how to do that either.  So I am stuck.

For me the perfect scenario would be that the data model RTF template could still be used but instead of one Relationship grid, there would be two (so that one can define a different format depending upon the type of link). One would basically be the one that currently exist, that is, it displays the relationships between the tables (this would require some type of filter that would only include class associations whose stereotype = table). The other grid would show relationships between the table's columns and any associated GUI Controls (this would require some type of filter that would only include associations where one side is a GUI Control, plus the capability to display the actual associated table columns).

As it is now, not sure if it is worth providing just a visual association using the "Link to Element Feature" between the GUI element and the table column, if I cannot report on it or create queries to trace the use of a table/column within the user interface.  

Any ideas?

Karl

27
General Board / Re: Hide unused tagged values?
« on: February 08, 2013, 07:17:46 am »
P.S.
View the tags using the View/Tagged Values rather than the Tagged Values under the object's properties. It displays the total hierarchy of the tags.
Karl

28
General Board / Re: Hide unused tagged values?
« on: February 08, 2013, 07:14:01 am »
See if this works for you.
Create an instance of the sysml Reuiqement. The instance should inherit the Sysml tags and any that you defined. For some reason, when EA created the instance, it assigns all the tags to the instance.  Delete any tags that are null. The tag should show up on the classifier of the instance, so you will not loose it for future use. In the Feature and Compartment Visibility wizard, only check "Tags" amd leave "Inherited Tags" unchecked. Your diagram now should only display the populated tags associated with instance.  If you later add a value to one of the tags from the classifier, it will add (associate) the tag to the instance and you will see it displayed.

Karl

29
General Board / Control over the "More Tools..." layout
« on: February 16, 2013, 09:01:03 am »
Does one have any control over how the toolboxes are displayed in the "More Tools..." selection list?  (Just to clarify, I am not talking about the groupings within individual toolboxes).

Appears when one clicks "More Tools" the available toolboxes are grouped by UML, UML Extended and then by MDG.  Sometimes EA collapses the two UML groups with the associated toolboxes visible as submenu selections, but usually all of the UML toolboxes are displayed within its group.  Appears that toolboxes for the MDG group, are typically displayed as subgroup menus under the MDG name, but even then I have seen in one case where an MDG's tooboxes were listed indivudlaly in the main list.  In addition there is no order to the MDG group.

At a minimum, it would be nice if the MDGs were in alphabetically order.  Would be even nicer if we could set the order wihtin the MDG group as well as specify if the 2 UML groups could be collapsed.

Karl

30
General Board / Re: Updating package with orher project package
« on: September 22, 2012, 12:08:51 am »
Phil:

Thanks. Definately am going in that direction.

As I read more about versioning, I think that Geert and you are thinking alike, that is, as I currently understand, baselining and compare is EA's internal way of versioning without the use of a third party.

Plan on playing with that today.

Thanks agian, both Phil and Geert

Karl

Pages: 1 [2] 3 4 ... 9