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 - Uffe

Pages: 1 ... 3 4 [5] 6 7 ... 70
OK, thanks guys. I'll give it a try -- in a separate, throw-away EAP project.

On an air-gapped computer.

Inside a bank vault.

In Siberia.

Hi all,

I need to create a bunch of generalization sets through the API.

I know the generalization set itself is stored in t_xref, and I can work out the details of the representation, get the power type in there, all good. But: can I just add a row to t_xref, or is there some more magic I need to do to make sure my database doesn't experience a critical power excursion resulting in a core meltdown and subsequent evacuation of substantial sections of northern Europe?

De profundis clamavi ad te, qwerty...


General Board / Re: Sub attributes
« on: September 18, 2017, 10:30:17 pm »
Late to the party here, but you can actually get pretty good visual results with properties (aka parts).

Let's say you have a class Outer where you want an attribute of another class Inner, and you want to show the structure of Inner inside Outer in a class diagram.

Instead of creating an attribute (or in addition if you prefer), drag-and-drop Inner onto Outer and select Property. Set the attribute/property's name, or leave it empty.

In the diagram, open Feature and Compartment Visibility for the property. Select Show element type.

So now you've got a property ": Inner" inside your Outer class, but you can't see the inner structure. Here's the trick.

Right-click the property and select Set Property Values (Ctrl-Shift-R, same as Set Run State for an object). For each sub-attribute you want to show in the diagram, specify a value. If you don't want to show a particular value, single white space works.

That's it.

Since the property is part of Outer's definition, you can repeat the same kind of thing if you want to show Outer as a property inside another class. The Inner property is also inherited as a structural element if you create additional classes with generalizations. It's all pretty neat really, if you are primarily modelling visually (as opposed to structurally) and are prepared to spend time fiddling the layout stuff.


General Board / Re: Best way to share a package
« on: September 11, 2017, 06:22:58 pm »

I know I bang on about this but the best way to do this is to use the reusable asset service -- the use case you describe is pretty much specifically what the RAS was designed to address.

It's not the simplest, but it is the best. It allows you to check differences, has a level of access control so you can restrict who can update the centralized models, and tracks dependencies between assets.


Bugs and Issues / Redefined Property vs Inherited Features
« on: September 07, 2017, 01:26:28 am »
Hi all,

Let's say I create two classes, both with some attributes, and a Generalization between them. In the more specific class, I can specify that an attribute is a "redefined property", and select an attribute from the more general class that the more specific attribute redefines.

If I then open the Feature and Compartment Visibility dialog for the more specific class and select Inherited Features -- Show Attributes, I would expect the property I have redefined not to show up. It's been redefined, after all. But it does show up.

Am I misunderstanding the "redefine property" feature?


General Board / Re: Versionhandling?
« on: September 07, 2017, 12:22:06 am »
Hej igen! :)

Given a set of generic version control requirements, a RAS-based solution gives you:

Access control of "as-is" model updatesYES
See differences between "as-is" and "will-be" modelsYES
Dependency tracking between version-controlled modelsYES
View "as-is" and "will-be" models side by side in same projectNO
Retrieve not-latest versions of version-controlled modelsNO
Ability for different teams to work on different "will-be" models      YES
Merging of different "will-be" modelsNO
Selective pull of version-controlled modelsYES
Mandated push of version-controlled modelsNO

A RAS-supported version control setup is a good fit if you have one team (architecture) working on one set of models, eg information model, basic requirements and test cases, common design components, while other teams (more than one) work on customer-specific requirements and design.

Each team works in their own EA project, to which they download the architectural models. If they make changes to those models, those changes are not automatically uploaded. If the team has sufficient access they can upload the updated models, but otherwise no. It's up to you to implement whatever review and approval process you need on top of that.

The architecture team also work in their own EA project, where they may update the architectural models and upload new versions to the storage. These updates are not automatically pushed to the customer projects; each customer project decides if and when they update their copies of the architectural models. There is no notification mechanism in EA to inform the customer projects of updated architectural models, so again it's up to you to implement one.

As always with EA, there is enough flexibility to allow several different ways of working, but that comes at the price of having to make a number of decisions yourself during deployment.


General Board / Re: Use Case x Test Case
« on: September 04, 2017, 09:13:54 pm »
I see. That seems to be a new feature in V13.5

It's been around since version 9 at least.

But the hierarchy it refers to is the project browser, or containment, hierarchy. That is indeed a type of relationship between entities, but it's not a connector. Connectors cannot be imported/exported using EA's built-in CSV functions.


General Board / Re: Versionhandling?
« on: September 04, 2017, 06:43:47 pm »
Hej Anders!

Version control is one of EA's weak spots. There are several features which can be used, none of them perfect: external version control of exported XMI files, baselines, auditing to some extent. For an organization that knows about version control in general and the issues around it, I strongly recommend implementing a version control scheme using the Reusable Asset Service, or RAS. (If you search the forum you'll find older posts by me recommending baselines; RAS is like baselines but with more features.)

With RAS, models are stored in a centralized storage, and uploaded/downloaded to EA projects. There is a diff function to show the differences between the model in storage and a project, and dependency management between models. There is also access control so only certain people may upload models, while others may download them. On the negative side, there is no way to compare two stored versions or even download an earlier version of a model from storage -- you can only access the latest version. But the older versions are still in there, so they could be extracted with a bit of work.

There is no branching, but if that's a key requirement it could be implemented using multiple storages.

RAS is more of a chore to set up since it requires the cloud server, but it's in my opinion the best solution. I haven't looked into time-aware modelling in any detail, but it looks to me to be more of a local feature used within a single project, not something suited for an enterprise deployment.

Whatever solution you choose, you need to be aware that for anything like an enterprise architecture you will need to do a bit of work yourself. EA has no concept of a configuration item, so you have to determine what constitutes a CI in your environment. This is crucial for any version control scheme to work outside of a very small team or a time span of a few months.

With the setup I outline, there are never two versions of a model in the same project. Each version-controlled model is maintained in one project, but accessed in several others. That's not how you described your requirements, but you also said you wanted a merge function and access control, which RAS has but I don't think time-aware modelling does.

The short answer is that there's no simple solution or single best practice. It is possible to set up some sort of version control in EA, but for it to be useful you do need to sit down and think about how you want to work.



But I think there should be some way of turning off the relatedElements temporarily. I can do it by turning off the metamodel, but that can corrupt my models. It might be possible to create some shape script inside each relatedElement script to do that, but again to complicated.

One way of working around this problem might be to duplicate each custom diagram type, naming the duplicates "bla bla - sketch" or similar. You can then check the diagram.type or diagram.mdgtype property in the shape scripts. Switching between diagram types is easy and, provided you've set them up with the same toolboxes, seamless.

How well this works I couldn't say. The shape scripts would still get executed, but they'd issue fewer drawing commands.


The reason you can't move the AssociationClass link to a normal Class is that it is virtual (it's not implemented as a real entry in t_connector).

Right. It's not even a NoteLink. It looks like it's purely visual and has no backing representation in the database.

What is the mechanism for the Association Lozenge (Diamond) to become an AssociationClass for a relationship?  I can do for a Class via the context menu, but there's no corresponding context menu entry for the Lozenge.

The N-ary Association is a weird beast. It too seems to be be the subject of some behind-the-scenes fancy footwork -- it's stored in t_object, but behaves neither as a Classifier nor as an Instance. But you shouldn't use it as an Association Class anyway: the Association Class represents an association between two elements where the association also has some Class-like properties, while an N-ary Association is an association between multiple elements.


Hi Doru,

You want the "context item" events, specifically EA_OnContextItemChanged(). This alerts the Add-In that the user has changed their selection in the GUI.

The similarly named EA_OnNotifyContextItemModified() is fired when the element, attribute, etc data has been modified.



General Board / Re: Security: Row Level Locking
« on: August 22, 2017, 05:13:12 pm »
Do I understand correctly that this is a "vertical" visibility level mechanism?  From the documentation, a user at level M can see anything defined at level <M.  There is NO concept of "horizontal" visibility.  Say we have two branches both at Level M; B1 and B2.  We can't restrict Users from (for example) seeing stuff in B1 but not seeing stuff in B2.

Yes, that's how I read it too. They are cumulative levels, not individual privileges (like the user security model).

Disclaimer: I don't know anything.

It is in a bit of a raw state; I think the author was still doing some tweaks to it.

I'll say. That third paragraph in particular reads like it's lifted straight from an internal pitch memo. :)


General Board / Re: Security: Row Level Locking
« on: August 21, 2017, 08:10:47 pm »
It's in the Pro Cloud Server. It's listed under the "new features coming soon" section of the sales blurb, but the installation help page says it's in place. I haven't tested it myself though.


General Board / Re: Locked Packages not visible
« on: August 21, 2017, 06:17:25 pm »
The lock mechanism can sometimes get out of sync, especially if combined with version control, reusable assets, or some other function that exports/imports packages as XMI.

IIRC, the problem is a GUID mismatch. The locking mechanism locks by GUID (t_seclocks), and both packages and individual elements can be locked. Each package is represented by both a t_package row and a t_element row. Their GUIDs are supposed to match, but that match can break when something goes wrong during XMI import. When this happens, you're left with ghost locks.

So you should take a look at t_seclocks and verify that all its rows actually refer to valid GUIDs. You should also verify that each supposed package has both a t_package and a t_element row and that their GUIDs match.

Oh, and: the project integrity check doesn't catch this.


Uml Process / Re: What is an "Instance"?
« on: August 17, 2017, 09:26:43 pm »
Thoughts welcome!

Here are some! :)

I think ArchiMate's discussion of "generic/specific" is unfortunate. Or just plain wrong. Classifiers should never be used to represent a specific individual.

In UML terms, "generic" and "specific" should be used to denote what generalization/specialization relationships show, and Customer cannot be specialized to "John Smith" -- that's an instantiation if ever I saw one. Customer could be specialized to Private Customer and Corporate Customer, but not to an individual member of the set of all customers. That's instantiation.

Instances are set members, and classes are sets. Specialization creates progressively smaller subsets (and multiple inheritance creates intersections), but even a subset containing only one member is still a set -- it isn't the member. You could specialize Customer all the way down to "Customer Whose Name Is John Smith", but there is still a world of difference between that and the instance "John Smith".

As to Classifier, I think that's a bit of a red herring here. Classifier is a concept in the UML metamodel, not in any actual model created using UML. Throwing metamodel concepts into a regular model doesn't really make sense. It's like if you're reading a novel, and suddenly the author breaks into a definition of the term "adverb."

Classifier is the generalization of most element types that are not instances or structural features -- in other words Class, Component, Interface, Use Case, Actor, Node, Activity, etc. One of the characteristics of a Classifier is that it is instantiable, another is that it can be the source and target of generalizations. Those characteristic are inherited by all specializations of Classifier.

So I would say no, there are no classifiers in your examples. Car is a class, and BMW 318i is another class which is a specialization of Car. The only classifier here is Class itself. If you want to look at the metamodel side, Car and BMW 318i are both instances of Class. You can look at Car and say "this is a Class", but you can't look at it and say "this is a specialization of the concept Class".

It may help to add (silently in your head) the word "characteristics" after the name of any classifier. The Car class defines a car's characteristics, the Customer actor defines a customer's characteristics.

An instance can represent either one (specific) or any (unspecified) member of the set defined by the classifier. Which it is, is up to you the modeller: UML has no concept of definite and indefinite articles. I usually use named instances in the former case, unnamed ones in the latter. Or you can name your instances "a", "some" or "any" if you prefer.

Regarding actors and roles, you raise some interesting points. I disagree with your contention that UML Actors are incorrectly named, because Actors belong to Use Cases where they are loosely defined as those who act, or more specifically those who interact with the system.

Roles are often useful, but you can't replace Actor with Role because in contrast with actor, a role can't be defined simply as "that which (inter)acts." Role must be defined by two characteristics: that which takes on the role and the situation in which the role is taken on. In other words, Role is a relational concept and as such is best represented by a connector.

So in a use case model you could use a set of reusable actors, and stereotype the use case associations with "approves", "supervises", etc to represent the role each actor takes on within the context of each use case.


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