Using Refactoring Techniques to Exploit Variability in Conceptual Modeling Jan Verelst Dept. of Management Information Systems University Of Antwerp
[email protected]
Abstract The term variability refers to the possibility of building different correct conceptual models for a given set of requirements in a given modeling language (for example, UML or the Entity Relationship model). We call each model a variant of the others. In previous work, we presented a framework identifying 3 different types of variability. These 3 types of differences have been shown to be present even under restrictive conditions; or in other words, these 3 types can occur in almost any modeling effort. Moreover, controlled experiments have shown that some of these types of variability affect quality characteristics such as the evolvability of the conceptual model. This suggests that a developer has to choose the variant with the most appropriate quality characteristics. However, changes in the environment of the information system over time can make other variants more appropriate. This paper focuses on the question whether a developer can still switch to another variant later in the system life cycle. This would allow him to use the quality benefits of the different variants at different points in time. Our results show the applicability of refactoring for these purposes and demonstrate the promising practical relevance of the variability framework.
1
Introduction
The term variability refers to the possibility of building different, correct conceptual models for a given set of requirements in a certain modeling language. We discuss variability in the context of modeling languages such as UML class models and Entity Relationship (ER) models. So examples of variability can be found when it is possible to build different, correct UML class models for a given set of requirements. We call these different, correct models variants of each other. Models built in different modeling languages (for example, a UML class model and an ER model) are not considered examples of variability in this research. In an industrial setting, it is quite clear that there is
Bart Du Bois and Serge Demeyer Lab On ReEngineering University Of Antwerp {bart.dubois,serge.demeyer}@ua.ac.be
a high probability that different developers will build different conceptual models for a system. Possible explanations include that they interpret requirements differently, use synonyms for certain concepts or that they add different assumptions or details to different parts of the conceptual model. The existence of variability in this context is without question. However, we have been investigating if variability still exists in a more controlled, restrictive setting, where different interpretations and other factors such as model layout are ruled out. Our conclusion so far is that variability is inherent to conceptual modeling and can occur in almost every modeling effort [Verelst, 2004b]. Next, we investigated whether the variants have differences in qualities such as readability, evolvability and others. Numerous claims to that effect can be found in literature. Additionally, we also provided empirical evidence of effects on evolvability [Verelst, 2004a]. However, whether variability can be exploited by easily switching between variants over time currently remains unclear. If switching is relatively trivial, modelers have the option of switching to another variant at a point in the future in order to exploit quality differences, i.e. if other changes in the requirements occur than was expected, the modeler can switch to a variant with the most appropriate evolvability characteristics. In this paper, we investigate to which extent known refactoring techniques can be used to switch from a chosen variant to another one. We illustrate the feasibility of using refactorings to exploit variability in conceptual modeling by a) identifying representative couples of variants for the three types of variability; b) illustrating a refactoring strategy between the identified variants; c) determining limitations for the application of the transformation; and finally d) generalizing a refactoring strategy. This paper is organized as follows. In section 2, the existence and nature of variability is introduced and categorized using the framework from [Verelst, 2004b]. Section 3 introduces the subject of refactoring. Variants for each of the three variability types and associated refactoring strategies are illustrated in section 4. Finally, we interpret the results of our study in section 5.
2
Existence of Variability
classes or entities. The framework therefore suggests that these types of variability can occur under severe restrictions, i.e. with written requirements so simple that different interpretations are ruled out as a source of variability, as well as synonyms, differences in detail and so on. The existence of variability under these restrictions suggests that it is possible in virtually every modeling effort to generate variants.
At the moment, literature reports minimum two different schools of thought on the existence of variability. First, some authors recommend building conceptual models based on heuristics, the simplest of which is “model nouns as objects; verbs as associations” (see, for example, Jacobson et al. [Jacobson et al., 1992]). This view of modeling is rather deterministic; it describes conceptual modeling as an almost mechanical translation process. Many authors disapprove of this view [Shanks et al., 1993, Batory, 1995, Parsons and Wand, 1997, Florijn and van Oosterom, 1996, Lubars et al., 1992]. This view of conceptual modeling certainly does not emphasize the existence of variability. Second, other authors in the fields of database design and object orientation (OO) explicitly recognize that variability does exist and in some cases, provide examples [Batini et al., 1992, Moody and Shanks, 1994, Simsion and Shanks, 1993, Simsion, 1994, Fischer et al., 1995]. Researchers in cognitive psychology go even further and take the view that conceptual modeling is an ill-structured design problem [Vitalari and Dickson, 1983]. Characteristics of ill-structured design problems are that there is merely an incomplete and ambiguous specification of the problem; there is no deterministic path to a solution; there are no clear criteria to compare and evaluate possible solutions and multiple correct solutions are possible [Chatel and Detienne, 1996]. In this view, the existence of variability is recognized very explicitly. It is actually even one of the core features of the modeling process. However, none of the research mentioned above provides a systematic overview of the types of variability, i.e., which differences actually exist between the possible variants. Recently, [Verelst, 2004b] proposed a non-exhaustive framework of three types of variability, based on a literature survey and empirical evidence. The framework is applicable to OO conceptual modeling, as well as ER modeling and others. It is aimed at variability in the initial identification of objects or entities in the requirements. The three types of variability are:
3
Refactoring
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure [Fowler, 1999]. The key idea is to redistribute classes, variables and methods in order to facilitate future adaptations and extensions [Mens et al., 2002]. To do so, a battery of behavior preserving transformations are cataloged, which define the steps of source code alterations that are applied numerously in most maintenance activities. Examples are extracting methods, moving methods across class hierarchies, replacing conditionals with polymorphism and the like. Research on refactoring started in the early nineties, in the context of application frameworks [Opdyke and Johnson, 1993]. First contributions introduced a set of primitive transformations which can be composed in higher order refactorings [Griswold, 1991, Opdyke, 1992]. Further investigations were targeted towards restructuring of class hierarchies [Casais, 1992, Moore, 1996], and tool support [Roberts et al., 1997]. Arguably one of the major milestones in the lifetime of refactoring is the advent of eXtreme Programming [Beck, 2000], which introduced refactoring as one of the key principles of an agile development process. For further references to refactoring, we direct the interested reader to [Philipps and Rumpe, 2001, Mens et al., 2002]. Refactorings have been demonstrated to be valuable for the introduction of design patterns [Kerievesky, 2004] and aspects [Tourw´e et al., 2004]. These higher level goals provide the necessary guidelines by which to apply refactorings. In this work, we demonstrate that variants within the conceptual model variability framework can steer the application of refactorings. The relevance of qualitative differences between these variants is strongly dependent on the ability to easily switch between these variants in late stages of development or maintenance. More specifically, when switching between variants is only feasible by redevelopment from scratch, the qualitative benefits of the target variant might not outweigh the associated costs. Therefore, it is interesting to investigate whether switching is more easy for some variability types than for others.
• Construct variability: Different constructs of the modeling notation are used to represent the concepts, but the semantics of the concepts are identical • Horizontal abstraction variability: Concepts are modeled using different properties • Vertical abstraction variability: Concepts are modeled in a more abstract/generic or concrete way Horizontal and vertical variability are quite fundamental: they are linked with a core activity of conceptual modeling, i.e. the translation of concepts in the real-world into 2
4
Refactoring between variants
height to derive the correct value. We consider the difference between a calculation and an attribute to be predominantly at design level. At the analysis level, the semantic definition of the surface (including the formula how it is calculated) is in both models the same.
In this section, we discuss three types of variability. We will provide examples of each and illustrate the feasibility of using refactoring techniques to switch between variants. Our research has shown that it is far from evident to classify occurrences of variability in a systematic manner. However, we claim three types of variability are sufficiently well definable to have theoretical and practical value. The variability framework and its limitations are discussed in more detail in [Verelst, 2004b]. To describe the framework, we describe the real world (or Universe of Discourse-UoD) as consisting of ”concepts” having certain ”properties”.
4.1 4.1.1
Rectangle -width: int -height: int -surface: int +Rectangle(int,int)
Figure 2. Example of variability between the modeling of a concept as an attribute (variant A) or as a method-construct (variant B).
Construct variability Even though the differences between the variants described above are limited, literature contains claims that they affect evolvability of the conceptual model. For example, Batini et al. [Batini et al., 1992] claim that an entity should be preferred over an attribute if it is likely that the concept in the UoD that is modeled will have additional properties in the future. This claim suggests that it is useful to be able to switch between these 2 variants.
Definition
Construct variability refers to the possibility of modeling concepts in the UoD using different constructs in the modeling language. The semantics of the concept, however, are the same in all variants. 4.1.2
Rectangle -width: int -height: int +Rectangle(int,int) -calcSurface(): int
Illustration
There are many types of construct variability. Some concepts in a UoD can be represented by a class or entity, a relationship, an attribute, or even an instance. In Figure 1, a typical illustration of construct variability within OO analysis and design is depicted. The concept of the price of a book can be both modeled as a class (variant A), having a single attribute amount, or as a plain attribute of type integer (variant B). The semantic definition of the price and the book are completely identical in both variants, but different language constructs are used to represent it. Book -price: Price +Book(Price)
Price -amount: int +Price(int)
4.1.3
Refactoring strategy
We will describe a common strategy for refactoring between the variants in both illustrations of construct variability: Refactoring a class to a set of attributes. This operation is commonly known as the Inline Class refactoring [Fowler, 1999]. In the example illustrated in Figure 1, the attribute of type Price in class Book is replaced by the set of attributes contained in the Price class (amount). When the Price class would contain methods these would also be moved to the Book class.
Book -price: int +Book(int)
Refactoring a redundant attribute to a method. A redundant attribute can be calculated from other information sources. Therefore, the attribute initialization most likely consist of a formula of which the interpretation results in the correct value of the attribute. Moreover, the initialization or update of this attribute should only be applied using this formula. Therefore, when this formula is extracted to a method, calls to this method can replace former accesses to the redundant attribute. As a result, the redundant attribute will no longer be referenced, and can therefore safely be removed.
Figure 1. Variability of modeling concept price as a class-construct (variant A) or as an attribute-construct (variant B).
A second example is less straightforward. Similar to normalization of database definitions, class definitions can be normalized by removing all redundant data elements. Figure 2 provides a before-after view on such a normalization. In variant A, the concept of the surface of a rectangle is modeled as an attribute. In variant B, the concept surface is modeled as a method, which multiplies the width with the
Summarizing, these representative examples demonstrate that refactoring between construct variants is feasible. 3
Moreover, the effort required to switch between the variants is limited to the application of a very limited number of small refactorings. 4.1.4
Discount
4.2.1
Amount
Figure 4. Variant B: Generic model
Action
Discount
change, in a variety of situations”. IEEE defines genericity as ”the degree to which a system or component performs a broad range of functions” [IEEE, 1994]. Abstraction is defined as ”a view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information” [IEEE, 1994]. These definitions are applicable to the variants of the discount concept: in variant C, the concept discount is valid in a wider range of situations than in variants A and B, because it is also applicable to a.o. relative amounts. The literature on the above domains contains numerous claims of evolvability advantages (for example, see [Garlan and Perry, 1995, Fayad and Schmidt, 1997, Schmid, 1997, Codenie et al., 1997, Helm, 1995] and [Cline, 1996]). In [Verelst, 2004a], the claims with respect to vertical abstraction variability are verified using controlled experiments. Results indicate that some changes can be applied faster to abstract/generic models, but less correctly than to more concrete models. Correctness disadvantages of abstract models are consistent with the results of [Larsen and Naumann, 1992]. Again, this makes it interesting to be able to switch between variants to exploit the evolvability advantages.
Figures 3, 4 and 5 illustrate 3 model variants of a discount concept that cannot be interpreted as merely examples of construct variability, because the definitions of the concept discount are not the same in the 3 models. In variant A, a discount is defined as an amount that will be deducted from every invoice total. Amount
Figure 3. Variant A: Concrete model In variant B, a discount is defined as an amount that will be deducted from invoice totals when certain actions are performed (e.g. a purchase). In variant C, the discount is defined as an absolute or relative amount that can be deducted from invoice totals of persons fulfilling certain roles when certain actions are performed. Parnas [Parnas, 1979] defines genericity as: ”software can be considered ’general’ if it can be used, without is
used
by
Kao
and
Relative Amount
Figure 5. Variant C: Very generic model
Illustration
1 Similar terminology [Kao and Archer, 1997]
Amount
Role
Definition
amounts to
amounts to applies to
Vertical abstraction variability
Discount
Absolute Amount
is assigned to
Vertical abstraction variability1 refers to the possibility of modeling concepts in the UoD in a more or less generic/abstract way. 4.2.2
amounts to
Action
Limitations
Based on these examples and confirmed by our extensive experience with refactoring [Demeyer et al., 2000, Tichelaar et al., 2000, Demeyer et al., 2002, Du Bois and Mens, 2003, Du Bois, 2004], we are convinced that it is unlikely that hard obstacles for refactoring between construct variants will be found. Moreover, this type of variability is exploited in the shift from OO analysis to design. This has familiarized software engineers with this type of variability. Such familiarity of applying changes is one of the key requirements for the specification and implementation of refactorings. Therefore, we expect that construct variability is already being exploited in current refactoring activities.
4.2
is assigned to
4.2.3
Refactoring strategy
We differentiate between transforming to a less or a more generic variant: Transforming to a more generic variant. Let us describe the switch from an implementation from variant A to variant C. Such a transformation would introduce the possibility of differentiating discounts w.r.t. the actions in which they are provided, the way they are cal-
Archer
4
culated, etc. Switching to variant C thus requires the implementation of the concepts action and role and the specialization of amount into an absolute and a relative amount. This can be categorized as forward engineering, and would make use of refactorings in limited activities only.
case for the property eye color, which is the secondary dimension. The instances of red colored creatures and brown colored creatures are dispersed over both humans and animals.
Human
Summarizing, our analysis leads to the following conclusion. Transformations exploiting vertical abstraction variability either consist of removing redundant program elements, or forward engineering to implement new concepts and specialized behavior. Assumably, refactoring is only required in the former, in order to ensure that the preconditions for safe removal are satisfied. 4.2.4
4.3.1
*
has has has as tailcolor
Animal *
Limitations
Definition
1 Eye color
1
Color
1
1 Red-eyed creature
Illustration
Brown-eyed creature
We use the UoD provided by [Schmid, 1983]: There are 2 kinds of creatures: humans and animals. Humans live at a certain location. Animals have a certain tail color. Both have a certain eye color. Two variants can be distinguished, according to what we call their primary dimension. Like in vertical abstraction variability, the concepts in the UoD are modeled using different semantic definitions. In this case, it is not a matter of different levels of genericity. Here, the concepts are modeled based on different properties. In Figure 6, we see that the type of creature (human or animal) is visible in the model; therefore we call type of creature the primary dimension of variant A. It is typical for the primary dimension to be visible in the model. When modeling type of creature as a primary dimension (variant A), its instances are categorized either in humans or in animals. That means that the primary dimension exhibits localization: all instances of humans are grouped into one entity type. This is not the terminology [Kao and Archer, 1997]
Location
In Figure 7, variant B has eye color as its visible, localized, primary dimension. Type of creature is not directly visible; it is the secondary dimension. Instances of type of creature are categorized in the entity types red-eyed creatures and brown-eyed creatures. Therefore, it is delocalized.
Horizontal abstraction variability
2 Similar
1
Figure 6. Variant A: Type of creature as primary dimension
Horizontal abstraction variability2 refers to the possibility of modeling concepts in the UoD based on different properties. 4.3.2
lives at
*
The precondition that there is no usage of the superfluous genericity when refactoring to a less generic variant is true by default. Therefore, this precondition does not pose a limitation on the exploitation of vertical abstraction variability. Moreover, such exploitation already has found its applications in the simplification of over-engineered designs.
4.3
*
is
used
by
Kao
and
*
lives at
lives at * has as * tail color 1 has as * tail color 1
Location 1
Color
Figure 7. Variant B: Eye color as primary dimension
In variant AB, both dimensions are visible and localized; therefore we consider the dimensions equivalent. Also for horizontal abstraction variability, the literature contains claims that it affects evolvability. [Schmid, 1983], for example, claims that the delocalization typical for the secondary dimension, will imply evolvability disadvantages. 4.3.3
Refactoring strategy
In the illustration, the primary dimension could be varied from type of creature in variant A (Figure 6) to eye color in variant B (Figure 7). Such a transformation can take place
Archer
5
Color 1 has tail color * Animal
Brown-eyed animal
introduce redundancy, as for example, clients using an instance of a red-eyed human should be able to infer that its eye color is red. Moreover, supertypes of these specialized types will have to be introduced, as to indicate the relationship between the specialized types of the equivalent dimension, and the entity types of the primary dimension of variant B.
Location 1 lives at * Human
Red-eyed animal
Brown-eyed human
Brown-eyed creature
Red-eyed human
After these steps, the implementation of variant A will be transformed into an implementation of variant AB, as depicted in Figure 8.
Red-eyed creature
Creature
*
Eye color
Refactoring to a primary dimension. This operation is the inverse of the previously described refactoring. Subclasses in variant AB will be generalized to the entity types of the primary dimension of variant B (red-eyed creatures, brown-eyed creatures). Therefore, clients will again have to be adjusted as to create instances of these primary dimension entity types only. As a result, the former entity types of the primary dimension of variant A can be safely removed.
Figure 8. Variant AB: Equivalent dimensions type of creatures and eye color.
in two major phases. In a first phase, variant A can be transformed to a variant AB, which models both dimensions as equivalent. The associated model is represented in Figure 8. In the second phase, variant AB is transformed to variant B, thereby promoting dimension eye color as the primary dimension.
Moreover, a mechanism to verify whether a creature is a human or an animal has to be introduced. In the example, one can make use of the implicit relationship between humans and locations (only humans have a location), or one can simply introduce a type-variable. Therefore, refactoring an implementation of a variant with equivalent dimensions to a variant will require more effort than the previous phase when there are many relationships or constraints which become implicit in the resulting model.
Refactoring to equivalent dimensions. When transforming from variant A to variant AB, the entity types of variant A will be specialized for each entity type of variant B. Concretely, humans will be specialized to red-eyed and brown-eyed humans, and the same specialization will take place for animals. Therefore, when variant A has m=2 entity types in its primary dimension, and variant B has n=2, then variant AB will consist of n × m=4 specialized entity types.
As demonstrated, refactoring from an implementation of variant A to variant B can make use of an intermediate implementation of a variant AB with equivalent dimensions.
Refactoring from an implementation of variant A to variant AB will therefore consist of the following steps:
4.3.4
Limitations
Constraints for refactoring between horizontal abstraction variants are mostly pragmatical. The number of changes to be applied for refactoring between the variants is dependent on the number of entity types in the primary dimensions of both variants, and the extent to which these types are used. Therefore, it can be expected that certain threshold can be exceeded, above which the costs of refactoring do not trade off against its benefits. Further research is required to estimate the effort required for applying such a refactoring strategy. This effort can then be used as a measure for comparing the distance between two variants, and therefore, to decide whether refactoring between them is cost-effective.
• Introduce subclasses for each class representing an entity of the primary dimension (human or animal in Figure 6): red-eyed humans, red-eyed animals, brown-eyed humans and brown-eyed animals. These subtypes will represent the combinations of the related entity types of the primary dimensions of variants A and B. • Push down the data and behavior of the entity types of the primary dimension to these subclasses. Creation of instances of the entity types of the former primary dimension (humans or animals) will have to specialized as well. This will 6
5
Interpretation of Results
The different normal forms provide means to switch to a more appropriate variant. In schema evolution, the investigation of schema changes has led to the identification of OO database refactorings [Delgado et al., 2003]. Therefore, we are confident that the practical relevance of the proposed framework is not limited to OO modeling.
Table 1 summarizes the results from this study. We have recognized that construct variability is already exploited in current refactoring activities. Regarding vertical abstraction variants, we have identified a precondition for refactoring to a less generic variant, and demonstrated that transforming to a more generic variant requires forward engineering. Type of variability Construct Vertical Abstraction Horizontal Abstraction
6
Refactoring strategy Well-known basic refactorings Safe redundancy removal or forward engineering Specialization and generalization refactorings
Acknowledgments
This work has been sponsored by the Belgian National Fund for Scientific Research (FWO) under grants ’Foundations of Software Evolution’ and ’A Formal Foundation for Software Refactoring’. Other sponsoring was provided by the European Science Foundation by means of the project ’Research Links to Explore and Advances Software Evolution (RELEASE)’.
Table 1. Summary of refactoring strategies for the three types of variability.
References [Batini et al., 1992] Batini, C., Ceri, S., and Navathe, S. (1992). Conceptual database design: an entityrelationship approach. Benjamin/Cummings.
Currently, switching between horizontal abstraction variants seems to be the most challenging. Our illustrations demonstrate that for this type of variability, estimating both the effort for refactoring between variants as well as the resulting benefit regarding relevant external quality characteristics is essential. Further investigations in the economical aspects of exploiting horizontal variability should among others provide insight as to how return on investment estimation models can be composed within this context. Moreover, an evaluation of the contribution of refactorings to these external quality characteristics is required, as well as methods for verifying behavior-preservation by code transformations. As current refactoring research has identified these requirements as part of its primary goals [Mens et al., 2002], we are confident that a natural symbiosis between the domains of variability and refactoring will take place. This work provides a modest first contribution. We have confidence in the reliability of using refactoring to exploit variability for the following reasons. First, while we presented toy examples, these are representative for each of the three types of variability, and shed light on the specific issues on refactoring between the variants. Moreover, our extensive experience with refactoring confirms the feasibility of the application of refactorings as described in this work. Finally, the existence of construct and vertical abstraction variability and the application of transformations between them is already recognized in software evolution practice and research [Fowler, 1999, Kerievsky, 2002]. Moreover, while we focused on the exploitation of variability in OO modeling, at least data modelling supports this concept too. In the domain of databases, however, this concept is accepted as one of the key aspects of database design.
[Batory, 1995] Batory, D. (1995). On the relationship of adage and design patterns. Technical report. [Beck, 2000] Beck, K. (2000). Extreme Programming Explained: Embrace Change. Addison Wesley. [Casais, 1992] Casais, E. (1992). An incremental class reorganization approach. In Madsen, O. L., editor, Proc. ECOOP ’92, volume 615 of Lecture Notes in Computer Science. Springer-Verlag. [Chatel and Detienne, 1996] Chatel, S. and Detienne, F. (1996). Strategies in object-oriented design. Acta Psychologica, 91:245–269. [Cline, 1996] Cline, M. (1996). The pros and cons of adopting and applying design patterns in the real world. Communications of the ACM, 39(10):47–49. [Codenie et al., 1997] Codenie, W., De Hondt, K., Steyaert, P., and Vercammen, A. (1997). From custom applications to domain-specific frameworks. Communications of the ACM, 40(10):71–77. [Delgado et al., 2003] Delgado, C., Jos´e, and Torres, M. (2003). Primitive operations for schema evolution in odmg databases. In Proc. Int. Conf. on Object-Oriented Information Systems 2003. Springer. [Demeyer et al., 2000] Demeyer, S., Ducasse, S., and Nierstrasz, O. (2000). Finding refactorings via change metrics. In Proc. Int. Conf. OOPSLA 2000. ACM Press. 7
[Demeyer et al., 2002] Demeyer, S., Ducasse, S., and Nierstrasz, O. (2002). Object-Oriented Reengineering Patterns. Morgan Kaufmann and DPunkt.
[Kao and Archer, 1997] Kao, D. and Archer, N. (1997). Abstraction in conceptual model design. International Journal of Man-Machine Studies, 46:125–150.
[Du Bois, 2004] Du Bois, B. (2004). Opportunities and challenges in deriving metric impacts from refactoring postconditions. Fifth International Workshop on Object Oriented Reengineering (WOOR2004), ECOOPworkshop.
[Kerievesky, 2004] Kerievesky, J. (2004). Refactoring To Patterns. Addison-Wesley. [Kerievsky, 2002] Kerievsky, J. (2002). Stop overengineering! Software Development Magazine. [Larsen and Naumann, 1992] Larsen, T. and Naumann, J. (1992). An experimental comparison of abstract and concrete representations in systems analysis. Information and Management, 22:29–40.
[Du Bois and Mens, 2003] Du Bois, B. and Mens, T. (2003). Describing the impact of refactoring on internal program quality. International Workshop on Evolution of Large-scale Industrial Software Applications (ELISA), ICSM-workshop.
[Lubars et al., 1992] Lubars, M., Meredith, G., Potts, C., and Richter, C. (1992). Object oriented analysis for evolving systems. volume Proceedings of the International Conference on Software Engineering (ICSE’92).
[Fayad and Schmidt, 1997] Fayad, M. and Schmidt, D. (1997). Object-oriented application frameworks. Communications of the ACM, 40(10):32–38.
[Mens et al., 2002] Mens, T., Demeyer, S., Du Bois, B., Stenten, H., and Van Gorp, P. (2002). Refactoring: Current research and future trends. Language Descriptions, Tools and Applications (LDTA).
[Fischer et al., 1995] Fischer, G., Redmiles, D., Williams, L., Puhr, G., Aoki, A., and Nakakoji, K. (1995). Beyond object-oriented technology: where current approaches fall short. Human-Computer Interaction, 10:79–119.
[Moody and Shanks, 1994] Moody, D. and Shanks, G. (1994). What makes a good data model ? evaluating the quality of entity relationship models. volume Proc. 13th International Entity Relationship Conference, pages 94–111.
[Florijn and van Oosterom, 1996] Florijn, G. and van Oosterom, N. (1996). Objectorientatie: Wat, waarom en hoe ? Informatie, pages 8–13. [Fowler, 1999] Fowler, M. (1999). Refactoring: Improving the Design of Existing Code. Addison-Wesley.
[Moore, 1996] Moore, I. (1996). Automatic inheritance hierarchy restructuring and method refactoring. In Proceedings Int’l Conf. OOPSLA ’96, ACM SIGPLAN Notices, pages 235–250. ACM Press.
[Garlan and Perry, 1995] Garlan, D. and Perry, D. (1995). Introduction to the special issue on software architecture. IEEE Transactions on Software Engineering, 21(4):269– 274.
[Opdyke, 1992] Opdyke, W. (1992). Refactoring ObjectOriented Frameworks. PhD thesis, University of Illinois at Urbana-Champaign.
[Griswold, 1991] Griswold, W. (1991). Program Restructuring as an Aid to Software Maintenance. PhD thesis, University of Washington.
[Opdyke and Johnson, 1993] Opdyke, W. and Johnson, R. (1993). Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In Proc. of the 1990 Symposium on Object-Oriented Programming Emphasizing Practical Applications, pages 274–282.
[Helm, 1995] Helm, R. (1995). Patterns in practice. volume Proceedings of the Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA’95).
[Parnas, 1979] Parnas, D. (1979). Designing software for ease of extension and contraction. IEEE Transactions on Software Engineering, 5(2):128–138.
[IEEE, 1994] IEEE (1994). Ieee std 610.12-1990: Ieee standard glossary of software engineering terminology. In IEEE standards collection: software engineering. IEEE.
[Parsons and Wand, 1997] Parsons, J. and Wand, Y. (1997). Choosing classes in conceptual modeling. Communications of the ACM, 40(6):63–69.
[Jacobson et al., 1992] Jacobson, I., Christerson, M., Jonsson, P., and Overgaard, G. (1992). Object-Oriented Software Engineering: A Use Case Driven Approach. Addison Wesley.
[Philipps and Rumpe, 2001] Philipps, J. and Rumpe, B. (2001). Roots of refactoring. In Baclavski, K. and Kilov, 8
H., editors, Tenth OOPSLA Workshop on Behavioral Semantics. Tampa Bay, Florida, USA, October 15, 2001. Northeastern University. [Roberts et al., 1997] Roberts, D., Brant, J., and Johnson, R. (1997). A refactoring tool for Smalltalk. Theory and Practice of Object Systems, 3(4):253–263. [Schmid, 1983] Schmid, H. (1983). A comparative survey of concepts for conceptual information models. In Bubenko, J.A., J., editor, Information Modeling, pages 63–102. [Schmid, 1997] Schmid, H. (1997). Systematic framework design by generalization. Communications of the ACM, 40(10):48–51. [Shanks et al., 1993] Shanks, G., Simsion, G., and Rembach, M. (1993). The role of experience in conceptual schema design. Technical report, Monash University. [Simsion, 1994] Simsion, G. (1994). Data Modeling Essentials: Analysis, Design and Innovation. International Thompson Publishing. [Simsion and Shanks, 1993] Simsion, G. and Shanks, G. (1993). Choosing entity types - a study of 51 data modellers. Technical report, Monash University. [Tichelaar et al., 2000] Tichelaar, S., Ducasse, S., Demeyer, S., and Nierstrasz, O. (2000). A meta-model for language-independent refactoring. In Proc. Int. Symp. Principles of Software Evolution, pages 157–169. IEEE Computer Society Press. [Tourw´e et al., 2004] Tourw´e, T., Kellens, A., Vanderperren, W., and Vannieuwenhuyse, F. (2004). Inductively generated pointcuts to support refactoring to aspects. In Proceedings of the Workshop on Softwareengineering Properties of Languages for Aspect Technologies,Workshop on AOSD 2004. Lancaster, UK. [Verelst, 2004a] Verelst, J. (2004a). The influence of the level of abstraction on the evolvability of conceptual models of information systems. In Proceedings of the 2004 International Symposium on Empirical Software Engineering, pages 17–26, Los Angeles. IEEE CS Press. [Verelst, 2004b] Verelst, J. (2004b). Variability in conceptual modeling. Technical Report Technical Report RPS2004-019, University of Antwerp. [Vitalari and Dickson, 1983] Vitalari, N. and Dickson, G. (1983). Problem solving for effective systems analysis: an experimental exploration. Communications of the ACM, 26(11):948–956.
9
