LOGIN | REGISTER NOW | SUBSCRIBE
 
 
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
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

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

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

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


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

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

Modeling Is Key to Software Success


Behavioral and structural views make for better code, claims evangelist Douglass

By P. J. Connolly
February 1, 2007 — 
Modeling an application is more than just creating a flow chart. Model Driven Architecture (MDA) is a scheme in which fundamental concepts are abstracted away from incidental methods, for easier understanding and, hopefully, process improvement. As Telelogic chief evangelist Bruce Powel Douglass noted, “The key principle behind MDA is the separation of the essential characteristics from the things that change.”

Douglass, a former co-chair of Object Management Group’s Real-Time Analysis and Design Working Group and the author of several books on developing real-time systems using modeling techniques, has recently been espousing the benefits of C programming in a graphical way. Telelogic in early January released Modeler, a free, entry-level modeling environment that can be used to create embedded systems.

Douglass explained that “[models] improve your ability to visualize characteristics of your system. In 5 million lines of source code, where are your threads? Who creates them, who destroys them, where do they run, when do they run? What are the resources the threads share and how are they managed?”

The advantage, as Douglass put it, is that “I can visualize things better; I can more easily see what’s going on.” This doesn’t always make the customer happy, he conceded. “A lot of people have found that once they can see the architecture of the system, they say, ‘What was I thinking?’” Communication, consistency and provability are the obvious byproducts of a model-driven development culture, according to Douglass.

He likened the development of an application to the construction of a building, arguing, “I don’t have one picture with every detail of that building on it. I have blueprints that emphasize structural members; I have blueprints that emphasize water conduits, electrical management, heating management, different views that support different questions.” Class diagrams, sequence diagrams and state machines can be seen as analogous to the electrical, HVAC and plumbing diagrams of a physical structure.

“What we’ve done in [our] graphical C environment,” Douglass noted, “is we’ve identified eight functional, or operational, views. First is the use case diagram—that’s a way of representing requirements…and clustering requirements into usable, coherent units.

“Then,” he continued, “there’s a set of [four] structural views. A build diagram basically shows the things you’re going to construct. For example, you’ll have a database, you’ll have some DLLs, an executable, and you want to represent the set of these built things that you’re going to wire together in the actual application, which might be distributed across processors, or threads, maybe all running in one thread.

“A call graph shows how I’m going to have these things called functions and provides a sequence in which it can call other functions, as well as things that get passed as variables, as parameters, amongst those things. [It] represents a sequenced set of function calls for your system,” Douglass explained.

“Another one is the file diagram,” he said, which represents .c and .h files, and their features, including “the functions, the types and the variables they contain. Well, I can represent those with boxes showing one compartment for the variables, one compartment for the functions and one for the types. I can show how they relate to other [files], in terms of ‘Do they have a header-include, or is it a source-include?’ I can show whatever the level of detail I need on a file diagram.

“The last of the structural views,” Douglass continued, “is, of course, source code. It’s always available to me, and if I need to look at it, I can go there.”

Douglass went on to outline three behavioral views of software. “Message diagrams basically show messages among these file elements, as they invoke services and pass data. These invocations can either be synchronous, as in just a regular call, or they can be asynchronous, in terms of I’m sending an event, which is queued and processed. So, I can represent both those kinds of ‘thread rendezvous,’ if you will.”

He continued, “A state diagram, I can take for a file as a combination of functions, types and variables. What a state diagram does is, it says in what order can those services be invoked. [For example,] I might not want to take an aircraft on an approach vector unless my landing gear is down. I can enforce certain preconditions in a state machine.”

Last, Douglass said, “we have flow charts, which represent algorithms. In UML, we have something similar, called an ‘activity diagram,’ which is like a flow chart on steroids.”

Although some code jockeys will always scoff at the use of modeling, he observed, everyone has a limit to the amount of source code that they can sight-read. “No matter how smart you are, there’s a system too complicated for you to grasp,” he noted.


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

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading