Domain Engineering and Reuse
(Expanded version of column, to appear, IEEE Computer, Roundtable on Components and Reuse, May, 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
The notion of components has certainly caught on. No longer do we simply talk about object libraries. Instead, we have discussions about COM, COM+, CORBA, JavaBeans, and EJBs. And UML has become a pervasive software blueprinting language with many vendors providing tools support-even Microsoft provides a component-oriented subset in the form of Visual Modeler. Larger-grain components, in the form of business objects or business components, are being seriously defined by OMG and others. So components and scripting-or business components and scripting-are becoming the standard by which large-scale enterprise development will be judged. All these technologies, taken together, could radically change the way people do reuse, even though none is revolutionary by itself.
COMMONALITY, VARIABILITY AND FLEXIBILITY
I now believe that agents combined with a workflow language will be the next step in increased flexibility and reuse . Just as JavaBeans have grown into enterprise JavaBeans, so business components will incorporate the notion of agents, providing specific interfaces and using services that enhance their autonomy and robustness. Furthermore, in order for collaborations of business components to provide well-understood support for business processes, they will interact according to a local and global workflow. Thus, to choreograph these collaborations explicitly and flexibly, workflow languages will become the next generation of scripting languages. Also, we've come to realize that you can't simply take random things and reuse them in a context for which they weren't designed. And you can't just design something to make it reusable all by itself. You have to think about how a group of components will fit together, how they will collaborate, and how these components may be individually variable , or variant members of a component family.
Domain engineering is about looking for commonality and variability. Express it somehow and then take advantage of it when you build the components. The work Ivar Jacobson and I did on reuse was to add some extensions to all UML elements that we call variation points, which can be thought of as a generalization of extension points or "hot spots" that allow you to state that some models are variable without saying how they vary. This is key to using UML for the domain analysis of families of systems, right from the usecase and architectural level.
There is clearly a rich stream of technology innovation, such as enhancements to Java, Web tools, and generators. Then there is aspect-oriented programming, new pattern and modeling tools, and so on. Yet success with large-scale reuse is not just technology; architecture and standards are a social process. The decision to reuse rather then invent from scratch involves culture, education, management, and professional incentives. Many companies have a rather short-term silver-bullet view that limits investment in architecture, component development, domain engineering, and reuse. To change behavior like that, there must be some kind of publicized success that shows it really works and that it pays off. There are successes, but I don't think we publicize them well enough. You don't pick up an issue of Computer every month and see a discussion of the latest and the greatest success. Another element is reducing the cost of entry. By having good components available to cover more of the space you don't have time to fill yourself, you can do all the up-front architecting and domain engineering pretty easily. Many people believe that it's an all or nothing thing. Either you do it properly with domain engineering or you don't bother. But that's not true. You can get incremental benefit for incremental investments. More companies seem to be realizing that they can make domain-specific components according to one or another standards. But things are still very complex. I think, though, that we are able to follow a two-tier strategy . That is, our technology allows some fairly sophisticated components to be written (e,g, business agents) and used with much less sophistication (e.g., scripting) . I'm working on a paper now that is about moving from components and scripts to agents and workflow-in other words more competent components, a richer framework, and a more stylized scripting language.
[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).
[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.
[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.
[wise98] Wise, Alexander, "Little-JIL 1.0 Language Report", Technical Report 98-24, University of Massachusetts at Amherst, Sept. 1998.
Martin L. Griss(firstname.lastname@example.org) 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.