LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Of Diffrent Minds About Modeling


Industry mavens weigh in on UML, broader uses for visual representations

By Jennifer deJong
June 15, 2006 — 
Time was when UML was just UML. When modeling experts talked about the Unified Modeling Language, they were referring to the language used to communicate the design of a software application. The UML’s 13 diagram types—including Class, Object, Component, Sequence, Use Case and Activity—enabled development teams to map out the various pieces of software applications, and to specify how those pieces worked together.

But last month, when SD Times asked a team of five modeling experts to weigh in on UML’s future, it was clear the term UML had taken on a broader meaning. “The future is not just about UML, but about modeling in general—as a level of abstraction for describing systems,” said Richard Soley, chairman and CEO of Object Management Group, the industry consortium that maintains UML. Just shy of its 10-year anniversary, UML is also used to map out business processes, define business rules that help companies implement security policies and comply with government regulations, and to create new standards, such as SysML, used to describe complex engineering projects, the experts said.

Originating in 1997, UML underwent a significant upgrade in August 2003 when OMG formally adopted UML 2.0 and made it available to tool makers. The final version of UML 2.0 was published last August. UML 3.0 isn’t on the horizon yet. But the team of experts, which, in addition to OMG’s Soley, comprised Bran Selic from IBM, Jack Greenfield from Microsoft, Cris Kobryn from PivotPoint, and Jan Popkin from Telelogic, had plenty to say about code generation, round-trip engineering and what it will take to increase UML adoption among development teams.

SD Times posed the same set of question to each expert. What follows are excerpts from their responses.

SD Times: What is the future of UML?
Bran Selic, IBM: As a standard, UML is being maintained continuously. We have just completed UML 2.1, and already work on UML 2.2 is commencing. The scope of these point releases is mostly maintenance, confined to fixing any leftover inconsistencies or, in cases where the spec is ambiguous or incomplete, to adding clarifications.

On a technical level, I foresee more and more people taking advantage of the deeper semantics of UML 2.0 (relative to 1.0) for advanced capabilities, such as automatic code generation, model execution and model verification. I also see more and more domain-specific languages [DSLs] being defined in the form of UML profiles. These profiles are modeling languages that are based on standard UML and its semantics, thereby taking advantage of the UML foundation as well as the tooling and general familiarity and experience built up around UML. After all, modeling language design is still far from an exact science, and it makes sense to start from a proven base.

Jack Greenfield, Microsoft: I believe the industry will move from general-purpose UML models to DSLs in order to obtain the higher fidelity in modeling activities required to support meaningful code generation, validation, transformation, traceability, refactoring, pattern expansion and other applications of model resident metadata. UML will become a source of modeling language concepts, notations and fragments used in the construction of DSLs.

Richard Soley, OMG: [In addition to extending UML 2.0], the future is about defining new standards, based on UML. The recently released SysML, for designing complex systems that include software, hardware and processes, is an example. It’s the first UML-based language that falls outside the realm of pure software.

Jan Popkin, Telelogic: Modeling will remain the accepted communications vehicle. The question is: How tightly should we couple the model and the code? The answer is different for different types of modeling. The first area is business processes and activities, which are abstract. There is no code involved, and a pictorial model is a necessity. In the middle area—applications and SOA—models are used to guide and make changes. You document [the system], often on a whiteboard, before and after implementation. But in the third area—the real-time and embedded space—the model and code coexist. They are self-contained, and they work well together.

Cris Kobryn, PivotPoint: In the longer term, I am optimistic about the future of Model Driven Development (MDD) and visual modeling languages such as UML, since I think it is inevitable that the software industry will eventually mature and bona fide software blueprints will eventually become commonplace. However, in the shorter term, I am concerned about the adverse impact that UML 2.0 language bloat, UML 2.0 dialect divergence, and XMI 2.0 lack of diagram support are having on the marketplace. [XML Metadata Interchange enables easy interchange of metadata between UML-based modeling tools and metadata repositories.].

The technical solutions to these problems are relatively straightforward. First, reduce the gratuitous complexity of UML 2.0 by defining a “UML Light” or “Agile UML” subset. Second, define an XML-based model interchange format for “Agile UML” that is simpler than XMI. Third, specify a test suite for “Agile UML” compliance and interoperability. These improvements will make UML significantly easier to learn, apply, implement and interoperate with other software tools.

How can development teams take better advantage of UML-based tools to improve the software development process?

Greenfield: If they are using vanilla UML, then they can move to UML profiles to improve their ability to capture information precise enough to support software development activities. Even better, they can move to DSLs, which are even more precise than UML profiles and offer better user interfaces and tool extensibility.

Kobryn: Developers should begin by realistically assessing the current capabilities and limitations of UML 2.0 and UML-based tools, and find specific ways that these technologies can simplify and automate parts of their current development process. For example, after their UML 2.0 assessment, they may decide that they need only four to five diagram types to precisely specify their software architecture, instead of the baker’s dozen that are available. Similarly, after their UML-based tool evaluation, they may decide they only need to be able to draw UML diagrams, but not execute them, since they want to craft the software code themselves, instead of automatically generating it.

Selic: [How teams take advantage of UML] depends on the extent to which they intend to integrate MDD methods into their development process. There is a range of possibilities, from simple visual rendering of source code, to so-called round-trip engineering [where a change made to the model is automatically reflected in the code, and vice versa]. The main thing, however, is for developers to realize that there is value in using models and modeling tools. The reason there is still a lot of skepticism about this among developers is that, in the past, too much was promised and not enough value delivered.

Soley: There is a scale of modeling maturity you find across development groups. On one end, they are writing Assembly language. On the other, they are using abstract models of systems and generating the code. The good news is that no one is at either extreme. Most development groups are using modeling languages as sketching languages, saying: “This is what I want to build.”

Popkin: The trick [to taking better advantage of UML] is to keep using UML in a stricter and stricter fashion. The more you use it as the language of communication, the more the comfort level goes up, and the more UML becomes part of the software development process.

What role does modeling play in enhancing software security and compliance?

Soley: UML has a lot to say about compliance. We don’t define [the financial and accounting disclosure act] Sarbanes-Oxley, for example. We define business models, which, when followed, allow you to comply with various regulations. Last year, the OMG Regulatory Compliance Alliance (ORCA) began capturing information about regulations, such as Basel II [the worldwide banking initiative] and how to model those regulations. I would love to see governments publish regulations as business rules. We are far from that, but it’s the most fair thing to do for business.

Kobryn: As MDD technologies such as UML mature, we are seeing increased interest in domain specific models for vertical markets, platforms and specialized technology areas, such as software security and regulatory compliance services. An MDD approach can increase the precision with which security and regulatory compliance services are specified; when driven by system requirements, it can also help automate system verification and validation.

Selic: Modeling [relates to compliance and security in that it] allows us to specify and view our software from a perspective that is much closer to the problem domain than traditional programming languages.

Popkin: Whether it’s security—what I want to do—or compliance—proof of what I did—modeling is the means of representation. The security model [for a software application] is like a blueprint for a house. It specifies how your house will stand up, how you get out in case of a fire. For compliance, modeling lets you lay out an architecture that supports regulations, such as [the health-care initiative] HIPAA and the data protection acts of various countries.

Greenfield: Security and compliance is one of the many domains in which models can capture information that would be difficult to express and/or discover effectively using code alone. A lot of the information captured in security/compliance models ends up in XML-based configuration files, rather than code. Models provide a better means of visualizing that configuration information than raw XML editors. If attention is paid to how models are managed, then model files can be reliably versioned, cross referenced and digitally signed.

What drives development teams that haven’t previously used UML tools to adopt them?

Selic: Perhaps the most compelling [driver] is the realization that traditional code-centered methods can no longer cope with the level of complexity of modern software and the reduced tolerance for poor quality. The existence of successful Model Driven Development projects in the same or related domains is often a key motivator—particularly when those projects were realized by competitors.

Popkin: There are a lot of drivers: failure, complexity, compliance, error rates, the size of teams. We have not forced people to do modeling. But [these things] are pointing everyone there very heavily.

Greenfield: Teams that adopt UML tools are usually motivated by the promise of capturing information about logical and technical architecture, deployment and functional and nonfunctional requirements that is difficult or impractical to capture effectively in code. However, they often become disillusioned with UML tools when they discover that the UML notations do not capture that information with enough fidelity to support the generation of useful development artifacts, and that the models do not fit effectively into the software development process.

Soley: Long-term maintenance is the driver for adopting UML. You have to [convey] that competitive advantage to CIOs. That UML models can generate code is important. But it’s secondary, compared with UML’s ability to plan for systems that last for decades. When UML was adopted as a standard in 1997, it wasn’t integrated with the IDEs. That has changed completely. It’s in Eclipse, Borland [tools], Visual Studio. [That helps] convince developers UML is in their self-interest.

Kobryn: The best software developers are always looking for innovative ways to amplify their productivity, but they tend to be pragmatists and skeptics, since software compilers are harsh taskmasters.

I generally recommend that software developers introduce UML and MDD incrementally into their current development process, so that their teams will realize statistically significant productivity gains and error reductions in each increment. This sort of incremental approach that emphasizes improvement metrics can furnish a compelling existence proof to developers and managers who are skeptics.


Share this link: http://www.sdtimes.com/link/29385
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading