What next, now that we have solved all reuse problems?
(WISR 99, Position paper, Austin, Texas, Jan 5-7, 1999)
Martin L. Griss
Hewlett-Packard Laboratories, 1U16
1501 Page Mill Road, Palo Alto, CA 94304-1126
Tel: (650)857-8715, fax: (650)813-3668
We have made tremendous progress in understanding the critical technology, methods, processes, and organizational factors that lead to effective reuse. There is of course much more we can do, but still, far too few software developing organizations see reuse as the solution to the problems they have, nor do they practice reuse systematically. Far too few schools teach much about reuse.
What should we do? Should we continue to develop new and improved reuse techniques as we have been doing? Or should we try to apply reuse ideas to non-software areas, such as knowledge engineering? Or should we try a completely different tack to incorporating reuse techniques into software engineering practice? How should we best provide basic education to new students and continuing education to practitioners? What is our recommended best practice?
Keywords: software engineering, education, technology transfer, reuse best-practice, agents, business components, workflow.
For the last 15 years, I have worked on reuse methods, education and software engineering process improvement at HP. I have gained a lot of experience with software engineering and reuse courses at the University of Utah[kessler97]. I have recently worked on the joint ACM/IEEE software engineering education taskforce and helped develop accreditation guidelines[griss98].
All of this experience has made it painfully clear that too few people understand or practice systematic reuse (or even systematic software engineering!). Feedback on my reuse book[jacobson97] and from the many reuse panels, workshops and tutorials I have given at non-reuse conferences (SD'xx, COMDEX/Enterprise, OOPSLA, ICSE, TOOLS98, ) further confirms this concern.
We have lots of promising technology, methods, and guidelines. As an example, we believe that we have a good understanding of how issues and choices in several areas could influence critical success or failure of reuse:
In fact, we have too many good techniques, and no clear statement of reuse community concensus of what works best.
There is a growing pressure to develop guidelines and policies for software engineering as a profession: ethics, body of knowledge, accreditation guidelines, and model curricula[griss98,tracz98]. SIGSOFT and ACM are participating in various joint IEEE/ACM taskforces on software engineering as a profession. These mention reuse only in passing. The software engineering "body of knowledge" (SWEBOK) [IEEE98], is structuring key software engineering knowledge areas into basic, advanced, and domain-specific. The presidents information technology advisory group (PITAC), advocates the construction of (yet another) national component library, probably focusing once again on the library technology, and not the component certification and design issues[graham98]. We need to provide input to this effort.
As a community, we need to develop a consensus on the "reuse body of knowledge" and clearly articulate and differentiate the "basic", "advanced", and "domain-specific" reuse knowledge areas. This will guide several activities in developing standards and courseware, and provide advice to other national strategy setting bodies. We need to better coordinate our efforts in reuse conferences and workshops (ICSR, WISR, SSR, ), both with our own community of reuse research and practices, and importantly, in contact with other software engineering activities, such as architecture, objects, software engineering, etc. (ISAW, ICSE, OOPSLA, FSE, ).
The following is just a set of ideas on how to address this issue:
I would like to surface this topic at WISR, and lead a discussion to see if we can agree on a direction, and create some enthusiasm to work together on this "technology transfer" program.
3.1 Agents, business components, workflow and reuse
For those who don't want to talk to me about "technology transfer" issues, I have a second area of more technical interest. The last year,I have become involved in architecting, designing and prototyping a distributed, agent-based application management framework, integrating software bus architectures, business components, reusable models and component parts, generation, scripting and workflow.
Experience with this technology suggests to me that some form of workflow language could become a widely used agent-oriented scripting language, used to glue together higher-level business components and autonomous agent components. This could be viewed as a "generic" domain-specific language. There are several approaches to agents[huyn97,FIPA97], to business components[sims94] and to workflow[HP98,sutton98].
A domain analysis of the (common/compatible) features of these three areas, with an eye to integration, would be one useful way to start. This should lead to the specification and design of a "domain-specific kit" for workflow-enabled business agent component applications.
There are now many books on reuse, and a growing number of reuse courses, both at schools and from vendors. However, apart from the DOD Reuse technology roadmap[DOD96], there does not seem to be a community concensus on reuse best practice. No one seems to be addressing this in the context of the new licensing and accreditation context.
There are many approaches to agents[huyn97,FIPA97, jennings98], to business components[sims94, OMG98] and to workflow[HP98,sutton97,wise98]. No one seems to be integrating those together, and certainly not from a reuse perspective.
[bucci98] Bucci, Paolo, and Timothy J. Long and Bruce W. Weide, "Teaching Software Architecture Principles in CS1/CS2", Position Paper, Third International Software Architecture Workshop, Orlando, Nov 1-2, 1998, pp. 9-12. (Seehttp://www.cis.ohio-state.edu/ ).
[DOD96] Reifer, Don, "Reuse Technology Roadmap", Department of Defense, 1996.
[FIPA97] Foundation for Intelligent Physical Agents(FIPA)- FIPA97 Agent Specification. Provides 7 parts. New FIPA98 specification under development).
[graham98] Graham, Susan L., "The Software Recommendations of the U.S. President's Information Technology Advisary Committee (PITAC)", Proceedings of FSE-6: ACM SIGSOFT 6th International Symposium on the Foundations of Software Engineering, Nov 3-5, Orlando, ACM SIGSOFT, 1998. (Seehttp://www.ccic.gov/ac/interim.)
[griss98] Griss, Martin, "Letter from the Executive Committee," Software Engineering Notes, Vol. 23, No. 5, Sept. 1998, pp. 1-2.
[HP98] HP Changengine - an enterprise process flow system. (See http://www.ebizsoftware.hp.com/main1.html).
[huyn98] Huhns,Michael N., and Minidar P. Singh, "Readings in Agents", Morgan-Kaufman, 1998.
[IEEE98] Bourque, Pierre at. al., "Guide to the Software Engineering Body of Knowledge (SWEBOK)", Strawman Version, IEEE Computer Society, September 1998. (Seehttp://www.ieee.org/ ).
[jacobson97] Jacobson, Ivar, and Martin Griss and Patrik Jonsson, "Software Reuse: Architecture, Process and Organization for Business Reuse," Addison-Wesley-Longman, 1997.
[jennings98] Jennings, Nicholas R. and Michael J. Wooldridge, "Agent Technology," Springer, 1998.
[kessler97] Kessler, Robert R.,"CS451-CS453 - Software Engineering Laboratory", Computer Science Department, University of Utah, Salt Lake City, UT, 1997. Seehttp://www.cs.utah.edu/~cs451.
[omg98] Object Management Group, Business Object Domain Task Force (BODTF)(See http://www.omg.org for information on Common Business Objects, and Workflow Management Facility).
[sims94] Sims, Oliver, "Business Objects," McGraw-Hill, London, 1994.
[sutton97] Sutton Jr., Stanley S. and Leon J. Osterweil, "The design of a next generation process programming language," Proceedings of ESAC-6 and FSE-5, Springer Verlag, 1997, pp. 142-158.
[tracz98] Tracz, Will, and Mary Shaw, and Martin Griss, and Don Gotterbarn, "Panel: Views on the State of Texas Licensure of Software Engineers", Proceedings of FSE-6: ACM SIGSOFT 6th International Symposium on the Foundations of Software Engineering, Nov 3-5, Orlando, ACM SIGSOFT, 1998, pp. 203-208.
[wise98] Wise, Alexander, "Little-JIL 1.0 Language Report", Technical Report 98-24, University of Massachusetts at Amherst, Sept. 1998.
Martin L. Griss(email@example.com) HP Laboratories, http://www.hpl.hp.com/reuse.
Martin is a Principal Laboratory Scientist in the Software Technology Laboratory at Hewlett-Packard Laboratories, Palo Alto, California. He has over 30 years of experience in software development, education and research. For the last 16 years at HP, he has researched software engineering processes and systems, systematic software reuse, object-oriented development and software process improvement at HP. He created and led the first HP corporate reuse program and participated in the development and execution of the HP corporate software initiative. He led HP efforts to standardize UML for the OMG, and is a member of the OMG UML revision taskforce. He was previously director of the Software Technology Laboratory at HP Laboratories, and an Associate Professor of Computer Science at the University of Utah.
Martin is co-author of the influential book "Software Reuse: Architecture, Process and Organization for Business Success" (with Ivar Jacobson and Patrik Jonsson), which holistically addresses technology, people and process issues in a UML framework. He writes numerous articles on software engineering and a reuse column for the "Object Magazine/Component Strategies". He lectures widely on systematic reuse and software process improvement. He is a member of the ACM SIGSOFT Executive Committee, and of the joint IEEE/ACM committee on software engineering education and accreditation. He is an adjunct professor at the University of Utah, co-developing component-oriented software engineering courses, and advising on software engineering curriculum design.
An ICSR98 paper with John Favaro and Massimo d'Alessandro shows how the integrated OO reuse strategy developed by Martin Griss and Ivar Jacobson, can be combined with the FODA feature-oriented domain analysis approach, using UML elements and extensions.