5th August, 2010 - Posted by rafael.chaves - 7 Comments
The TextUML Toolkit version 1.6 has been released. It is the same RC1 build mentioned here a week ago. The listing on the Eclipse Marketplace has been updated, so in addition to the regular update site (http://abstratt.com/update/), if you are using Eclipse 3.6, you can get it even more conveniently using the brand new Eclipse Marketplace Client.
Take a look at the new notation features:
- preconditions on operations
operation withdraw(amount : Real);
precondition { amount > 0 and amount < self.balance }
begin
self.balance := self.balance - amount;
end;
reference employees : Employee[*]
/* calculated field */
derived attribute employeeCount : Integer := ():Integer { return self->employees.size() };
- initial values on properties
attribute available : Boolean := true;
You can also try these new features online on AlphaSimple. Sign up or start a guest session to create, validate and run your models on the spot, there is nothing to install!
Read More
26th July, 2010 - Posted by rafael.chaves - 4 Comments
TextUML Toolkit 1.6 RC1 is now available! You can install it using the Marketplace Client or by pointing Eclipse to the update site:
http://abstratt.com/update
If you find any problems installing this build, please let us know asap so it can be addressed before the final release.
New features
Much of the work in this release went into improving the model building infrastructure to be even more notation agnostic. That work is still ongoing and should be completed in 1.7. But there were plenty of user-facing feature additions as well:
- preconditions on operations (2986923 and 3002571)
- support for a default notation (so file extensions can be optional) (2995372)
- support for implicitly applying profiles/stereotypes (so models are less verbose) (2981580)
- support for derived properties (2928428)
- support for initial values in properties (2115439)
- advanced features (closures, constraints) are now implemented using profiles instead of metamodel extensions (2933692)
In other news
The reason it took so long for a new TextUML Toolkit release to come about was that I have been busy working on AlphaSimple, which went on public beta today. AlphaSimple is an online tool for domain-driven prototyping that currently uses TextUML as modeling notation. Thus, AlphaSimple is also the driving force behind most of the changes that happened in the 1.6 cycle, and you can try them right away by starting a guest session and studying the example projects.
Read More
8th February, 2010 - Posted by rafael.chaves - 19 Comments
UML has been getting a lot of criticism from all sides, even from the modeling community. Sure, it has its warts:
- it is a huge language, that wants to be all things to all kinds of people (business analysts, designers, developers, users)
- it has a specification that is lengthy, hard to navigate and often vague, incomplete or inconsistent
- it is modular, but its composition mechanism (package merging) is esoteric and not well understood by most
- it is extensible, but language extensions (profiles and stereotypes) are 2nd-class citizens
- it lacks a reference implementation
- its model interchange specification is so vague that often two valid implementations won’t work with each other
- its committees work behind closed doors, there is no opportunity for non-members to provide feedback on specifications while they are in progress (membership is paid)
- <add your own grudges here>
However, even though I see a lot of room for improvement, I still don’t think there is anything better out there. The more I become familiar with the UML specification, the more impressed I am about its completeness, and how issues I had never thought about before were dealt with by its designers. And it seems that the OMG recognizes some of the issues I raised above as shortcomings and is working towards addressing them. Unfortunately, some fundamental problems are likely to remain.
In my opinion (hey, this is my blog!), for a modeling language to beat UML:
- it must be general purpose, not tailored to a specific architecture or style of software
- it must not be tailored to an implementation language
- it must be based on or compatible with the object paradigm
- it must not be limited to one of the dominant aspects of software (state, structure, behavior)
- it must be focused on executability/code generation (and thus suitable for MDD) as opposed to documentation/communication
- it must be modular, and user extensions should be 1st class citizens
- its specification should follow an open process
- it must not be owned/controlled by a single company
- it must not require royalties for adoption/implementation
My suspicion is that the next modeling language that will beat the UML as we know today is the future major release of UML. Honestly, I would rather see a new modeling language built from scratch, focused on building systems, that didn’t carry all that requirement/communication/documentation-oriented crap^H^H^H^Hbaggage that UML has (yes, I am talking about you, use case, sequence, instance and collaboration diagrams!), and developed in a more open and agile process than the OMG can possibly do. But I am not hopeful. The current divide between general purpose and domain specific modeling communities is not helping either.
So, what is your opinion? Do you think there are any better alternatives that address the shortcomings of UML without imposing any significant caveats of their own? Have your say.
Read More
6th February, 2010 - Posted by rafael.chaves - 17 Comments
It seems that people that resist the idea of model-driven development (MDD) do so because they believe no tool can have the level of insight a programmer can. They are totally right about that last part. But that is far from being the point of MDD anyways. However, I think that unfortunate misconception is one of the main reasons MDD hasn’t caught on yet. Because of that, I thought it would be productive to explore this and other myths that give MDD a bad name.
Model-driven development myths
Model-driven development makes programmers redundant. MDD helps with the boring, repetitive work, leaving more time for programmers to focus on the intellectually challenging aspects. Programmers are still needed to model a solution, albeit using a more appropriate level of abstraction. And programmers are still needed to encode implementation strategies in the form of reusable code generation templates or model-driven runtime engines.
Model-driven development enables business analysts to develop software (a variation of the previous myth). The realm of business analysts is the problem space. They usually don’t have the skills required to devise a solution in software. Tools cannot bridge that gap. Unless the mapping between the problem space and solution space is really trivial (but then you wouldn’t want to do that kind of trivial job anyways, right?).
Model-driven development generates an initial version of the code that can be manually maintained from there on. That is not model-driven, it is model-started at most. Most of the benefits of MDD are missed unless models truly drive development.
Model-driven development involves round-trip engineering. In MDD, models are king, 3GL source code is object code, models are the source. The nice abstractions from the model-level map to several different implementation artifacts that capture some specific aspect of the original abstraction, combined with implementation-related aspects. That mapping is not without loss of information, so it is usually not reversible in a practical way, even less so if the codebase is manually maintained (and thus inherently inconsistent/ill-formed). More on this in this older post, pay attention to the comments as well.
Model-driven development is an all or nothing proposition. You use MDD where it is beneficial, combining with manually developed artifacts and components where appropriate. But avoid mixing manual written code with automatically generated code in the same artifact.
What is your opinion? Do you agree these are myths? Any other myths about MDD that give it a bad name that you have seen being thrown around?
Rafael
Read More
25th January, 2010 - Posted by rafael.chaves - No Comments
Last December I had the pleasure of being interviewed by Jordi Cabot, the maintainer of Modeling-Languages.com, a web site on all things model-driven. We talked mostly about the TextUML Toolkit project, but Jordi also asked about my opinions on more general subjects, such as modeling notations, textual modeling frameworks, DSLs, UML and trends in modeling.
Jordi has recently made a transcription of the interview available on his web site. Take a read, feel free to leave a comment, I am very keen on discussing on any of the topics covered.
Read More
17th January, 2010 - Posted by rafael.chaves - No Comments
The TextUML Toolkit has since release 1.2 had a metamodel extension package (inaptly named ‘meta’). This metamodel extension package defined new metaclasses not available in UML such as:
- closure – an activity that has another activity as context
- conversion action – an action that flows an input directly as output just changing the type
- literal double – a literal value for double precision numeric values
- signature – a classifier that contained parameters, the type of a closure
- meta value specification – a value specification for meta references
- collection literals – a value specification that aggregates other value specifications
Turns out extending the UML metamodel by definining new packages and metaclasses is a bad idea. Some reasons (yes, I am feeling ‘bullety’):
- it is non-standard
- other UML tools cannot read instances of your metaclasses, some won’t read your models at all if they have *any* unknown metaclasses
- there is little documentation on how to maintain these kinds of metamodel extensions
- since it is not the mainstream approach, we are bound to encounter more issues
Because of that, release 1.6 will rely exclusively on profiles and stereotypes for extending the UML metamodel.
What to expect
For conventional users of the Toolkit, this change might possibly go unnoticed, barring any potential bugs introduced in the process.
People using the built-in base package and the base_profile will be directly affected. The elements in these models are still provided, by they are now in the new mdd_extensions profile, or one of the new mdd_types, mdd_collections and mdd_console packages.
We apologize for any inconvenience these changes might bring, but we strongly believe they are required to make the TextUML Toolkit a better product. If you have any trouble moving to 1.6 (to be released later this month), make sure to hit the user forums or report issues.
Read More
2nd December, 2009 - Posted by rafael.chaves - No Comments
Release 1.5 of the TextUML Toolkit is now available from the update sites, for both Eclipse 3.5+ and 3.4. Update or install. We got a few new features in this release.
Content assist
There is now early support for content assist (contributed by Attila Bak), with initial support for stereotype applications.
Element aliasing
You can now enable aliasing by creating repository properties in the form:
mdd.aliases.<source-qualified-name>=<target-qualified-name>
For instance:
mdd.aliases.base\:\:Real=mypackage\:\:MyReal
New textual notation features
There is now textual notation support for decimal literals.
You might have noticed 1.4 was announced here less than a month ago. We decided to start pushing releases as often as we can, so you can expect a bunch of 1.x releases throughout 2010. If you want to see some feature in the TextUML Toolkit, ask away!
Read More
29th November, 2009 - Posted by rafael.chaves - 1 Comment
I have been trying to figure out whether the TextUML notation for action semantics can be dealt with properly by tools such as Xtext and EMFText (class models and state machines should be fine). For example, given this structural model fragment:
class Advertisement
attribute summary : String;
attribute description : String;
attribute keywords : Keyword[*];
attribute category : Category;
operation addKeyword(keywordName : String);
static operation findByCategoryName(catName : String) : Advertisement[*];
end;
association AdvertisementKeyword
role Advertisement.keywords;
role advertisement : Advertisement;
end;
class Keyword specializes Object
attribute name : String;
end;
class Category specializes Object
attribute name : String;
attribute description : String;
end;
association AdvertisementCategory
role Advertisement.category;
role ad : Advertisement[*];
end;
Notice the Advertisement class declares two operations. Their behaviour in TextUML could be written as:
operation Advertisement.addKeyword;
begin
var newKeyword : Keyword;
newKeyword := new Keyword;
newKeyword.name := keywordName;
link AdvertisementKeyword(keywords := newKeyword, advertisement := self);
end;
operation Advertisement.findByCategoryName;
begin
return Advertisement extent.select(
(a : Advertisement) : Boolean {
return a->AdvertisementCategory->category.name = catName;
}
);
end;
Note that TextUML allows the behavior to be specified inline when declaring an operation in a class, or in separate, as above (that explains the lack of parameters, modifiers etc).
In the resulting UML model, the behaviour of Advertisement.addKeyword would roughly map to this (using a textual pseudo-notation for UML activities that is hopefully more readable than raw XMI):
activity(name: "addKeyword") {
structuredActivityNode {
variable(name: "newKeyword", type: #String)
writeVariable(variable: #newKeyword, value: createObject(class: #Keyword))
writeAttribute(
attribute: #Keyword.name,
target: readVariable(variable: #newKeyword),
value: readVariable(variable: #keywordName)
)
createLink(
association: #AdvertisementKeyword,
end1: #AdvertisementKeyword.keyword,
end1Value: readVariable(variable: #newKeyword),
end2: #AdvertisementKeyword.advertisement,
end2Value: readSelf()
)
}
}
and the behaviour Advertisement.findByCategoryName would map to this:
activity(name: "findByCategoryName") {
structuredActivityNode {
// implicit variable for return value
variable(name: "@result", type: #Advertisement, upperBound: *)
// implicit variable for parameter value
variable(name: "catName", type: #String)
writeVariable(
variable: #@result,
value: callOperation(
operation: #Advertisement.select,
target: readExtent(class: #Advertisement),
filter: metaValue(#@findByCategoryName_closure1)
)
)
}
}
// a closure is an activity that has a reference to a context activity
closure(name: "@findByCategoryName_closure1") {
// implicit variable for return value
variable(name: "@result", type: #Boolean)
// implicit variable for parameter value
variable(name: "a", type: #Advertisement)
writeVariable(
variable: #@result,
value: callOperation(
operation: #Object.equals,
// variables from the context activity are available here
target: readVariable(variable: #catName)
args: readAttribute(attribute: #Category.name, target: readLink(
association: #AdvertisementCategory,
fedEnd: #Advertisement.ad,
fedEndValue: readVariable(variable: #a),
readEnd: #Advertisement.category
))
)
)
}
Note that UML does not have closures, this is an extension to the UML metamodel which I wrote about here before.
Some background on the metaclasses involved: ReadVariableAction, CreateObjectAction, CreateLinkAction, ReadExtentAction etc are all action metaclasses. Actions are the building blocks for modeling activity behaviour in UML.
The million dollar question is: can Xtext and EMFText handle more complex textual notations like this? Is this out of the happy path? Has anyone done something similar? I am under the impression I could use Xtext or EMFText better if I used them based on a intermediate metamodel for behavior that would be closer to the concrete syntax (to get all the IDE bells and whistles for free) and then transformed that to UML in a separate step.
If you have the answers for any of these questions (or even if you have comments and questions of your own), please chime in.
Read More
20th November, 2009 - Posted by rafael.chaves - 3 Comments
Last Wednesday I attended the Eclipse Modeling Day in Toronto. Coming all the way from Victoria, I must have been the participant that came from farthest. Except, of course, those folks from SAP AG and Itemis that were presenting. But I was really glad to be there. I finally had the chance to chat and discuss about Eclipse and Modeling face to face with people like Simon Kaegi (server-side OSGi), Kenn Hussey (MDT UML2), Eike Stepper (CDO), Ed Merks and (fellow Brazilian) Marcelo Paternostro (EMF), Lynn Gayowski and Ian Skerret (Eclipse Foundation). It’s weird: I have been part of the Eclipse Modeling community since 2006 (and the larger Eclipse community since 2002), but had never actually met any of those folks before. Also amusing was that even though I worked for IBM Ottawa for quite a few years, my first time at the Toronto Lab was many years later as an ex-IBMer living on the West Coast.
The presentations I attended were in general very good. I had seen Ed Merks’ opening presentation on the web before, but this time I could ask questions. I got a better understanding of Xtext (great presentation!), CDO, and the Query, Validation and Transaction frameworks, some technologies I am considering adopting in the near future. I had a first time contact with the Papyrus 2.0 vision, which might provide an opportunity for increasing adoption of the TextUML notation by integrating the TextUML Toolkit into a larger modeling environment. And I liked the idea of a discussion panel at the end.
I had to catch a flight back home that same night, so I could not attend the Eclipse RT Day on the following day nor could I see any of the demos at the DemoCamp. Speaking of which, I did manage to stay long enough to have a beer on the Foundation (thanks!), and chat with Christopher Nagy from Dexterra/Antenna Software, who made a quick ad hoc demo to Ian and myself of their Eclipse/GEF-based tool for authoring multiplatform mobile applications. Very impressive!
As constructive criticism, I do agree with Bjorn that the format could use some tweaking. I sure had to miss some very promising presentations. Maybe with two presentation formats, a longer (for instance, 40-50 mins) and a shorter one (20-25 mins), we wouldn’t need two tracks. I am not sure presenters who came from Europe would have come had they had a shorter slot though. That being said, I was very satisfied with the event overall and am sincerely thankful to IBM Toronto for hosting the event, the Eclipse Foundation for organizing it, all the folks presenting and the companies sponsoring them. Thank you very much! As Lawrence wrote, hope we will see more events like this in the future!
Read More
6th November, 2009 - Posted by rafael.chaves - No Comments
Release 1.4 of the TextUML Toolkit is now available from the update sites, for both Eclipse 3.5+ and 3.4 (by the way, it is possible this will be the last major release targetting Eclipse 3.4, unless someone volunteers to generate and test builds for 3.4).
This is mostly a bug fix release. However, there were some minor notation changes to support stereotypes on dependencies, generalizations and interface realizations, hence the version change from 1.3.x to 1.4.x.
Thanks to Vladimir Sosnin, Attila Bak and fredlaviale for contributing with code and/or bug reports/feature requests. Keep them coming!
As usual, you can find a summary of the changes in the TextUML Toolkit Features page. If you are using the Toolkit, make sure you upgrade soon. If not, what are you waiting for? Install it already!
Read More
2nd October, 2009 - Posted by rafael.chaves - No Comments
Last week I did a short presentation on “Model-driven prototyping” for the Vancouver Island Java User Group (VIJUG). It was lots of fun, with good participation from the group. I also showed a quick demo of AlphaSimple, our upcoming service for model-driven prototyping, which seemed to be well received.
For the benefit of those not there, here is a web-version of that presentation, with notes showing on the slides (click here for a full screen view).
Comments are very welcome. I would be very happy to discuss the approach with anyone interested.
Read More
23rd June, 2009 - Posted by rafael.chaves - No Comments
The TextUML Toolkit 1.3 is now available, 4.5 months after 1.2. If you already got RC1 (1.3.0.20090614…), it is the same build, no need to upgrade again. Otherwise, just point the Eclipse update mechanism to:
http://abstratt.com/update/ – if you are using Eclipse Galileo, or
http://abstratt.com/update/3.4/ – if you are using Eclipse Ganymede.
Please see the feature page for a summary of the evolution of the TextUML Toolkit in terms of features across releases. Some highlights for this release are better integration with other UML tools and support for both Eclipse 3.4 and 3.5.
As usual, bug reports and feature requests are much appreciated. And if you need help, make sure to ask on the user forum.
The TextUML Toolkit Team
Read More
15th June, 2009 - Posted by rafael.chaves - 3 Comments
The first release candidate towards version 1.3 of the TextUML Toolkit is now available. The feature overview page has been updated to reflect the changes in the 1.3 cycle.
Please give it a try and report any issues you might find. If no serious problems are found with this build, it will be promoted to 1.3 final later this week.
Note that the main update site supports Eclipse 3.5, but there is also an update site for Eclipse 3.4. The features are the same, the only differences between the two sites are the dependencies (UML2 3.0 and EMF 2.5 on Eclipse 3.5, UML2 2.2 and EMF 2.4 on Eclipse 3.4).
The TextUML Toolkit team welcomes your feedback.
Read More
11th June, 2009 - Posted by rafael.chaves - No Comments
Wow, it is been more than a month since my last post, but I have been busier than ever working on an upcoming MDD-related product (cannot say much now other than that you will hear more about it here first). However, In TextUML Toolkit-land things are looking pretty exciting.
More hands on deck
Vladimir Sosnin has joined the project and has been on a roll contributing many patches, not only bug fixes but design improvements and features too. It is amazing how quickly he has become very comfortable with the TextUML Toolkit code base (Vladimir is certainly a solid developer, but I’d like to think the quality of the code base helped him too). And if that was not good enough, Vladimir is also using the TextUML Toolkit in his daily work around model-driven development, so that should help ensuring the Toolkit has the features its target audience actually needs.
New release in the making
1.3RC1 should be made available during the weekend. It has some shiny new language features, a bunch of bug fixes, better integration with other UML2 tools and support for both Galileo and Ganymede. By the way, shipping code that can handle different incompatible versions of Eclipse has become a little more challenging with P2, as you cannot ship a feature that has bundles that resolve in a mutually exclusive way – it seems you really need two different features for that.
Documentation moved to SourceForge
SourceForge now has support for MediaWiki, which is used to author and serve the documentation for the TextUML Toolkit. In the spirit of strengthening the message that the project should really be considered a community-based effort, I decided to migrate the documentation from the Abstratt web site over to SourceForge.
I guess that does it, at least for now. Stay tuned.
Read More
3rd May, 2009 - Posted by rafael.chaves - 9 Comments
I have heard the mantra ‘code is model’ several times. Even though I always thought I got the idea of what it meant, only now I decided to do some research to find out where it came from. Turns out that it originated from a blog post that MS’ Harry Pierson wrote back in 2005. It is a very good read, insightful, and to the point.
The idea that gave title to Harry’s post is that whenever we use a simpler representation to build something that is more complex and detailed than we want to care about, we are creating models. 3GL source code is a model for object code. Byte code is a model for actual CPU-specific executable code. Hence code is model.
He then goes to ask that if we have been successfully reaping the benefits of increased levels of abstraction by using 3GLs for decades now, what prevents us from taking the next step and using even higher level (modeling) languages? He makes several good points that are at the very foundations of true model-driven development:
- “models must be precise“- models must be amenable to automatic transformation. Models that cannot be transformed into running code are “useless as development artifacts“. If you like them for conceiving or communicating ideas, that is fine, but those belong to a totally different category, one that plays a very marginal role in software development, and have nothing to do with model-driven development. Models created using the TextUML Toolkit are forcefully precise, and can include behavior in addition to structure.
- “models must be intrinsic to the development process” – models need to be “first class citizens of the development process” or they will become irrelevant. That means: everything that makes sense to be modeled is modeled, and running code is generated from models without further manual elaboration, i.e., no manually changing generated code and taking it from there. As a rule, you should refrain from reading generated code or limit yourself to reading the API of the code, unless you are investigating a code generation bug. There is nothing really interesting to see there – that is the very reason why you wanted to generate it in the first place. Build, read, and evolve your models! Generated code is object code.
- “models aren’t always graphical” – of course not. I have written about that before here. The TextUML Toolkit is only one of many initiatives that promote textual notations for modeling (and I mean modeling, not diagramming – see next point).
- “explicitly call out models vs. views” – in other words, always keep in mind that diagrams != models. Models are the real thing, diagrams are just views into them. Models can admit an infinite number of notations, be them graphical, textual, tabular etc. Models don’t need notations. We (and tools) do. Unfortunately, most people don’t really get this.
The funny thing is that, most of the times I read someone citing Harry’s mantra, it is misused.
One misinterpretation of the “code is model” mantra is that we don’t need higher-level modeling languages, as current 3GLs are enough to “model” an application. The fact is: 3GLs do not provide an appropriate level of abstraction for most kinds of applications. For example, for enterprise applications, 4GLs are usually more appropriate than 3GLs. Java (EE) or C# are horrible choices, vide the profusion of frameworks to make them workable as languages for enterprise software – they are much better appropriated for writing system software.
Another unfortunate conclusion people often extrapolate from the mantra is that if code is model, model is code, and thus it should always be possible to translate between them in both directions (round-trip engineering). Round-trip engineering goes against the very essence of model-driven development, as source code often loses important information that can only exist in higher level models. The only reason people need RTE is because they use models to start a design and generate code, but then they switch to evolving and maintaining the application by directly manipulating the generated code. That is a big no-no in true model-driven development – it implies models are not precise or complete enough for full code generation.
So, what is your view? How do you interpret the “code is model” mantra?
Read More
13th April, 2009 - Posted by rafael.chaves - 3 Comments
Even though it has always been possible to open models generated by the TextUML Toolkit in UML2-based diagramming tools, until 1.2 the Toolkit assigned new ids to each element every time a model was regenerated. That meant that any diagrams based on the model being regenerated would become invalid as any cross-references from the diagram to the model would be broken.
Starting with 1.3 M1 (test build available from the milestones update site), the TextUML Toolkit is now better compatible with diagramming tools based on UML2. You can edit the source in TextUML and save it to cause model generation to occur, and any existing diagrams should still remain valid.
Here you can see the TextUML Toolkit being used side-by-side with the UML2 Tools graphical editor:
Actually, I found out that UML2 Tools can be a great companion for the TextUML Toolkit because it seems to just do the right thing when it notices the underlying model has been changed externally: new elements show up, removed elements disappear, preserved elements preserve their layout. I tried doing the same with Papyrus 1.11 and unfortunately it does not seem to handle external updates properly. I haven’t tried with other UML2-based diagram editors, so at this point I am not sure which one represents the trend here.
Read More
5th April, 2009 - Posted by rafael.chaves - No Comments
I have been doing some exploratory work around running the TextUML Toolkit‘s compiler as a standalone Java application. In other words, without OSGi. You Eclipse/OSGi heads out there might ask: why would anyone want to do that? The answer is: enhanced applicability. Severing ties with the Eclipse runtime/OSGi means the compiler would become usable in other contexts, and by more people. Think Ant or Maven-driven builds, or (the horror!) other IDEs.
The TextUML compiler’s dependencies
The TextUML compiler is not very different from any ordinary 3GL compiler. It reads a bunch of source files and spits another bunch of object files. For reading and writing files, the TextUML compiler uses EFS, the Eclipse File System. For generating the object files, which are UML models, the compiler uses UML2 and EMF.
Luckily, all these components are expected to work on a standalone application, although some restrictions in functionality might apply. At a first glance, one would expect that running the TextUML compiler without OSGi should be quite feasible. But, as I should have learned by now, it is never that simple…
Extension registry without OSGi
The TextUML compiler, and some of its dependencies use the extension registry to receive contributions to their extension points or make contributions to other components’ extension points. Since Eclipse 3.2, the extension registry API provides support for creating registries without OSGi. Basically, you can add any extension and extension points you want, all you need to do is to provide the XML markup for them.
Problem: in a standalone Java application, it is the application’s responsibility to somehow find the plugin manifests and populate the extension registry.
Solution: I started with the example Paul Webster posted on the platform newsgroup almost two years ago. It basically starts from a file system location which it assumes to hold plugins, both on JAR’d and directory form. It will find plugin manifests (plugin.xml), recognize translation resources (plugin.properties), and even discover the bundle name by parsing the bundle manifest (MANIFEST.MF), and use that to populate the extension registry. Pretty cool, thanks PW. I just cleaned-up the code a bit and enhanced it to also find plugin manifests using the application’s classloader. I also had to add support for setting the default extension registry, which is the one other components will get when invoking Platform.getExtensionRegistry() or RegistryFactory.getRegistry(). Finally, I had to implement basic support for creating executable extensions, which was not too hard given that I could assume the entire application is using the same (application) classloader.
EFS without OSGi
Also since 3.2, the Eclipse File System does not require OSGi to operate, however it does require a functional registry as it uses an extension point to allow file system implementations to be plugged in. So, provided one manages to populate the default extension registry, EFS works fine on a standard Java app. No action required here (yay!).
EMF and UML2 without OSGi
EMF has long been advertised as being mostly functional when running in non-managed mode. However, when running in an standalone app, EMF does not process extensions to its extension points (such as resource factories, metamodel packages and URI mappings), so a standard Java application needs to explicitly initialize EMF, which is clearly suboptimal. That is because EMF only processes contributions to its extension points right during bundle activation. There is no alternative way to trigger processing of the registry (see bug #271253), which sucks, given that the registry is there just waiting to be used. With no OSGi, there is no such thing as bundle activation, and thus EMF goes into autistic mode. This is also true for UML2 (not surprisingly, as they share many implementation traits), the main difference being that UML2′s extension points are much less used than EMF’s.
Problem: Ecore won’t process the extension registry when running in a standalone Java application.
Solution: Change Ecore so it allows clients to explicitly trigger processing of the contributions to Ecore’s extension points. My local hacky solution was to make Ecore’s extension registry parsers to be publicly visible so any client could invoke them.
‘platform:’ URLs without Equinox
Extensions to Ecore’s URI mapping extension often translate to ‘platform:’ URLs, which are another common Eclipse-ism, and thus not supported in plain Java applications.
Problem: No support for ‘platform:’ URL schemes in standalone mode.
Solution: I implemented a simple URL stream handler for the ‘platform’ protocol. The current implementation complete ignores the path component that determines what bundle the resource is in. That is clearly something that needs to be improved, but should not be too hard.
Conclusion
Well, it wasn’t really a walk in the park, but other than the issue that requires a change in EMF (bug #271253, which I am hoping could be addressed for Ganymede Galileo), I am pretty happy with the results of this exploration.
I made all the code I wrote (including my version of Paul Webster’s registry loader) available on the TextUML Toolkit’s SVN repository on SourceForge. Feel free to use it and submit improvements. I wonder if this sort of stuff could find a home in Eclipse.org, as I think many people currently developing for non-OSGi targets would like to take advantage of some great OSGi-agnostic Eclipse APIs.
Read More
27th March, 2009 - Posted by rafael.chaves - No Comments
I decided it was time to start using Eclipse 3.5 before it went RC or else if I find any blockers there won’t be time left for them to get fixed before the next release this Summer. I have been on the other side of the fence and know how frustrating it is when people only really start reporting bugs at the very end of the release cycle.
After I installed the 3.5 M6 SDK, I decided to install the TextUML Toolkit 1.2…
Nothing to install?
First surprise: no features would show on the update site! WTH? Well, turns out I had the Update UI to show available features grouped by category, but the TextUML Toolkit update site does not use categories. Unchecking the option to group by categories shows the four features in the TextUML Toolkit update site as it was usual in 3.4. Phew… I was just about to enter a bug report against the Eclipse update component (a.k.a. p2), when I found out that that unintuitive UI behavior has been recently addressed and the next milestone won’t show this problem any longer.
A roadblock
I managed to install the TextUML Toolkit, and that brought along EMF and UML2, which are required features. Since, at this time, the TextUML Toolkit does not specify version range for its dependencies, the latest versions of EMF and UML2 were automatically installed by Eclipse. That should be fine, I thought, as one of the Eclipse development key mandates has always been backward compatibility. But this time around that was not the case: the TextUML builder was failing to compile a TextUML source file that was making use of template parameters. Turns out the UML2 API around templates has changed in its version 3.0. Before (in UML2 2.2), a template parameter substitution could have multiple formal and actual parameters. Now it can have only one of each, and thus the TextUML Toolkit is (partially) broken in 3.5.
So much for core values, you might be thinking? Well, to be fair, this is a bit of a fringe case. The UML2 API is an Eclipse component, and as such should strive for backward compatibility too. However, it is also a high-fidelity rendition of the UML specification published by the OMG. In this case, the OMG fixed a bug (#9838) in the spec, and as often is the case with UML, that resulted in a change that was not backward compatible. If the OMG promotes changes that are not backward compatible, the UML2 team does not have much of a choice: in order to continue to closely implement the spec, it has to break the Eclipse guidelines.
And neither do I. For the TextUML Toolkit 1.2, I will have to issue a maintenance release (1.2.1) that will explicitly depend on UML2 2.2, thus avoiding the new version, and probably becoming incompatible with other UML modeling packages that only run on Galileo and UML2 3.0. For the next release of the TextUML Toolkit (1.3), I will have to adopt the new API and explicitly depend on UML 2 3.0.
That is how life goes… for some reason, I kind of feel like a flea crawling on the back of an elephant.
Read More
18th March, 2009 - Posted by rafael.chaves - 1 Comment
I strongly believe queries are an essential part of a domain model. As such, in our quest to have (UML) models that can fully (yet abstractly) describe object models for the common enterprise applications, we cannot leave out first class support for queries.
But how do you do queries in UML? The obvious answer seems to be OCL, but that is not the approach I am taking as OCL and UML have serious interoperability/duplication issues. Instead, I took the middleweight extension approach.
First, we model a protocol for manipulating collections of objects (showing only a subset here):
class Collection specializes Basic
operation includes(object : T) : Boolean;
operation isEmpty() : Boolean;
operation size() : Integer;
operation exists(predicate : {(:T) : Boolean}) : Boolean;
operation \any(predicate : {(:T) : Boolean}) : T;
operation select(filter : {(:T) : Boolean}) : T[*];
operation collect(mapping : {(:T) : any}) : any[*];
operation forEach(predicate : {(:T)});
operation union(another : T[*]) : T[*];
(...)
end;
That protocol is available against any collection of objects, which in UML can be obtained by navigating an association, reading an attribute, invoking an operation, obtaining the extent of a class (remember Smalltalk’s allInstances), anything where the resulting value has multiplicity greater than one.
Note most of the operations in the Collection protocol take blocks/closures as arguments. Closures are used in this context to define the filtering criterion for a select, or the mapping function for a collect.
For instance, for obtaining all accounts that currently do not have sufficient funds, this method would do it:
static operation findNSFAccounts() : Account[*];
begin
return Account extent.select(
(a : Account) : Boolean {return a.balance < 0}
);
end;
Note the starting collection is the extent of the Account class. That is very similar to what is done in the context of query languages for object-oriented databases, such as OQL or JDOQL. We then filter the class extent by selecting only those accounts that have a negative balance, by passing a block to the select operation.
When mapping that behavior to SQL, we could end up with a query like this:
select _account_.* from Account _account_ where _account_.balance < 0
Another example: we want to obtain all customers with a balance above a given amount, let’s say, to send them a letter to thank them for their business. The following method specifies that logic:
static operation findBestCustomers(minBalance : Real) : Customer[*];
begin
return (Account extent.select(
(a : Account) : Boolean { return a.balance >= minBalance }
).collect(
(a : Account) : Customer { return a->AccountOwner->owner }
) as Customer);
end;
Note that we start off with the extent of Account class, filter it down to the accounts with good balance using select, and then map from that collection to a collection with the respective account owners by traversing an association using collect.
If that was going to be mapped to SQL, one possible mapping would be:
select _customer_.* from Account _account_
inner join Customer _customer_
on _account_._accountID_ = _customer_._customerID_
where _account_.balance >= ?
Much of this can be already modeled if you try it out with the TextUML Toolkit 1.2. But, you might ask, once you model that, what can you do with UML models containing queries like the ones shown here?
Since the models are complete (include structure and behavior), you can:
- Execute them. Imagine writing automated tests against your models, or letting your customer play with them before you actually start working on the implementation.
- Generate complete code. The generated code will include even your custom queries, not only those basic ones (
findAll, findByPK) code generators can usually produce for you.
If you would like to see tools that support that vision, keep watching this blog.
So, what is your opinion?
Do you see value in being able to specify queries in your models? Is this the right direction? What would you do differently?
Read More
4th February, 2009 - Posted by rafael.chaves - 1 Comment
The TextUML Toolkit 1.2 is now available, 5 months after 1.1, when it first became an open source project. If you already got RC2 (1.2.0.200902011417), it is the same build, no need to upgrade again. Otherwise, just point the Eclipse update mechanism to:
http://abstratt.com/update/
Please see the feature page for a summary of the evolution of the TextUML Toolkit in terms of features across releases.
As usual, bug reports and feature requests are dearly appreciated. And if you need help, make sure to ask on the forum.
Read More
Older Entries
Newer Entries
