Developing Frameworks by Aligning Requirements, Design, and Code

 

Greg Butler

Department of Computer Science

Concordia University

Montreal, Quebec, H3G 1M8 Canada

Tel: (514) 848-3031

Tel: (514) 848-3000

Fax: (514) 848-2830

Email: gregb@cs.concordia.ca

URL: http://www.cs.concordia.ca/~faculty/gregb/home.html

 

Abstract

Object-oriented frameworks offer a concrete reusable architecture for a family of applications. Methodologies for the development of a framework have been suggested that use domain analysis, software evolution, and design patterns. However, identifying the required flexibility for the family of applications and designing mechanisms that provide this flexibility is the problem. Furthermore, the evolution of the framework must be considered, especially as all frameworks seem to mature from initial versions through to a stable platform.

This position paper looks at application frameworks and how they should be developed. We are developing a framework for database and knowledge-based systems, called Know-It-All, and attempting to align (1) a use case model of requirements including variation points; (2) an architectural design including hotspots; (3) an overlapping of roles from design patterns onto the hotspots; and (4) the classes, hooks, and templates in the code.

For framework evolution, we will attempt to extend our ideas on design deltas [B-WISR7].

Recent results at ICSR'5 suggest we may need to include at least a feature model from a domain analysis to the above methodology.

Keywords: Reuse, design, framework, design pattern, architecture

Workshop Goals: Learning; networking; understanding

Working Groups: reuse and product lines; object technology, architectures and domain analysis; domain engineering tools

 

1 Background

Butler is interested in constructing frameworks for scientific knowledge-based systems, and the software aspects of developing, documenting, and reusing them. His background in computer algebra systems [B89-92] convinced him that a more flexible environment, using a single language, C++, is needed to research the issues of software architectures and their integration for computer algebra systems. Recently, applications in the field of bioinformatics have taken the place of computer algebra as the motivation for the development of the framework for scientific knowledge-based systems. Since moving to Concordia University at the end of 1991, Butler's research has focussed on C++ libraries and frameworks, issues of reuse, and issues of reliability (which includes correctness).

In the past six years Butler has been actively leading a discussion group at Concordia on object-oriented design that concentrates on design patterns, UML, software architectures, and frameworks. He also teaches a course on object-oriented design based on OMT [RBPEL91] that also includes material on reuse. In Winter 1996 the course used the ET++ framework [Lew+95, Ch. 7,] as a source of design examples.

On the research side there is ongoing work on

Know-It-All framework

for databases and knowledge-bases is being designed and constructed by PhD student Lugang Xu, building on past student projects that provided object-oriented designs for deductive databases, object comprehension query language, and the Mantra knowledge-based system;

use of design patterns

for development and documenting software (especially frameworks) is the focus of several student projects, and the discussion group on object-oriented design;

development and understanding frameworks

is being studied by PhD student, Pierre Dénommée, who is focusing on software visualization, documentation, and analysis techniques for the understanding of frameworks, and together with Lugang Xu looking at distilling a development methodology for frameworks from the experience of constructing Know-It-All.

 

2 Position

Developing a framework should not be viewed as a single task, since it is not the development of a single software system. There are two dimensions to the space of systems encompassed by framework development: the first dimension is the usual one for product lines of the family of applications within the domain of the framework; the second dimension is the maturity level of the framework itself  [RJ98] as it evolves from white-box to black-box to plug-and-play to application generator.

At each stage of maturity, the way that a framework is applied for the development of an application is different, and demands different documentation in order to make the job of the application developer easy.

Perhaps, at each stage of maturity, there are different issues to be considered when evolving the framework, but our experience with frameworks over their entire life-cycle is rather limited, and it is too early to draw conclusions.

A framework is often cited as an example of the reuse of requirements, architecture, design, and code, yet most of the literature on framework development highlights design and architecture. We want to address that omission and at the same time emphasise traceability between the software artefacts.

 

3 Related Work

The classic iterative, incremental approach of the OO evangalists see  [RJ98] is bottom-up and considers one application at a time.

Step 1: Build first application

Step 2: Iterate

Step 2.1 Change impact analysis for n-th application

Step 2.2 Refactor existing framework to accommodate changes

Step 2.3 Build n-th application

Domain analysis approach is a top-down approach that considers the development of all applications in the family.

Step 1: Domain analysis

Step 2: Develop domain specific software architecture (DSSA)

Step 3: Implement DSSA

Step 4: Populate DSSA as applications required

Of course, hybrid top-down and bottom-up approaches are possible, where one considers the development of a few applications at once and performs a partial domain analysis.

Step 1: Interleave

Step 1.1 Partial domain analysis

Step 1.2 Change impact analysis and refactoring

Step 1.3 Build n-th application

The method of generalization of hotspots, see Schmid's article [CACM97] traces the variability in the requirements (the so-called hotspots) to abstract classes in the design: one abstract class per hotspot. There is a variation of this by Demeyer et al [CACM97] that introduces a separate abstract class for each dimension of variability of the hotspot.

Step 1: Identify hotspots

Step 2: Classify variability required for each hotspot by selecting from meta-patterns of Pree

Step 3: Associate a subsystem with each hotspot

Step 3.1 select a design pattern for subsystem

Step 3.2 subsystem generalizes abstract class/facade

A quite rigorous development procedure for frameworks is part of the RSEB [JGJ97]. It builds on the features from the Catalysis methodology of d'Souza in UML and also stresses traceability. The method is extended in [GFA98] to include a feature model, as in the FODA domain analysis method.

John McGregor and his colleagues have developed a method called use case assortment for the requirements analysis phase of framework development. The use case model is refactored (similarly to the refactoring of a class hierarchy) so that variation points or hotspots are explicitly identified as abstract use cases. So the commonality/variability analysis is therefore explicit in the use case model.

A good start into the work on use cases and traceability throughout the life-cycle is  [LS96], even though it is not specific to frameworks.

 

4 Proposed Methodology

The methodology we propose to follow is a hybrid top-down and bottom-up approach. A partial domain analysis will identify commonality and variability among the family of applications and be captured in a feature model. The feature model will guide the development of the use case model for the first application by indicating potential variation points. If necessary, we will refactor the use case model, so that each variation point is an abstract use case. Variation points in the requirements will be mapped to hotspots in the design. The variability of each hotspot along each of its dimensions of variability will be classified. Each hotspot will map to a subsystem in the design, represented by one abstract facade class that is an aggregate of abstract (parameter) classes, one per dimension of variability.

Each parameter class will be assigned a role in a design pattern that is appropriate for the required flexibility in the design. Perhaps this will be followed by the standard step from role-based OOSE of overlaying some of these roles onto a single class, hence refactoring the design. However, this may cloud traceability.

We propose to model scenarios in the requirements phase in synch with the use case model. The interaction diagram of a scenario may help identify appropriate template and hook methods in the class behaviours that are variable across the family of applications. These will then be mapped to methods in the class interfaces. The class designs will be reviewed to check for narrow specialization interfaces, or a graded set of specialization interfaces (as was so successfully done in ET++).

Evolution of the framework will try to coordinate refactoring of the use case model, with the refactoring of the design.

 

References

[CACM97] Special Issue on Object-Oriented Application Frameworks, CACM, October, 1997.

[ACM98] Symposium on Object-Oriented Application Frameworks, Special Issue, ACM Computing Surveys 1998 to appear.

[B89-92] G. Butler and J.J. Cannon, Cayley, version 4: the user language. Lecture Notes in Computer Science 358, Springer-Verlag, Berlin, 1989, pp. 456-466. G. Butler, S.S. Iyer, E.A. O'Brien, A database of groups of prime-power order, Software -- Practice and Experience 24, 10 (October 1994) 911-951. G. Butler and S.S. Iyer, An experimental knowledge base of simple groups, Australian Journal of Intelligent Information Processing Systems 2, 1 (1995) 11-23.

[B-WISR7] G. Butler, Design deltas in reusable object-oriented design, Proc. 7th Workshop on Software Reuse (WISR'7), St Charles, Illinois, August 26--30, 1995.

[B-WISR8] G. Butler and P. Dénommée, Documenting frameworks, Proc. 8th Workshop on Software Reuse (WISR'8), Columbus, Ohio, March 1997.

[BD98] G. Butler and P. Dénommée, Documenting frameworks to assist application developers, Object-Oriented Application Frameworks, M. Fayad, D. Schmidt, and R. Johnson (eds), John Wiley and Sons, New York, 1998.

[FSJ98] M. Fayad, D. Schmidt, and R. Johnson (eds), Object-Oriented Application Frameworks, 2 volumes, John Wiley and Sons, New York, 1998.

[GFA98] M. Griss, J. Favaro, M. d'Alessandro, Integrating feature modeling with the RSEB, ICSR'5, IEEE Computer Society, 1998.

[JGJ97] I. Jacobson, M. Griss, P. Jonsson, Software Reuse: Architecture, Process and Organization for Business Success, Addison-Wesley, 1997.

[Lew+95] Ted Lewis et al, Object-Oriented Application Frameworks, Manning Publications, Greenwich, CT, 1995.

[LS96] M. Lindvall and K. Sandahl, Practical implications of traceability, Software - Practice & Experience. 26,10 (1996) 1161-1180.

[RJ98] Don Roberts and Ralph Johnson, Patterns for evolving frameworks, Pattern Languages of Program Design 3, Addison-Wesley, 1998.

[RBPEL91]J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenson, Object-Oriented Modelling and Design, Prentice Hall, 1991.

 

 

Biography

Gregory Butler is Associate Professor in Computer Science at Concordia University, Montreal, Canada. His research interests are reusable object-oriented design, software architectures, C++ libraries and frameworks for knowledge-based systems with applications in bioinformatics. He obtained his PhD from the University of Sydney in 1980 for work on computational group theory. He spent 1976/77 at ETH, Zürich as part of his doctoral studies, and for two years, 1979-1981, was a postdoctoral fellow at McGill and Concordia Universities in Montreal. He was on the faculty of the Department of Computer Science at the University of Sydney from 1981 to 1990. He has held visiting positions at the University of Delaware, Universität Bayreuth and Universität Karlsruhe.