Monday, October 27, 2008

On Separation Anxiety...

You gotta keep 'em separated. Or so says conventional wisdom (and the song). One of the homework items for this week's UML Roadmap working group meeting was to propose a solution to the 'separation of concerns' problem in UML. I would argue that this, like many other problems with UML, is actually a symptom of more fundamental issues with the way specifications are defined/developed at the OMG, and that we ought to address these issues before it’s too late (if it isn’t already).

The bottom line is that the status quo will no longer suffice. Design by committee and vendor politics won't get us anywhere. Neither will closedness and opaqueness. In his webinar on ecosystem development the week before last, Mike suggested that ecosystems could be evaluated on the basis of five key concepts (see below). In order for the ecosystem of specifications (languages) that exists at the OMG to survive, I'd say its health in these areas needs to be measured and improved.

Co-evolved innovation. There's certainly a lot of innovation happening at the OMG, and by a lot of players. But sometimes I wonder how relevant the innovation is (in the absence of reference implementations) and how coordinated the activities are (sometimes chairing a task force seems a lot more like cat-herding than coordinated evolution).

Alignment of Vision. The OMG has a vision - MDA (Model Driven Architecture). But how aligned are the various OMG specifications with this vision? How long will the industry wait for it to be realized?

Degree of openness. The OMG is an open organization, in the sense that its reason for being is to produce open specifications. But its processes are less open than other organizations like Eclipse, and that has garnered it some negative press. To borrow from Bjorn's analogy, I think the OMG would benefit from being an openness bear that's "just right".

Degree of modularity. I think this is at the heart of the 'separation of concerns' problem. Languages like UML and its relatives are in fact designed to be modular - they're structured as sets of packages, or "capabilities" and then merged into various compliance levels... but something went wrong along the way, because subsets of these languages aren't as reusable as they were originally intended to be.

A network of niches. A set of vertices without edges is not a graph - it's just a set of vertices. I think many of the niches (UML, BPMN, IMM) are falling into place at the OMG; now, we just need to connect the dots.

Mike also talked about the importance of an open, extensible platform as the basis for a successful ecosystem. I think that's what's missing in the OMG ecosystem. Yes, it has MOF, but that's not a platform on its own; MOF is to the OMG as OSGi is to Eclipse. The OMG needs a platform (a working version of what the InfrastructureLibrary in UML was intended to be) upon which MOF-based languages can be built.

So, here's what I think should be done to solve the 'separation of concerns' problem in UML. Direct the renewed interest and energy in "fixing" UML toward defining a platform of shared concepts upon which UML (and other specifications like BPMN and IMM) can be based. Implement (yes, implement!) a proof a concept that demonstrates the benefits of refactoring UML based on this platform using mechanisms from the emerging Diagram Definition and Semantic MOF specifications, and extrapolate to infer how the same benefits could be reaped by other specifications like BPMN and IMM. Then, and only then, submit responses to the RFPs for Diagram Definition, Semantic MOF (MOF 3.0?), and UML 3.0.

Some say that making changes like this will only serve to disrupt the industry, to scare away the vendors and users once and for all ("they waited forever for UML 2.0; if we propose UML 3.0, we'll lose them for good!"). That's just FUD, if you ask me and, well, desparate times call for desparate measures. The way to avoid this disruption is to make the changes in a more open and transparent way than before, for example, in a project at Eclipse. Of course, we'd try to maintain backward compatibility if at all possible or, at the very least, provide an explicit migration path for existing tools. But let the (proven) technology speak for itself. If we build it, they will come. The time is now.

Friday, October 24, 2008

On Where I'll Be Next Week...

EclipseWorld 2008, of course! It's shaping up to be a great conference, and three of my colleagues and I have the distinct honor of being on the "expert faculty". We'll be delivering technical classes on a variety of topics important to application developers and database professionals. Our presentations will explore concepts such as software archeology, delve into architectural styles such as REST, and provide how-to guidance for database development, data modeling, and application factories in Java.

Scott Walz, senior director of product management, will deliver a class entitled "Classic Database Development Mistakes Made by Java Developers — and Five Ways to Overcome Them" on Wednesday at 3:15 pm. In this session, Scott will outline the five most common databas development mistakes made by Java developers and offer specific direction on how to overcome them.

Ravi Kumar, principal architect, will deliver a class entitled "How to Implement Application Factories in Java" on Thursday at 8:45 am. In this session, Ravi will utilize real-world examples to demonstrate how to build an end-to-end Web application with core capabilities, from database table all the way to presentation.

Michael Rozlog, JBuilder evangelist and co-author of “Mastering JBuilder", will deliver a class entitled "I’ve Just Inherited 1,000,000 Lines of Java Code — NOW WHAT?" on Thursday at 10:30 am. In this session, Michael will help developers understand the concepts behind software archeology and the tools used to support it, as well as explain how to apply the techniques of static and dynamic analysis in the real world. This session has been selected as one of the nine hottest classes at EclipseWorld.

I will be delivering a class entitled "Data Models for Java Applications" on Thursday at 8:45 am and another entitled "RESTful EMF" at 10:30 am. In the first session, I'll be reviewing the various types of data models and exploring how they are supported by projects at Eclipse. In the second session, I'll be providing an overview of Representational State Transfer (REST) and discussing how Java programs can be developed in accordance with the REST architecture style using the Eclipse Modeling Framework (EMF).

In addition to the two technical classes on Thursday, I'll also be doing a Model Development Tools (MDT) project demo between 8:45 and 9:00 pm at the Eclipse Foundation party on Wednesday. I'll be giving a sneak preview of some of the technology soon to be contributed to Eclipse as part of the newly created Papyrus component and will also offer insights into more new subprojects on the horizon.

Where will you be next week? If your answer is the same as mine, I hope to see you there!

Friday, October 17, 2008

On Beginnings and Ends...

So far, it seems that Microsoft's participation at the OMG is more like the end of the beginning than the beginning of the end. Pariticipants in the UML Roadmap working group met on Tuesday to discuss everybody's top three problems/concerns with UML, and there seems to be a concensus that most of the issues fall under a general theme of separation of concerns. More homework has been issued for the next call (to take place in two weeks); this time, the  assignment is to provide feedback on a proposal to develop an integration architecture that would support a family of related languages (wasn't that what MDA was supposed to be?) and to make alternative proposals for addressing the "Separation of Concerns" problem in UML. Any ideas?

Speaking of beginnings and ends, there have been some bitter-sweet changes in the MDT project recently. Termination reviews for the EODM and OCL Tools components were "successful" as of last Wednesday (since nobody from the community requested a formal review), and so both have been archived. The OCL Tools component was actually never completely provisioned, so all that remains of it is a page in Eclipsepedia. EODM, on the other hand, was a more or less functional component for several years, but unfortunately it no longer had a community of developers to maintain it (despite a small but interested user community). The Eclipsepedia page for EODM also remains, and its newsgroup and mailing list have been archived, as have its downloads. Luckily, a proposal for a new ODM implementation at Eclipse is in the works; stay tuned for details.

On a positive note, there have been a couple of new beginnings in MDT. The Papyrus component has now been successfully created, and provisioning is nearly complete. The initial project team (one of the largest and most diverse that I've seen at Eclipse) has plans to provide a code contribution sometime in November; for more details, see the newsgroup or mailing list. Also, the proposal for a new Metamodel Specification Tools (MST) subproject in MDT has finally been declared. If you're interested, please join in the newgroup discussion or drop me a line!

Thursday, October 9, 2008

On Ducks...

All things in my world seem to be pointing toward ducks lately. I just unlocked the "Quacker" bike in Mario Kart Wii, I got a random sales call from Black Duck Software, and I stumbled upon the concept of duck typing for the first time. All on the same day. I've always been a firm believer, as Red Green often attested, that duct tape is indispensable. But now I'm starting to wonder whether all those years he was saying "duck type". If duct tape is a handyman's secret weapon, should duck typing be a programmer's secret weapon?

So what is duck typing? It's the notion that if something walks (waddles) like a duck and quacks like a duck, then it can be assumed to be a duck. Duck typing, commonly used in languages like Ruby and Python, is a style of typing where an object's current set of methods and properties, rather than its inheritance from a particular class, determines its semantics. Duck typing really isn't all that new - it's really about dynamic versus static typing. Real programming languages like Smalltalk have supported this concept for a long time. ;)

Who decides what the definitive characteristics of a duck are? Does something need to look like, dress like, or weigh as much as, a duck to be a duck (or a witch, as the case may be)? Does it have to feel, smell, and taste like a duck to be a duck? If "beauty" is in the eye of the beholder, does the beholder get to decide what a duck is? Is it a matter of perception?

After reading about duck typing, I got to thinking that it might be one approach to resolving the issue of unintended inheritance in UML. What if, rather than specializing metaclasses from a common infrastructure, or merging them into a hybrid representation using package merge, related languages could simply declare what they assume the definitive set of shared characteristics for each metaclass (duck) is? Should a metamodel perhaps be simply a selection of mixins rather than a complex heirarchy of (base) classes?

Tuesday, October 7, 2008

On What's Wrong with UML...

Sure enough, I had an inevitable encounter with said company the week before last at the OMG technical meeting in Orlando. As Steve Cook said, he was welcomed with mostly open arms. The Analysis and Design Platform Task Force meeting was a little more interesting than usual because Steve had the gumption to point out many of the problems that exist with UML. I'm glad he did. Although many of his observations weren't a surprise to all of us, with any luck his fresh perspective will inspire the UML community to act rather than sit around and pontificate...

One of the things that came out of the Orlando meeting was the formation of a UML Roadmap working group, participation in which is open to any OMG member. As homework for today, participants were asked to come up with the top three things that they feel are wrong with UML. I'm sure many will cite complexity as a major problem with UML, but as I've said before, I think this failure is largely in the tools, not necessarily the metamodel. Rather than been passing the complexity of UML on to the end user, vendors should work smarter (not harder) to find innovative ways to make consumable products.

I don't claim to know everything about UML, but after spending several years developing and maintaining the de facto reference implementation of UML at Eclipse, I have a few opinions about what's wrong with the language. While difficult to choose only three, here's what I think my picks (mostly related to interchange) are.

1. Un-intended inheritance

The hierarchy of metaclasses in UML is deep and wide, and riddled with multiple inheritance. The designers of UML strived for a rich architecture with many reusable levels of abstraction; unfortunately, one of the side-effects of such a design is that concepts which make sense in one context (metaclass) are unintentionally inherited in another (metaclass). This is further exacerbated by package merge, which combines mutltiple flavours of a metaclass, from various contexts, into one overloaded representation.

2. Undefined namespaces for standard stereotypes and primitive types

The UML specification defines standard stereotypes for use in its higher compliance levels, but fails to define a normative URI via which the profiles containing them can be referenced. Similarly, UML defines a set of four standard primitive types, but rather then defining a model library with a normative namespace URI so that they can be reused, it merges them into the langage itself, forcing other related languages to do the same.

3. Inability to create a usable XML schema for UML

Currently, it's not possible to produce a working XML schema for UML because of its extensive use of multiple inheritance. Even with a schema produced using the XML extension mechanism a copy-down inheritance, a given UML instance document couldn't be validated, because UML doesn't make a consistent distinction between base classes and mixin classes.

Here's hoping this new working group will bear some fruit.

Wednesday, October 1, 2008

On Plans...

What's that expression again? Luck is what happens when preparation meets opportunity. I was reminded of this cliche recently while reading The Last Lecture by Randy Pausch (a must read). How lucky are you? To be prepared, I think you need to have a plan.

I've been spending a lot of time planning lately. So much that I've had little time to come up for air. In addition to looking at what I'd like to release in the next versions of ER/Studio, ER/Studio Enterprise Portal, and other Embarcadero products in 2009, I've been looking at what will be part of next year's incarnation of MDT as part of the Galileo simultaneous release in June.

Plans for Eclipse projects were due yesterday, and I'm pleased to say that the MDT component leads were able to pull together plans for the MDT components just in time. There's a new, standard format for plans now, which I think is a good thing. One of the nice aspects of the standard plan format is that much of a plan's content can be populated dynamically using Bugzilla queries. Projects like EMF have been doing this for years; I'm glad that more projects will now be able to take advantage of this time-saving approach to planning.

Unfortunately, one of the not-so-nice aspects of the standard plan format is that much of a plan's content can be populated dynamically using Bugzilla queries. I'm cool with the notion that a plan is a "living document", and that using Bugzilla queries allows plan items to transition from "proposed" to "committed" or "deferred" without having to update the document. But this approach also allows bugs to be added and removed from a plan without an easily consumable record of these changes or why such decisions were made. Where's the accountability? In my mind, a plan is not just a document that you can point to at the end of a release to say what you ended up actually doing - that's what release notes are for.

One of the challenges I encountered early on while trying to put together the plans for my MDT components was the desire to view a plan after a release and have it still accurately reflect what was originally planned. Depending on how the Bugzilla queries in a plan are written, it seems that items (particularly ones with version-agnostic target milestones like "M6") which are on the plan for one release could conceivably disappear from that plan and reappear on the plan for a subsequent release. In the absence of the ability to assign multiple target milestones in Bugzilla (one of the features of JIRA that really like) I realized that I needed a way to tag a bug such that it would always be affiliated with the plan for a given release.

I proposed the introduction of a 'galileo' keyword (for bugs that are part of the plan for the Galileo release), but some folks were concerned about the proliferation of keywords (because they are global elements in Bugzilla). Then Denis suggested an even better idea - a 'galileo' flag that could be made available only for projects that wanted/needed it. As it turns out, it's quite a useful thing. Not only can I now tag bugs as being committed (galileo+) or deferred (galileo-) items on my Galileo plan (in perpetuity), I also have a way of marking bugs that get fixed in the Galileo release but weren't originally on my plan (indicated by the absence of the 'plan' keyword). Thanks, Denis!