TEAM Zarate Tarrani Notes From the Field

Opening note: If you've been following the UCITA dicsussion that Linda and I started in our 27 January entry, I just added more information in today's entry in Postcards from the Revolution.

My adventures in Aspect-Oriented Software Development (AOSD), or more specifically, learning about AOSD, have given me a basic understanding of the method, and has led me to some interesting information that is scattered about the web.

What is it and why should you care? The heart of the method is separation of concerns. In other words, AOSD recognizes that those who have requirements, those who elicit and document the requirements, and those who write specifications have concerns that are often uniquely different for each stakeholder or role player. Of course, developers have their own set of concerns. From my still new view of AOSD (I only discovered it existed a few days ago) the method synthesizes the different concerns (aspects).

What is remarkable, though, is the influence that AOSD appears to have over a number of projects. For example, it has been adapted to components, which is evidenced by the Aspect-oriented Component Engineering page that is maintained by Dr John Grundy at the University of Auckland, NZ. It is also embraced by Concurrent Programming Research Group at the Illinois Institute of Technology, and has influenced a number of projects at USC's Information Science Institute. Some specific projects that employ or reference AOSD include:

• WebScripter - a tool that enables users to easily and quickly assemble reports extracting and fusing information from multiple, heterogeneous Web sources that use DARPA Agent Markup Language (DAML).
• SIM-TBASSCO - Semantic Interoperability Measures: Template-Based Assurance of Semantic Interoperability in Software Composition (from where do they get these names?). SIM-TBASSCO helps software developers engage in guided, efficient searches and evaluations of the set of alternative system implementations that can be built with the components available to them. It will let developers evaluate components' functional and data equivalence compatibility, find pertinent data conversion mappings, and predict performance (time, space, network) of a component architecture under specific usage situations and hardware/networking environments.
• Information Agent Research - intelligent techniques that enable heterogeneous information integration to be simple, powerful, and efficient.

These projects have two things in common: (1) a connection to AOSD, and interesting implications for knowledge and/or information management on an ambitious scale. That aside, the reason these projects were cited is because I was led to them as I drilled down into AOSD references.

It doesn't end there, however. My quest also took me to Xerox's PARC, where I found a paper titled Why are Black Boxes so Hard to Reuse?, subtitled Toward a New Model of Abstraction in the Engineering of Software. This paper was a part of the Open Implementation Group, which appears to have started the AOSD movement in the first place. I may be wrong about that, but it does appear to be the case.

I'm still researching AOSD and will share any interesting tidbits in future entries.

Shifting gears: a site with the improbable name, Coyote Valley Software, has valuable tools (Product Life Cycle, Software Requirements and design specification templates), and models (Satir Change Model and Requirements Mind Map) that are valuable and indicative of Brian Lawrence's generosity. Mr. Lawrence has had this site up since 1998 and his helpful spirit and willingness to freely share has greatly influenced me.

I've been corresponding with Manisha Saboo about software quality for months. Manisha has graciously given her time to assist another friend, Tanya Vinta who is pursuing certification as Certified Software Quality Engineer. Tanya and I first met on a project that started in Bethesda, MD and migrated to Kansas City. The following documents are for Manisha, Tanya and anyone else who is serious about quality:

• Defect Prevention
• Defect Root Cause Analysis
• Life Cycle Testing
• SQC Peer Reviews (this is a ZIP archive that contains a document titled SQC Peer Reviews in PDF format, and MS Word files that support peer reviews (procedure, templates and forms).

I also have a document titled Component Scalability that architects and developers involved with component-based software engineering will find useful.

Tomorrrow's entry will address architecture, refactoring and design patterns. I also have two open source Oracle tools to share. Until then it's goodnight from Tustin, California.