Applying aspect-oriented programming to music computing

Computer programs for the composition, performance and analysis of music generally involve the tangled interaction of many dimensions of musical and extra-musical concern. In this paper we introduce the concepts of Aspect-Oriented Programming (AOP) to Music Computing and argue that AOP and related techniques and technologies form an appropriate solution to the separation and composition of such concerns. We motivate our argument with simple examples from the musical domain, but argue that the underlying principles may be applied to a wide and expressive range of musical application

Building Customizable Middleware using Aspect-Oriented Programming - Master\u27s Thesis, May 2002

In order to support a wide range of applications, Distributed Object Computing (DOC) middleware frameworks such as ACE and TAO have grown to include a vast number of features. For any one application, though, unused functionality either contributes to code bloat, degrades performance or both. When applied to embedded and realtime systems, these issues can preclude the use of middleware altogether. Currently, to address these concerns, middleware developers continually refactor code to relegate functionality to separate libraries. This process is tedious, time-consuming, and adds complexity for both users and developers. To address the difficulties of creating subsettable middleware, we have developed a novel method for constructing middleware using Aspect-Oriented Programming (AOP) and applied it to develop a realtime CORBA Event Channel called the Framework for Aspect Composition of an EvenT channel (FACET). FACET consists of a small, essential core that represents the basic structure and functionality of any event channel. By using aspects, additional features are woven not the core so that the resulting event channel supports all of the features needed by a given embedded application

Aspect-oriented modelling and analysis of information systems

In this paper we introduce an approach of aspect-oriented modelling and analysis of information systems. First we give an overview of the concepts of Aspect Oriented Programming and provide an outlook to model aspect-oriented programs. On the basis of this introduction, we describe a method of using aspects at the modelling level and weaving them into a single integrated model. Finally, we extend this framework with the automatic construction of analysis models based on separate aspect models. In our example, fault tolerance structures are modelled by aspects and the analysis model is a dependability model that is used to determine the non-functional properties of the system like reliability and availability. In this way the separate design of the functionality and the dependability is supported and the design decisions concerning fault tolerance can be analysed on the basis of the dependability model

Aspect oriented programming: Concepts, characteristics and implementation

Programming techniques have been passed through many development stages in their progressing path to cope with the increasing complexity of systems requirements. So, one of the main goals of the programming languages designers is how to develop programming language that can handle and manage the spread and overlapping of different functionality concerns. Because unmanageable and uncontrollable scattering of concerns inside the system may cause many problems during system running in present or/and during applying maintenance and developing the system in future. One of the most recent and powerful solutions to overcome these problems is via using Aspect-Oriented Programming (AOP) approach. This research is demonstrates the features and the problems with implying AOP techniques in the software development process

Experiences In Migrating An Industrial Application To Aspects

Aspect-Oriented Software Development (AOSD) is a paradigm aiming to solve problems of object-oriented programming (OOP). With normal OOP it’s often unlikely to accomplish fine system modularity due to crosscutting concerns being scattered and tangled throughout the system. AOSD resolves this problem by its capability to crosscut the regular code and as a consequence transfer the crosscutting concerns to a single model called aspect. This thesis describes an experiment on industrial application wherein the effectiveness of aspect-oriented techniques is explained in migration the OOP application into aspects. The experiment goals at first to identify the crosscutting concerns in source code of the industrial application and transform these concerns to a functionally equivalent aspect-oriented version. In addition to presenting experiences gained through the experiment, the thesis aims to provide practical guidance of aspect solutions in a real application

Aspect-oriented evolution of legacy information systems

Cataloged from PDF version of article.A legacy information system is an old system that typically has been developed several years ago, and remains in operation within an organization. Since the software requirements change, legacy systems must be evolved accordingly. Various approaches such as wrapping, migration and redevelopment have been proposed to maintain legacy information systems. Unfortunately, these approaches have not explicitly considered the concerns that are difficult to capture in single components, and tend to crosscut many components. Examples of such crosscutting concerns include distribution, synchronization, persistence, security, logging and real-time behavior. The crosscutting property of concerns seriously complicates the maintenance of legacy systems because the code of the system needs to be changed at multiple places, and conventional maintenance techniques fall short to do this effectively. Aspect-Oriented Software Development (AOSD) provides explicit mechanisms for coping with these crosscutting concerns. However, current AOSD approaches have primarily focused on coping with crosscutting concerns in software systems that are developed from scratch. Hereby, the crosscutting concerns are implemented as aspects at the beginning, hence localized in single modules. In this way the implementation and maintenance of crosscutting concerns can be prepared to a large extent so that the maintenance of these systems will be easier later on. Unfortunately, legacy systems impose harsher requirements, because crosscutting concerns in legacy systems are neither explicitly identified nor have been prepared before. We provide a systematic process for analyzing the impact of crosscutting concerns on legacy systems. The process, which is called Aspectual Legacy Analysis Process (ALAP), consists of three sub-processes, Feasibility Analysis, Aspectual Analysis and Maintenance Analysis. All the three sub-processes consist of a set of heuristic rules and the corresponding control. Feasibility Analysis, which consists of two phases, describes rules for categorizing legacy systems, in the first phase; and describes the rules for evaluating legacy systems with respect to the ability to implement static crosscutting and ability to implement dynamic crosscutting, in the second phase. The rules of the first phase are based on the categories of legacy systems that we have defined after a thorough study to legacy information systems, and the rules of the second phase are based on our discussion of these categories with respect to crosscutting implementation. Once the legacy system has been categorized and evaluated with respect to crosscutting implementation, the Aspectual Analysis sub-process describes rules for identifying and specifying aspects in legacy systems. Based on the results of the Feasibility Analysis and Aspectual Analysis sub-processes, the Maintenance Analysis describes the rules for the selection of the appropriate legacy maintenance approach. ALAP has been implemented in the Aspectual Legacy Analysis Tool (ALAT), which implements the rules of the three sub-processes and as such helps to support the legacy maintainer in analyzing the legacy system and identifying the appropriate maintenance approach.Satıroğlu, YaseminM.S

Generic Roles: Reducing Code Replication

In partial fulfillment of requirements for the degree of Doctor of Philosophy in Informatics Enginnering by the Doctoral Program in Informatics EngineeringFor many years the concept of modularity has been considered a very important part in the development of large software systems. Modules help to manage the system’s complexity by decomposing it in smaller parts. These parts can be assigned to individuals or teams for development. Modules hide the information they manipulate behind an interface, allowing its developers to develop the module independently of any other module in the system. Developers can change the information their module manipulates and even the way it does it without the need to consult other developers, and breaking their code. This enables the interchangeability of modules, allowing one module to be substituted by another without further modifications to the system. It also reduces compiling time as modules can be precompiled. The concept of modularization lead to the dawn of several decompositions techniques, each with its own ideas on how a system should be decomposed into modules. For each decomposition technique and to help programmers extract the most benefits from modularization, several programming languages provide support for expressing modules. In object-oriented decomposition, for example, several programming languages provide support to define abstract data types, usually in the form of classes. Ideally, each module would capture one coherent concept that would deal with a set of coherent concerns related to the module’s concept. Unfortunately that is not always true. Sometimes, modules need to interact in more complicated and intertwined manners. Sometimes, the need to communicate with other modules lead one module to assume concerns that are not related to its main concern. This is, as argued by many authors, because only a single decomposition strategy is used . To avoid this we may need to use more than one decompositions strategy or extend an existing one. Code clones are an outcome of the lack of other decomposition strategies, among others sources. Code cloning in a system is considered a bad thing with multiple drawbacks. One of the more known problems is the inconsistent maintenance: bugs are fixed in some clones, but not in others. Another major objection to the use of cloning is that it degrades the design of the system over time. Awkward, verbose designs lead to the accumulation of irrelevant code that ends up obscuring the original intent of the code. In this dissertation we study the reduction of the code replication using modularity as a cornerstone around which our solution must be based. We intend to reduce code replication using another kind of module, which we can use to extend the object-oriented strategy. The module that we will study is the role. Roles have been used to specify na object’s behavior related to a specific collaboration in the modeling stages of a system. But in the implementation that specification is merged with all the object’s other collaboration behaviors, inside a class. It is a purpose of this dissertation to take the specification from the design phase to the implementation phase and study its impact on the code replication problem. The solution proposed in this dissertation is to use roles as a way to compose classes and thus reducing code replication. To pursue this goal a role language is designed and a suitable compiler is implemented. The JavaStage language allows a programmer to “program with roles”. It introduces several features like a powerful renaming mechanism and to state role dependencies easily. Using JavaStage and roles we were able to identify several refactorings that enables us to write the replicated code as roles thus removing the code clone. The use of these refactorings proved their value when applied to a series of case studies developed to assess the amount of duplicated code that could be removed using roles. As already mentioned, the modularity principles were followed throughout the design of the proposed solution and, to assess the reusability of roles, a role library was started. Its evolution corroborates the idea that roles are reusable modules and can be used as a compositional element.A modularidade é, já há muitos anos, vista como uma peça importante no desenvolvimento de sistemas informáticos de grandes dimensões. Os módulos ajudam a gerir a complexidade do sistema decompondo-o em várias partes mais pequenas que podem ser adjudicadas a um indivíduo ou a uma equipa para desenvolvimento. Os módulos encapsulam a informação que manipulam e o modo como a manipulam, permitindo assim aos seus autores desenvolvêlo independentemente dos outros módulos do sistema. Os autores de um módulo podem, inclusivé, alterar o modo de representação da informação à medida das suas necessidades, ou até alterar o modo de a manipular, sem consultar os autores dos outros módulos e sem quebrar os módulos destes. Isto permite a permutação de módulos, podendo assim um módulo ser substituído por outro sem que o sistema sofra outras alterações. Também permite um tempo de compilação mais rápido devido a poder-se pré-compilar os vários módulos. O conceito de modularização levou ao surgimento de várias estratégias de decomposição, cada uma com as suas ideias sobre como um sistema deveria ser decomposto em módulos. Para cada uma destas estragégias, e para ajudar os programadores a usufruir ao máximo dos benefícios da modularização, surgiram várias linguagens de programação com suporte para a representação de módulos. Por exemplo, na decomposição orientada a objetos, muitas linguagens permitem a definição de tipos abstratos de dados, normalmente na forma de classes. Idealmente, cada módulo capturaria um conceito coerente e esse conceito lidaria com um conjunto coerente de responsabilidades ligadas ao conceito principal do módulo. Infelizmente, não é assim. Por vezes os módulos precisam de interagir de forma mais complexa e interligada com outros módulos. Outras vezes a necessidade de comunicar com outros módulos leva-os a assumir responsabilidades que não estão de acordo com a sua “razão de ser”. Isto, como é argumentado por muitos autores, é uma consequência do uso de uma única estratégia de decomposição. Para evitar isto provavelmente necessita-se de uma outra forma de decomposição ou expandir uma já existente. O aparecimento de clones no código é uma consequência do uso de uma única estratégia de decomposição, entre outras causas. A presença de código repetido num sistema é considerada um mau indício e acarta muitas consequências nefastas. Um dos problemas mais conhecidos é a inconsistência na manutenção: os bugs são reparados em algumas instâncias do código repetido mas não em todas. Outro grande problema do uso de cópias de código é que o seu uso irá degradar o design do sistema a longo prazo. Isto leva à acumulação de código irrelevante que acaba por obscurecer o objectivo inicial do código. Nesta tese tenta-se estudar a redução de código repetido usando a modularidade como “pedra de toque” em torno da qual a nossa solução se baseará. Tencionámos reduzir a repetição de código usando outro tipo de módulo, que nos permita expandir a decomposição orientada a objetos. O módulo que iremos estudar será o role. Os roles têm vindo a ser usados para especificar o comportamento de um objeto em relação a outro objeto, dentro de uma colaboração, na etapa de modelação do sistema. Mas, na fase de implementação, essa especificação é agrupada com todos os comportamentos que o objeto exibe em todas as suas colaborações, dentro de uma classe. É um dos propósitos desta tese levar esta especificação desde a fase de modelação até à fase de implementação e estudar o seu impacto no problema de repetição de código. A solução proposta nesta dissertação é usar os roles como uma maneira de compor classes e assim reduzir a repetição de código. Para atingir este objectivo uma linguagem de programação que suporta roles será idealizada e um compilador adequado desenvolvido. A linguagem JavaStage permite a um programador “programar com roles”. Ela introduz algumas funcionalidades como um mecanismo de renomeação de métodos poderoso e uma forma de exprimir as dependências do role facilmente. Usando a JavaStage e os roles fomos capazes de identificar várias refactorings que nos permitem expressar o código presente nas várias repetições como roles e assim remover o código repetido associado. Estas refactorings mostraram o seu valor quando usadas numa série de casos de estudo que foram desenvolvidos com o propósito de avaliar a quantidade de código repetido que se poderia remover usando roles. Como já foi mencionado os princípios da modularidade foram seguidos ao longo da concepção da solução proposta e para avaliar a reutilização dos roles a construção de uma biblioteca de roles foi iniciada. A sua evolução corrobora a ideia de que os roles são módulos reutilizáveis e podem ser usados como um elemento composicional de classes