wisr98-griss

Reuse 2001-2004

What next, now that we have solved all reuse problems?

Martin L. Griss

Hewlett-Packard Laboratories, 1U16

1501 Page Mill Road, Palo Alto, CA 94304-1126

Tel: (650)857-8715, fax: (650)813-3668

Email: griss@hpl.hp.com

URL: http://www.hpl.hp.com/reuse

Abstract

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.

Workshop Goals:

Understand what is core reuse best practice

Determine how to influence more reuse uptake

Decide on (my) next important research area

Working Groups:

Reuse "accreditation" workshop - education and technology transfer

Integration of OO, architecture, domain engineering

Domain engineering methods for component-based product-lines

Component-based product-line development, feature teams, etc.

Business components and agents

1 Background

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:

Technology - OO; architecture; patterns; components; interfaces; generators; library systems and classification schemes; =85.
Process - domain analysis, CFRP, DFR-DWR, incremental pilots, process, product and reuse metrics; process maturity models; economics
People: distinct create, reuse, manage, support organizations; explicit high-level management leadership; domain- and component- engineering skills; roles

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.

2 Position

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).

3 Approach

The following is just a set of ideas on how to address this issue:

Run a panel, workshop, write a white-paper, create a taskforce, etc. to develop some consensus on strategy.

Compile information on existing reuse courseware, best practice areas, primary resources such as text books, handbooks, guidelines.

Provide a starting "reuse body of knowledge" index and analysis. Use this to provide input to IEEE/ACM SWEBOK, and education taskforces.

Develop a reuse curriculum strategy and find some committed educators and software engineers to refine draft curricula and validate.

Write a book called something like "reuse for dummies", "all you wanted to know about reuse, but were afraid to ask", "reuse made simple", etc.

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.

4 Comparison

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.

References

[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. (See http://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 6^th International Symposium on the Foundations of Software Engineering, Nov 3-5, Orlando, ACM SIGSOFT, 1998. (See http://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. (See http://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. See http://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 6^th 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.

Biography

Martin L. Griss (griss@hpl.hp.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.