News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

Software modeling finds new support on business side




May 1, 2009 — 
Model-driven development is touted by experts as a best practice for creating software that best executes on an organization’s strategies. Developers, by contrast, don’t like model-driven development. Why the disconnect?

“It’s really complicated, and not everyone has the desire or time to learn it,” said Mike Munger, senior manager of component technology development at InfoPrint, a joint venture between IBM’s printing systems division and hardware manufacturer Ricoh. “And the tools are very expensive.”

That’s one cause, but it’s not the whole story, of course. There are deeper issues at work here. Meanwhile, new avenues are emerging into organizations that are discovering the benefits of modeling for service-oriented architectures, business processes and—paradoxically—agile practices.

Munger explained that much of InfoPrint’s development time is spent maintaining and updating IBM’s legacy code, adding that he believes developers in organizations everywhere are spending more time on this type of work than on kicking off new development projects. As such, he said, “there’s no real point” in doing UML modeling, where code can be generated from the model. “I’ve only seen that once, and it worked fine, but they still had to fill in [the code].”

According to Munger, modeling “is really good for getting all the players to understand their roles and what data they will be getting and passing around. The model ties it all together on one piece of paper.” He said his group uses data flows, state diagrams and hierarchies, but then put that aside and code by hand. “We use a lot of the same principles and practices [as UML], but in a graphics drawing program.”

Where new development is concerned, Munger said modeling’s value “is undisputed.” And, where existing products are being combined (as would happen after a merger), or if significantly large extensions were being written to existing applications, he called modeling important. “We just don’t have the big, overarching projects,” he said.

Munger’s point that UML’s inherent complexity limits its use to what he called “a small handful of people” was echoed by Dan Hebda, vice president of technology at Mega International, a company that sells modeling software.

“We’re heavily involved in standards. We’d rush to do them,” Hebda said. “But then we said, ‘Wait. Let’s talk to the market. Are you using UML? If not, do you plan to?’ We found that 95 to 98% of the people we talked to were not using UML 2 or intending to.”

Hebda said Mega was pushing UML for a time, but he admitted, “We didn’t get a strong reaction.” So the company found a new route: modeling for contextual development. “We’re staying out of full development, but we see a need for architectural modeling to give context for what’s being developed. We’re pushing that as a form of bridging.” The company’s UML core is Use Case, Class and Sequence diagrams, which he said was unchanged from UML 1x to 2.

A shift in thinking
Andrew Watson of the Object Management Group, which oversees the UML specification, said that model-driven development “is shifting from the idea of development to the ability to capture an organization’s key knowledge assets in a form [machine-readable] that can reused.”

Watson said modeling benefits organizations that don’t want to lose those knowledge assets by having them manually translated into code. With modeling tools, you can generate applications that can live for five or 10 years or more, he pointed out. “Of course, they will change, but only at about 10% per year. The advantage [to using models] is that you won’t have to start all over when rolling out a new platform.”

He said organizations that toss out their COBOL applications for newer ones based on more current languages, without first creating models of those systems, run the risk of tossing out the knowledge of how their processes work.

Mega’s focus is on enterprise architecture, which involves modeling the organizations and the processes and systems within it. “There’s enormous value to say, 'I need a system here for this purpose.' You can use that to drive requirements in the context of the architecture in place, and then go further with detailed requirements and use cases, to see what impact those systems will have on the overall enterprise,” Hebda explained.

Enterprise architecture also opens the door to service-based development and agile practices, according to Neil Patterson, a systems product manager in IBM’s Rational division. He acknowledged it is “often the case” that developers don’t want to use UML modeling on their projects, but said, “Architects and development managers have a longer-term focus about the software being developed, the projects the software is going into and especially reuse.”

IBM offers a variety of modeling tools, such as System Architect for enterprise architecture modeling; Rhapsody and Tau (acquired with the purchase of Telelogic) for embedded systems and system architecture modeling; and the Rational line of application modelers.

Patterson went on to acknowledge that “in these times, reaching out to the people who own the money is very important with a model-driven development story. They understand very well the future of the business relies on being able to move quickly to react to market conditions and to look ahead” at new business opportunities.

As for approaching developers, Patterson said the idea is to keep them working in the way they want. Coining a concept IBM calls “model-code associativity,” it wants to let developers continue to work with code, but what programmers contribute is then modeled in a standard way.

“It’s capability beyond round-trip engineering that respects how developers want to code. That approach is paying off with developers buying in,” Patterson said. “They’re working in a paradigm they’re used to.”

Modeling in a services world
Development paradigms are changing. Fewer organizations are doing monolithic, waterfall-style development, instead moving more toward application composition using iterative or agile processes, and often picking up pieces of applications or services that weren’t created by that organization.

“SOA technology grabbed hold,” Mega’s Hebda said. “People went out and got ESBs [enterprise service buses] and now wonder what do they do with it. We say, ‘Design your business first. Then see where the candidates for decomposition are, so you can swap pieces out in context.’ ”

Mega created System Blueprint, which incorporates business processes that provide context for software utilization. Using the “Interaction Scenario Diagrams”—essentially Sequence diagrams at the services level—System Blueprint provides a place where development managers and the business-side can analyze proposed software designs against requirements to assess the impact on the business. Hebda said risk management organizations are increasingly implementing business process models to help in the audit process.

Watson and Patterson also insist there’s a role for modeling in development shops doing composite development.

“The cloud is an interesting phenomenon, but the same rules apply,” Watson said. “You’re using encapsulated services with well-defined interfaces. It’s vital [that] the services are precisely described. You’ve got to have accurate, machine-readable metadata so [the resultant application] is compatible with expectations.”

Patterson said IBM also has seen an uptake in modeling for composite applications, but “more in terms of planning around how [a development team] will evolve a set of applications, the differentiation for each platform. Software product line development is starting to pull modeling into their story.” There is some difficulty in going from requirements to code, when some requirements are common to all the organization’s software and others are specific to applications and platforms.

Modeling, he explained, allows organizations to simulate software to see if what’s being developed makes sense in the context of what is needed. “Modeling allows [organizations] to drive that home more quickly,” he said. “You can visualize it, then plug and play” the components to determine the overall impact.

Be specific
The use of domain-specific languages can help organizations provide context. Domain-specific languages combined with UML can help development shops create profiles particular to their industry; health care organizations can undertake safety-critical initiatives, for example.

“Domain specifics make the modeling environment well-understood by the domain experts, and that can then be driven down to the code level,” IBM’s Patterson explained, saying that organizations are looking for more domain-specific advances, “rather than another level of generality” in UML itself.

Mega’s Hebda agreed that the context provided by domain specifics enables better requirements to be written “before you spend a dime on actual development.”

Watson said OMG is seeing interest from business users in modeling processes, rules and organizational structure, then automating the generation of glue code that ties services together into applications that work to achieve business goals. “It’s what BPM people call 'choreography code,' ” he noted.

Model-driven development is finding a new set of supporters on the business side, Watson said. “Businesses are creating models of business processes and business rules written in modeling languages tailored to that task. Business people don’t want to talk about how their requirements get turned into software. They model their process and, in a short time, have an application to execute the process. They don’t care how it’s done.”

Of course, developers do. Watson opined that there is a “rearguard action” from developers every time you raise the level of abstraction. “People say, ‘I can write better code than what comes out of a model,’ but business users are getting impatient with the slow speed of development and the high cost.”

Watson said software development has been in this loop before. Early programmers, he said, had to hand-optimize code. Then assemblers came along, which made code easier to write, but some tricks for optimization were lost along the way. Then high-level languages came along, and machine optimizations made obsolete all that came before.

“Certainly, if you pull code apart, you could make it more efficient,” he said. “But it takes days to do tiny optimizations. The focus should be on solving end-user problems, and efficiency should take care of itself.”


Related Search Term(s): model-driven development


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading