Architecture-Level Dependence Analysis for Software Systems

Stafford, Judith A.; Wolf, Alexander L.

doi:10.1142/s021819400100061x

Cited by 67 publications

(38 citation statements)

References 30 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In the literature, a number of dependency analysis solutions are presented to support dependency analysis as part of activities related to the construction and use of architectural descriptions (see Table 3). These activities include, the analysis and understanding of formal architectural descriptions (Stafford and Wolf 2001;Stafford et al 2003;Zhao 2001), code architecture analysis (Sangal et al 2005), and the description of large component-base systems (Vieira et al 2001;Vieira and Richardson 2002).…”

Section: Architecture Description and Analysismentioning

confidence: 99%

“…Solutions that use semi-formal descriptions written on ADLs include chaining analysis (Stafford and Wolf 2001;Stafford et al 2003) and the construction of architectural dependency graphs (ADG) (Zhao 2001 Korel et al 2002) are another semi-formal descriptions that describe software systems and are used by some dependency analysis solutions. Dependency analysis enables the analysis of differences between a original ESFM model and a modified model, which help to identify the modified elements and support the reduction of regression testing activities.…”

Section: Semi-formal Descriptionsmentioning

confidence: 99%

“…ADLs (Stafford and Wolf 2001;Zhao 2001) andEFSM (Jourdan et al 2006;Korel et al 2002) are some of the tools that have emerged as potential solutions for formally describing system architectures at a higher level of abstraction. These initiatives provide support for modeling not just the system structure, but also the behavior and communication between components.…”

Section: Semi-formal Descriptionsmentioning

confidence: 99%

See 2 more Smart Citations

A practice-driven systematic review of dependency analysis solutions

2011

View full text Add to dashboard Cite

When following architecture-driven strategies to develop large softwareintensive systems, the analysis of the dependencies is not an easy task. In this paper, we report a systematic literature review on dependency analysis solutions. Dependency analysis concerns making dependencies due to interconnections between programs or system components explicit. The review is practice-driven because its research questions, execution, and reporting were influenced by the practice of a group of software architects at Philips Healthcare MRI. The review results in an overview and assessment of the state-of-the-art and applicability of dependency analysis. The overview provides insights about definitions related to dependency analysis, the sort of development activities that need dependency analysis, and the classification and description of a number of dependency analysis solutions. The contribution of this paper is for both practitioners and researchers. They can take it as a reference to learn about dependency analysis, match their own practice to the presented results, and to build similar overviews of other techniques and methods for other domains or types of systems.

show abstract

Section: Architecture Description and Analysismentioning

confidence: 99%

Section: Semi-formal Descriptionsmentioning

confidence: 99%

Section: Semi-formal Descriptionsmentioning

confidence: 99%

See 1 more Smart Citation

A practice-driven systematic review of dependency analysis solutions

2011

View full text Add to dashboard Cite

show abstract

“…This is due to the fact that a considerable part of the distributed applications implementation is already available, when the architecture is defined, for example, during the Elaboration phase of the Unified Process. Another approach is to build on architectural level dependency analysis (e.g., [Stafford and Wolf, 2001]) research to extract cost estimates of accommodating i i , guided by some structural criteria.…”

Section: Selecting Stable Middleware-induced Software Architectures Wmentioning

confidence: 99%

Using real options to select stable middleware-induced software architectures

2005

View full text Add to dashboard Cite

The requirements that force decisions towards building distributed system architectures are usually of non-functional nature. Scalability, openness, heterogeneity, and fault-tolerance are examples of such non-functional requirements. The current trend is to build distributed systems with middleware, which provide the application developer with primitives for managing the complexity of distribution, system resources, and for realizing many of the non-functional requirements. As non-functional requirements evolve, the "coupling" between middleware and architecture becomes the focal point for understanding the stability of the distributed software system architecture in the face of change. We hypothesise that the choice of a stable distributed software architecture depends on the choice of the underlying middleware and its flexibility in responding to future changes in non-functional requirements. We devise an option-based model to value such flexibility and guide the selection. We empirically evaluate the model using a case study that adequately represents a medium-size component-based distributed architecture. We report on how a likely future change in scalability could impact the architectural structure of two versions, each induced with a distinct middleware: one with CORBA and the other with J2EE. Our hypothesis is verified to be true for the given change. We conclude with some observations that could stimulate future research in the area of relating requirements to software architectures.

show abstract

“…This is due to the fact that a considerable part of the distributed applications implementation could be already available, when the architecture is defined, for example, during the Elaboration phase of the Unified Process. Another approach is to build on architectural level dependency analysis (e.g., [Stafford and Wolf, 2001]) research to extract cost estimates of accommodating ii, guided by some structural criteria.…”

Section: Estimating Ceimentioning

confidence: 99%

Evaluating architectural stability with real options theory

Bahsoon

Emmerich

20th IEEE International Conference on Software Maintenance, 2004. Proceedings.

View full text Add to dashboard Cite

Evolution is a key problem in software engineering and exacts huge costs. Industrial evidence even hints that companies spend more resources on maintaining and evolving their software than on the initial development. In managing the change and guiding evolution, considerable emphasis is placed on the architecture of the software system as a key artifact involved. One of the major indicators of the success (failure) of software evolution is the extent to which the software system can endure changes in requirements, while leaving the architecture of the software system intact. We refer to the presence of this "intuitive" phenomenon as architectural stability.We highlight the requirements for evaluating architectural stability. We pursue an economics-driven software engineering approach to address these requirements. We view evolving software as a value-seeking activity: software evolution is as a process in which software is undergoing a change (an incremental) and seeking value. The value is attributed to the flexibility of an architecture in enduring likely changes in requirements. To value flexibility, we contribute to a novel model that builds on an analogy with real options theory. The model examines some likely changes in requirements and values the extent to which the architecture is flexible to endure these changes. The model views an investment in an architecture as an upfront investment plus "continual" increments of future investments in likely changes in requirements. The objective is to provide insights into architectural stability and investment decisions related to the evolution of software architectures.We support the model with a three-phase method for evaluating architectural stability. The method provides guidelines on eliciting the likely changes in requirements and relating architectural decisions to value. The problem of valuing flexibility of an architecture to change requires a comprehensive solution that incorporates multiple valuation techniques, some with subjective estimates, and others based on market data, when available. To introduce discipline into this setting and capture the value from different perspectives, the method outlines a valuation points of view framework as a solution. The framework is flexible enough to account for the economic ramifications of the change on both structural (e.g., maintainability) and behavioral (e.g., throughput) qualities of an architecture and on relevant business goals (e.g., new market products).We report on our experience in using the model and its supporting method with two case studies. In the first case, we show how the model and its supporting method can be used to assess the worthiness of re-engineering a "more" stable architecture in face of likely changes in future requirements. We take refactoring as an example of re-engineering. In the second case, we show how the model and its supporting method can inform the selection of a "more" stable middleware-induced software architecture in the face of future changes in non-functional req...

show abstract

Architecture-Level Dependence Analysis for Software Systems

Cited by 67 publications

References 30 publications

A practice-driven systematic review of dependency analysis solutions

A practice-driven systematic review of dependency analysis solutions

Using real options to select stable middleware-induced software architectures

Evaluating architectural stability with real options theory

Contact Info

Product

Resources

About