How to secure info from unauthorized change?

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   Hi, 

My client needs a library of fixed reusable elements. After reading this forum I understand there are 2 ways to reuse an element from a library:

1. As it is, via reference to the element itself

2. Make a type from the element and use its instances in new models

We have not decided yet which way to follow (any practical advice, Steven?), but in any case we would like to give end users access to the original element. This is not only to have access to complete external specs of the element, but also to internal details, rationals, detailed documentation, etc..

Obviously, the client does not want end-users change the library directly (instead they should follow a separate change process). After reading MetaEdit+ User's Guide I am left with a feeling that the tool aims to allow multi-users as much change as possible, only taking care of concurrency conflicts..

What is the best way to secure such a library from unauthorized change in MetaEdit+?

Thanks!

Edited by alev - 13.Oct.2010 at 15:19

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
alev Members Profile Send Private Message Find Members Posts Add to Buddy List Contributor Joined: 08.Oct.2010 Location: Arnhem, NL Points: 19	Post Options Post Reply Quote alev Report Post Thanks(0) Quote Reply Topic: How to secure info from unauthorized change? Posted: 13.Oct.2010 at 15:11
	Hi, My client needs a library of fixed reusable elements. After reading this forum I understand there are 2 ways to reuse an element from a library: 1. As it is, via reference to the element itself 2. Make a type from the element and use its instances in new models We have not decided yet which way to follow (any practical advice, Steven?), but in any case we would like to give end users access to the original element. This is not only to have access to complete external specs of the element, but also to internal details, rationals, detailed documentation, etc.. Obviously, the client does not want end-users change the library directly (instead they should follow a separate change process). After reading MetaEdit+ User's Guide I am left with a feeling that the tool aims to allow multi-users as much change as possible, only taking care of concurrency conflicts.. What is the best way to secure such a library from unauthorized change in MetaEdit+? Thanks! Edited by alev - 13.Oct.2010 at 15:19

stevek Members Profile Send Private Message Find Members Posts Add to Buddy List MetaCase Joined: 11.Mar.2008 Points: 643	Post Options Post Reply Quote stevek Report Post Thanks(0) Quote Reply Posted: 13.Oct.2010 at 15:20
	It depends how much the use of a element: - constrains the rest of the model (e.g. what can be connected to it is different for each element) - requires per-use configuration information (and the set of information required is different per element) - should prevent changes to the definition of that element The more those are true, the more likely it is that you should promote the reusable elements into types.

alev Members Profile Send Private Message Find Members Posts Add to Buddy List Contributor Joined: 08.Oct.2010 Location: Arnhem, NL Points: 19	Post Options Post Reply Quote alev Report Post Thanks(0) Quote Reply Posted: 13.Oct.2010 at 15:26
	Steven, you are quick! It seems that you are answering as I am typing Thank you for the pointers on choosing the correct reuse implementation. But how about the change?

stevek Members Profile Send Private Message Find Members Posts Add to Buddy List MetaCase Joined: 11.Mar.2008 Points: 643	Post Options Post Reply Quote stevek Report Post Thanks(0) Quote Reply Posted: 13.Oct.2010 at 15:37
	You answered it already: "client does not want end-users change the library directly (instead they should follow a separate change process)." In other words, the important thing is the defined process, not the technical implementation of security. If people don't believe in the process, or find it tiresome, they'll always find a way around any technical system (e.g. just ask a friend for his password). As I said, the type-based system is better if you want a technical implementation of security right in the repository: metamodeling rights are per user, so giving certain users metamodeling rights would stop others from changing the element definitions. It's also possible to have the component definitions in a separate repository under version control, whether they are models or metamodels; users could e.g. view them there, and maybe even change them, but not check in the changed version. I wouldn't use this as the main deciding factor, though. At this stage, you'd be better off concentrating on the modeling languages, raising the level of abstraction, and what works well for the users. That's where the major gains of DSM are to be found. If major gains were to be found by locking or traceability, we'd have seen them without DSM in plenty of cases that have tried to apply them.

alev Members Profile Send Private Message Find Members Posts Add to Buddy List Contributor Joined: 08.Oct.2010 Location: Arnhem, NL Points: 19	Post Options Post Reply Quote alev Report Post Thanks(0) Quote Reply Posted: 13.Oct.2010 at 16:44
	Steven, these are not a deciding factors for the client (the part of the organization I work for, has already committed to DSM and the MetaEdit+), these are simply expected practicalities. But I think we are wandering away from the main point: the client wants to provide end users with read access to library of fixed elements (be it for modeling reuse or pure documentation value this library has). I am sure we can find an external solution to this and introduce additional processes, but I was wondering perhaps there is a simple way to make contents of a project read only, directly in MetaEdit? Steven, I appreciate your prompt replies - they are very helpful. Thanks!

stevek Members Profile Send Private Message Find Members Posts Add to Buddy List MetaCase Joined: 11.Mar.2008 Points: 643	Post Options Post Reply Quote stevek Report Post Thanks(0) Quote Reply Posted: 13.Oct.2010 at 16:52
	Thanks for the extra background! It's often difficult to answer questions on "best ways" in DSM, because almost by definition the answer is "it depends". People obviously prefer simpler, more direct answers :-). So I'll answer your question somewhat inaccurately but very succinctly: "no". But if it matters to you, the answer can change in the future to be "yes" with no major difficulty.

alev Members Profile Send Private Message Find Members Posts Add to Buddy List Contributor Joined: 08.Oct.2010 Location: Arnhem, NL Points: 19	Post Options Post Reply Quote alev Report Post Thanks(0) Quote Reply Posted: 13.Oct.2010 at 18:14
	"simpler, more direct" is very much in the DSM spirit :-) From you answers I derive that MetaEdit+ distinguishes two rights: metamodeling and modeling. Users that have modeling rights have complete access to each other's modeling information. Users with metamodeling rights have complete access to all metamodels, code generators and models. Is it correct?

stevek Members Profile Send Private Message Find Members Posts Add to Buddy List MetaCase Joined: 11.Mar.2008 Points: 643	Post Options Post Reply Quote stevek Report Post Thanks(0) Quote Reply Posted: 14.Oct.2010 at 11:41
	Yes, that's pretty much it. The repository system administrator assigns a user name and password to a person to give them modeling rights. He can assign metamodeling rights separately per user (Repository \| Options \| Repository tab).

alev Members Profile Send Private Message Find Members Posts Add to Buddy List Contributor Joined: 08.Oct.2010 Location: Arnhem, NL Points: 19	Post Options Post Reply Quote alev Report Post Thanks(0) Quote Reply Posted: 14.Oct.2010 at 11:54
	Thanks Steven! The answer is very helpful - now I have all info to implement the libraries.