Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.

- Archives - 2004-06-13 2004-06-20 2004-06-27 2004-08-29 2004-09-05 2004-09-12 2004-09-19 2004-10-10 2004-10-24 2004-11-07 2004-11-28 2004-12-05 2004-12-12 2004-12-26 2005-01-30 2005-02-06 2005-03-06 2005-03-13 2005-03-20 2005-04-03 2005-04-10 2005-04-17 2005-04-24 2005-05-01 2005-05-08 2005-05-15 2005-05-29 2005-06-05 2005-06-12 2005-06-19 2005-06-26 2005-07-10 2005-07-17 2005-07-31 2005-08-28 2005-10-09 2005-10-16 2005-10-23 2005-11-13 2005-11-27 2005-12-04 2005-12-18 2006-01-08 2006-02-05 2006-02-12 2006-02-19 2006-03-05 2006-03-12 2006-03-26 2006-04-23 2006-04-30 2006-07-16 2006-07-30 2006-08-06 2006-09-03 2006-10-08 2006-10-22 2006-10-29 2006-11-26 2006-12-10 2007-01-28 2007-02-04 2007-02-11 2007-03-11 2007-03-25 2007-04-08 2007-06-03 2007-06-10 2007-06-17 2007-07-01 2007-07-08 2007-08-19 2007-09-30 2007-10-07 2007-10-21 2007-11-04 2007-11-11 2007-11-18 2007-11-25 2008-01-27 2008-02-03 2008-02-10 2008-02-17 2008-02-24 2008-03-09 2008-04-06 2008-05-18 2008-05-25 2008-06-01 2008-06-08 2008-07-13 2008-08-10 2008-08-24 2008-08-31 2008-09-07 2008-10-05 2008-12-28 2009-05-10 2010-04-25


Blog Feed

Recent Items
 
Automated Authentication of Programming Standards?...
 
The Important Software Standards: Quality, Perform...
 
Virtual Classrooms Model Social/Collaborative Soft...
 
Microsoft Cracks Open the Word, Excel, and PowerPo...
 
A Litany of Lists: Creatiing Secure Applications
 
As Complex as Necessary and no More.
 
The Same Old Mistakes, Over and Over Again
 
Sorting the Mail: Agile Databases, Vulnerable Appl...
 
SSH and Known_Hosts Vulnerabilities Threaten Grid
 
Service Research: Focusing on Requirements for Tec...

  

visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
 
Millennia Antica: The Kiln Sitter's Diary
 
nfoWorks: Pursuing Harmony
 
Numbering Peano
 
Orcmid's Lair
 
Orcmid's Live Hideout
 
Prof. von Clueless in the Blunder Dome
 
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
 
DMA: The Document Management Alliance
 
DMware: Document Management Interoperability Exchange
 
Millennia Antica Pottery
 
The Miser Project
 
nfoCentrale: the Anchor Site
 
nfoWare: Information Processing Technology
 
nfoWorks: Tools for Document Interoperability
 
NuovoDoc: Design for Document System Interoperability
 
ODMA Interoperability Exchange
 
Orcmid's Lair
 
TROST: Open-System Trustworthiness

 

Rigorous Software Engineering at the Application-Domain Integration Level

ACM News Service: Microsoft Research Aims to Ease Development.  Early in my experience with Grace Hopper, I recall a presentation on the introduction of programming languages into IT operations.  She told of the following simple way that she found to overcome the “real programmers don’t Flowmatic” (or Cobol) syndrome:

• Find some bright kid in computer operations that wants to get into development and turn them loose with the manual and the compiler.
• As expected, the bright kid (the same ones we recruited whenever they showed up among the maintenance and operations folk) would quickly become quite productive, producing small useful programs that were seen to be needed.
• The new performer was promoted into a programming position and continued to be rewarded for the high productivity.
• Other programmers are forbidden to use the new tool.

This came back to me when I noticed that the chosen venue for exploring and proving out the ideas for Rigorous Software Engineering is the new Microsoft Research India center in Bangalore. 

John Ribeiro’s 2005-06-13 ITworld.com article expands on a number of key ideas:

• There is little or no narration of the work [courtesy of Jon Udell] that is done in software, and that creates difficulties for integrators (among others) who need to dig into the code to arrange for its integration into a larger system.
• The institutional memory of software designs and architectural decisions need to be preserved some other way.
• Rigorous Software Engineering is proposed for taking the level of abstraction of the programming closer to the application domain, so this becomes the level of modification and maintenance, using code-generation techniques to move from that level down to lower levels where the software is expressed to the computer.
• I always wonder how this sort of thing is tested and debugged.  The MSR-India researcher said they intend to create tools that “provide visibility into the system and the way it is functioning at various levels of abstraction.”  That sounds like a valuable way to make sure the higher-level expression has been compiled in a way that preserves essential application behavior.

This is not unlike the Model-Driven Architecture (MDA) view, at a high-altitude of comparison.  I find this appealing, although I wonder whether the rigorous codification of design rules from near-application solution space to platform-specific solution space will be too demanding.  I don’t know. I am curious about that and about how performance factors enter into consideration. 

I do look forward to schemes of this kind for what they show us is involved in near-application modeling as well as reconciliation of problem space and solution space in ways where our clients may be able to check whether we’re building and integrating what they expect.

 

¶ posted by orcmid at 6/20/2005 12:02:00 AM

  <$BlogBacklinkTitle$>  

<$BlogBacklinkSnippet$>
posted by <$BlogBacklinkAuthor$> at <$BlogBacklinkDateTime$>