Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I stumbled across the Extension Manager and see three unchecked extensions. What are they for? Any use in loading them for working with NORMA? What else beside loading them would I have to do you use them? Thanks. BRN..
The NORMA designer is a highly extensible system based on the Microsoft DSLTools framework, enhanced with a number of our own extension points to allow multiple models, multiple diagrams, etc. In fact, the main distinction between the two default models (the core model and the shape model) lie in the fact that you can't turn off these two main extensions.
We do not want to 'pollute' our core conceptual model with non-core elements. For example, it is very useful to store information such as who was responsible for entering a fact, who is currently responsible for it, when it was last/first edited, etc. However, these are not core conceptual concepts, so do not belong in the core model. A large chunk of this type of property will be handled by an extension we call a 'Custom Properties' extension, which allows configurable properties to be added to any of the main object types.
Extensions have access to the full object model and can add their own rules (used to make model changes in response to other changes) and listen to other changes in the model. As far as the core architecture is concerned a registered extension is indistiguishable from the core and shape domain models. We are also working on dynamic grouping and categorization in the model browser, which will also be fully customizable from extensions (this is a ways off).
We are working on several extensions. Some our closer to prime-time than others. Custom properties is pretty close. Another one called the 'ORM Intermediate Abstraction Language' extension is doing live what we are currently doing in the OIAL xml format (a prerequisite for most of our generation output). This will allow us to dynamically and incrementally project changes in the core model onto changes in the relational model (this is done statically now, not dynamically). This is a very important step for the tool because many relational customizations can be attached to live OIAL objects. As an example, a single role can correspond to multiple column names. However, we don't actually know which column names a given role corresponds to until we generation the absorbed view of the model. Moving OIAL to a live object model instead of the result of a static transform will enable us to provide full and live integration of a number of additional relational and generation settings. One of the first things attached to the live OIAL model is a Relational View of the model (this is not yet live and regenerates (slowly) on most model changes).
The goal is that any generator will be able to modify its generated output using data from custom extension elements that integrate seamlessly into the NORMA tool. At some point we'll also be providing extension documentation. You will need VS2005 Pro and a current VSSDK to create extensions (base requirements for creating DSLTools models).
In any case, we're aggressively coding on some major extensions which will come into play in the next few months.
Kevin may want to add additional information on this topic, particularly on the Relational View. -Matt
Gonna take a little while to digest what you passed along! Thanks for the reply, Matt. There's an apparent subtext in what you said, and that is there's a great deal of cooking going on in great many pots - to paraphrase a line from John LeCarre's "A Spy who Came in From the Cold." I hope you and others will post more "heads up" notices on some of the recipies you are testing for NORAMA.
My immediate goal is to get each release working as well as I can to generate viable Relational Model compliant Database schemas. I know that this functionality is only a part of larger usefulness you envision for the product. Because the current state of the product produces unexpected results sometimes, it's a (I hope), useful exercise in learning (and sometimes re-learning), what I need to know and will need to know to get the most out of even that limited potential of the tool.
Later on, I hope to explore more of the ontological and other concepts for which NORMA appears to have promiss.
While some of these other areas are very interesting, I hope you'll concentrate on the core functionality as a tool to make it easier to generate RM compliant, application specific DB schemas. The larger and more complex the UofD, the tougher it is to get all the normalization done in a way that you can be confident, relects the distal stimulous you are trying to model. Having the right tool (and that's what we hope NORMA will become), is essential. BRN..