An Approach to Software Architecture Analysis for Evolution and ReusabilityAbstract1. Introduction2. Framework for Information Gathering and AnalysisGathering.Modeling.Analyzing.Evaluating.2.1 Example of Modeling of Objectives3. Architectural Views for Evolution and Reusability AnalysisScenarios.Functional Flow.Structural View.Mapping between Functions and Components.Causal Diagram.Identification of Architectural Styles.Identification of Design Violations.4. Examples of Scenarios and Analyses5. Lessons LearnedThe role of views.Scenario generation.6. SummaryReferencesFigures and TablesFigure 1Table 1Figure 2Figure 3Figure 4Table 2Table 3Figure 5Table 4- 1 -AbstractSoftware evolution and reuse is more likely toreceive higher payoff if high-level artifacts—suchas architectures and designs—can be reused and canguide low-level component reuse. In practice, how-ever, high-level artifacts are often not appropriatelycaptured. This paper presents an approach to captur-ing and assessing software architectures for evolu-tion and reuse. The approach consists of aframework for modeling various types of relevantinformation and a set of architectural views for re-engineering, analyzing, and comparing softwarearchitectures. We have applied this approach tolarge-scale telecommunications systems, where theapproach is useful to reveal areas for improvementand the potential for reuse.Keywords: Software architectures, product lines,analysis, software evolution, software reusability,scenarios1. IntroductionSoftware evolution and reuse are two critical topicsin industry, because of the huge expense involvedand because of global competition. However, soft-ware systems are becoming increasingly complex,further complicating the already difficult problem ofevolving or reusing software assets and products. Tosystematically support the process for the evergrowing complexity of software, higher levels ofabstraction are needed. Kruchten [9] noted that “fora software reuse technique to be effective, it mustreduce the cognitive distance between the initial1. Kazman’s current address: Software EngineeringInstitute, Carnegie Mellon Univ., Pittsburgh, PA,15213. E-mail: [email protected] of a system and its final executable imple-mentation” (p. 136). Software architectures are criti-cal artifacts in bridging the gap between the initialconcept of a system and the system’s implementa-tion; its low-level software components.This paper presents a framework and a set of archi-tectural views that were developed to assess soft-ware architectures for evolution and reuse builtupon a scenario-based approach [7]. This frame-work is used to model different types of informa-tion, namely, stakeholder information [2,4],architecture information, quality information, andscenarios. Stakeholders can include, for example,designers, managers, and end-users. The informa-tion for stakeholders describes their objectives.Architecture information deals with the criticaldesign principles or architectural objectives. Qualityinformation refers to the non-functional attributessuch as performance, modifiability, availability, andintegrability. Scenarios are narratives that describeuse cases of a system. Scenarios can be used to cap-ture the system’s functionality. Scenarios that arenot directly supported by the current system can beused to detect possible flaws or to assess the archi-tecture’s support for potential enhancements. A setof scenarios is derived from the stakeholder objec-tives, architectural objectives, and desired systemquality attributes or objectives. Section 2 will give amore detailed discussion on this topic.Objectives provide boundaries and drive the analy-sis. Architectural views are important for evolutionand reuse, because various views provide differentperspectives, which are useful in understanding, re-engineering, and analyzing systems. In addition,these architectural views support analysis of sys-tems developed using different paradigms. Forexample, one application that we have made of theAn Approach to Software Architecture Analysis forEvolution and ReusabilityChung-Horng Lung, Sonia Bot, Kalai Kalaichelvan Rick Kazman1Software Engineering Analysis Lab. Department of Computer ScienceNortel University of WaterlooOttawa, Ontario, Canada K1Y 4H7 Waterloo, Ontario, Canada N2L 3G1{lung | sdbot | kalai}@nortel.ca [email protected] 2 -views is to compare systems developed using func-tional decomposition and object-oriented design inthe same problem area.The main objective of the approach was toassess an existing architecture for projectevolution or reuse in a future project in thesame problem domain or product line. Thework reflects empirical experience gatheredby an external review team to evaluate thesensitivity of an architecture to changes inkey customer value parameters. An exampleof a customer value is scalability. Forinstance: what is the sensitivity of an archi-tecture if the system is to be modified so thatit supports fifteen features, instead of the pre-vious ten, and at the same time the system isto be scaled from processing fifty calls toeighty calls per minute?The remainder of this paper is organized as follows:Section 2 demonstrates the framework for analysis.Section 3 describes the context of architecturalviews and various architectural views adopted forthe analysis of software architectures. Examples ofthe views are also demonstrated in this section. Sec-tion 4 highlights some example scenarios and partialanalysis results. Section 5 presents some importantlessons learned from applying the approach to sev-eral telecommunications systems. Finally, Section 6gives our concluding remarks.2. Framework for InformationGathering and AnalysisTo ensure that the software architecture analysisprocess is organized and scientific (and hence,repeatable), a framework for architecture informa-tion gathering and analysis was formulated, asdescribed in Figure 1. The activities described in theframework are performed iteratively instead of in astrict sequential manner.Gathering. This phase focuses on becoming awareof the available and required information to do theanalysis, and then to collect and compile it. Cur-rently four categories of information are beingaddressed: stakeholder, architecture, quality, andscenarios or use cases. In the future, the informationcategories may be extended, to include for example,competitive analysis.FIGURE 1.Framework for Architecture