Think Again About Promoting Your Language

Are you one to promote your programming language of choice? I know I am. This entry may in fact force anyone who promotes a given language and is not thoroughly in touch with the technical realities to reconsider what they are promoting. Lots of interesting data found here and and a very worth-while read.

Stateful Python Lists

The Python programming language defines list objects as one of the primitive language types. Lists, are similar to arrays in more traditional programming languages. Of course, Python lists are mutable types, as are arrays. The main difference between Python lists and traditional arrays are similar in most other comparisons of Python to other languages; Python lists are more flexible and elegant. However, Python lists are not magic. One situation where Python lists have the potential to easily fall apart is when used in a multi-threaded environment. This fact isn't exclusive to lists, the same risk involved with passing data across threads applies to all types. The good news is that this can be easily remedied with lists. Python list instances support the notion of "pushing" and "pulling" data. This is a useful thought construct because this transfers directly to the design. Any given list instance can be "pushing" state when adding data to the list or a "pulling" state when retrieving data from the list.

The Set class in the boduch Python library is essentially a Python list that publishes events. These events that are published by Set instances have the potential to be handled in a multi-threaded environment. If Set instances are being both "pushed" to and "pulled" from in a multi-threaded environment, this could be very dangerous. Data that is expected to exist in the set instance when "pulled" may not have arrived yet. In this scenario, it would be useful to know what state the Set instance is in. By combining both the Set and StateMachine classes as demonstrated below, we end up with a "stateful" Python list. The implementation of the StatefulSet shown here isn't fully thread safe. This is because it is incomplete. However, the code used in the main program is thread safe.

#example; Creating a multi-threaded Python list with a boduch Set.

#Necessary imports.
from boduch.event import threaded, subscribe, EventSetPush
from boduch.handle import Handle, HandleSetPush
from boduch.data import Set
from boduch.state import StateMachine
from boduch.type import is_type
from boduch import PRIORITY_MINOR, PRIORITY_CRITICAL

#A handle for Set.push() method invocations.
class HandlePreStatefulSetPush(Handle):
   #This gets a higher than critical priority since it is
   #intended to run before the core behavior.
   priority=PRIORITY_CRITICAL+1
   def __init__(self, *args, **kw):
       Handle.__init__(self, *args, **kw)
      
   def run(self):
       #Check if we are handling a StatefulSet event.  If
       #so, set goes into a pushing state.
       set_obj=self.get_event_data("set")
       if is_type(set_obj, "StatefulSet"):
           set_obj.change_state("PUSHING")

#A handle for Set.push() method invocations.
class HandlePostStatefulSetPush(Handle):
   #This handle gets a minor priority since it is 
   #intended to run after all the pushing is complete.
   priority=PRIORITY_MINOR
   def __init__(self, *args, **kw):
       Handle.__init__(self, *args, **kw)
      
   def run(self):
       #Check if we are handling a StatefulSet event.  If
       #so, set goes into a ready state.
       set_obj=self.get_event_data("set")
       if is_type(set_obj, "StatefulSet"):
           set_obj.change_state("READY")

#A stateful version of the Set class.
class StatefulSet(StateMachine, Set):
   def __init__(self, *args, **kw):
       #Initialize the base classes and populate the 
       #potential set states.
       StateMachine.__init__(self, *args, **kw)
       Set.__init__(self, *args, **kw)
       self.add_state("READY")
       self.add_state("PUSHING")
      
   def _push(self, data):
       #Change to a pushing state before actually pushing data.
       self.change_state("PUSHING")
       self.push(data)
      
   def _get(self, index):
       #Don't attempt to return anything while in a pushing state.
       while self=="PUSHING":
           print "Hold on, still pushing data."
           pass
       return self[index]
  
#Subscribe the custom stateful handles.
subscribe(EventSetPush, HandlePreStatefulSetPush)
subscribe(EventSetPush, HandlePostStatefulSetPush)

#Main program.
if __name__=="__main__":
   #Enable threaded event mode.
   threaded(True)
   #Instantiate a stateful set.
   set_obj=StatefulSet()
   #Populate the set while retrieving data in a thread-safe manor.
   for i in range(0,10):
       set_obj._push("SET DATA"+str(i))
       print set_obj._get(i)
  

Persisting Python Objects With pod.

Some Python applications are so lightweight, it is a challenge to justify incorporating a big RDBMS into the ORM logic. Popular Python ORM packages such as SQLObject and SQLAlchemy, support many major relational database management systems. These RDBMS packages are hardly suitable for more modest Python packages. The pod Python package offers a nice alternative to using the more popular Python ORM technologies. At the core of the pod storage engine is SQLite. Although the other popular ORM technologies support SQLite, you also get support for the larger RDBMS packages even if you don't need them. The pod codebase is thus much smaller than any equivalent. Similar ORM concepts apply when using pod to store Python instances. The following is an example of the pod Python library in use.

#Example; Using the pod Python Object Database.

#Import the library.
import pod

#Initialize the database connection.
db=pod.Db(file='myblog.sqlite3', very_chatty=False)

#The blog schema.  Extends the core pod.Object class.
class Blog(pod.Object):
   #Schema fields.
   name=pod.column.String(index=False)
  
   #Constructor.
   def __init__(self, **kw):
       pod.Object.__init__(self, **kw)
      
   #Called before any instances of this class are deleted
   #from the database.
   def pre_delete(self):
       #Ensure that all blog entries associated with this
       #blog are also deleted from the database.
       print "Destroying blog entries."
       for entry in BlogEntry.owner==self:
           entry.delete()

#The blog entry schema.  Extends the core pod.Object class.
class BlogEntry(pod.Object):
   #Schema fields.
   owner=pod.column.Object(index=True)
   title=pod.column.String(index=False)
   body=pod.column.String(index=False)
  
   #Constructor.
   def __init__(self, **kw):
       pod.Object.__init__(self, **kw)

#Instantiate the main blog instance.
def make_main_blog():
   print "Creating main blog."
   blog=Blog(name="main")
   db.commit()  
   return blog

#Instantiate two blog entry instances.
def make_entries():
   print "Creating blog entries."
   blog_obj=get_main_blog()
   BlogEntry(owner=blog_obj, title="Title1", body="Body1")
   BlogEntry(owner=blog_obj, title="Title2", body="Body2")
   db.commit()
  
#Retrieve the main blog instance, creating it if not found.
def get_main_blog():
   for blog in Blog.name=="main":
       return blog
   return make_main_blog()

#Retrieve the blog entries associated with the main blog.
def get_entries():
   entries=[]
   for entry in BlogEntry.owner==get_main_blog():
       entries.append(entry)
   return entries

#Delete the main blog from the database.
def cleanup():
   print "Destroying main blog."
   blog_obj=get_main_blog()
   blog_obj.delete()
   db.commit()

#Main program.
if __name__=="__main__":
   #Build the main blog instance.
   blog_obj=get_main_blog()
   #Build the blog entry instances.
   make_entries()
   #Retrieve and display the blog entries.
   for entry in get_entries():
       print "Entry Title:",entry.title
   #Destroy the blog.
   cleanup()

SQLAlchemy Bind and Result Processors

With any given object-relational mapper technology, the basic use case is the ability to map abstract data types to tables and instances of these types to rows in these tables. There is also a need to may primitive programming language types to primitive database column types. This is be no means easily achieved. Especially if the object-relational mapper in question supports multiple databases. Any popular object-relational mapper will support more than a single database. If it were the case that only a single database were supported by an ORM, there really wouldn't be a need for the ORM to begin with. In fact, if only a single database would need to be supported, it might be beneficial to not use an ORM because of the overhead that would be removed. This is rarely the case. Having said that, developers can generally assume that support for multiple database technologies is a given. Going back to the problem of dealing with primitive type mapping, how would an ORM accomplish this? One approach might be to implement the specific column types for each supported database. This would mean much duplicated functionality and would not be good object oriented practice. SQLAlchemy takes a different approach to handling the vary disparate column types between different database technologies.

SQLAlchemy defines two abstract type classes; AbstractType and TypeEngine. These two classes not only provide the base type interfaces used in SQLAlchemy, but also provide the default implementations for these methods. When mapping a primitive programming language type to a primitive database column type, there are two directions these types can be mapped. When supplying binding parameters to SQL queries that are initially primitive programming language types, and when retrieving query results from an executed query. In the latter case, the type mapping goes from the primitive database column type to the primitive programming language type.

The AbstractType class defines two methods to accomplish this; bind_processor() and result_processor(). Both methods accept a database dialect parameter so they know which database technology they are dealing with and the idea is to return a callable that performs the necessary transformations before using the data in a query or result set. In other words, bind_processor() returns a function to make the bind parameters used in a query actually usable. The result_processor() method uses the inverse concept. The SQLAlchemy String type is a good example of why these methods are useful. With strings, there are many questions of encoding before they can be used in a database.

One implementation note on the SQLAlchemy implementation of the AbstractType and TypeEngine classes. As illustrated below, the TypeEngine class directly inherits from AbstractType. TypeEngine unnecessarily overrides the bind_processor() and result_processor() methods. Both the signature and implementation of the two methods are the same in both classes. All that changes is the API documentation.

The SQLObject attribute collection functionality

One of the many available Python database object-relational mappers, SQLObject has some interesting meta class functionality. There are many ways to declare a database table using an object-relational mapper such as SQLObject. However, since dealing with declarative meta data in the database, it would be a logical step to treat the Python declarations as meta data as well. A developer using SQLObject to declare a database table will define a class that extends the SQLObject class. Then, the fields of the database table will correspond to the class attributes of the newly derived SQLObject class. These can't just be any primitive Python type attributes. They have to be of a specific SQLObject type. When dealing with meta attributes such as these, much examination of these classes is required. SQLObject has functionality which will collect collect meta attributes from classes.

In the context of SQLObject, the rationale behind such a requirement as class attribute collection is simple. The SQLObject base classes are not always going to know which parameters are used with the class. When instantiating SQLObject instances, the keyword parameters correlate to the fields declared for that instances' database table. In several scenarios, SQLObject needs to inspect a given class and return a list of attributes that were passed to the constructor. This list of parameters at this point are unknown to the class, although, the SQLObject attribute collection functionality assumes that this each attribute in this list is a class attribute of the class being inspected. Since much of the behavior invoked on SQLObject instances is transformed, and called by meta classes, the attributes may not necessarily be needed by the instance. The attribute collection functionality in SQLObject has an opportunity to remove these attributes from the instance and perform any other transformations it sees fit. It also accepts parameters to help it determine what exactly it is modifying.

The _collectAttributes() function is where this functionality is implemented. The parameters that can be passed to this function are as follows.

• cls - This is the actual class that is being inspected. It is assumed that all attributes being collected are a part of this class.
• new_attrs - This parameter is the dictionary of keyword parameters that are passed to the constructor of SQLObject instances. The values in this dictionary are SQLObject column types.
• look_for_class - The column type to look for. Only attributes of this type will be returned.
• delete - If true, all attributes will be deleted from the class.
• set_name - The actual attribute name will change to the key of the dictionary item corresponding to the attribute.
• sort - If true, a sorted list will be returned. The sorting is based on field creation order.

Illustrated below is an over-simplified conceptualization of how the _collectAttributes() function is executed.

Two Ways to Visualize Method Invocations

Analogy making lies at the heart of object-oriented software development. Developers make analogies to objects in the domain of interest to yield software objects. It is this concept of classes and instances of these classes that make object orientation such a powerful paradigm. When designing object-oriented software, it is sometimes helpful to visualize more than one abstraction for any given solution. As any developer knows, there are several ways to implement a given solution. The act of visualizing different approaches to these abstractions will often yield something in between. The same idea can be applied to understanding and designing the behavioral aspects of software objects. Designing of the behavior of software objects equates to building methods for those objects and how these methods are invoked. There is more than one way to visualize these method invocations.

Method invocations can be visualized as the sending of a message. In this abstraction, the instance that makes the invocation can be thought of as the sender. The instance that implements the method can be though of as the receiver. The method name and method parameters can collectively be thought of as the message. This approach is illustrated below.



An alternative way to visualize method invocations is as the publishing of an event. In the event publishing abstraction, the instance that implements the method can be thought of as the subscriber. The instance that invokes the method can be thought of as the publisher. The method name and the method parameters can collectively be thought of as the event. This approach, not all that different from the first, is illustrated below.



Which approach is the right one? Either. Since this is simply an abstraction visualization strategy, the right approach is the one that yields the better code, and thus, the better software. However, some developers may find the message method invocation visualization approach to be more useful when designing single, one-time method invocations. The event method invocation visualization might prove more useful when designing a polymorphic method invocation over a set of instances.

Restish Resources In Python.

RESTful resource design is not only a common theme in the Python web application framework world, but in countless other languages and frameworks. However, Python has the advantage of rapid development. Not just for the developers who use the frameworks in question, but also the developers creating these frameworks. The lessons learned from previous previous framework implementations have a very rapid turnaround. The restish Python web application framework is an example of just this. The package started out as the Pylons web application framework. However, the developers of restish soon realized that Pylons had shortcomings for what they were trying tho achieve. They then started to remove the problematic components from Pylons and what they eventually ended up with was a web application framework that was stripped down significantly. Just like Pylons, the restish package relies on the paster utility to create restish project and to execute restish projects. As the name of the project indicates, the framework is best suited for designing RESTful resources.

With restish, there is more than one way to define a resource, as is commonly the case with any software component. The best design is to represent a resource by building a class for that resource. Luckily, this is a no-brainer with restish. As a developer, all that needs to be built for a resource is a class that extends resource.Resource. The methods defined by this class are then responsible for returning the appropriate content. These resource methods are then decorated to indicate which HTTP method they correspond with. This is incredibly powerful and insightful; methods corresponding to methods. That is not all the decorated resource methods are capable of, however, I won't dig any further here. Resources can also be nested. The parent controller simply returns an instance of the child controller.

The abstractions provided by the restish package are very valuable to developers who want to design RESTful resources. This is a common design requirement that is elegantly implemented here. The sheer simplicity involved puts a smile on my face.

How Trac Determines The Wiki Processor

Within Trac is a powerful wiki syntax engine that offers a wide array of tools to the author who creates wiki pages. Richly formatted Trac wiki pages can be created in several ways. Just using the default wiki syntax to format plain text is often enough to get started. However, Trac offers much more. There are two other key components to the Trac wiki syntax; processors and macros. Macros invoke specific Python functionality, possibly with supplied parameters, to inject dynamic page content. Processors on the other hand, wrap around a specific chunk of wiki text and manipulate it in controlled ways. For instance, a plain processor would wrap some wiki text in three curly brackets. Doing this would simply transform the wrapped text to pre-formatted output. Wiki page authors can also invoke more exotic processors, such as html or syntax highlighting processors. To use a specific processor, the first line in the curly brackets must specify the processor name. The name of the processor must also be preceded by #!. So, for example, an html processor definition in Trac might look like {{{#!html hello world}}}. So, how does Trac know about these specific types of processors? Under the hood, The WikiProcessor class takes on this responsibility. The key task of this class is to load the required processor rendering functionality. Illustrated below is an elided view of the WikiProcessor class, showing only key attributes.




The logic executed by the WikiProcessor class to determine which processor is to be used in the rendering process takes place in the constructor, which accepts a processor name parameter. First, the constructor will check if the specified processor name is part of the builtin processor set. The builtin processor set in actually hard-coded in the constructor. If the specified processor name is found in this set, the processor attribute of the WikiProcessor instance becomes the method associated with the builtin processor name. If the specified processor isn't a builtin processor, the processor could potentially be a macro. All the macro providers, which contain actual macros, are retrieved from the WikiSystem class and iterated over. Each macro provider is then checked, to see if the specified processor is a macro. If it turns out that the specified processor is a macro, the macro_provider attribute of the WikiProcessor instance becomes the macro provider containing the matching macro. Also, the processor attribute of the WikiProcessor instance will become a method for rendering the macro. Finally, if the specified processor isn't a builtin and isn't a macro, the default rendering functionality is used.

This is an extremely flexible way to determine where the extensible wiki processing functionality resides. The one issue in the WikiProcessor constructor is that there are three if statements, all in the same context with no else. This means that all three if statements are executed no matter what. Not only is this inefficient, but the else adds a grouping aspect to the code. However, this is trivially easy to remedy.

Creating State Machines in Python

In the UML, state machines help modelers understand the various states the system in question goes through. When the system is in one state, the available behavior differs from when the system is in another state. Visualizing these states by drawing them as UML elements is an extremely powerful tool. State machines are not only powerful for examining the potential states of a given system, but also in helping to understand the transitions that could potentially take place between these states. In object-orientated systems, the concept of objects being in one state or another is often implemented in code, even if implicitly. Given that this is object-oriented code we are working with, and the whole idea behind object orientation is to assist with creating realistic abstractions, why not use the concept of state machines directly in code? The 0.1.6 version of the boduch Python library tries to realize this possibility. Although this is the first iteration of this new feature, with lots of work left to do, it seems promising. Below is an example of the new StateMachine class in use.

#Example; Using boduch state machines.

from boduch.state import StateMachine
from boduch.predicate import Equal

#Define two predicate functions used to return
#the predicate variables.
def get_o1():
   return o1

def get_o2():
   return o2

#The two predicate variables.  Notice they 
#aren't equal.
o1=1
o2=2

#Construct a state machine instance.
state_obj=StateMachine()

#Construct a predicate instance using the 
#two previously defined predicate functions.
predicate_obj=Equal(get_o1, get_o2)

#Populate the state machine with two states.
state_obj.add_state("RUNNING")
state_obj.add_state("STOPPED")

#Add a state transition to the machine using
#the previously defined predicate.  Once true,
#the machine will be in the target state.
state_obj.add_transition("STOPPED", predicate_obj)

if __name__=="__main__":
   #Change the machine to a RUNNING state.
   state_obj.change_state("RUNNING")
   print state_obj.current_state
  
   #Change the value of the predicate variable.
   o2=1
   print "o2 now equals o1"
  
   #Check for any state changes.
   state_obj.transition()
   print state_obj.current_state
  

Be brief overview of the above code follows below.

• Import the classes required. There are StateMachine and Equal.
• Define the predicate functions. These functions are used by the predicate associated with the state machine. They are invoked each time the predicate is evaluated.
• Define the predicate variables. These variables are global and are returned by the predicate functions. Any changes to these variables are reflected by invoking the predicate functions.
• Create a new StateMachine instance. This is the main state machine involved in the example.
• Create a new Equal predicate instance and use the predicate functions as operands.
• Populate the state machine instance with some states. A state can be any Python object.
• Add a new transition to the state machine using the previously defined Equal instance. When this predicate instance evaluates to true, the target state, in this case, "STOPPED", will become the active state.
• Set the initial state to "RUNNING".
• Change the value of one of the predicate variables. The predicate can now be considered equal.
• Test the state machine for any state changes. Here, there are changes because the transition that was previously added to the state machine will evaluate to true, causing the target of the transition to become the active state.
• The state machine is now in a "STOPPED" state.

The Idea of Running Wine on Ubuntu For Windows Compatibility

Wine is software that acts as a compatibility layer to allow applications designed to run on the Windows platform to run on Linux platforms. An interesting entry has brought up several questions about the need to run Windows applications on Linux desktops. It is indeed a very involved question which has the potential to go unanswered indefinitely. Chances are, if you are running a Linux desktop in the first place, you didn't have a need for Windows applications. But what about when you do need them? It would be nice if all open source alternative did it all, but that simply isn't the reality of today.

Mark Shuttleworth, founder of the Ubuntu Linux distribution was asked how important the role of Wine and Windows + Linux compatibility in general, will be in the success of Ubuntu. The reply was straightforward, it is, and it isn't.

Wine is hugely innovative software that has no doubt contributed to the success of not only Ubuntu, but open source software in general. Not by allowing users to simply just run Windows applications on Ubuntu. If that were the reason, there would obviously be no point in running an open source operating system. Wine is a gateway application. By allowing people to use Windows applications on open source systems, there is no avoiding the exposure to lots of interesting stops along the way. But what about the native Linux user? Does Wine have any useful purpose for these users? Maybe not all of them but there will no doubt come a time where the open source alternative simply doesn't exist. In times such as these, Wine negates the need to install Windows natively or, even virtually for that matter.

When considering questions such as these, there is always lots of ego involved from both the open and proprietary sides of the table. Both sides have a cause and once joined, people tend to stick to them. On the open source side, the direction of any given project isn't dictated so much as collaborated. There really is no rank among contributing project members aside from what they are able to produce. This is what really counts, and this was made very apparent by Shuttleworth's response. I for one applaud it.

How UML constrains subsetted properties

Classes are by far the most commonly encountered UML modeling element. As most users of the language have heard hundreds of times, classes do not exist in isolation for any given object system. Classes are often related to other classes by an association element. At each end of an association is a Property element. These property elements are generally not modeled directly but exist in the UML meta-model. In the context of a class associated with another class, these Property elements correlate to attributes of the two classes. These properties can be subsets of other properties and classes. In the UML model, this would be specified by applying the subsets tagged-value along with the context for the value. This values both modelers and software tools a better clue about how the design is organized. The UML specifies constraints that must be satisfied for a Property subset to be considered valid.

The following is an illustration of what takes place when the constraints of a subsetted property are validated.



First, the subsetting property and the subsetting context are both checked for emptiness. If so, the subset is not valid. Next, the validation will iterate through each subsetting context element and each subsetting property element. It is in this iteration that the validation process will ensure that the elements of both sets conform with one another.

Django Templates and NodeLists

Whether dealing with a complex web application or a simple web site with relatively few pages, using templates is generally a good idea. With complex page structures, this is unavoidable. The alternative would be to implement the page structure manually. Even with simplistic web pages, there is often a dynamic element that is undesirable to manually edit. If the web application is built with a Python web application, developers have several template engines to choose from. TuboGears, for instance, offers support for several third-party template engines. Django, on the other hand, offers their own template rendering system. The Django template engine provides many of the same features as do other Python template engines. The syntax used in Django templates is simplistic and easy to use. Inside the template engine are two closely related classes that represent key template concepts and are illustrated below. These classes are Template and NodeList.



The Template class represents a template in its' entirety. During the construction of Template instances, the template is compiled. Since this process takes place in the Template constructor, the template string is a required constructor parameter. Since any given Template instance is compiled, it may be rendered at any time. The template passed to the constructor is only compiled once since the compilation takes place in the constructor. Template instances support iteration. Each iteration through a particular Template instance yields a node from the NodeList instance that resulted from compiling the template. Invoking Template.render() will in turn invoke NodeList.render(), passing along the specified context.

The NodeList represents a collection of nodes that result from compiling a template string. The majority of these nodes are HTML elements, template variables, or some Python language construct such as an if statement. NodeList instances are also instances of the Python list primitive. This means that each node contained within the list behaves just like a Python list element. The NodeList.render() method will cumulatively invoke render() on each node contained within the list. The end result is the rendered template. This rendering behavior provided by the NodeList.render() method can be considered polymorphic. The method iteratively invokes render() on anonymous instances. All it cares about is the render() interface.

How Gaphor Checks Association Ends.

With the Unified Modeling Language, comes a well defined meta model. It is this meta model that defines the semantics of the modeling elements available within the UML. An important feature of this meta model is consistency enforcement. The semantic rules defined in the UML meta model not only supply the UML modeling element but also govern how those elements may be used in relation to one another. If these rules, specified by the meta model could be verified for any given UML model, it could provide a means of ensuring a consistent model. As an example UML element that has the potential to be validated for consistency, consider the two ends of an association. One end could be a subset of the opposite end. There are a couple ways that this arrangement could go wrong. There could be missing names or there could multiplicity inconsistencies. The Gaphor UML modeling tool provides a checkmetamodel plugin that is capable of validating the association ends, as well as other potential meta model issues. This plugin can be viewed by selecting "Tools", "Check UML model". Illustrated below is the dialog that will be displayed. Only errors will be displayed here so if there is no content, the current Gaphor UML model is consistent with the Gaphor UML meta model.



When the checkmetamodel plugin validates the UML model, there are three functions involved. These functions are check_associations(), check_association_ends(), and check_association_end_subsets(). The check_association_end_subsets() function is important when validating association ends. It is the only validation that actually takes place on associations. The check_associations() and check_association_ends() functions exist for infrastructure purposes. If new functionality were to be added to Gaphor association or Gaphor association end checking, it would be placed in one of these functions. As the same suggests, the check_association_end_subsets() function will make sure that any association ends that are subsets of the opposite association end are consistent with one another. There are two basic tests to make this happen. First, the plugin will make sure that a given association end that is a subset of the opposite association end, contains names that actually exist in the opposite set. There can't be a subset property which contains elements that do not exist in the referenced set. Next, all multiplicity upper bounds in the subset need to be consistent with the upper bounds of the opposite set. This will ensure a multiplicity consistency amongst association end subsets.

With Gaphor, these meta model consistency checks are especially important because the meta model is loaded into Gaphor as any other UML model would be. If the core Gaphor UML meta model fails, there isn't much hope for any models created by users. The checkmetamodel plugin also offers potential for adding additional checking functionality.