http://wp13117963.server-he.de/blog/2007/01/15/ocl-support-in-enterprise-architect/comment-page-1/#comment-2035
I am facing an issue mentioned in the above article. i.e. Enterprise Architect is not giving any error when I create a constraint on an attribute with wrong syntax.
The answer is simple: it fakes OCL. EA is doing no syntax check of OCL itself. In no way does it execute OCL and will not do any constraint checking. You can only mark a constraint as being OCL:
That's it. Just try to enter an inalid constraint and EA will swallow it with no warning.
Related
Some diagrams in our repository contain DiagramObjects, which are missing InstanceGUID (DUID) attribute (both in API and in t_diagramobjects table). And, of course, DUID is needed to manipulate some style features from the API.
It is possible to fix this easily by updating and saving anything in the diagram via GUI - the DUIDs are generated automatically; but I didn't find a method to invoke similar action from the API (in my case VbScript) to fix all the "broken" diagrams. Update() methods of DiagramObject or Diagram didn't help.
Have anybody met this situation? Thanks.
And maybe extension to this question: Is it possible, that the missing DUID situation is caused by wrong sequence of saving the changed diagram elements/features? What should be the correct sequence?
The DUID from t_diagramobject is not necessarily needed. EA will create them on purpose and they are just for their internal reference. I for myself had never issues deleting a DUID with a database update.
There's a DUID for t_diagram which is used in certain contexts, though.
I am trying to use NDepend in code review process. The one thing I want to solve is to check if newly created classes are valid from the point of CQL rules.
I have plenty of legacy code and there numerous fields/classes/methods that violates CQL rules. But I want to find only these rules which are violated by a particular class which was newly created by a developer and which I want to review.
Is there a way to find all CQL rules violated by a particular class, so I could fix them?
Yes, you can compare two analysis and select new classes with the CQL condition "WasAdded".
Select Classes Where WasAdded
Other attributes to compare two versions are
WasRemoved
CodeWasChanged
Check out CQL Documentation and this article from Patrick.
I know enums are currently only available in the June 2011 CTP and won't be in 4.2. What other factors would make someone choose one or the other?
Ladislav Mrnka has a great SO answer that breaks down the differences between DB First, Code First and Model First. I strongly suggest that you go read it and upvote it.
Besides that, I would only add the following points:
Even in the June 2011 CTP, Enum support is limited, so you might
want to see if any of those issues are showstoppers for you. Update: EF5+ supports Enums with EF Designer and Code First.
If you are implementing EF against an Oracle DB, and you
don't want to pay for a data provider, then you will be
without Code First, as Oracle's own provider (still in beta)
doesn't support it.
Edit: here is another comprehensive answer from Ladislav.
See Entity Framework Development Approaches in
http://www.asp.net/entity-framework/tutorials/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
Advantages : One common syntax ( LINQ / Yoda ) for all object queries whether it is database or not , Pretty fast if used as intended , easy to implement SoC , less coding required to accomplish complex tasks
Disadvantages : you have to think in a non traditional way of handling data , not available for every database
Disadvantage: If there is any schema change in database FE won’t work!!! You have to update the schema in solution as well!!!
Advantage: Its fast and straight forward using LINQ/FE objects For Add/Modify/Delete/Update.
Advantages:-Easy to map business objects (with drag & drop tables on environment).
-It keeps a good performance when you work with a small / middle domain model.
Disadvantages:-It's limited when you work with a huge domain model.
-Scalability.
I am defining the meta model of a domain specific modeling language by means of Ecore in EMF. I therefore generate an editor from the related genmodel I can use to create models conform to the meta-model.
I would like to specify some OCL constraint on the values that some elements of the meta-model can assume. It would be very nice if I could specify these constraint in the Ecore model and have the related checks automatically generated editor Java code.
Is there a standard way to do that?
First step is to decide how you want to add constraints to your ecore (meta-)model. There is two ways I am aware at the moment, you can do this:
1- having ocl expressions embedded in annotation elements of the ecore model.
2- having OCL expressions in the separate file beside ecore.
For getting more information on the first approach look at OCLInEcore , and for the second one look at OCLComplete . It seems that they are providing some API for checking OCL constraint for the given models (conformance check).
For your purpose, it seems that OCLInEcore is suitable. You can have your ocl embedded in ecore, and you can use the API provided by OCLInEcore to check if the given model satisfy ocl constraints.
Hope this helps.
You should have a look at the recent work of the OCL project in Eclipse with "OCL in Ecore" or you could try one of the other way to integrate OCL with Ecore specified in the OCL Juno documentation.
Do you mostly use this option (the default is checked) or do you uncheck it?
I found out that when I have both FK column and navigation property on my entities it results in problems with mapping tools - they might bind one or the other but almost never both.
If we were to follow the guidelines of conceptual models strictly I think those columns should never make it to properties, should they?
Hopefully many of you reply so we can get a better representation of what developers choose more often.
If we were to follow the guidelines of
conceptual models strictly I think
those columns should never make it to
properties, should they?
Right - that's what the EF team did in the first release with .NET 3.5 SP1 - and got a ton of very negative feedback on it.
Yes, "puristically" speaking - you shouldn't be using foreign key columns directly - you should use the proper way of dealing with the referenced entity instead. But in reality, in many cases - you don't want to have to deal with the whole referenced entity, really - just setting the foreign key column will do (e.g. when importing data or many other cases).
So while yes - I agree - it's a bit of a hack at times, I do see it as a big plus that you have the option to use the foreign key column in an entity - after all, at the database level, that's what you'll be dealing with, too.
So in my opinion, and all the recommendations I've heard from colleagues who also use EF in serious work and all the blogger and EF gurus out there (like Julie Lerman who wrote the book on EF) - turn on that option, and you get the best of both worlds!