Reflexion Models

7/29/2019 Reflexion Models

1/11


2/11

Detines

/reted By

\

Y3=-qInput

O*

Input ProducesSource Extraction SourceCode Tool Model

Figure 1: The Reflexion Model Approach

In essence, a reflexion model summarizes asource model of a software system from the view-point of a particular high-level model. This formof summarization is useful to engineers perform-ing a variety of software engineering tasks. Inone case, an engineer at Microsoft Corporation,prior to performing a reengineering task, appliedreflexion models to help understand the struc-ture of the Excel spreadsheet product. In an-other case, computing a sequence of reflexionmodels highlighted several places where calls be-tween modules violated the layers of the softwarearchitecture that an engineer had perceived toexist.

We have developed several techniques for sim-plifying the engineers task of defining high-levelmodels and mappings. We have also developedtools that compute reflexion models for large sys-tems in a minute or two. As described in Sec-tion 2, these techniques and tools have made itpossible for an engineer, in a few hours, to bet-ter understand a system of several hundreds ofthousands of lines of code.

To clarify the meaning and computation of re-flexion models, we present a formal characteri-zation of a reflexion model system in Section 3.The flexibility of our approach is demonstratedin Section 4 through descriptions of the use of re-

flexion models in a variety of settings. Section 5considers the theoretical and practical perfor-mance aspect of the approach and our tools. InSection 6, we discuss key aspects of the approachthat provide software engineers with the neededflexibility y.

2 AnTo convey

Section 7 considers related work.

Exampleour basic approach, we describe how

a developer with expertise in Unix virtual mem-ory (VM) systems used reflexion models to fa-miliarize himself wit h an unfamiliar implement a-tion, Net BSD. The system is composed of about250,000 lines of C [KR78] source code spread overapproximately 1900 source files.

The developer first specified a model he be-lieved, based on his experience, to be characteris-tic of Unix virtual memory systems. This modelconsists of a modularization of a virtual mem-ory implementation and the calls between thosemodules (Figure 2a).

A calls relation between NetBSD functionswas then computed using the cross-referencedatabase tool (xrefdb) of Field [Rei95], and asmall awk [AKW79] script was written to trans-late the output of Field into our input format.The extracted calls relation consisted of over15,000 tuples over 3,000 source entities.2

Next, the developer defined the following map-ping:

[ file=. *pager. *[ f ile=mn-xnap. *[ f ile=vm_f ault\. c[ dir= [un] fs[ dir=sparc/mem. *[ f ile=pmap. *[ f ile=vm_pageout \. c

mapTo=Pager ]mapTo=VirtAddres sMaint 1mapTo=KernelFaultHdler 1mapTo=FileSystem 1mapTo=Memory 1mapTo=HardwareTrans 1mapTo=VMPolicy 1

Each line in this declarative map associates en-tities in the source model (on the left) with enti-ties in the high-level model (on the right). Theseeming difficulty of defining a mapping giventhe thousands of entities in the NetBSD source

2Each tuple cent ained the name of the calling function,the name of the called function, and the file and directoryinformation for both functions.

19 ,


3/11

,=Memory

HardwareTrans

{b

I,tl II

L

I KemelFaultHdler I

&)agerFileSystemVirtAddressMaint II

\ d+ser /I I

n 0* calls

(a) High-level Model

,,///IIIIIIIIII16IIIIIIIII

uemory.:;0:0. v4

4 I.. (0 ;0 I 16.,l-l

. . . . 1User II

.\ \

\

-\ \IIII

3 ;6IIIII

//,

n Module> Convergence

-- --> Divergence>. . . . . . . . . . Absence

(b) Reflexion Model

Figure 2: High-level and Reflexion Models for the NetBSD Virtual Memory Subsystem

20


4/11

model is mitigated in three ways. First, the engi-neer only named entities in subsystems of inter-est. For example, the mapping above does notconsider entities from the 1/0 subsystem. Sec-ond, the physical (e.g., directory and file) andlogical (e.g., functions and classes) structure ofthe source are used to name many source modelentities in a single line of the mapping. In thiscase, only physical structure is used since C pro-vides little logical structure. Finally, regular ex-pressions are used to obviate the need to enu-merate a large set of structures. For instance,the first line of the mapping states that all func-tions found within files whose name includes thestring pager should be associated with the high-level model entity Pager.

Given these three inputs, a reflexion model wascomputed to compare the source and high-levelmodels (Figure 2b). The solid lines show the con-vergence, where the source model agrees withthe high-level model. For instance, as the de-veloper expected, there were calls found in thesource between functions in modules implement-ing VMPolicy and functions in modules imple-menting Pager. The dashed arrows show thedivergences, where the source model includesarcs not predicted by the high-level model. Forin$tance, the dashed line from FileSystem toPager indicates that functions within modulesmapped to FileSystem make calls to functionswithin modules mapped to Pager. The dottedlines show the absences, where the source modeldoes not include arcs predicted by the high-levelmodel. For instance, no calls were found be-tween modules mapped to Pager and modulesmapped to FileSystem. The number associatedwith each arc in the figure is the number of sourcemodel relation values mapped to the convergenceor divergence; absence arcs are annotated withthe value zero.Computation and display of the reflexion

model shown in Figure 2 takes twenty secondson a DEC 3000/300 with our tools, which con-sist of several small C++ [Str86] programs and auser interface implemented in TCL/TK [OUS94].Computed reflexion models are displayed usingAT&Ts graphviz package. The tools allow theengineer to select arcs in a reflexion model, pro-

ducing displays of the associated source modeltuples. The screen snapshot in Figure 3 includesa window Arc Values that shows the resultof selecting the divergence between FileSystemand Pager. Values in this window show the call-ing and called functions, including their directoryand file information.In a one hour session, the VM developer was

able to iteratively specify, compute and interpretseveral reflexion models. (The source model wasextracted beforehand, and it was not changedduring this session.) Informally, the developerfound the representation of the source code asa reflexion model useful in providing a globaloverview of the structure of the NetBSD im-plement ation. For example, from studying spe-cific divergences, the developer concluded thatthe implement ation of FileSyst em included op-timization that rely on information from pager.This information is useful for planning modifica-tions to either module.

3 Formal CharacterizationTo make precise the meaning and computationof a reflexion model, we present a formal speci-fication of a reflexion model system using the Zspecification language [Spi92].

3.1 Reflexion ModelA static schema in Z describes a state the sys-tem can occupy as well as invariants that mustbe maintained across state transitions. Any sys-tem implementing the reflexion model approachmust maintain the state components and in-variants described in the ReflezionModel schemapresented below.The ReflexioniWodel schema uses two basic

types, HLMENTITY, which represents the typeof a high-level model entity and SMENTITY,which represents the type of a source modelentity. Four type synonyms are also defined:HLMRelation and SiWRelation, which define re-lations over high-level model entities and sourcemodel entities respectively, and HLMTuple andSMTuple, which define the types of tuples in theHLMRelation and SMRelation.

21


5/11

file function dir file function M

Figure 3: The Reflexion Model Tool User Interface

[HLMENTITY, SMENTITYj

HLMReiation == HLMENTITY +-+ HLMENTITYSMRelation == SMENTITY ++ SMENTITYHLMTuple == HLMENTITY x HLMENTITYSMTupie == SMENTITY x SMENTITYreflexionModelconvergence : HLMRelationdivergences : HLMRelationabsences : HLMRelat ionmappedSourceModel : HLMTuple * SMTuple

convergence n divergences = 0divergences n absences = 0convergence n absences = 0dom mappedSourceModel =

convergence U divergences

The variables (above the dividing line) in theschema define the information that must bemaintained by a reflexion model system. Therelation described by the convergence variabledefines where a high-level model agrees witha given source model; the relation described

by the divergences variable describes where asource model differs from a high-level model;and the relation described by the absences vari-able defines where a high-level model differsfrom a source model. The fourth variable,mappedSourceiWodel, defines a relation t hat de-scribes which source model values contribute toa convergent or divergent arc in the reflexionmodel. The information in mappedSourceA40delis used to support operations that aid an engi-neer in interpreting a reflexion model, For ex-ample, the information in mappedSourcehlodel isnecessary to support a query of the form shownin Figure 3.In addition to declaring the state components

of a reflexion model, the static schema includesthe definition of constraints (below the divid-ing line) that must be satisfied by all reflexionmodel systems. The first three constraints statethat the values of the convergence, divergencesand absences relations are disjoint. The fourthconstraint states that the investigation of thesource model values contributing to a reflexionmodel arc is only meaningful for values in the

22


6/11

convergence and divergences relations; absenceshave no contributing source model values.

3.2 Computing a Reflexion ModelThe dynamic schema, ComputeReflexionModel,presented below, describes the computation of areflexion model from three inputs: a high-levelmodel, a source model, and a mapping fromthe source to the high-level model. The high-level model (Mm?) is described as a relation overhigh-level model entities, and the source model(srn?) is described as a relation over source modelentities. The mapping (map?) is an orderedlist of map entries. Each map entrydefinedby the type MapEntrynames zero or moresource model entities and associates with theseentities, one or more high-level model entities.3SMENTITYDESC represents the type of a de-scription naming zero or more source model en-tities (e.g., a regular expression over logical andphysical software structure in our tools).

[SMENTITYDESC]

MapEntry ==SMENTITYDESC X (P HLMENTITY)

- CompuieReflexionModelARejlexionModelhim? : HLMRe!ation~m? ~SMRelataonmap? : seq MapEntrymapFunc : [seq MapEntry x SMENTITY) --+

(P HLMENTITY)rnappedSourceMod el =

(J{t : SMTuple ~ t E sm? q( mapFunc ( map?, jirst t ) xmapFunc ( map?, second t ) ] x

{t]]convergencest =

him? n (dom mappedSourceModel )divergences =

(dom mappedSourceModei) \ him?absences = him? \ (ciom mappedSourceMode l)

3An additional invariant which constrains a map entryto name only high-level model entities specified in hkn?has been elided for presentation purposes.

Computing a reflexion model also requires afunction (mapl+mc) that matches entities fromthe source model to the specified map, producinga set of associated high-level model entities.The value of mappedSourceModel is computed

by pushing the elements of each source modeltuple through the map, resulting in two sets ofhigh-level model entities. The cross-product ofthese sets is taken and each element in the re-sultant set is associated (through another cross-product) with the original source model tuple.Once the mappedSourceModel is computed, thevalues of the convergence, divergences, andabsences relations are easily determined throughset intersection and set difference operations.

3.3 A Family of Reflexion ModelsThis Z specification defines a family of reflex-ion model systems. Different kinds of reflexionmodel systems result depending on the choicesmade for representing the source model entity de-scriptions in a map ( SMENTITYDESC) and fordefining the mapping function (mapl%nc). Ourreflexion model system describes source modelentities using a combination of structural infor-mation and regular expressions. Our tools sup-port the use of two different mapping functions.The most common mapping function used pro-duces the set of high-level model entities associ-ated with the first match of a given source modelentity to an entry in the map. Alternatively, ourtools support the use of a mapping function thatreturns the set of high-level model entities result-ing from the union of all matches found in themap. Our tools can thus be configured to provideimplement at ions oft wo different reflexion modelsystems.

4 ExperienceThe reflexion model approach has been appliedto aid engineers in performing a variety of soft-ware engineering tasks on a number of differentsoftware systems that vary in size and implemen-t ation language.

23


7/11

Reengineering A software engineer at Mi-crosoft Corporation applied reflexion models toassess the structure of the Excel spreadsheetproduct prior to a reengineering activity. TheExcel product consists of over one million linesof C source code, The engineer computed reflex-ion models several times a day over a four weekperiod to investigate the correspondence betweena posited high-level model and a model of almost120,000 calls and global data references extractedfrom the source. A detailed mapping file con-sisting of almost 1000 entries was produced andis being used to guide the extraction of compo-nents from the source. The engineer found theapproach valuable for understanding the struc-t ure of Excel and planning the reengineering ef-fort.

Design Conformance We used a sequence ofreflexion models to compare the layered archi-tectural design of Griswolds program restructur-ing tool [GN95] with a source model consistingof calls between modules. The reflexion modelhighlighted, as divergences, a few cases wheremodules in the source code did not adhere to thelayering principles. We are unaware of any otherapproach that would allow such violations to befound so directly.An industrial partner applied reflexion mod-els to check if a 6,000 line C++ implementation

of a subsystem matched design documentation(in the form of a Booth object diagram [Bo091])prepared prior to implementation. This case wasunique in that the reflexion model was fully con-vergent with the source model.

System Understanding We used reflexionmodels to try to determine why a compiler usedin undergraduate education at the Universityof Washington was difficult for the students tochange. We computed a reflexion model com-paring an extracted Ada file imports relationwith a conventional model of a compiler [PW92].The reflexion model contained meaningful diver-gences between almost all pairs of high-level en-tities. This high degree of coupling explains, inpart, why the students had difficulty changingthe system.

We later applied reflexion models to a newerversion of the compiler, written in C++. Thereflexion models for this compiler were far lesscluttered than the Ada version. However, someunexpected interactions were identified using thereflexion model; these may provide the basis foreither minor restructuring of the compiler or atleast additional warnings to the students.

5 PerformanceEngineers iteratively specify, compute, and in-terpret reflexion models. The rate at which anengineer can interpret and iterate reflexion mod-els is dependent, in part, upon the the speed ofthe computation.The formal characterization presented in Sec-tion 3 provides a basis for considering the

theoretical complexity of computing a reflex-ion model, From the dynamic Z schema,ComputeReflexionModel, we can see that thetime complexity of computing a reflexion modelis dependent upon the cost of computing themappedSourceModel relation and the cost ofcomparing that computed relation to the high-level model. An upper bound, then, on the com-plexity of computing the mappedSourceModel re-lation is given by:

O(#sm x #map x tcomp.rt$on) ~((#~~~)2)where #sm is the cardinality of the source modelrelation, #may is number of entries in the map,tcompa,i.ons the cost of comparing a sourcemodel entity to a source model entity descrip-tion in a map entry, and #him is the cardinalityof the high-level model relation. Since the num-ber of entities in the high-level model is gener-ally small and constant, the 0((#Mm)2) can, inpractice, be ignored, yielding:

O(#sm x #map x tcompartson)

Our initial implementation of tools for com-puting reflexion models performed the compu-tation of a reflexion model in the straightfor-ward manner described by the dynamic schema

24


8/11

in Section 3.2. This implementation was suffi-ciently fast for moderately large systems (withsource models consisting of tens of thousands oftuples) and small maps (tens of lines), but wasnot fast enough to support the iterative compu-tation of reflexion models for larger systems orlarger maps, For example, an early version ofour tools required 40 minutes on a Pentium tocompute a reflexion model for Excel.By trading space for time in the implementa-

tion of our tools, we have been able to supportthe computation of reflexion models for largesoftware systems and large maps in a minute ortwo (see Table 1). Specifically, our tools hashthe mat ch of high-level model entities for a givensource model entity the first time a source modelentity is seen. The additional space requirementsdepend upon the naming scheme used for sourcemodel entities and the number of unique entitiesin the source model. In the case of Excel andthe naming scheme used by our tools, there are18,118 unique source model entities each requir-ing on the order of 100 bytes (less than 2 Mb intot al). Our tools provide a variety of options tolet the engineer determine the appropriate spacetime tradeoff.

6 DiscussionReflexion models permit an engineer to easily ex-plore structural aspects of a large software sys-tem. The goal of the approach is to provide engi-neers with the flexibility to produce, at low-cost,high-level models that are good enough forperforming a particular software engineering t ask(restructuring, reengineering, or porting, etc.).Three aspects of the approach critical to meet-ing this goal are the use of syntactic models, theuse of expressive declarative maps, and supportfor querying a reflexion model.

Syntactic Models As described in the formalcharacterization, reflexion models are computedwithout any knowledge of the intended semanticsof the high-level or the source model. A benefit ofthis syntactic approach is the ability of an engi-neer to use reflexion models to investigate many

different kinds of structural interactions in a soft-ware system (calls, data dependence, or eventinteractions, etc.). It also means, however, thatit is the engineers responsibility to ensure thatit makes sense to compare a selected high-levelmodel wit h an ext ratted source model. For ex-ample, comparing the specified calls diagram ofFigure 2a with an extracted calls relation makessense, but comparing the same high-level modelwith a source model representing the #includestructure of NetBSD would probably be mean-ingless.In practice, engineers have exploited this flex-

ibility by changing the meaning of their mod-els over time. For example, both the VM de-veloper and the Microsoft engineer first useda calls source model and later augmented thesource models with static dependence of func-tion definitions on global data. By adding staticdependence, both developers implicitly shiftedtheir high-level model from a calls diagram to acommunicates-with diagram. In both cases, thechanges were driven by the need to understand,for the task being performed, additional aspectsof the system structure.To aid the engineer in interpreting reflexion

models computed wit h models cent aining differ-ent kinds of information, we are adding supportfor typing relations in both source and high-levelmodels.

Maps The declarative maps used in comput-ing a reflexion model enable an engineer to focuson information of interest in the source in twoways. First, an engineer may specify a partialmap that cent ains entries for only those parts ofthe system relevant to the task at hand. Second,an engineer may iteratively refine a map to theappropriate e level of detail necessary for the taskbeing performed.Generally, an initial reflexion model is cOrn-

puted with a rough and partial map. Then,based on an investigation of the reflexion model,an engineer refines the map in the areas of in-terest until the necessary information about thesystem is obtained. Sometimes, as was the casewhen we applied reflexion models to assess thestructure of the compiler implemented in Ada, a

25


9/11

System Language Approx. Source Mapping High-Level SPARC 20/50 486 PCLines of Model Model 100 MHzCode (Thples) (Lines) (Entities) (min:sec) (min:sec)

Uw c++ 3,700 607 33 5 :00.5 :01compilerUw Ada 4,200 72 9 5 :00.2 :01compilerRestructuring CLOS 47,000 5,855 215 9 :04.3 :06ToolNetBSD c 250,000 15,657 7 8 :04.0 :19(VM)Excel c 1,200,000 119,637 971 15 2:13.0 4:05

Table 1: Performance of Reflexion Model Tools

fairly rough map was sufficient. In contrast, inthe case of Excel, a detailed map was desired toplan reengineering activities.The reflexion model approach enables an en-

gineer to balance the cost of refining the mapwit h the level of detail necessary for performinga particular software engineering task. We planto track the use of some declarative maps acrossthe evolution of several systems to determine thedegree of sensitivity of our mapping language tochanges made in the source. This will aid an en-gineer in judging the amortization costs of cre-ating detailed maps for large systems,Querying Reflexion Models Reflexion mod-els bridge the gap between an engineers high-Ievel model and a model of the source. Theconvergence, divergences, and absences summa-rize selected interactions in the source, whilethe mappedSourceModel captures t he connec-tions between the high-level and source modelarcs. Based on the summary information, theengineer intersperses two kinds of queries to in-terpret a reflexion model for a specific softwareengineering task.In the first kind of query, an engineer investi-

gates the source model values contributing to aconvergence or divergence. In the second kind,an engineer performs queries to determine thesource model entities and values that were notincluded in the reflexion model. This query en-ables an engineer to assess whether the map issufficiently complete and to investigate whether

26

absences in the computed reflexion model are theresult of incompleteness in the map.Based on the results of the interpretation, an

engineer may either decide to refine one or moreof the inputs, computing a subsequent reflexionmodel, or else may decide that sufficient informa-tion has been obtained to proceed with the over-all task. To better support an engineer in the in-terpretation process, we are currently developingtechniques to improve the querying and investi-gation of a series of computed reflexion models.

7 Related WorkReverse Engineering The reverse engineer-ing approaches closest to ours use clustering in-formation, which is generally culled from a com-bination of human input and numerical com-putation, to create abstract representations forthe engineer, Examples of this approach includeRigi [MK89] and Schwankes statistically-basedarchitectural recovery technique [Sch91].Reflexion models differ in a number of ways.

First, in our approach the engineer specifies thehigh-level entities explicitly, whereas the archi-tectural recovery systems instead infer them.Second, we focus on comparing high-level andsource models, rather than on discovering high-level models. Third, our mappings are declara-tive, associating source and high-level entities, incontrast to approaches such as Rigi, which usesoperational mappings.


10/11

Rigi differs from our approach by enabling anengineer to build explicit hierarchical models ofthe software structure of a system. We insteadsupport the investigation of substructure (i.e.,a subsystem) by computing different reflexionmodels at various levels of abstraction.

Model Comparison Ossher has consideredthe comparison of relational models of softwarestructure for a fixed type of high-level model, aGRID [0ss84]. The intent of a GRID descriptionof a system is to specify, represent, documentand enforce the structure of large, layered sys-tems [0ss87, pg. 219]. The GRID mechanismpermits an engineer to choose a concise descrip-tion of the software structure and then to anno-tate how the actual structure of the system de-viates from the description. Our approach is notintended to specify or enforce a desired structureof the system, but rather to compare two modelsof the structure using an explicit mapping be-t ween the two models provided by the engineer.

Jacksons Aspect system [Jac93] comparespartial program specifications (high-level mod-els) to data flow models extracted from thesource to detect bugs in the source code thatcannot be detected using static type checking.Aspect uses dependence between data stores asa model of the behavior of a system and as-sumes that this model is correct, focusing on howthe source model differs from the posited behav-ior. In contrast, we focus on high-level structuralmodels, and we are interested in both how thesource model differs from the high-level modeland also how the high-level model differs fromthe source.

Jackson has also developed a semantic differ-ence approach for comparing the differences ininput and output behavior between two versionsof a procedure [J L94]. This approach derivesan approximate model of the semantic effect ofa procedure consisting of a binary relation thatsummarizes the dependence of variables after ex-ecuting the procedure upon the value of variablesat the entry to the procedure. The semanticdifferencing tool compares the binary relationsresulting from different versions of a procedure.We focus on the comparison of relations at differ-

ent levels of abstraction through an explicit anddeclarative mapping.

8 SummaryA reflexion model summarizes information ex-tracted from source code into a high-level modelthat is sufficiently accurate to support an engi-neer in performing a software engineering task.The engineer defines three inputs to a reflexionmodel computation: a high-level model, a sourcemodel, and a map. The refiexion model presentsthe summary information in the context of thehigh-level model defined by the engineer. Theengineer interprets and iteratively computes suc-cessive reflexion models until satisfied. The fea-sibility and flexibility of the approach have beendemonstrated through its application in a num-ber of different settings on systems ranging fromseveral thousand to over one million lines of code.

AcknowledgmentsRobert Allen, Kingsum Chow, David Garlan,Bill Griswold, Michael Jackson, Kurt Partridge,Bob Schwanke, and Michael VanHilst each pro-vided helpful comments on earlier drafts ofthe paper. Conversations with Daniel Jacksonhelped clarify a number of aspects of our work.An anonymous Microsoft engineer applied reflex-ion models to Excel. Dylan McNamee was ourVM developer. Pok Wong applied reflexion mod-els as part of a design conformance task. StephenNorth of AT&T provided the graphviz graph dis-play and editing package. We also thank theanonymous refereesments.

for their constructive com-

References[AKW79]

[Bo091]

A.V. Aho, B.W. Kernighan, and P.J.Weinberger. Awk A Pattern Scan-ning and Processing Language. SoftwarePractice and Experience, 9(4):267-280,1979.G. Booth. Object-oriented Designwith Applications. Benjamin-Cummings,1991.

27


11/11

[GN95]

[Jac93]

[JL94]

[KR78]

[MK89]

[0ss84]

[0ss87]

[OUS94]

[PW92]

[Rei95]

[Sch91]

[Smi84]

W.G. Griswold and D. Notkin. Architec-tural Tradeoffs for a Meaning-PreservingProgram Restructuring Tool. IEEETransactions on Soflware Engineering,21(4):275-287, April 1995.D. Jackson. Abstract Analysis with As-pect. In Proceedings of the 1993 Inter-national Symposium on Software Testingand Analysis, pages 1927, 1993.D. Jackson and D.A. Ladd. SemanticDiff A Tool For Summarizing the Ef-fects of Modifications. In Proceedings ofthe International Conference on SoftwareMaintenance, September 1994.B. Kernighan and D. Ritchie. The C Pro-gramming Language. Prentice Hall, 1978.H.A. Muller and K. Klashinsky. A Sys-tem for Programming-in-the-large. InProceedings of the 10th InternationalConference on Software Engineering,pages 8086. IEEE Computer SocietyPress, April 1989.H .L. Ossher, A New Program StructuringMechanism Based on Layered Graphs.PhD thesis, Stanford University, Decem-ber 1984.H, Ossher. A Mechanism for Speci-fying the Structure of Large, LayeredSystems. In Bruce Shriver and Pe-ter Wegner, editors, Research Directionsin Object-Oriented Programming, pages219-252. MIT Press, 1987.J.K. Ousterhout. TCL @ the TX Toollcat.Addison-Wesley, 1994.D.E. Perry and A. Wolf. Founda-tions for the Study of Software Architec-ture. ACM Sofiware Engineering Notes,17(4):40-52, October 1992.S.P. Reiss. The Field Programming En-vironment: A Friendly Integrated Envi-ronment for Learning and Development.Kluwer Academic Publishers, 1995.R. Schwanke. An Intelligent Tool for Re-engineering Software Modularity. In Pro-ceedings of the 13th International Con-ference on Software Engineering, pages83-92, May 1991.B.C. Smith. Reflection and Semanticsin LISP. In Proceedings of the 1984

ACM Principles of Programming Lan-guages Conference, pages 23-35. ACM,December 1984,

[Spi92] J.M. Spivey. The Z Notation. PrenticeHall, second edition edition, 1992.

[Str86] B. Stroustrup. C++ Programming Lan-guage. Addison-Wesley, 1986.

[WTMS95] K. Wong, S.R. Tilley, H.A. Miiller, andM.D. Storey. Structural Redocumenta-tion: A Case Study. IEEE Software,12(1):46-54, January 1995.

28

Reflexion Models

Documents

Transcript of Reflexion Models