Measuring stability of object‐oriented software architectures
2015; Institution of Engineering and Technology; Volume: 9; Issue: 3 Linguagem: Inglês
10.1049/iet-sen.2014.0017
ISSN1751-8814
Autores Tópico(s)Software System Performance and Reliability
ResumoIET SoftwareVolume 9, Issue 3 p. 76-82 Research ArticlesOpen Access Measuring stability of object-oriented software architectures Shouki A. Ebad, Corresponding Author Shouki A. Ebad [email protected] Faculty of Computing & IT, Northern Border University, P.O. Box 840, Rafha, 91911 Saudi ArabiaSearch for more papers by this authorMoataz Aly Ahmed, Moataz Aly Ahmed Information & Computer Science Department, King Fahd University of Petroleum & Minerals, Dhahran, 31261 Saudi ArabiaSearch for more papers by this author Shouki A. Ebad, Corresponding Author Shouki A. Ebad [email protected] Faculty of Computing & IT, Northern Border University, P.O. Box 840, Rafha, 91911 Saudi ArabiaSearch for more papers by this authorMoataz Aly Ahmed, Moataz Aly Ahmed Information & Computer Science Department, King Fahd University of Petroleum & Minerals, Dhahran, 31261 Saudi ArabiaSearch for more papers by this author First published: 01 June 2015 https://doi.org/10.1049/iet-sen.2014.0017Citations: 6AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Abstract Software architectural stability reflects the capability of software to evolve while preserving its architecture. Stability in this context means preserving cross-architectural components communications and structural relationships unchanged. It is recognised that cross-architectural components changes are costly and should be avoided. In object-oriented development, class packages form the basic architectural components of large-scale software systems. There has been a number of architecture stability metrics proposed in the literature. Those metrics mainly measure changes in cross-components structural relationships and not cross-components communication. In this study, the authors' present a new architectural stability metric that measure inter-package calls. The authors' theoretically validated ASM through a set of prominent mathematical properties. The authors' also empirically validated the metric using two open source projects: JHotDraw and abstract window toolkit. Measurements of the ASM were shown to be consistent with the lines of code changes across releases in the two projects. 1 Introduction The software architecture represents those design decisions that are hardest to change [1-3]. If the business goal is that the system should be long-lived, should evolve to accommodate future user requirements and should create future value, stability becomes an important goal to evaluate an architecture against. Architectural stability is a quality that refers to the extent an architecture is flexible to endure evolutionary changes in stakeholder's requirements and the environment, while leaving the architecture intact. Consequently, failing to accommodate the change leads ultimately to the degradation of the usefulness of the system. In other works, a number of metrics for measuring software stability have been proposed in the literature. These proposals considered factors such as module size [4, 5], number of modules [5-7], number of class hierarchies/relationships, inheritance, aggregation [4, 6, 8], number of services (methods), measurement of class coupling [4] and lines of code (LOC) [9]. To the best of our knowledge, however, the available architectural stability measures lack some other important structural aspects of architecture, such as inter-package connections (IPCs). The objective of this paper is to propose a new metric to measure the architectural stability of object-oriented (OO) system in terms of IPC that considers more factors than what is used in available measures. This will provide information about the package and its evolution, enabling the monitoring of trends in software evolution. Owing to some control over change amplification, maintenance cost and effort can be reduced [6]. The rest of this paper is organised as follows: Section 2 presents a review of existing architectural stability measures and the evaluation approaches. Section 3 introduces our new metric for measuring architectural stability. The validation of the proposed metric against theoretical stability properties is discussed in Section 4. Sections 5 and 6 discuss the empirical validation and the application to two real case studies, respectively. Section 7 discusses some threats to the study's validity. Finally, the last section presents concluding remarks and offers some directions for future work. 2 Related work Many researchers have proposed metrics for measuring architecture stability. Martin [8] hinges the stability of a system on the dependency between the different packages in the system. He proposed a metric for measuring the stability of the system based on structural dependencies implemented using '#include' statements in C + + code. However, it was not clear how the metric assesses the impact of evolution on the software architecture. Bansiya [4] proposed an approach to evaluate the architectural stability of frameworks by means of a suite of OO design metrics. These metrics are computed from the class model of successive releases of frameworks; corresponding measurements are compared to determine the extent-of-change in the structural characteristics of the different releases. However, the design metrics used to measure extent-of-change are class-level metrics. This is not practical for large software systems where higher-level structures are used. The class is too finely grained to be used as an organisational unit for large systems [10]. Besides, while the inheritance dependency type is considered heavily in the metrics suite, the aggregation and association types, for example, were not considered at all. The criteria for selecting the used metrics were not clear. AlShayeb [11] assessed the impact of software refactoring [12] on architecture stability, and as a result, recommended the designers interested to optimise their design for architecture stability to avoid using refactoring methods that affect the class hierarchy. Instead, they can use those methods that affect field/method levels. AlShayeb used Bansiya's approach [4] in his assessment. However, the author did not consider the package as the basic unit of software architecture; instead focused on the class level. Therefore, the study was limited to investigate the effect of refactoring methods at fine/medium grain level that is, field, methods and class. Jazayeri [5] has applied retrospective analysis to 20 releases of a large telecommunication software system. The analysis uses simple metrics such as software size metrics (e.g. module size, number of modules changed and the number of modules added in the different releases), coupling metrics and colour visualisation, to outline the evolution pattern of a software system across releases. In spite of its simplicity, the evaluation approach, however, uses fine-grained artefacts such as size metrics, which are not architectural in essence. Further, it is assumed that the system already exists and has evolved making this approach unsuitable for early evaluation. Bahsoon and Emmerich [1] used a predictive approach for measuring architectural stability. They presented an architectural review approach, called ArchOptions, with stability as the primary review objective. The approach is based on real options theory; it takes economic perspective as its core. It does not concentrate on other measurements that can help to obtain an insight into the stability and therefore is commendable to use only if one is having cost as his backdrop to proceed further with the enhancements of his architecture. Tonu et al. [13] have identified complexity, cohesion and coupling as the factors that contribute to the architectural stability. They presented a metric-based approach to assess the architecture stability. Both retrospective and predictive analyses are applied in the approach. By using the metric-based approach, Tonu et al. were able to identify where the architecture of the systems used in the experiment becomes stable. Ahmed et al. [14] introduced an approach to measure the architectural stability of an OO system by using similarity metrics. These metrics compare the base version of a system with the next versions. Then, a regression line is generated from these similarity values. A higher value represents a stable architecture. However, the considered case study does not constitute a thorough validation of the proposed metrics. Raemaekers et al. [9] introduced a way to measure interface and implementation stability of a library. To that end, they proposed four metrics that provide different insights, in both implementation and interface stability. From the architectural perspective, the drawback of these metrics is the granularity level of the metric; they are not at package level (coarse-grain) but method level (fine-grain). Moreover, the LOC value was used to measure the amount of work going on in a library since implementation can change while an interface stays constant. Aversano et al. [15] presented an empirical study aimed at assessing software architecture stability and its evolution along the software project history. Two metrics were defined based on a previous work [16]. Although both metrics provide a measure of how much the architecture of a software system changed passing from a release to another one, one metric finds the change in terms of number of packages and the other in terms of number of the interactions among packages. Smaller their values indicate less change, which means greater stability. However, their values are not normalised; accordingly, they could not be compared with a chosen threshold. In conclusion, our literature survey reveals that the available architectural stability measures and the evaluation approaches have some limitations. For instance, the metrics proposed by [4, 9] and the methodology presented by [5, 11] consider the method/class level, that is, fine/medium grain level. The work of Bansiya is suitable to use only if one is having cost and economic as his backdrop [4]. The metrics proposed in [9] use source code where the LOC value is a main component in their formulas. Our literature review also revealed some observations with regard to the soundness of the proposed stability metrics. Although the definition of sound measures requires that they be theoretically validated [17], the designers of the metrics proposed in [8, 9, 14, 15] did not validate their proposed metrics against theoretical or mathematical properties. In general, the available architectural stability metrics (ASMs) consider structural relations among packages but not message passing among packages. In fact, good architecture is one with minimal such connections (structural and message passing) among packages so that changes and impact of evolution are localised. If changes are propagated to many packages, maintainability would be lower. To address the above issues, we define new metric for architectural stability based on IPCs in high-level software design, that is, architectural design phase. We theoretically validated our proposed metric by showing that they satisfy the properties for architecture stability, and also experimentally against real-case studies. Elaboration on our approach to extract the IPCs is also provided. 3 Measuring architectural stability In this section, we first identify the types of message passing change that affect the architectural stability and then propose a new ASM based on these types of change. 3.1 Inter-package connections Our new stability metric focuses on inter-package message passing connections. In this context, IPC is a connection where the caller and callee belong to different packages. There are three types of change that can be observed on IPCs when two releases of the same software are compared. These types are Addition: An IPC that did not exist in release i has been added to release i + 1. Deletion: An IPC that exists in release i has been deleted in release i + 1. Modification: An IPC that exists in release i has been modified in release i + 1. The above types indicate that IPCs are instable. Since our aim is to measure the architecture stability, such a measure would depend on the unchanged types and find architectural stability by counting the unchanged IPCs between release i + 1 and release i. We consider the subsequent release (release i + 1) completely stable if none of its IPCs has been changed and completely unstable if all of its IPCs have been changed with respect to release i. The extent of stability of the subsequent release is then the percentage of unchanged IPCs to the total IPCs. It is worth noting here that at architecture level, sometimes, the IPC is modified through making change in the method signature that includes at least the number of its arguments. Indeed, the study focused on the analysis of the architecture; then, the deletion and addition types, besides the originals, are the most relevant information. An IPC is original if it exists in release i. The modification type of change is excluded in the evaluation, since we think they do not have a clear impact on architecture of the involved packages. 3.2 Calculation of architectural stability Consider two releases r1 and r2 with two packages P1 and P2. Let A be the set of added IPCs in r2, D be the set of deleted IPCs in r1 and O be the set of original IPCs that exist in r1. Let |D ∪ A| be the cardinality of the combined D and A sets and also let |O ∪ D ∪ A| be the cardinality of the three combined sets: O, D and A. The former represents the number of changed IPCs, whereas the latter represents the total number of IPCs. Since D ⊆ O, then |O ∪ D ∪ A| = |O ∪ A|. The change ratio (ChRatio) between r1 and r2 is then calculated as in (1) (1)where |O| > 0, |D| ≥ 0, |A| ≥ 0, D ⊆O, O ∩ A = Ø. Thus, the ASM is then calculated as in (2) (2)Both (1) and (2) could be simplified as in (3) (3)The ASM value varies from 0 to 1, where the ASM value '0' indicates the highest possible amount of change between r1 and r2 (i.e. unstable architecture) and the ASM value of '1' indicates the lowest possible amount of change between r1 and r2 (i.e. stable architecture). As an example, consider two software releases r1 and r2 with three IPCs in r1 (a, b and c) and four IPCs in r2 (a, b, d and e). In this case, O = {a, b, c}, D = {c} and A = {d, e}. The amount of change, that is, ChRatio, between r1 and r2 is |{c, d, e}|/|{a, b, c, d, e}| = 0.6; therefore, the ASM value is 0.4. 4 Validation of metric against theoretical properties To validate the proposed metric theoretically, we used the mathematical properties proposed by Hassan [18]. Hassan proposed seven properties to be satisfied in order to validate the stability metrics theoretically: non-negativity, normalisation, null value, maximum value, transitivity, package cohesion impact and change impact. The theoretical validation of ASM based on these properties is as follows. Non-negativity: The non-negativity property requires the stability of software architecture to be greater than or equal to zero. The proposed ASM metric possesses this property because the variables used in ASM are cardinalities of corresponding sets and the cardinality of a set cannot be negative. Normalisation: This property requires the stability of software architecture to belong to a bounded interval. It is worth noting here that given the popularity of the non-negativity property, we opted to bind the measurements of ASM to the interval [0, 1]. A '1' value means there is not any architectural change from IPCs perspective across two releases. A '0' value means all IPCs have changed across two releases. Clearly, the ASM value is bounded between 0 and 1, since the denominator in ASM metric is always greater than or equal to the numerator; that is, ASM cannot exceed 1 in value. Null value: The null value property holds that the stability of software architecture is null if there is no common IPC between the base release and the considered release; that is, the intersection results in an empty set. This property is satisfied with ASM metric when both sets O and D are equal, that is, all IPCs in ri (the base release) are deleted from ri+1 (the considered release). Maximum value: This property holds that the stability of software architecture is equal to Max if there can be addition but no deletion. The ASM metric has the maximum value when there is no addition or deletion. This is done formally when D ∪ A = Ø. Transitivity: Consider three stability measurements such that the first measurement is less than the second and the second is less than the third, and then the first measure should be less than the third one. Release j is more stable than i if there is less number of deleted/added IPCs in j than in i. ASM will always show that architecture with less number of deleted/added IPCs has higher architectural stability than architecture with more deleted/added IPCs. Let i, j, k and m are four releases; ASMj is the ASM of j relative to its previous release i, ASMk is the ASM of k relative to its previous release j and ASMm is the ASM of m relative to its previous release k, if ASMj < ASMk and ASMk < ASMm. Then it implies that ASMj < ASMm, which means the summation of both |D| and |A| in k and m, respectively, is less than those in i and j. Therefore, ASM satisfies the transitivity property. Change impact: This property holds that if the number of unchanged IPCs in release j relative to release i is less than that in release k relative to release j, then the stability of j relative to i will be less than the stability of k relative to j provided that the total IPCs in j relative to i is not less than that in k relative to j. With ASM metric, the number of unchanged IPCs is formally represented by the numerator value, that is, |O| − |D|. Thus, if the numerator value of j is less than that of k, then ASM of j is less than ASM of k. Package cohesion impact: This property states that if the difference between two releases is the number of unchanged IPCs and the number of unchanged IPCs, then the system with greater unchanged IPCs will be of higher stability while its total unchanged connections are not more than those of the other releases. IPC is a connection where the caller and callee belong to the same package. This property could not be validated against ASM because our focus was not on the IPCs. However, we assume that ASM satisfies this property intuitively. A higher value of IPC indicates towards high coupling between the packages and a lower value indicates towards lower coupling between the concerned packages. Changing IPCs has greater impact on the architecture stability as compared to changing IPCs that has greater impact on the class stability. This is because the IPCs are the ones that link the different components of a software system together and changing them would change the architecture of the system. 5 Empirical validation Empirically validating our metrics posed a great challenge as it is always the case in the field of software engineering. Owing to the data scarcity problem, we were not able to find relevant architectural and design artefacts where the ASM metric could be applied. Accordingly, we reverse-engineered code of two open source projects: JHotDraw and abstract window toolkit (AWT), as explained in the following subsection. Ideally, we would want to have the records of the maintenance effort of the systems we use. The hypothesis in this case could be that measurements computed using our metric are negatively correlated with the maintenance effort. The rationale is that architectural changes are the most expensive due to the propagation of changes. Stable architectures are highly maintainable. Unfortunately, we failed to find such maintenance effort records available to use. Moreover, we did not find any similar work in the literature against our work. To overcome the issue, we tested another hypothesis: there is a negative correlation between measurements of our metric at the architecture level and changes at the code level across different releases of a given system. We computed the number of changes among these releases at source code level using the tool BeyondCompare [http://www.scootersoftware.com/]. BeyondCompare is a tool that provides the users with extensive side-by-side file comparison and management. 5.1 IPCs extraction According to Jacobson [19], the functionality (i.e. the services) that users require of the OO system is documented in use cases (UCs). These UCs describe the typical interactions between the users of a system and the system itself, providing a narrative of how a system is used. Each UC is realised by one or more sequence diagrams (SDs) that depict how the objects interact and work together to provide services [20]. Each individual object provides only a small element of the functionality – its particular responsibilities – but when they work together, objects are able to produce services that people can use. Even though there are some tools such as Enterprise Architect [http://www.sparxsystems.com/products/ea/], Together [http://www.borland.com/us/products/together/], AltovaUModel [http://www.altova.com/umodel.html/] that can generate SDs from source code, the generated SDs are based on run-time behaviour; they are based on methods behaviour at run-time. In other words, when one specifies a particular method, the run-time system can generate the behaviour of this method across the entire system. Source code of real software projects usually contains a lot of statements representing the run-time environment such as loop and control statements. A transient task should therefore take place after generating the SDs; it is a filtering process. Filtering is a means to eliminate all run-time variables and messages shown in UML-SDs. It then makes the generated 'run-time' SDs mimic the 'functional' SDs that describe the 'functional' behaviour of UCs through objects and messages starting from the pre-condition to the post-condition. The goal for ASM, as we discussed in Section 3, is to be used in retrospective analysis of architectures. Architectures are commonly documented using CASE tools. As XML metadata interchange (XMI) is de-facto standard for storing artefacts by prominent CASE tools, we developed a tool to calculate ASM directly from XMI. However, owing to the data scarcity issues, we were not able to find the architecture artefacts available in the literature as we pointed out in this paper. Accordingly, we had to reverse engineer the code to XMI, we chose AltovaUModel tool (Enterprise Edition Version 2012 sp1) in generating the SDs from the system source code. Then, we have used an XMI to UCs transformation tool (XMI2UC) to extract UCs from OO source code via XMI documents generated by AltovaUModel. The whole system, after filtering process, is exported in XMI document to be used as input to the XMI2UC tool. XMI2UC produces three outputs: (1) package information document, (2) class information document and (3) use case path information document. The first two documents list the details of all packages and classes, respectively. The UC in the third output is nothing more than a sequence of related messages passing, that is, method callings. A detailed discussion on XMI2UC can be found in our previous work [21]. We developed another tool called 'FindStability', which reads the three documents, generated by XMI2UC, of two different releases of the considered system; finds all aspects related to the stability, that is, original IPCs of the first release and deleted/added IPCs of the second release; and calculate the ASM value. The above reverse-engineering process could be modelled through data flow diagram (DFD) shown in Fig. 1. Fig. 1Open in figure viewerPowerPoint DFD described the reverse-engineering process 6 Case studies Using the above-mentioned procedure of reverse engineering, we applied our proposed metric on two case studies: JHotDraw and the Java AWT library. We also computed the number of changes among these releases at source code level using BeyondCompare. The following subsection presents the obtained results. 6.1 JHotDraw JHotDraw is an open source Java GUI framework that can be used for developing custom-made drawing editor applications. As a wide amount of historical data of JHotDraw is available in its CVS repository, several researchers used this system as a case study in their research [21-24]. Table 1 and Fig. 2 show the statistics produced by 'FindStability' described in the previous section for the three releases of JHotDraw project 5.1, 5.2 and 5.3. In terms of ASM, it is clear that release 5.3 is less stable than release 5.2 with a difference of 21.7%. Fig. 2Open in figure viewerPowerPoint Stability of JHotDraw releases in terms of ASM measurements Table 1. ASM values of three JHotDraw releases Original IPCs Deleted IPCs Added IPCs ASM metric release 5.1 293 N/A N/A N/A release 5.2 268 45 27 77% release 5.3 261 80 69 55% Intuitively, the above result is expected because of adding new functionalities in release 5.3, which in turn leads directly to reduce the value of ASM metric. This reduction increases when the new functionality cuts across many features and activities in the entire system as in the case of release 5.3. The undo functionality, for instance, is added to JHotDraw system starting from release 5.3; we borrowed (from [24]) a simplified representation of the participating classes in the JHotDraw undo implementation shown in Fig. 3. The 'Undoable' interface provides the undo and redo methods that encapsulate the notion of undoing and redoing an action. JHotDraw has more than 20 commands that can be undone, causing the undo feature to be spread over many classes. Moreover, each class implementing a concrete command that can be undone defines a static nested class conforming to this Undoable interface. Whenever the command is executed, it also updates fields in its associated undo activity needed to actually perform the undo. The implementation of cross-cutting undo aspect is scattered over many locations and tangled with the implementation of other aspects. Such tangling can be directly responsible for system inter-dependency, that is, IPCs [24-26]. Fig. 3Open in figure viewerPowerPoint Participants for the Undo concern 6.2 Java AWT library The Java AWT Library is a collection of classes for creating lightweight user interfaces and for painting graphics and images. It is part of the standard Java platform. Since AWT library is structured into relatively large packages, we concentrated on the main packages that make up the library's core: 'color, datatransfer, event, font, geom., im, image, image.renderable and print'. Compared to JHotDraw case study, AWT library is bigger in its size. The size does not depend only on the number of classes but also on the number of UCs generated by XMI2UC tool [in AWT, number of UCs generated by XMI2UC was 196 and 271 for releases 1.4 and 1.5, respectively, whereas in JHotDraw was 130, 131 and 165 for releases 5.1, 5.2 and 5.3, respectively.], which is also impacted by the number of methods in the whole system. For instance, some classes in AWT have tens of methods, for example, BufferedImage and ColorModel; such cases would generate tens of UCs/SDs by Altova which are filtered by XMI2UC tool to avoid overlaps and duplications. Table 2 shows the statistics produced by FindStability described in the previous section for the two releases of AWT 1.4 and 1.5. In terms of ASM, it sounds that release 1.5 with the value of 0.47 is less stable than release 5.2. Table 2. ASM values of two AWT releases Original IPCs Deleted IPCs Added IPCs Unchanged IPCs ASM metric release 1.4 287 N/A N/A 287 N/A release 1.5 449 120 246 329 47% 6.3 Changes amount at source code level To provide more confidence on validation of ASM, we used BeyondCompare tool to find out the number of differences between any two releases at source code level. Table 3 shows the statistics for different releases of JHotDraw and AWT where '#diff' and 'LOC amount' are the number of changes (in terms source code) and amount of added/removed LOC between two considered releases, respectively. Additionally, the table shows the number of new classes added to each package in the considered release. Table 3. Results of BeyondCompare tool JHotDraw AWT Release 5.2 Release 5.3 Release 1.5 against the prev. release # diff 367 2175 718 LOC amount 2292 8712 3173 packages 'Contrib' 10 6 'Datatransfer' 2 'Figure' 1 0 other packages 0 'Standard' 1 8 'Util' 4 16 total 16 30 2 The amount of changes at source code level is close to what ASM reflected. The code of JHotDraw 5.2 contains 367 changes against JHotDraw 5.1; the code of JHotDraw 5.3 contains 2175 changes against JHotDraw 5.2; and the code of AWT 1.5 contains 718 changes against AWT 1.4. The large number of differences or changes in, for instance, JHotDraw 5.3 reflects the high decrease in ASM value (from 77.5% down to 55%). Consequently, the more the LOC value of release, the less stable the release as shown in Table 3. As discussed earlier, the ASM value falls down in JHotDraw 5.3 due to adding 'Undo' functionality that cuts across many features and activities in the entire system. Table 3 also shows the number of classes added in the different releases of JHotDraw and AWT projects. In JHotDraw 5.3, the 'Undo' is added with 8 classes/interfaces in package 'util'. In other words, 50% (8 out of 16) of the new classes/interfaces added to 'util' was due to Undo functionality; this addition represents 27% (8 out of 30) of the amount of addition to the whole system. 7 Threats to validity Although it is a common problem for software engineering research, data scarcity poses a major threat to the validity of the results of this study. To overcome this limitation, we used Altova and XMI2UC to reverse engineer JHotDraw to identify UCs and corresponding SDs to finally generate architecture-level IPCs. It is worth noting that the reverse-engineering process results in generating the actual sequence of messages passed in the system. The user of the ASM metric should keep in mind the validity of our results depends on the validity of the used approach. We intend targeting a more empirical validation against industrial data in the future. Owing to their big size, the JHotDraw and AWT projects do not present a size threat for this study. The use of larger size software in the empirical validation would provide more confidence on the validation. However, correlating architecture stability with external quality attributes such as maintainability or defect detection may also provide more confidence on the validation of the metric. Correlating measurements of ASM to the changes at the code level gives an indication of correlation between measurements using ASM and the maintenance effort. The last threat is that we considered only two types of IPCs change (additions, deletions). This set of types of change ignores other types such as IPC modification. Such types of change and changes in the structural relationships across packages remain to be investigated. 8 Conclusion and future work Stable architecture tends to reduce maintenance cost and effort. Packages in large-scale OO systems form the basic elements of the architecture. In this paper, we propose ASM to measure the stability of the inter-package communication. We validated ASM against theoretical properties, and also experimentally using two open source projects: three releases of JHotDraw and two releases of AWT. BeyondCompare is used to measure the changes at source code level for these two projects. Despite some threats to the study's validity, the findings of this study have become foundation for further empirical retrospective studies of the architectural properties. As ASM is mainly to be used in retrospective analysis, future research can use it in identifying predictors of stable architectures [1, 3, 5, 18]. For instance, researchers can use ASM to study the correlation between cohesion and coupling on architecture stability. The goal would be to use such predictors early during the design to predict the stability of the architecture. Unfortunately, we did not have access to data that would carry out such a study. 9 References 1Bahsoon, R., Emmerich, W.: 'Evaluating the stability of software architectures with real options theory'. Proc. 20th IEEE Int. Conf. Software Maintenance, Chicago IL, USA, September 2004, pp. 11– 17 2Keung, J., Liu, Y., Foster, K., Nguyen, T.: 'A statistical method for middleware system architecture evaluation'. 21st Australian Software Engineering Conf., Auckland, New Zealand, April 2010, pp. 183– 191 3Bahsoon, R., Emmerich, W.: 'Architectural stability'. OTM Workshops, Vilamoura, Portugal, 2009 (LNCS, 5872), pp. 304– 315 4Bansiya, J.: 'Evaluating framework architecture structural stability'. ACM Computing Surveys (CSUR), 2000, vol. 32, (1) 5Jazayeri, M.: 'On architectural stability and evolution'. Proc. Seventh Ada-Europe Int. Conf. Reliable Software Technologies, Vienna, Austria, June 2002, pp. 13– 23 6Elish, M., Rine, D.: 'Investigation of metrics for object-oriented design logical stability'. Proc. Seventh European Conf. Software Maintenance and Reengineering, Benevento, Italy, March 2003, pp. 193– 200 7Alshayeb, M., Li, W.: 'An empirical study of system design instability metric and design evolution in an agile software process', J. Syst. Softw., 2004, 74, (3), pp. 269– 274 (doi: 10.1016/j.jss.2004.02.002) 8Martin, R.: ' Stability' (C++ report, February 1997), pp. 54– 60 9Raemaekers, S., Deursen, A., Visser, J.: 'Measuring software library stability through historical version analysis'. The IEEE 28th Int. Conf. Software Maintenance, Trento, Italy, September 2012, pp. 378– 387 10Martin, R.: ' Granularity' (C++ report, November–December 1996), pp. 57– 62 11Alshayeb, M.: 'The impact of refactoring on class and architecture stability', J. Res. Pract. Inf. Technol., 2011, 43, (4), pp. 269– 284 12Fowler, M.: Refactoring Website http://www.refactoring.com/, accessed January 2014 13Tonu, S., Ashkan, A., Tahvildari, L.: 'Evaluating architectural stability using a metric-based approach'. Proc. Conf. Software Maintenance and Reengineering, Bari, Italy, March 2006, pp. 261– 270 14Ahmed, M., Rufai, R., AlGhamdi, J., Khan, S.: ' Measuring architectural stability in object oriented software' (King Fahd University of Petroleum and Minerals, Saudi Arabia, 2003) 15Aversano, L., Molfetta, M., Tortorella, M.: 'Evaluating architecture stability of software projects'. The 20th Working Conf. Reverse Engineering, Koblenz, Germany, October 2013, pp. 417– 424 16Olague, H., Etzkorn, L., Li, W., Cox, G.: 'Assessing design instability in iterative (agile) object-oriented projects', J. Softw. Maint. Evol. Res. Pract., 2006, 18, (4), pp. 237– 266 (doi: 10.1002/smr.332) 17Briand, L., Morasca, S., Basili, V.: 'Defining and validating measures for object-based high-level design', IEEE Trans. Softw. Eng., 1999, 25, (5), pp. 722– 743 (doi: 10.1109/32.815329) 18Hassan, Y.: ' Measuring software architectural stability using retrospective analysis'. MS thesis, King Fahd University of Petroleum & Minerals, 2007 19Jacobson, I.: ' Object-oriented software engineering: a use case driven approach' (Addison-Wesley, 1992, 1st edn.) 20 Object Management Group (OMG): ' Unified modeling language (UML)', 2010 21Ebad, S., Ahmed, M.: 'XMI2UC: an automatic tool to extract use cases from object-oriented source code', Int. J. Future Comput. Commun., 2012, 1, (2), pp. 196– 198 22Seng, O., Bauer, M., Biehl, M., Pache, G.: 'Search-based improvement of subsystem decompositions'. Proc. Conf. Genetic and Evolutionary Computation, Washington, DC, USA, June 2005, pp. 1045– 1051 23Seng, O., Stammel, J., Burkhart, D.: 'Search search-based determination of refactorings for improving the class structure of object oriented systems'. Proc. Conf. Genetic and Evolutionary Computation, Seattle, WA, USA, July 2006, pp. 1909– 1916 24Canfora, G., Cerulo, L.: 'How crosscutting concerns evolve in JHotDraw'. Proc. 13th IEEE Int. Workshop on Software Technology and Engineering Practice, Budapest, Hungary, September 2005, pp. 65– 73 25Kiczales, G., Lamping, J., Mehdhekar, A., et al.: 'Aspect-oriented programming'. Proc. 11th European Conf. Object-Oriented Programming, Jyväskylä, Finland, June 1997, pp. 220– 242 26Herzig, K., Zeller, A.: 'The impact of tangled code changes'. Proc. 10th Working Conf. Mining Software Repositories, San Francisco, CA, USA, May 2013, pp. 121– 130 Citing Literature Volume9, Issue3June 2015Pages 76-82 FiguresReferencesRelatedInformation
Referência(s)