Exploring Oslo's modeling language promises

Fundamentally, software modeling is about describing an application. Modeling has long held promise for software developers, especially as they struggle with ever-more-complex, distributed, composite applications built on IT silos that Do Not Play Well With Others. But modeling has not gained mainstream adoption, explains Burley Kawasaki, Microsoft director of product management, Connected Systems Division.

"Until now," is the unspoken addition. With Oslo, Microsoft wants to bring modeling to the software development mainstream. Among Oslo's pieces: a modeling-specific language-code-named M-in which to write domain specific languages (DSLs); a way to build visual DSLs (code-named Quadrant); and a repository that brings all the models together to be viewed and managed as a cohesive whole (mysteriously, the repository does not have a code name). "This represents us going from a world of general programming languages and domain-specific APIs to a more domain-specific language world," says Doug Purdy, Microsoft product unit manager for Connected Systems Architecture.

Today, M will be made available under the open specification promise, which allows anyone to implement the language spec. "As much as we're proud of the intellectual property we've put into it," says Kawasaki, "It's what you do with the language that matters."

We do, however, hope that the company resists the recent tendency to turn the code name into the final product name. Some developers inevitably will hate M just as some hate C# and others hate Java. Just thinking of the phrase, "Anti-M" makes us contemplate a future in which developers chant, "There's no place like home. There's no place like home."

So what's the big deal about modeling? Hasn't it been around for years? Yes-but only to a degree. When it's used in enterprise development, modeling is most often adopted for the software design phase. That can be helpful in drawing a picture of what the business wants, Kawasaki says, and "it can help developers implement what they thought the picture meant." But it's what they thought the picture meant; how often is that actually the case? Even when the model matches the original software vision, it goes out of sync very quickly.

But just as "the map is not the territory," the software model isn't the picture; the model has to describe the application. If the business rules change or the software intent changes, the application needs to change too.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine