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 - Modesto Vega

Pages: 1 2 [3] 4 5 ... 11
I am configuring a brand new installation of EA Business and Software Engineering Edition v 13.0.1310 for a team of about 5 users and would like some thoughts/opinions/ideas on how to address a couple of aspects of the installation:

The repository -  ultimately we are going to have the repository on a private cloud, possibly, but not necessarily, AWS; however the wheels here move slowly, very slowly, and would like to have the team collaborating before a decision is made. This is going to require a tactical solution; so the question is, can any think of any available options that does not involved procuring and plugging to a secure network a piece of tin (either virtual/cloud or real)?

"The metamodel" - I also want to customise EA for our specific needs and, as those who have read some of my previous posts know, I will typically approach this by developing a metamodel, which I have started to do, however, based on previous experience I am not convinced this is the best approach. I would also appreciate any thoughts/ideas/opinions on this.

[P.S.: A customised metamodel will be either an extension of TOGAF or the Zachman framework]

Well, it is been quite a while since I posted or contributed anything to the forum but I am back, at least until work demands every single minute of my time.

The first of 3 questions regards TOGAF. Our service desk has just gotten EA Business and Software Engineering Edition version 13.0.1310; I understand this comes with both TOGAF and the Zachman framework but somehow I cannot enable these extensions. Before I bother our service desk I need to establish if they missed a step during the installation - such as downloading/installing particular MSIs.

General Board / Re: Importing directly into an EA repository
« on: June 08, 2016, 07:31:33 pm »
I should be easy enough to create a cache of the existing elements as a dictionary so you don't need to loop the elements each time.
I think I've done so in the past in a modified version where performance was an issue.

Yes you can get almost anything from the API by GUID (except for parameters and tagged values I think)

Thanks I'll give it a try.

General Board / Re: Importing directly into an EA repository
« on: June 08, 2016, 06:14:57 pm »
Have you looked at the Excel Importer shared on my website?

There's a also a section that exports tagged values. You could do something similar for attributes so you can import and export them using this tool. (currently only import has been implemented)

I have seen your Excel importer, it would be fair to say the I am using a modified version of it. The main performance bottleneck appears to be with the function that gets an element by name, this is because it has to loop through the entire elements collection, it performs well on small packages but there are 2 very big packages and the performance is not so good.

I have been considering running the imports in 2 steps: 1) create "shell" elements (without attributes) returning the GUID and, then, 2) add the attributes. This assumes that that there is an API to find an attribute by GUID and have not done my homework regarding this.

Once again the problem is establishing the baseline.

General Board / Re: Importing directly into an EA repository
« on: June 07, 2016, 10:28:21 pm »
Thanks for the replies, much appreciated.

Please keep in mind the issue is the volumes, about 10,000 elements organised into different packages and 120,000 attributes.

4) Can I return the GUID back to the spreadhseet?
The normal way of syncing between Excel and EA is to include the GUID in a CSV export. If you don't want to do that you can probably do something using the Excel API to update its contents directly. The element GUID is stored in Element.ElementGUID.
Fully aware of this but as you know, you cannot import attributes using CSV file, the only way to import attributes is through Excel. Please correct me if I am wrong. Attributes are very important for the type of work I do, as important as elements.

5) How can I add 2 Tags to each element and attribute (Updated, Changed)
Element already has properties Element.Created and Element.Modified. For Attribute, add them as tagged values using Collection.AddNew() on the Attribute.TaggedValues collection. You can do that with an Element as well, if the regular properties don't work the way you want them to.
Also, fully aware of this. But what I am trying to do is finding an easy way to identify which elements and atributes have being or going to be updated each time the repository is refreshed using an import routine.

General Board / Re: Importing directly into an EA repository
« on: June 04, 2016, 02:01:24 am »
Let's explore the API option for a minute, just a few randon questions:

1) How do I set the language?
2) How do I set the version?
3) If some of those objects are database tables, how do I set the tablesapce and owner
4) Can I return the GUID back to the spreadhseet?
5) How can I add 2 Tags to each element and attribute (Updated, Changed)

General Board / Re: Importing directly into an EA repository
« on: June 04, 2016, 01:11:32 am »
About 10,000 elements organised in different packages and 120,000 attributes. This is to start with. They are organised into 3 packages with various sub-packages. There is also a need to identify changes once the baseline is contracted.

General Board / Re: Importing directly into an EA repository
« on: June 03, 2016, 09:59:20 pm »
Hi again,

If C# isn't an option, C++ works and so does Java -- but only for applications which drive themselves and access the EA repository from outside. The alternative to that is an Add-In, where EA is in the driver's seat, but that part of the API ("Add-In Model") does not support Java.

If you haven't done a lot of EA API coding, Geert's blog is probably the best place to start. There are also some simple examples included in the help.


PS  Oh, and qwerty isn't Paolo. :)
That will be too easy, work has to be made more difficult. I will have the same problem with C++ and Java. I am restricted to Excel and SQL.

P.S.: Yep, Paolo is not qwerty but qwerty words some of his messages sounding as if he is pretending to be Paolo; there are both quite unique.

General Board / Re: Importing directly into an EA repository
« on: June 03, 2016, 08:54:15 pm »
Thanks Uffe and Paolo. My preference is the API but this is a large job, very heavy lifting. Cannot use C# because getting the relevant tools installed on my machine will take a long time due to internal red tape.

I do understand the database schema relatively well, including some nuances. Any technical details on both routes database and C# will be welcome.

Currently using some custom code largely based on Geert samples.

IMHO, the import is still broken because only elements can be imported; it is not possible to import attributes or operations

General Board / Importing directly into an EA repository
« on: June 03, 2016, 05:55:11 pm »
Let me just start by saying that this sounds like complete heresy to me but I am going to ask about it. Other than the usual mechanisms, CSV imports or Excel macros, has anybody considered or even tried importing directly into the database tables of an EA repository?

The reason for such a heretical question is that the usual mechanisms, quoted above, are proving to be too "slow" to keep up with release cycles of a relatively large solution.

Hopefully nobody starts screaming "heresy".  ;) 

General Board / Re: Nesting classes (and generalization)
« on: April 23, 2016, 01:00:15 am »
Sometimes the automatic nesting is a good thing.
For example when using BPMN diagrams, or modelling user interfaces.

The option Tools|Options|Objects|Support for Composite Objects controls the automagical nesting behavior.

I will always learn something from you. Pity it cannot be done by type.

General Board / Re: Nesting classes (and generalization)
« on: April 22, 2016, 08:25:51 pm »
I wasn't expecting such a reply, thanks for the contributions.

Reading through the answers, I suppose an important part of the question is: when is it reasonable to use nested classes?
AND you MUST distinguish visual embedding versus nesting.

For the record, Nesting is about access (as KP said) it's an inner-class which should not be able to be accessed without passing through the outer class.  Specialization (get into the habit of calling it Specialization rather than Generalization) is about creating a (specialized) sub-class with a structure similar to the base - whereas there is NO such requirement in the nested class
In our framework, we go to extreme lengths to stop Sparx "nesting things" and in fact if we find it has we un-nest them - automagically.
Visual embedding is an exposition mechanism NOT a definition mechanism!

In our framework, we have instantiated the concept of the Generalization Set (Specialization Set) to allow multiple Set types.  We see NO reason why the metaphor should not be extended to ALL relationship types, SO LONG as the type is clearly communicated. 

The set element is interposed between the encompassing element and the set members - both within the repository and on the diagram.   You're not allowed to have a visually embedded element without having specified the relationship.

Paolo is correct
1) I am looking at representing specialisation (rather than generalisation) at a conceptual/abstract level which is often close to typing; please note that not all conceptual/abstract classes have a code implementation
2) I am visually embedding conceptual/classes for exposition/presentation reasons: it communicates the message better and it reduces the size of the diagrams
3) All visually embedded elements have a specified relationship, which is always an specialisation (but could be anything else)

IMHO architects who habitually visually embed elements are very lazy and inconsistant modellers.
If you have never faced a situation where you had to use visual embedding you are not modelling something too complex, or you do not print your diagrams, or you are not very environmentally conscious.
Conclusion, get rid of a bad having (nesting) and stop Sparx from automagically “nesting things”.

General Board / Nesting classes (and generalization)
« on: April 22, 2016, 01:18:22 am »
I have been extensively using nested stereotyped classes each time that a generalisation is involved; for example:

-----Structure Diagram
----------------Class Diagram
----------------Component Diagram
-----Behaviour Diagram
----------------Activity Diagram
----------------Use Case Diagram

In some diagrams I want to depict the generalised classes inside the generalising classes (to save space) and in other diagrams I want to depict a hierarchy. If the classes are nested, Sparx allows me to do the former but does not like me doing the later.

Other than not nesting the classes, is there anything I can do to be able to create both diagrams?

MOF, OWL, ArchiMate and IDEF5 are all languages that could be used to express ontologies. However, a class UML diagram can also be used to express an ontology.
Ontologies are not the languages used to express them. The languages are the means to an end, expressing an ontology.

I'd love to see you try and model a disjoint in Archimate :-)
You don't  ;)

I seem to have made a profession of modelling disjoints. Keep in mind disjoints are hindsight, while a well joined architecture is foresight. The difference between hindsight and foresight:  hindsight happens after the event, foresight before.

Disjointed architectures are architectures that already exist, they are not new designs. This is approaching the edge of consistency, similar to approaching the edge of chaos.

By the way the whole point of this thread was to understand what is involved in putting together an MDG to model disjoints. IMHO, you cannot model a disjoint using just one language, which in Sparkish, means multiple profiles.

There is a risk of confusing 2 things:

1) what an ontology is
2) the languages created by standard makers to express ontologies

I don't particularly enjoy quoting Wikipedia, but the following is a good definition and saves me having to consult my Kindle: “An ontology is a formal naming and definition of the types, properties, and interrelationships of the entities that really or fundamentally exist for a particular domain of discourse”.

An ontology is essentially a controlled vocabulary describing a particular business domain and the interrelationships between item in the vocabulary. The interrelationships are not just generalizations, which in this case are really types; there are also associations and information flows. With regards to the later, a Delivery happens after Payment, and Payment happens after Purchase.

MOF, OWL, ArchiMate and IDEF5 are all languages that could be used to express ontologies. However, a class UML diagram can also be used to express an ontology.
Ontologies are not the languages used to express them. The languages are the means to an end, expressing an ontology.

Pages: 1 2 [3] 4 5 ... 11