Oren E. Livne, N. Dustin Schultz, Scott P. Narus et al. · 2011
Abstract We present a software architecture that federates data from multiple heterogeneous health informatics data sources owned by multiple organizations. The architecture builds upon state-of-the-art open-source Java and XML frameworks in innovative ways. It consists of (a) federated query engine, which manages federated queries and result set aggregation via a patient identification service; and (b) data source facades, which translate the physical data models into a common model on-the-fly and handle large result set streaming. System modules are connected via reusable Apache Camel integration routes and deployed to an OSGi enterprise service bus. We present an application of our architecture that allows users to construct queries via the i2b2 web front-end, and federates patient data from the University of Utah Enterprise Data Warehouse and the Utah Population database. Our system can be easily adopted, extended and integrated with existing SOA Healthcare and HL7 frameworks such as i2b2 and caGrid.
Cited by 0
Paul Wiley, Tzilla Elrad, Robert E. Filman et al. · 2001
Computer science has experienced an evolution in program-ming languages and systems from the crude assembly and machine codes of the earliest computers through concepts such as formula translation, procedural programming, struc-tured programming, functional programming, logic pro-gramming, and programming with abstract data types. Each of these steps in programming technology has advanced our ability to achieve clear separation of con-cerns at the source code level.
Cited by 0
Kevin Hoffman, Patrick Eugster · Science of Computer Programming · 2009
Cited by 14
2008
technology that promises to improve productivity and product quality in software development projects. Architecture stratification combines the strengths of component-based frameworks and model-driven architectures to
Cited by 0
Rena Wigastari · 2008
Cited by 0
Shixian Li · 2011
Today a lot of people not only from industrial community but also from academic community simply take Aspect-Oriented Programming(AOP) as modularizing crosscutting concerns and in a narrow-mined way to believe that AOP is just an extension or an effective supplement to Object-Oriented Programming(OOP).Based on the definition of AOP,its nature which makes it different from the other programming languages was dug out.And the quantified statement and aspect in the definition were formalized.Moreover the semantics of them were defined.And then we argued quantification and obliviousness in the definition are the real nature of AOP.Modularizing crosscutting concerns is just a benefit from it.And AOP is a new programming paradigm which is independent of all the other programming languages.Based on the definition,the minimum condition set which Aspect-Oriented Programming Languages(AOPL) need to satisfy was proposed.And the difference between the mainstream AOPL from the view of the definition was probed into.
Cited by 0
Frank Sauer · 2015
This paper describes Frame Oriented Programming (FOP) and shows that this programming technique unifies the Object Oriented concept of classes and the Aspect Oriented Programming (AOP) concept of aspects into a single coherent concept called a Frame. The unification is embodied in the adapt relationship between frames that allows frames to reuse and modify other frames in ways that unify the generalization and aggregation relations of Object Oriented Programming (OOP) and at the same time allows for the injection of crosscutting concerns into at “breakpoints ” of arbitrary granularity. 2. FRAME HIERARCHIES A frame hierarchy defines how frames are combined to make other frames. Frame hierarchies can be thought of as a parts-explosion diagram. A higher-level frame is an assembly of its lower level frames and the arrows in a frame hierarchy diagram can therefore be labeled as ‘part-of’. shows an example frame hierarchy. In this frame hierarchy the top-level frame (or specification frame) a has two subassemblies, b and c. The b and c frames themselves can be considered specification frames for their respective sub-hierarchies. Frame e is part of both b and c; however, b and c receive separate copies of frame e in the assembly process. The reverse of the part-of relationship between frames is far more interesting and forms the basis for the rest of the ideas set forth by FOP. When frames b and c are part of frame a, frame a is said to ‘adapt ’ frames b and c.
Cited by 0
Donal Lafferty, Vinny Cahill · 2003
The term aspect-oriented programming (AOP) has come to describe the set of programming mechanisms developed specifically to express crosscutting concerns. Since crosscutting concerns cannot be properly modularized within object-oriented programming, they are expressed as aspects and are composed, or woven, with traditionally encapsulated functionality referred to as components.Many AOP models exist, but their implementations are typically coupled with a single language. To allow weaving of existing components with aspects written in the language of choice, AOP requires a language-independent tool.
Cited by 2
Noury Bouraqadi, Abdelhak-Djamel Seriai, G. Leblanc · HAL (Le Centre pour la Communication Scientifique Directe) · 2005
Cited by 0
Gregory T. Sullivan · 2001
What infrastructure is needed to support aspect-oriented software development? To the programmer, we must supply aspect-oriented (sub)languages that are based on the constructs and basic syntax that the programmer is most familiar with, as well as facilities for reifying and manipulating the cross-cutting features of immediate concern. At the implementation level, the aspect specifications mu' insinuin themselves into the application proper. Furthermore, the support for aspect specification and integration should not impose a performance penalty on the application at r u time. We are conducting research into dynamic reflective object-oriented language design and implementation that provides a rich infrastructure for the development of aspect-oriented technology. The main concepts that we bring to bear are: Reflection and Dynamism: A program is able to reflect on its structure and behavior, and then modify its behavior. metaobject protocols rely on reflection to present a programmer-modifiable dynamic semantics. Syntactic abstraction: A procedu al, hygienic macro system facilitates implementation of AOP langu age extensions; Dynamic, Optimistic Optimization: Programs do not pay a performance penalty merely for the existence of a metaobject protocol. That is, if part of an application does not makeu se of the abstraction provided by a metaobject protocol, performance is as good as if the metaobject protocol did not exist.
Cited by 0
Robert Hirschfeld · 2007
Aspects is an approach to general-purpose aspect-oriented programming in the Squeak/Smalltalk environment. Based on concepts of AspectJ it extends the Smalltalk metaobject protocol to accommodate the aspect modularity mechanism. In contrast to systems like AspectJ, weaving and unweaving in Aspects happens dynamically at rantime, on-demand, employing metaobject composition. Instead of introducing new language constructs, Aspects utilizes the expressiveness of Smalltalk itself as a pointcut language.
Cited by 0
Andy Clement · 2003
Cited by 0
Karl J. Lieberherr · 2007
The objective of the Demeter method and tools is to improve the productivity of software developers by an order of magnitude. We hope to achieve this through a methodology and tools supported by a theory of adaptive and aspect-oriented programming. To make our results practically useful, we want to leverage existing commercial technology such as Java, the Unified Modeling Language (UML [GRB97]) and design patterns. Our recent work has focused on rethinking our Demeter/C++ tools and the corresponding theory and to implement the new results in Demeter/Java. Demeter/Java is an implementation of Adaptive Programming (AP) for Java. Demeter/Java programs consist of Java code together with programs in a small language to express traversals, visitor methods, and class diagrams. Demeter/Java also includes the coordination aspect Cool and the remote invocation aspect Ridl. Demeter/Java programs are typically written in a preventive maintenance style using traversal strategies for expressing object navigation. The resulting programs are very robust under changes to the class diagrams and visitors. This preventive maintenance style also leads to simpler programs, making both software development and maintenance easier.
Cited by 0
Leonardo Cole, Paulo Borba, Alexandre Mota · 2005
The proof of the behaviour-preserving property of programming laws is not trivially demonstrated. It is necessary to show that the programs, before and after the transformation, have the same behaviour. In this paper we show how it is possible to prove that an aspect-oriented programming law preserves behaviour; an operational semantics for Method Call Interception is used. An equivalence relation stating that two programs have the same behaviour is defined. We use these concepts and discuss soundness for the law Add-Before Execution.
Cited by 7
Donal Lafferty, Vinny Cahill · ACM SIGPLAN Notices · 2003
The term aspect-oriented programming (AOP) has come to describe the set of programming mechanisms developed specifically to express crosscutting concerns. Since crosscutting concerns cannot be properly modularized within object-oriented programming, they are expressed as aspects and are composed, or woven, with traditionally encapsulated functionality referred to as components.Many AOP models exist, but their implementations are typically coupled with a single language. To allow weaving of existing components with aspects written in the language of choice, AOP requires a language-independent tool.
Cited by 7
Kris De Voider · Lecture notes in computer science · 1998
Cited by 15
Daniela Gotseva, Mario Pavlov · 2012
This article describes the fundamental concepts of a complete AOP system. It discusses the AspectJ language specification and implementation. The article examines the use of the language, as well as its features and tooling support. It lays out a common crosscutting problem to illustrate the general syntax of the traditional AspectJ Language. The development tools of the AspectJ language are described and compared to popular Java development tools.
Cited by 3
Michiel Pouw · 2008
Cited by 0
Jorrit N. Herder · 2002
Software systems can have properties which affect multiple components. Examples of such concerns include debugging and synchronization policies. These cross-cutting concerns are called aspects. Aspects lead to complex systems that are difficult to develop and hard to maintain. The goal of aspect-oriented programming is to support the programmer to separate components and aspects from each other. This paper presents a conceptual framework for aspect-oriented programming and demonstrates this with a code example in AspectJ, a general-purpose aspect-oriented extension to Java. 1
Cited by 0
Iuliana Cosmina · Apress eBooks · 2019
AOP is the acronym for aspect-oriented programming, which refers to a type of programming that aims to increase modularity by allowing the separation of cross-cutting concerns. A cross-cutting concern is a functionality that is tangled with business code, which usually cannot be separated from the business logic. Auditing, security, and transaction management are good examples of cross-cutting concerns. They are mingled with the business code and heavily coupled with functionalities that might be affected if they fail. They are good candidates for separation using aspects, because there is no design pattern that allows writing code in such a way that it is separated from the business logic. This means that additional behavior is added to existing behavior when the application is compiled.
Cited by 3