Object-oriented software extensions in practice (original) (raw)
Related papers
Extensions during software evolution: Do objects meet their promise?
Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2012
As software evolves, data types have to be extended, possibly with new data variants or new operations. Object-oriented design is well-known to support data extensions well. In fact, most popular books showcase data extensions to illustrate how objects adequately support software evolution. Conversely, operation extensions are typically better supported by a functional design. A large body of programming language research has been devoted to the challenge of properly supporting both kinds of extensions.
Co-Evolution of Object-Oriented Software Design and Implementation
Software Architectures and Component Technology, 2002
Modern-day software development shows a number of feedback loops between various phases in its life cycle; object-oriented software is particularly prone to this. Whereas descending through the different levels of abstraction is relatively straightforward and well supported by methods and tools, the synthesis of design information from an evolving implementation is far from obvious. This is why in many instances, analysis and design is used to initiate software development while evolution is directly applied to the implementation. Keeping design information synchronised is often reduced to a token activity, the first to be sacrificed in the face of time constraints. In this light, architectural styles are particularly difficult to enforce, since they can, by their very nature, be seen to crosscut an implementation. This contribution reports on a number of experiments that use logic meta-programming (LMP) to augment an implementation with enforceable design concerns, including architectural concerns. LMP is an instance of hybrid language symbiosis, merging a declarative (logic) meta-level language with a standard object-oriented base language. This approach can be used to codify design information as constraints or even as a process for code generation. LMP is an emerging technique, not yet quite out of the lab. However, it has already been shown to be very expressive: it incorporates mechanisms such as pre/post conditions and aspect-oriented programming. We found the promise held by LMP extremely attractive, hence this paper.
The Object-Oriented Paradigm for Software Evolution
In this research work object-oriented concepts are applied to a software maintenance method named COMFORM (COnfiguration Management FORmalization for Maintenance). COMFORM is composed of seveml phases to provide the necessary guidance to maintain existing software systems. One of the aims of the method is redocumentation by keeping the maintenance history and information related to the software modules being maintained. Redocumentation is obtained by filling in pre-defined forms which go hand in hand with the phases of the method. Each form is mapped by a class definition. The concepts of classes and inheritance are used along software maintenance to help the system manager in the creation and administration of such forms. Version control of the predefined forms is cam'ed out either by reusing common parts of these forms or b y defining new subclasses from them. As a consequence, a generic implementation of the method is achieved, thus maintenance support for a wide range of existing software systems with various profiles is accomplished.
A formal foundation for object-oriented software evolution
Software Maintenance, 2001. Proceedings. IEEE …, 2001
My PhD thesis claims that the principles behind object-oriented software evolution are independent of a particular domain or phase in the software lifecycle. To validate this claim, a formalism based on graphs and graph rewriting was developed and applied to a particular aspect of software evolution, namely the problem of software upgrading and software merging. When the same piece of software is modified in parallel by different software developers, unexpected inconsistencies can arise. Formal support can be provided to detect and resolve these inconsistencies in a general way.
An Environment to Observe Object-Oriented Software Evolution
2006
Software systems are growing quickly in needs of functionality, complexity, size and structure. Therefore, it becomes necessary to advance the ways where software suffers changes, so it can be modified more easily to accommodate these needs. However, anticipating the changes is not an easy task, once there are a lot of reasons why the systems change. The Laws of Software Evolution describe how a system behaves throughout their successive versions regarding its decaying. Most of the experimental studies supporting these Laws are regarding legacy systems' source code. However, we believe the Laws can also be observed when dealing with the other software development process phases. Therefore, we present a set of observational hypotheses to verify whether the Laws of Software Evolution can also be supported by the different phases of a object-oriented software development process, as well as the linkages and influences among the Laws of Software Evolution, so as to establish how the Laws impact each other. Thus, we intend to experimentally study these hypotheses in order to have a better understanding of how objectoriented systems can evolve.
2021
Software evolution is an essential challenge for all software engineers, typically addressed solely using code versioning systems and language-specific code analysis tools. Most versioning systems view the evolution of a system as a directed acyclic graph of steps, with independent branches that could be merged. What these systems fail to provide is the ability to ensure stable APIs or that each subsequent evolution represents a cohesive extension yielding a valid system. Modular software evolution ensures that APIs remain stable, which is achieved by ensuring that only additional methods, fields, and data types are added, while treating existing modules through blackbox interfaces. Even with these restrictions, it must be possible to add new variations, fields, and methods without extensive duplication of prior module code. In contrast to most literature, our focus is on ensuring modular software evolution using mainstream object-oriented programming languages, instead of resorting to novel language extensions. We present a novel CoCo design pattern that supports type-safe covariantly overridden convert methods to transform earlier data type instances into their newest evolutionary representation to access operations that had been added later. CoCo supports both binary methods and producer methods. We validate and contrast our approach using a well-known compiler construction case study that other researchers have also investigated for modular evolution. Our resulting implementation relies on less boilerplate code, is completely type-safe, and allows clients to use normal object-oriented calling conventions. We also compare CoCo with existing approaches to the Expression Problem. We conclude by discussing how CoCo could change the direction of currently proposed Java language extensions to support closed-world assumptions about data types, as borrowed from functional programming.
Understanding Phases and Styles of Object-Oriented Systems' Evolution
2004
Understanding the phases and styles of evolution of software systems can provide valuable insight in support of project management. In this paper, we present a method for studying the evolution of object-oriented software at system/subsystem level and analyzing the underlying factors that drive its unfolding over time. This method relies on analyzing the design-level structural changes between two subsequent software versions to identify additions, removals, moves, renamings and signaturechanges of classes, interfaces, and their methods and fields, represented as change trees. A sequence of such change trees constitutes the system's evolution profile. Based on discrete system evolution profiles, three types of analyses phasic analysis, gamma analysis, and optimal matching analysis are applied, to abstract an overall sequential pattern and structural properties of system evolution phases and to develop the typology of system evolution styles. We report on two case studies evaluating our approach.
European Conference on Object-Oriented Programming, 2021
Software evolution is an essential challenge for all software engineers, typically addressed solely using code versioning systems and language-specific code analysis tools. Most versioning systems view the evolution of a system as a directed acyclic graph of steps, with independent branches that could be merged. What these systems fail to provide is the ability to ensure stable APIs or that each subsequent evolution represents a cohesive extension yielding a valid system. Modular software evolution ensures that APIs remain stable, which is achieved by ensuring that only additional methods, fields, and data types are added, while treating existing modules through blackbox interfaces. Even with these restrictions, it must be possible to add new variations, fields, and methods without extensive duplication of prior module code. In contrast to most literature, our focus is on ensuring modular software evolution using mainstream object-oriented programming languages, instead of resorting to novel language extensions. We present a novel CoCo design pattern that supports type-safe covariantly overridden convert methods to transform earlier data type instances into their newest evolutionary representation to access operations that had been added later. CoCo supports both binary methods and producer methods. We validate and contrast our approach using a well-known compiler construction case study that other researchers have also investigated for modular evolution. Our resulting implementation relies on less boilerplate code, is completely type-safe, and allows clients to use normal object-oriented calling conventions. We also compare CoCo with existing approaches to the Expression Problem. We conclude by discussing how CoCo could change the direction of currently proposed Java language extensions to support closed-world assumptions about data types, as borrowed from functional programming.