s Let Architectural Reuse Guide Component Reuse A Pattern for ReUse

  • 格式:pdf
  • 大小:60.92 KB
  • 文档页数:18

Copyright © 1996 Software Architects. All rights reserved.1

~ S o f t w a

r e

~Mod

e

ReneR

ealize

~

A r c h i t

e

c t

s

~

Let Architectural ReuseGuide Component Reuse: APattern for ReUse

John D. McGregor1Clemson University

Jim DobleNortel

Asha KeddyClemson University

ProblemThere is a need for techniques that facilitate the (re)use of existing architectures, designsand code as the basis for developing new applications. Despite many efforts, the reuse of codehas been largely limited to a few areas such as the ubiquitous data structures and mature domainssuch as graphical user interfaces (GUI). Techniques such as faceted classification[10] have beenproposed to solve one of the critical obstacles to reuse, locating the code segments that will bereused.

Reuse of individual pieces of code by individual developers is neither an efficient, nor is it often asuccessful, means of reuse[9]. Reuse should begin earlier in the life cycle where the conceptual“chunks” are larger and the potential leverage from reuse is greater. However, the earlier in thedevelopment process reuse begins, the more difficult it is to relate a specific point in the design tothe individual code segments needed to implement that design because the more abstract nature ofthe early models makes them difficult to directly associate with the very precise nature of asegment of code.

Krueger[8] states that “for a software reuse technique to be effective, it must reduce the cognitivedistance between the initial concept of a system and its final executable implementation.” In thispaper we will present an approach to reuse that reduces this cognitive distance by providing aspecific path from the earlier to later phases of the life cycle. The approach blends architecture,patterns and code repositories through the unifying theme of a framework.

ContextWe are organizing a software development community for the effective production ofapplications. The organization being established is a long term investment with a continuing

1. Direct correspondence to John D. McGregor, Dept. of Computer Science, Clemson University, Clemson,SC 29634-1906, johnmc@cs.clemson.edu.Copyright © 1996 Software Architects. All rights reserved.2

~ S o f t w a

r e

~Mod

e

ReneR

ealize

~

A r c h i t

e

c t

s

~

mission to produce software systems in support of the overall goals of the corporation. We intendto create a development process and culture that facilitates the reuse of architecture, designconcepts and code.

ForcesReuse of any artifact is predicated on the assumption that the artifact satisfies some need inthe development process.

Reuse happens within the context of a specific need. Reuse of individual components of any type(See Definitions Side-bar) occurs within the context provided by an individual developerattempting to satisfy a very specific architectural, design or implementation requirement. Largescale reuse of small, independent code-level components is difficult to achieve in isolationbecause the effort required to identify components and verify that they satisfy the current needincreases as the scope becomes larger[4].

The success of collecting a large number of individual components contributes to thedifficulty of locating and extracting the piece that we would like to use.

Another of Krueger’s reuse requirements[8] is that you must be able to find the componentquicker than you can build it. The larger the set of components the more time consuming thisprocess becomes. As the repository becomes larger, there will be more occurrences of overlaps incomponent specifications making the choice of which component to select more difficult.

New and/or inexperienced designers need guidance in creating designs based on reusablecomponents. Reuse is more likely to occur if the design being implemented is a standardapproach to a known problem.

It is not enough simply to present the designer with a user’s guide of reusable components. Thedesigner needs to understand any architectural concepts which underlie the reusable components.There should be pedagogical support to assist a developer in becoming familiar with a set ofcomponents. This support should relate the components to standard tactics for solving knownarchitectural, design and implementation problems. The often quoted psychological study inwhich chess masters were able to recall more about arrangements of game pieces when the pieceswere arranged according to a standard strategy than when they were randomly arranged supportsthe idea that standard patterns can be used to facilitate the selection of components for (re)use.