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 - Svend Erik Nygaard

Pages: 1 ... 3 4 [5] 6 7 8
61
General Board / BPMN: Data objects vs Classes?
« on: October 10, 2014, 02:24:06 am »
In my concept/information model I have classes representing physical objects as well as information objects. We have definitions, descriptions and a ton of other valuable specs/connections associated with these clases.

However in BPMN it is suggested that I use a ”Dataobject” element (as physical objects or information objects).
On the DataObject I can specify an ”ItemDefinition” element, and then on the Itemdefinition I can specify my class from my conceptual/information model. To me this is a lot of indirection a lot of extra work and elements:
DataObject.itemSubjectRef -> ItemDefinition.structureRef -> Class
That gives me three elements instead of one.

EA BPMN actually does not prevent me from using my Class elements directly with the BPMN data associations instead of the DataObject elements. So I’m very tempted to just use my classes directly in BPMN (or instances – or instances with states)
Is that a bad idea? Have I misunderstood the way to link from BPMN to my classes in concept/information model?

62
General Board / Re: BPMN: Data associations at two levels?
« on: October 07, 2014, 12:08:27 am »
Thanks.
Nice to be sure that I hadn't missed a point on this :-)

63
General Board / BPMN: Data associations at two levels?
« on: October 06, 2014, 08:46:50 pm »
Do I have to create separate data associations for detail level (inside the process) and for top level (inter process)?

I have a top level view showing the object transferred between the two top level processes as shown here:


And I also have detail views for the internals of those processes showing which internal activies sends/receives the object - as shown below for the process that sends the object to the other process (physically drives the object and leaves it at the place where the other process picks it up:


Now the question is: Do I have to create the data association at both levels - or is there a way that EA recognizes the lower level data association and is able to show it automatically at the higher level?



64
General Board / Re: Render the EA notes format in external formats
« on: August 09, 2013, 04:49:01 am »
Yes, I did make the observations about the line breaks within the list/bullets too - as well as whitespaces - in particular tabs are a challenge.

I never noticed the -> issue, even on EA 7.5 - but maybe that's due to my use of tagsoup's library for HTML encoding (with whitelists).

65
General Board / Re: Render the EA notes format in external formats
« on: August 07, 2013, 03:59:36 pm »
You're right.
I'm losing linebreaks.
But all formatting (bullets, bold etc seems to be fine)

66
General Board / Re: Render the EA notes format in external formats
« on: August 06, 2013, 10:50:35 pm »
A warning of course:
Ups, of course, I do need to check up on this very soon the see if that MS Report function actually includes some HTML encoding for non-white-listed tags  :-?)

67
General Board / Re: Render the EA notes format in external formats
« on: August 06, 2013, 10:20:48 pm »
Thanks, it got the right output now.

I found out that the MS Report Builder that I started to use this week actually covers it with an HTML render and then when the report is saved as either MS Word or HTML it works fine  :)

But I will keep both the API methods i mind for future use.

68
General Board / Re: Render the EA notes format in external formats
« on: August 06, 2013, 05:30:52 am »
Thanks.
I had not seen those.

I will have a look at them when I get into my office tomorrow.

I was thinking of something I could use externally to EA - in SQL or in the report processing (perhaps regular expressions or libraries if the EA format is a subset of some standard).

I never succeeded i using the EA Windows automation interface from Java.

Was what you had in mind, that I call those functions from outside of EA - - like from a report builder?

69
General Board / Render the EA notes format in external formats?
« on: August 05, 2013, 10:01:20 pm »
When I create SQL reports from the EA repository, i of course get the raw formatting tags in the notes field.
Does anyone know of formating methods/libraries/conversion formulas to render the EA notes format in external formats properly.

I realize that half the formula depends on the output format.
I need to render it in MS Word, HTML, excel, and plain text

70
General Board / Re: Version Control:  Practical limit in size?
« on: August 05, 2013, 09:40:03 pm »
Yes I'm going with the single shared model.

(Geert, you made me laugh with your "don't ruin my good mood by asking ..."  ;D)

So Yes, I see that for backup/rollback purpose I will probably rely on the DBMS restore (as Geert mentions) and encourage users to make focused XMI exports immediately before big updates on focused parts of the model.

And then I will look to the user securituy policies to manage team/user concurrence. I guess either of the two security policy modes ("User/Group" Locking and "Require User Lock to edit Mode") can will work without VC (?)

71
General Board / Re: Version Control:  Practical limit in size?
« on: August 03, 2013, 01:01:13 am »
Oh, - the  'Published-EA-Model' will only 'get all packages' from the VC (not check-out).  The  'Published-EA-Model' is not for modifying - only read. People can read and search the model via EA lite - or via an HTML site extracting its info from the  'Published-EA-Model'.

BACKUP: But I would need to go to my DBA and ask for a restore (into a tmp db) - and repeat doing so until I found the correct 'revision'.
If I don't know how far to go back - I think/hope it is easier to use VC to retrieve the needed revision. Especially if we have a number of smaller XMI-packages. I may need to retriev several different packages - but I only need to find one package to determine how far back I need to go.
 - maybe I'm too optimistic about that (?)

Ok, but 111.000 is still a lot (how big repositories do you know of?)
 - It's encouraging for me to see that it is ok with big EA repositories.

And in our 22.000, actually a few thousand elements are reversed engineered as well (DB and XML schemas). We have <impl>realizations showing where our <BusInfo> elements are implemented in DBs and in our canonical model.

(I have scripts breaking up the columns (attributes) and XML elements (often attributes) into separate fully valid model elements - making it possible to create the <impl> realizations - that accounts for a lot of elements)

72
General Board / Re: Version Control:  Practical limit in size?
« on: August 02, 2013, 10:02:21 pm »
'1/3 of our users are pure business analysts' - wow, then 110.000 elements is a really big repository - I thought ours was big because the elements are mostly handcrafted business elements.

"Check-in only":
I.e. we will actually only use the VC as a revision archive
  -  UNTIL we have an issue (e.g. unintended delete) and need to go back through the earlier revisions , find the relevant one - 'restore' it (check-out) into a new, temporary model - then manually fix the issue in the main single shared model.

Actually, a second  use could be to use the VC to build the Published model. Of course then "Check-in" would also mean "Publish" (and another 'Published-EA-Model' should "get all packages then").

Do you have any means of discriminating between a work-editing and a published-edition in your models?

How big is  your portion of shared packages I guess it is small compared to the 110.000 elements?

73
General Board / Re: Version Control:  Practical limit in size?
« on: August 02, 2013, 08:57:49 pm »
Thanks Geert.

So what are actually the scenarios/actions where you have had use for your VC?

I get the impression that in your 35 users are software analysts/designers/programmers mostly ?

At my site we are modeling business elements (strategy,processes,concepts, objects - and infrastructure - and more and more we get business people themselves active in modeling :)
But we want to be able to relate elements accross aspects and areas. So from your and qwerty's response I think, I may drop the plan about VC. I'm considering a solution with a single shared model where we checkin but never checkout and never get - but if needed I can checkout a revision of some packag(s) into a temporary secondary repository to resolve any issues. But I guess, I cannot block the checkout/get functions in the single shared repository's EA clients ?


74
General Board / Re: Version Control:  Practical limit in size?
« on: August 01, 2013, 05:39:56 am »
Thanks again qwerty
for a very elaborate answer  :).

Although a little disencouraging  :-/

It's my impression that you have got quite some experience with this topic.

Well it looks like, IF we go ahead with it, we need to perform quite some tests/experimenting on the chosen solution.

1- Get All Packages: 'will come in the way' - I suppose that means: too heavy.  I hope that any VC will recognize if a package (XMI) has not been changed since the client's existing package (?) in that way we MIGHT be able to control it.
2- moving packages - yes, that worries me. I think, especially on this one, we'll need to do some experimenting on different scenarios.

Sequence diagram - interesting, who would have thought that!.

Benefits:
- Undo: But (assuming private models) I could export an XMI with the messed up private model, then undo, then compare with my XMI (possibly creating an extra, local repository from that XMI), fix everything  ;D - and then check-in.  In that way, other users would remain unaffected by the incident.
- audit: that COULD though, in many cases make me aware of somebody's deletion perhaps months earlier than otherwise.
- backup: yes/no for us. The more concurrent users/projects, the worse a restore will be. (even with a continuous backup - although less so)

But of course, we will have to assess whether the VC will give more work than benefit! - and I guess, none of the challenges you mention depend on which VC we choose.

Again, thank you very much for your answers - they certainly have made me more concerned   :)

75
General Board / Re: Version Control:  Practical limit in size?
« on: August 01, 2013, 02:42:34 am »
Thanks qwerty.

I think, we will apply VC to many packages, thus having many 'discrete' XMI files. It is my understanding that that will make it possible to make relatively quick export/imports (checkins/outs).
I do have two concerns in that picture:
1) will there be any loss of connections between such 'discrete' XMIs (the documentation's word 'discrete' worries me here)?
2) Will that make a mess out of moving packages around later?

As for our reasons for VC: It is mostly for managing multiple concurrent projects on the same model (the model is an enterprise wide model). Things like 'undo-facility', audit changes, change management, package revision history, user access control.  Most important is probably the 'undo'. As it is right now, someone may unintentionally delete a portion of the model without anybody finding out for a long time. That makes me nerveous. (i guess the audit feature can help us somewhat with that even without VC)

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