Linux as a case study: its extracted software architecture

Bowman,; Holt,; Brewster,

doi:10.1109/icse.1999.841045

Cited by 57 publications

(97 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Recently, a series of studies has been undertaken by Holt et al to recover the architectures of several largescale, open-source applications (e.g., Linux, Apache) [4,15]. Their approach is similar to ours in that they also come up with a conceptual architecture and use it as the basis of understanding a system's implementation.…”

Section: Discussionmentioning

confidence: 99%

“…Poor Modularity -Numerous researchers, including a recent study by Bowman et al [4], have demonstrated that developer discipline is difficult to ensure in a large system built and maintained by many people over a long time; in such cases, the physical architecture of the system eventually reaches a high degree of connectivity among its components. We have not encountered cases of such severe architectural erosion in our studies classes, and so on.…”

Section: Discussionmentioning

confidence: 99%

“…Many of these requirements are often ignored in present-day development however, with a frequent willingness to compromise the quality and longevity of a system in order to decrease its time-to-market. This attitude, coupled with the complexity of the involved systems and the sloppiness with which the changes to them are often documented, directly contributes to numerous recorded cases of architectural erosion [4,5,8,29]. Architectural erosion denotes a major departure from the initial architecture's intent and conceptual integrity, caused by its frequent modifications; erosion also refers to the discrepancies between the architecture "as documented" and "as implemented."…”

mentioning

confidence: 99%

“…To deal with the problem of architectural erosion, researchers and practitioners have typically engaged in architectural recovery [4,11,13,15,16,32,41,43], a process whereby the system's architecture is extracted from its implementation. However, existing architectural recovery approaches fail to account for several pertinent issues.…”

mentioning

confidence: 99%

See 3 more Smart Citations

Using software evolution to focus architectural recovery

Medvidović

Jakobac

2006

Autom Software Eng

View full text Add to dashboard Cite

Ideally, a software project commences with requirements gathering and specification, reaches its major milestone with system implementation and delivery, and then continues, possibly indefinitely, into an operation and maintenance phase. The software system's architecture is in many ways the linchpin of this process: it is supposed to be an effective reification of the system's technical requirements and to be faithfully reflected in the system's implementation. Furthermore, the architecture is meant to guide system evolution, while also being updated in the process. However, in reality developers frequently deviate from the architecture, causing architectural erosion, a phenomenon in which the initial, "as documented" architecture of an application is (arbitrarily) modified to the point where its key properties no longer hold. Architectural recovery is a process frequently used to cope with architectural erosion whereby the current, "as implemented" architecture of a software system is extracted from the system's implementation. In this paper we propose a light-weight approach to architectural recovery, called Focus, which has three unique facets. First, Focus uses a system's evolution requirements to isolate and incrementally recover only the fragment of the system's architecture affected by the evolution. In this manner, Focus allows engineers to direct their primary attention to the part of the system that is immediately impacted by the desired change; subsequent changes will incrementally uncover additional parts of the system's architecture. Secondly, in addition to software components, which are the usual target of existing recovery approaches, Focus also recovers the key architectural notions of software connector and architectural style. Finally, Focus does not only recover a system's architecture, but may in fact rearchitect the system. We have applied and evaluated Focus in the context of several off-the-shelf applications and architectural styles to date. We discuss its key strengths and point out several open issues that will frame our future work.

show abstract

Section: Discussionmentioning

confidence: 99%

Section: Discussionmentioning

confidence: 99%

mentioning

confidence: 99%

mentioning

confidence: 99%

See 2 more Smart Citations

Using software evolution to focus architectural recovery

Medvidović

Jakobac

2006

Autom Software Eng

View full text Add to dashboard Cite

show abstract

“…Architectural recovery is one of the recognized counter-measures to this decay [12]. Several earlier works have been focused on the architectural recovery of proprietary [12], closed academic [1], COTS [4] and FLOSS [6,17,37] systems; in all of these studies, systems were selected in a specific state of evolution, and their internal structures analysed for discrepancies between the folder-structure and concrete architectures [37]. Repair actions have been formulated as frameworks [32], methodologies [20] or guidelines and concrete advice to developers [37].…”

Section: Background and Related Workmentioning

confidence: 99%

Successful Reuse of Software Components: A Report from the Open Source Perspective

Capiluppi

Boldyreff

Stol

2011

IFIP Advances in Information and Communication Technology

View full text Add to dashboard Cite

Abstract. A promising way of software reuse is Component-Based Software Development (CBSD). There is an increasing number of OSS products available that can be freely used in product development. However, OSS communities themselves have not yet taken full advantage of the "reuse mechanism". Many OSS projects duplicate effort and code, even when sharing the same application domain and topic. One successful counter-example is the FFMpeg multimedia project, since several of its components are widely and consistently reused into other OSS projects. This paper documents the history of the libavcodec library of components from the FFMpeg project, which at present is reused in more than 140 OSS projects. Most of the recipients use it as a blackbox component, although a number of OSS projects keep a copy of it in their repositories, and modify it as such. In both cases, we argue that libavcodec is a successful example of reusable OSS library of components.

show abstract

Maintaining a legacy: towards support at the architectural level

Bril

Feijs

Glas

et al. 2000

J. Softw. Maint: Res. Pract.

View full text Add to dashboard Cite

An organization that develops large, software intensive systems with a long lifetime will encounter major changes in the market requirements, the software development environment, including its platform, and the target platform. In order to meet the challenges associated with these changes, software development has to undergo major changes as well. Especially when these systems are successful, and hence become an asset, particular care shall be taken to maintain this legacy; large systems with a long lifetime tend to become very complex and difficult to understand. Software architecture plays a vital role in the development of large software systems. For the purpose of maintenance, an up‐to‐date explicit description of the software architecture of a system supports understanding and comprehension of it, amongst other things. However, many large complex systems do not have an up‐to‐date documented softwarearchitecture. Particularly in cases where these systems have a long lifetime, the (natural) turnover of personnel will make it very likely that many employees contributing to previous generations of the system are no longer available. A need to ‘recover’ the software architecture of the system may become prevalent, facilitating the understanding of the system, providing ways to improve its maintainability and quality and to control architectural changes. This paper gives an overview of an on‐going effort to improve the maintainability and quality of a legacy system, and describes the recent introduction of support at the architectural level for program understanding and complexity control. Copyright © 2000 John Wiley & Sons, Ltd.

show abstract

Linux as a case study: its extracted software architecture

Cited by 57 publications

References 0 publications

Using software evolution to focus architectural recovery

Using software evolution to focus architectural recovery

Successful Reuse of Software Components: A Report from the Open Source Perspective

Maintaining a legacy: towards support at the architectural level

Contact Info

Product

Resources

About