Results 1 - 10
of
173
Checking system rules using system-specific, programmer-written compiler extensions
, 2000
"... ..."
(Show Context)
Maintaining Mental Models: A Study of Developer Work Habits
, 2006
"... To understand developers ’ typical tools, activities, and practices and their satisfaction with each, we conducted two surveys and eleven interviews. Many problems arose from developers forced to invest great effort recovering implicit knowledge by exploring code and interrupting teammates only to p ..."
Abstract
-
Cited by 162 (17 self)
- Add to MetaCart
(Show Context)
To understand developers ’ typical tools, activities, and practices and their satisfaction with each, we conducted two surveys and eleven interviews. Many problems arose from developers forced to invest great effort recovering implicit knowledge by exploring code and interrupting teammates only to persist this knowledge in their memory. Contrary to expectations that email and IM prevent expensive task switches caused by face-to-face interruptions, we found that face-to-face communication enjoys many advantages. Contrary to expectations that documentation makes understanding design rationale easy, we found that current design documents are inadequate. Contrary to expectations that code duplication involves the copy and paste of code snippets, developers reported several types of duplication. We use data to characterize these and other problems and draw implications for the design of tools for their solution.
On the Notion of Variability in Software Product Lines
- In Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA’01
, 2001
"... In this paper, we discuss the notion of variability. We have experienced that this concept has so far been underdefined. Although, we have observed that variability techniques become increasingly important. A clear indication of this trend is the recent emergence of software product lines. Software ..."
Abstract
-
Cited by 115 (2 self)
- Add to MetaCart
In this paper, we discuss the notion of variability. We have experienced that this concept has so far been underdefined. Although, we have observed that variability techniques become increasingly important. A clear indication of this trend is the recent emergence of software product lines. Software product lines are large, industrial software systems intended to specialize into specific software products. Our contribution in this paper is that we provide the reader with a framework of terminology and concepts regarding variability. In addition, we present three recurring patterns of variability. Finally, we suggest a method for managing variability in software product lines.
Aspect mining through the formal concept analysis of execution traces
- in WCRE
, 2004
"... The presence of crosscutting concerns, i.e., functional-ities that are not assigned to a single modular unit in the implementation, is one of the major problems in software understanding and evolution. In fact, they are hard to locate (scattering) and may give rise to multiple ripple effects (tan-gl ..."
Abstract
-
Cited by 98 (8 self)
- Add to MetaCart
(Show Context)
The presence of crosscutting concerns, i.e., functional-ities that are not assigned to a single modular unit in the implementation, is one of the major problems in software understanding and evolution. In fact, they are hard to locate (scattering) and may give rise to multiple ripple effects (tan-gling). Aspect Oriented Programming offers mechanisms to factor them out into a modular unit, called an aspect. In this paper, aspect identication in existing code is supported by means of dynamic code analysis. Execution traces are generated for the use cases that exercise the main functionalities of the given application. The relationship between execution traces and executed computational units (class methods) is subjected to concept analysis. In the re-sulting lattice, potential aspects are detected by determin-ing the use-case specic concepts and examining their spe-cic computational units. When these come from multiple modules (classes) which contribute to multiple use-cases, a candidate aspect is recognized. 1
Object Teams: Improving Modularity for Crosscutting Collaborations
- IN PROCS. OF NET.OBJECTDAYS
, 2002
"... In this paper, we investigate whether module concepts for capturing multi-object collaborations can be effectively used to implement crosscutting concerns in reusable, independently developed modules for a-posteriori integration into existing systems. A new kind of collaboration module, called Ob ..."
Abstract
-
Cited by 95 (13 self)
- Add to MetaCart
In this paper, we investigate whether module concepts for capturing multi-object collaborations can be effectively used to implement crosscutting concerns in reusable, independently developed modules for a-posteriori integration into existing systems. A new kind of collaboration module, called Object Teams, is proposed which combines the best features of existing approaches, further enhances them with concepts for expressing crosscutting relations between independent collaborations, and facilitates a-posteriori integration of such collaborations into existing systems.
A Taxonomy of Variability Realization Techniques
- SOFTWARE—PRACTICE AND EXPERIENCE
, 2001
"... ..."
Design Erosion: Problems Causes
, 2002
"... Design erosion is a common problem in software engineering. We have found that invariably, no matter how ambitious the intentions of the designers were, software designs tend to erode over time to the point that redesigning from scratch becomes a viable alternative compared to prolonging the life ..."
Abstract
-
Cited by 61 (10 self)
- Add to MetaCart
(Show Context)
Design erosion is a common problem in software engineering. We have found that invariably, no matter how ambitious the intentions of the designers were, software designs tend to erode over time to the point that redesigning from scratch becomes a viable alternative compared to prolonging the life of the existing design. In this paper we illustrate how design erosion works by presenting the evolution of the design of a small software system. In our analysis of this example we show how design decisions accumalate and become invalid because of new requirements. Also it is argued that even an optimal strategy for designing the system (i.e. no compromises with respect to e.g. cost are made) does not lead to an optimal design because of unforseen requirement changes that invalidate design decisions that once were optimal.
Directives for composing aspect-oriented design class models
- TAOSD LNCS
"... Directives for composing aspect-oriented design class models ..."
Abstract
-
Cited by 53 (7 self)
- Add to MetaCart
(Show Context)
Directives for composing aspect-oriented design class models
Using Hierarchical Scheduling to Support Soft Real-Time Applications in General-Purpose Operating Systems
, 2001
"... ..."
(Show Context)
On the reuse and maintenance of aspectoriented software: An assessment framework
- In 17th Brazilian Symposium on Software Engineering (SBES
"... Abstract Aspect-oriented software development (AOSD) is gaining wide attention both in research environments and in industry. Aspect-oriented systems encompass new software engineering abstractions and different complexity dimensions. As a consequence, AOSD poses new problems to empirical software ..."
Abstract
-
Cited by 36 (4 self)
- Add to MetaCart
(Show Context)
Abstract Aspect-oriented software development (AOSD) is gaining wide attention both in research environments and in industry. Aspect-oriented systems encompass new software engineering abstractions and different complexity dimensions. As a consequence, AOSD poses new problems to empirical software engineering. It requires new assessment frameworks specifically tailored to measure the reusability and maintainability degrees of aspect-oriented systems. This paper presents an assessment framework for AOSD, which is composed of two components: a suite of metrics and a quality model. These components are based on wellknown principles and existing metrics in order to avoid the reinvention of well-tested solutions. The proposed framework has been evaluated in the context of two different empirical studies with different characteristics, diverse domains, varying control levels and different complexity degrees. Based on empirical and quantitative analysis, the advantages and drawbacks of the framework components are discussed.
