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

Pages: 1 ... 41 42 [43] 44 45 ... 71
You're making a rod for your own back.

I'd suggest you create a "menu" diagram at the top level and create your HTML report from the top.  That way your package structure can stay the way you want it.

General Board / Re: View AssociationClass in traceability window
« on: May 17, 2016, 07:20:22 am »
I'm pretty sure I've submitted a feature request for this.

Bugs and Issues / Re: Auto-hidden connectors
« on: May 16, 2016, 01:09:09 pm »
I'd settle for just being able to straighten the association class connector :-)

Bugs and Issues / Re: Label backgrounds - consistency please
« on: May 16, 2016, 01:03:41 pm »
The boundaries of the labels really p*** me off.  They look fine on your diagram and then when you save them them as an image or to the clipboard for use in a document you find an opaque background has materialized and is clipping your shapes.

Bugs and Issues / Re: HTML export on web server
« on: May 16, 2016, 07:16:23 am »
I've published models both directly to a directory under IIS and to a SharePoint file library.  For SharePoint you need WebDAV access and probably need the admin to change the setting for maximum number of files in a document library.

A MDG xml file is typically created from many other files (e.g xml profile files, doc-templates, icons, scipts,…) and as far as I understand, the MDG xml file is all about to pack all that stuff in one file.
For me that works well (apart of this,30648.0.html), but there is one thing what is different from all the others, and that is the model template stuff. For model templates there are not GUI elements to write the mts file (ok for me) and model templates are not packed in the xml mdg file (what this issue is about).

Packing the models into the MDG xml would remove several pieces of functionality.  Currently I can give a MDG to another organisation and they can create their own model templates or tweak mine and the MDG doesn't have to be recompiled.  And as I have said before you can change what parts of the MDG employee roles can use but using file system permissions to make them unavailable.

Doing that, would make EA mdg stuff implementation consistent and would help me and obviously some other people a lot; it is not at all “all or nothing”. It is about “providing consistency which helps”.

What you're suggesting isn't consistency, its downgrading current functionality to suit a very narrow usage of the application.

General Board / Re: Enterprise Integration Patterns
« on: May 13, 2016, 08:18:03 am »
I'm not sure why I personally would want to do this when I could do it more accurately in UML.

but what?

John, qwerty seems to have bad days when he thinks he can set rules in addition to the T&Cs and Etiquette posts Roy C has pinned to the top of each forum.  It's best to ignore him and not engage, he'll get over it and start to post productively again.

From my perspective I prefer that people ask again rather than suddenly having a bunch of zombie threads.  Often people are making statements that don't hold true across versions and the thread is a really crap knowledge record.

Bugs and Issues / Re: HasTag anomalies
« on: May 12, 2016, 02:33:58 pm »
In terms of the practical purpose of this thread as a discussion of if EA should be changed.

Both forms of HasTag behave as if they are evaluating based on a single call to get the value. As a result:

HasTag(tagname) gives a result that doesn't match the function name when an empty tag is present
HasTag(tagname, tagvalue) gives a result that doesn't match the function name when no tag is present and checking for an empty value

Unfortunately, changing the behavior of either of these cases would almost certainly break existing shape scripts out there in user land. I'm not willing to do that. The documentation will have to be updated to clarify the behavior and there will have to a be a separate solution to your requirement of distinguishing between an empty value and a missing tag.

You somewhat seem to address your own point.  Introduce a new properly named function call that returns results for all possible conditions.  Deprecate the old function calls.

Bugs and Issues / Re: HasTag anomalies
« on: May 12, 2016, 10:18:56 am »
Depends on the semantics you apply to the two extrinsics:  Null (or «Nothing» ) and Empty (or «Missing»); not to mention «Unknown».  You can't tell which is meant and certainly you can't assign both meanings to the one non-value.

This is where I disagree I think both «Missing» and «Unknown» are part of your test for completeness, and in practical terms missing equals unknown anyway.  It's just slightly more nuanced.

Our company has a modern distribution and management environment. Apart of getting distributed something, needs considerable time (done by out IT) that works fine for many cases. I personally distribute lots of things this way.
However distributing a mdg this way, that will have in future maybe once a week a new mdg version, were the users should decide which version to use on project level, what should work maybe ten years later, would cause nothing but trouble.
By having all stuff in one file, we would need no effort and nor trouble at all.

You don't distribute the MDG this way.  You already have a central key store, why would you also not have a central MDG and model store?  Bear in mind you're talking about text files that take at the most seconds to load even at distance over a WAN.  The IT management infrastructure ensures that all Sparx EA clients are configured correctly.

The shortcoming with loading the MDG and models into the repository is that it is all or nothing.  Everybody gets everything.  Next you'll be asking Sparx for development resource to go into developing more granular controls.  You can already achieve all that with the MDG path\URL functionality.  You can even hide things using excludes in the file system ACLs.

For that matter you can already achieve much the same outcome as a [wizard] model by importing UML patterns directly into the resource view.

Bugs and Issues / Re: HasTag anomalies
« on: May 12, 2016, 08:04:50 am »
There is actually, a practical result of my (theoretical) argument...  You are tackling the practical problem of how do we indicate an optional tagged value when all you can define are mandatory ones?  As you saw in my argument, an mandatory attribute allowing an empty or null value is, by definition, an optional attribute.

No it isn't.  An empty value conveys meaning in exactly same way as a non-empty value.  At a very crude level it says the information does not exist or is not known.  That information helps us evaluate the completeness of what we are modeling.

The descriptor existing but not the value only says that tagged values were poorly implemented.

There's a registry key called MDGTechnology PathList.  If you work in a managed environment an Active Directory GPP can be configured to set this to a central location for every EA user.
Quite often the people that develop the MDG's are not the same ones who control the technical stuff like AD and registry distribution.
The strings you have to pull, and the hoops you have to jump through to get a change like that distributed often isn't worth it.

That is why I like the model distribution. The model is something we control ourselves, and we don't need anyone approval or help to get it done.

As for development and testing, we have  DEV, TEST and PROD databases to be able to develop and test the MDG, scripts, and other stuff on.


So let's get this right; you should only follow the best practice is it is a developer practice.  Perhaps if you treated operations people with a bit of respect and less hypocrisy you may find that there aren't any hoops to jump through.

If you thinking I'm sounding a little bit too scornful it's because I've actually lost count of the number of times I've stopped or minimized the damage from a developer doing something stupid which in a country with laxer employment laws would have got them fired.  Not to mention the number of times I've debugged issues caused by the arrogant attitude that doing it our own way is the best.

Not to mention that modern distribution and management environments are very powerful tools which most organisations have invested in to perform standardized distributions and reduce the complexity and cost of environments.

Bugs and Issues / Re: HasTag anomalies
« on: May 11, 2016, 01:49:52 pm »
However, in the case of the Tagged Value setting a value to «Empty» string should cause the Tag to be purged (as with setting the value to «Null».
I strongly disagree. Even if your methodology doesn't allow tagged values with an empty value that is not going to be the case everywhere.

At a conceptual level, (and the entire basis of this thread) there is a difference between an empty value (eg string or set), missing value (null) or a missing container.

The analogy is the Axiom of the empty set.

Null has been described as the worst mistake in computer science, and the arguments for that position all seem to be true.

I'd be interesting is seeing those arguments. I'd say the concept of a null value is essential to computer science.

The article that first brought it to my attention is here, but if you google there's plenty of discussion of it.

Bugs and Issues / Re: Stereotype in MDG
« on: May 11, 2016, 11:34:12 am »
Would that be ?
No, Not exactly.  Haven't read the paper thoroughly, but a quick overview suggests we're on similar lines.

The framework they try and crowbar into Archimate is interesting and worth reading properly.  The Archimate implementation is in a few words a bit ridiculous. 

Pages: 1 ... 41 42 [43] 44 45 ... 71